SoRとSoEを柔軟に連携する方策
メインフレームを中心に設計・実装されている、いわゆるバックエンドのシステム環境では、スピードや柔軟性よりも信頼性、安定性、継続性が要件として重視される傾向がある。一方、スマホの普及やIoT技術の浸透を背景に、エンドユーザーのニーズに応じたサービスを短いライフサイクルで実現していく領域が、売上増に直結するIT投資の対象として急成長している。
前者はSoR（Systems of Records）、後者はSoE（Systems of Engagement）と分類されるが、調査会社ガートナーはこれら2つの共存を「バイモーダルIT」と呼んでいる。システム全体の価値を高めるには、2つをそれぞれ独立したものとして捉えるのではなく、両者の連携が重要ということである。
このことは、ミッションクリティカルな基幹システム用インフラの要件として「オープン性」「システム間連携の容易さ」「クラウドとの親和性」「AIなどの新技術との親和性」が「信頼性／可用性」に次いで重視されているという調査結果＊1からも伺い知れる。
このSoRとSoEを柔軟に連携する方策として「API」への期待が高まっている。本稿では、メインフレーム資産をAPI化するときの中核のコンポーネントになり得る「z/OS Connect Enterprise Edition」（以下、z/OS Connect）を紹介する。
「API」という用語の最近の意味合い
最初に「API」という用語について補足しておきたい。API自体は新しい考え方ではなく、古くからミドルウェアや共通パッケージなどで利用されてきたものである。メインフレームに長年携わってきた技術者にとっては「今さら当たり前のことを……」という思いがあるだろうが、昨今の「APIエコノミー」などの文脈で使われるAPIは、若干、意味合いが異なる場合がある。
APIは「Application Programming Interface」の略で、アプリケーション・プログラムが当該サービスを利用するときの作法を示すものである。たとえば、「入力値としてxとyを設定してAという関数を呼び出すと、zという値が返ってくる」というような決まりごとを指す。これはプログラムからあるサービスを利用する場合に知っておくべき情報であり、最低限その情報だけを知っていればサービスが利用できる（実装部分がある程度隠蔽される）という側面もある。
これに対してUI（User Interface）は、ユーザー（＝人）がサービスを利用するときの作法である。たとえば、「ブラウザで画面を開き必要項目をキーボードから入力してボタンをマウスでクリックすると、欲しい結果が画面に表示される」といった具合である。インターフェースとは「境界面」でしかなく、その実態は切り離して捉えるべきである（図表1）。Javaの「Interface」とその実装である「Implementation」との関係と言えば、イメージしやすいかもしれない。
これが従来のAPIについての共通理解だろう。しかし最近のAPIには、これに「標準的なアクセス方法」という条件が暗黙的に付随している。そしてさらに言えば、HTTPベースの通信プロトコルである「REST」とデータフォーマット形式である「JSON」が、APIの条件として見なされている。
RESTと対比される通信プロトコルには「SOAP／XML」がある。XMLは要素だけでなく属性も指定でき、SOAPではトランザクション管理をサポートするWS-AT（プロトコル）が規定されているように、要件や管理の厳しいエンタープライズ・システム向けに有効な仕組みが数多く提供されている。しかし、この多様な仕組みが逆に複雑さの理由となっている感があり、よりシンプルで手軽なREST／JSONが急速に浸透しつつあるのが実情である。
APIとは、前述のとおり、境界面の「作法」であり「実体」とは別との理解が従来からあるが、実体であるサービスそのものを含めてAPIと呼ぶ場合がある。
たとえば、「APIを作成する」「APIを実行する」と言うときは、単に「作法としてのインターフェースを定義する」あるいは「API経由でサービスの呼出しを行う」ということではなく、「標準的なAPIをもつサービスそのものを作成する／実行する」という意味合いで使われることがある。
とくにSoEの世界では、既存のサービスありきでそのAPIを標準化する（いわゆる「ボトムアップ・アプローチ」）のではなく、サービスそのものも新規に作成しそれを標準APIでアクセスできるようにする（「トップダウン・アプローチ」）ことが多いので、そのような曖昧な用語の使い方がされるようである。前後の文脈によってAPIが指す範囲を柔軟に考えないと混乱の元になる場合があるので注意したい。
メインフレーム資産のAPI化
メインフレーム上には長年にわたって使われている実績のある資産が数多く存在している。資産というのは、顧客に関するデータやそれにアクセスして処理を行うアプリケーション・プログラム（≒サービス）を指す。これらの資産はz/OS固有の作法やミドルウェア固有の作法によって作られており、標準的なAPI（REST／JSON）を意識していない。
メインフレーム固有の環境とオープンな環境との違いとしては、以下が挙げられる。
①レコードベースのデータフォーマット
メインフレームのアプリケーションでは、COBOL、PL／I、アセンブラなどの言語が使われることが多く、これらのアプリケーションでは、オフセットと長さによってフィールドの属性が決められるレコードベースのフォーマットでデータが扱われる。
1バイト目から10バイト目までは文字列のデータが入り、11バイト目から14バイト目に数値型のデータが入る、というようなイメージである。また、データのフォーマット情報は、COBOLならば「COPY BOOK」としてデータとは別に保持するが、JSON形式では「”項目名”:”値”」のように、やりとりされるデータそのものにデータ構造やフィールドの意味が含まれる。
②アクセス方法がz/OSやミドルウェアに依存
メインフレーム環境では想定されているインターフェースが3270端末エミュレータやシステム内のクライアントであることが多く、z/OSやミドルウェア固有の作法によるアクセスが前提となっている。
ざっくり言えば、メインフレーム上の資産をAPI化するというのは、これらのメインフレーム資産の特異性を隠蔽してオープンな環境からアクセスできるようにすること、と捉えることができる。つまり、データフォーマットの変換（JSON←→レコードベース）、およびプロトコル変換（REST←→メインフレーム固有プロトコル）を行うことがAPI化の主な要素である（図表2）。
また、メインフレームの特異な項目として文字コードが挙げられるが（メインフレームは EBCDIC、オープンな環境はUnicode）、この文字コード変換についてもデータフォーマット変換に含めて考慮が必要になる。
RESTfulサービス
API化とは、標準的な方法（REST／JSON）でアクセス可能にすることと述べたが、それだけでは不十分なケースもある。たとえば、HTTPのプロトコルでアクセスするサービスでも、HTTPのPOSTメソッドを使い、URIでサービス内容を表すという構造の場合がある。これは「RPC形式のサービス」と呼ぶことができる（図表3）。
一方で、サービスの操作をHTTPメソッドで区別し、URIは操作対象のリソースを示すという形式の構造をもつサービスを「RESTfulサービス」と呼ぶ（図表4）。
API公開をしたい既存のサービスが、これらHTTPメソッドに完全に合致しない場合もあるが、HTTPメソッドで操作の区別を行い、URIでは操作対象のリソースを指し示す、というのがRESTの作法に近い標準的なAPIの設計である。
z/OS Connectの
アーキテクチャと主要構成要素
ここまで、メインフレーム資産のAPI化について述べてきたが、まさにそのデータフォーマット変換、プロトコル変換、RESTfulサービスとしてAPI公開などをサポートする製品として「z/OS Connect」が提供されている。
これまでも、z/OS上の各種ミドルウェア（CICS, IMS, MQなど）が標準的な方法によるアクセス機能を個別に提供してきているが、z/OS Connectはミドルウェア共通の仕組みで、かつGUIベースのAPI作成支援機能なども提供している。z/OS Connectが担う役割を図表5に示す。
z/OS Connect経由でアクセスできる資産としては、CICSプログラム（COMMAREA／Channelベース）、IMSトランザクション、MQのキュー、DB2のテーブル、バッチプログラム、などが挙げられる。z/OS Connectを介することで、これらの資産に対してバックエンドの仕組みや実装を意識することなく、リクエスタがREST／JSONでサービスを利用することが可能となる。
z/OS Connectは先に示したようにデータフォーマット変換、プロトコル変換を主な役割としているが、それを行うためには、その変換を行うための情報を事前に整備しておく必要がある。先の図表5は、主にランタイムとしてのz/OS Connectの役割を示したものであるが、そのほかにもAPI公開に関連する操作を支援するツール類なども提供している。図表6に、z/OS Connectの全体像を示す。
z/OS Connectの主要構成要素は以下のとおりである（A・B・Cは図表6のA・B・Cに対応）。
（A）z/OS Connectランタイム：実体は、Liberty for z/OS
・RESTfulのAPIと既存サービスのインターフェースのマッピングを行う（データフォーマット変換&プロトコル変換）
（B）API toolkit：GUIベースの開発支援ツール
・既存サービスのRESTful API化を支援するEclipseツール（PC上で稼働）
（C）Swagger文書：API記述（API toolkitにより生成される）
・公開するAPIの管理／リクエスター側のテストなどに利用可
API公開に向けては、次のようなステップを踏む。
①公開対象サービスの入出力インターフェースの明確化
・既存サービスの構造や特性を分析し、必要に応じてアプリケーションの改修を行う
・既存インターフェースとして公開対象サービスの入出力データ構造を明確化する（COBOL COPYBOOKで表されるイメージ）
②新規RESTful APIの設計と、既存インターフェースとのマッピング
①は使用しているミドルウェアやアプリケーションに応じて適宜実施する必要があるが、②はz/OS Connect提供の「API toolkit」と呼ばれるEclipseベースのツールで、GUIベースの操作が可能になっている。図表7にRESTfulインターフェースを定義し、既存インターフェースとのマッピングをGUIで行っている画面例の一部を示す。
このようなEclipseベースのツールを使用して新規APIを定義して既存インターフェースとのマッピングを行うと、Swagger文書が自動的に作成される。
SwaggerとはAPIを記述するための標準仕様であり、仕様に従った形式でAPIの定義が生成される。標準的なAPIでアクセスでき、さらに、そのAPI記述も標準的なドキュメントで生成されるのは大きな意味をもつ。Swagger文書があることで、そこに記載されているAPIを簡単にテストしたり、リクエスタとなるコードの雛形を自動生成したり、API管理の仕組みと連携しやすくするなど、z/OS Connect以外でもこの標準に準拠した各種ツールを利用することができるようになっている。
本稿では、z/OS Connectを中心にメインフレーム資産のAPI化について紹介した。z/OS Connectは、z/OS上の他のミドルウェアと比べると発展途上の製品であるが、API連携は大きな注目を集めている分野でもあり、今後のさらなる機能拡張が期待される。
＊1：「2018年 国内企業のエンタープライズインフラのシステムタイプ別支出トレンド分析」 http://bit.ly/is21_idc
著者｜田口智大氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシーセンター
ミドルウェア・テクノロジー
シニアITスペシャリスト
1998年入社。以来、CICS関連製品（TXSeries, CTG, CICS TS）やメインフレームのモダナイゼーションに関する技術支援に携わる。
［IS magazine No.21（2018年10月）掲載］
