【連載】SOA時代のCOBOL資産活用術

• 前回の記事はこちら

前回までの連載（第1回、第2回）でCOBOLとJavaとの連携が少し身近なものになったと思います。今回は、実際にプロジェクトを始めるに当たり、検討が必要な事項および将来の発展性についてお話します。

プロジェクトを開始するに当たっては、当然のことながらCOBOLもJavaもスキルを持った人が必要になります。ところが、両方のスキルを十分併せ持つ人は、非常に少ないのが現実だと思います。ここは、おそらくスタイルの違う技術者同志がうまく連携するしかありません。全体的な要件から実装に落としていく段階では、双方の見地から実現可能性や必要なワークロード等を確認することが必要になります。“呼ぶ側のJava”“呼ばれる側のCOBOL”と立場は違っても全体の動作に責任を持っていることに違いはありません。では、何から始めるのが良いのでしょうか？幾つかのキーとなる項目があります。

ミッション・クリティカルなシステムでは、データの整合性を強く要求されます。一般的には更新を伴うデータベースの処理において業務としての“つじつま”を合わせることが必要になります。場合によって複数のリソース間での整合性を保つために2フェーズコミットを使用する必要がでてきます。開発する業務アプリケーションが2フェーズコミットを必要とするかどうかは、重要なポイントの一つです。このトランザクション処理の有無は、Java側のクライアントの形態にも影響を与えます。この判断は、業務全体を考えJava側およびCOBOL側双方で使用するリソースを見据えて下す必要性があります。場合によっては異なる言語でアクセスされる別のリソースが同じトランザクション・スコープで動くことになるわけです[図1]。このように重要な決定においては双方の技術者の密接な協力が必須です。プログラム的には分離していても双方が全体を考える共同作業になるわけです。また、Java側で呼び出したいモジュールの単位とCOBOL側で準備しているインターフェースにズレがあるかもしれません。この場合、どちらが違いを吸収するのかを決めなくてはなりません。これらの過程においては、双方の進め方の違いでのカルチャーショックがあるかも知れませんがそれを乗り越えないと成功はありません。

図1　トランザクション・スコープ

業務的な要件の検討が十分終わった後に使用する連携テクノロジーを決定することになります。この辺りから、徐々にJava技術者の活躍する局面になってきます。前回までの復習になりますが、もう一度連携方法について確認します。COBOLサーバーとの連携には、主に2つの方法があります。一つは、JCAアダプターに連携、もう一つがWebサービスによる連携です。先程のトランザクションのこともあり、一番適用範囲が広いのはJCAアダプターを使用する方法でしょう。後は、Java側のプログラム開発にどんなテクノロジーを使用するかを決めることになります。JCAアダプター経由でリソースをアクセスするにはCCI（Common Client Interface）を使用したコーディングが必要ですが、トランザクションを考えるのであればEJBを使用するのがスマートな方法でしょう。前回の連載にあったようにCOBOL側の開発環境がクライアントとなるEJB jarを生成してくれるのです。これをそのまま使用する形でよければ、かなり工数を減らすことができます。もし、CCIを直接コールするコーディングを自分で行うとしても一度行ってしまえば、後は同じ手法の繰りかえしですのでそれほどの労力は要らないはずです。

もしCOBOLシステムで提供されるサービスが多くの人にとって価値のある単位で提供される場合、Webサービスを利用したサービス提供も検討する価値があります。この場合、“多くの人にとって価値のある”という点がキーになります。簡単に言うと“多くの人が使いたくなるサービス”であるかということです。あまりに細かい業務ロジックをWebサービスで提供されても利用者はどう使えばいいのかが判りません。この問題は、よくサービスの“粒度”と表現されます。この検討を踏まえた上でさらに“価値あり”と思える場合は、Webサービスのインターフェースを公開すれば、利用者が非常に簡単にCOBOLシステムの恩恵を受けることが可能になります。この簡単なアクセスに貢献しているのが、COBOL開発ツールが生成するWSDLになります。このWSDLにCOBOLプログラムにアクセスするのに必要な情報が記載されています。[図2]

図2 WSDLの例

このWSDLさえ入手できればサービスの利用者は簡単にアクセスクライアントを生成することができるわけです。しかも、特別なアダプターやドライバーは必要ありません。また、このWebサービスの提供の準備ができれば、ESB（Enterprise Service Bus）に接続するという展開も視野に入ってきます。そうなるとESBに接続されたあらゆるアプリケーションがESBの仲介機能を利用しつつCOBOLサービスにアクセスするという形態に代わります。ESBが介在することでルーティングやフォーマット変換、ロギングなど新たな機能が加わり、全社的なSOAの枠組みの中でCOBOLサービスが位置づけられることになります。“簡単”なWebサービスの向こうにはこのような可能性があります。[図3]

図3 ESB接続

前回の連載でも触れられておりましたが、COBOLの開発には、洗練された開発環境が用意されています。これに対してJava側がエディターというのは寂しい気がします。開発する対象がEJBのように複雑な構造を持っている場合には特に開発ツールの支援が必要になります。もちろん、アノテーションのような簡単にEJBを生成してくれる仕組みも考えられてはいますが、優れたツールは今すぐに生産性の向上をもたらしてくれます。これはWebサービスに関しても同様です。開発ツールは、WSDLを読み取ってそこからアクセス用のクライアントを生成する機能も持っています。エディターとコマンド・ベースで進めるよりは遥かに効率良く安全な方法です。また、ツールの品質に対する貢献も重要な要素です。開発ツールのテスト環境を利用した繰り返しテストにより、品質の高いコードをリリースすることが可能になります。ミッション・クリティカルなJ2EE+COBOLシステムでは、是非、適切な開発ツールの検討をお勧めします。

これまでの連載でCOBOLとJ2EEの連携の可能性について少しでも興味を持っていただけたら幸いです。
ここまでお読み頂きました読者の方に感謝致します。

前回へ