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

軽量コンテナでの開発手法、O/Rマッピング・フレームワーク、・・・etc。最新のスキルを身に付け臨んだ開発プロジェクトにて突きつけられた最重要課題は、『既存のCOBOL資産の活用』だった。笑えないこの現実は、現在のJava開発者の置かれている立場を象徴しています。JavaそしてJ2EEを利用したシステムは、ついにWebの壁を破って基幹システムの中心に位置付けられようとしています。掘り進んだトンネルの向こうに待っていたのは、企業システムの“コア”を担って来たCOBOLだったというわけです。では、このCOBOLの岩盤にぶつかった時にはどのような対処ができるのでしょう？慌てる前に知っておくべきことがあります。

Javaに比較するとCOBOLは当然古い言語です。実は、筆者も少し前までは「もう過去のもの」などとタカをくくっていました。ところが色々と調べていくとどうも現実は違うのです。Java技術者として仕事をする限りは、他言語に触れる機会があるとしてもCやVisual BasicといったPC、UNIX系の言語、あるいはPerlやPHPといったWeb開発に主に用いられるものが多いと思います。ところがJava技術者が知らないところで今もCOBOLを利用した新規開発は活発に行われているのが実態なのです。知らないのはJava技術者のみといったところでしょうか。　しかもCOBOL言語自身そしてその実行環境も今も変わり続けていたのです。

COBOLを目の前にすると、そんな元気な声も聞こえてきます。Javaも汎用的な言語で豊富なClassと華麗な言語仕様を備えています。従って当然、それもアリです。決してできない話ではありません。スキルのあるJava技術者と最新の開発環境で臨めばきっと可能でしょう。でもそこには、考えなくてはならないことがあります。工数？テスト？品質？これは当然。スケジュール、そう納期。これも心配です。でも本当はもっと大きな乗り越えなくてはいけない問題があるような気がします。それは、人の問題ではないでしょうか？企業の基幹を支えてきたCOBOLプログラムの中に含まれているCOBOLのロジック、実はこれが企業の資産そのものです。そこには、長い時間を掛けて磨かれたノウハウが埋め込まれています。そしてそのノウハウ自身は現場のCOBOL技術者とともに存在していることが多いはずです。技術的にソースコードを移植可能というだけでは対応が難しい課題があります。単に『書き換えてしまえ！』だけではJavaの旗を持ったドン・キホーテになる可能性ありです。

少し冷静になって、周りを見回してみるとSOA（サービス指向アーキテクチャー）の時代が始まっています。そしてSOAの重要な考え方の一つが“既存システムの有効活用”です。COBOLシステムは、まさに既存システム。ここは少し上位の視点に立ってCOBOLシステムが現在実施していることを“サービス”として捉えてみてはどうでしょう？このサービスは既に実証済みで、当然、品質も高いのです。うまく利用できさえすれば、高品質なシステムを短い期間、少ないコストで開発できそうです。大きな時代の流れを考えてもどうやら“Java化”だけが方法では無い様です。では、COBOLプログラムを“Java化”する以外の道を選択するとした場合、どのような方法があるのでしょうか？

多くのJava技術者にとっておそらく（じっくりと？）見たこともないCOBOLプログラム。アクセスするといってもいったいどうすれば良いのでしょう？　最初に思いつくのはおそらくJNI（Java Native Interface）を使用してNativeコードをアクセスする方法でしょう。ただ、J2EEコンテナの中でのJNIの使用はできれば避けたいことの一つです。それにそもそもコンパイルされたCOBOLのオブジェクトをどうやってJNIで呼ぶの？という疑問もあります（注1）。また、メッセージングのインフラに詳しい方でしたら既存のリソースと通信するならこれが一番だと考えられるかも知れません。これはCOBOLプログラムにメッセージングに対する“口”を設けることで実現できます。このメッセージングによる方法では基本的に非同期のプログラミングモデルを採用することになります。メッセージングではトランザクション・スコープについて配慮する必要があります。　あるいは、現在のホストシステムでTP Monitorを使用して起動されているCOBOLプログラムであれば、TP Monitorに対するJavaのインターフェースを利用してCOBOLプログラムをキックするという従来通りの方法も適用可能です（注2.）。分散系のUNIXサーバーでTP Monitorを動かすことも可能です。
色々と方法はありそうですが、J2EEサーバーでは、最初に考えなければいけないことがあります。それは、外部リソースに対しても“J2EE標準”の範囲でアクセスすることが一番望ましいということです。

注1. Micro Focus社からはJavaプロセスからCOBOLを直接呼び出すライブラリーが提供されています。
注2. JCAアダプターを提供している製品もあります。　例. CICS Transaction Gateway V6.0

ご存知のようにJ2EEサーバーから外部のリソースにアクセスするには、J2EE、あるいはJ2SEにて定義されているAPIがあります。データベースならば、JDBC。メッセージングなら、JMSです。より汎用的な標準としては、JCAがあります。JCAは、幅広いリソースに対しての標準的なアクセス方法を提供するもので既に多数の外部リソースがこのJCAでのアクセスが可能になっています。JCA自身は、クライアントからのアクセスAPIと共に外部リソースとJ2EEアプリケーション・サーバーとの間の“約束事”（コントラクト）も定めています。この“約束事”に従っていれば、J2EEアプリケーション・サーバーにベンダーがアダプターを組み込むことが可能になっているわけです。このJCAがJavaとCOBOLとの橋渡しをしてくれる最も有力な候補になります。JCAによる接続は外部リソースに対してトランザクションを伝播することもできます。このJCAによる連携方法は、おそらく“普通”のJavaプログラマーには最も理解しやすい方法です。図1にJCAを使用して書かれたソースコードを記載しました。これを見る限りアクセスしている相手がCOBOLかどうかの判別すら難しいのがお判りになると思います。つまり、J2EEプログラマーは相手の実装を意識することなくメソッドを呼び出すだけでいいということになります。この『相手の実装を意識することなく』のくだりで、思い出すのが“Webサービス”です。このWebサービスは、J2EE1.4からはもう立派なJ2EE標準の仲間です。これはまさにサービスを呼び出すための標準ですのでこれも外せません。もしWebサービスが使えるとCOBOLの姿は本当に全く見えなくなります。どこか遠い所で処理された結果がSOAPに乗って戻ってくる。そんな印象かもしれません。いわゆる疎結合です。トランザクション処理ができない（注3）など制約はありますが、“スマート”であることは間違いありません。
JCA, Webサービス。もし、ここまでの環境が整うと確かに後は簡単そうです。ただ、読者の皆様の中には「ちょっと待てよ・・・」と思われている方もいらっしゃるかも知れません。そう、ここに至るには、幾つか乗り越えなくては行けないことがあるはずです。

拡大図

図1
注3. Webサービスでのトランザクション処理への対応も始まっています。WebSphere Application Server V6では、WS-Transactionが使用可能になっています。

言語には、“型”と呼ばれるものが存在しています。整数、文字列などあの型です。JavaとCOBOLは違う言語ですので、当然この型が異なるのです。あるプログラムを呼び出すということは通常、何らかの型で表現された結果を受け取るということになります。JavaとCOBOLでは、型が異なるためこの結果の受け渡しがすんなりとは行かないのです。この問題を解消するためには、型から型への変換を行う必要があります。これは、結構厄介な問題です。この辺りは、1プログラマーの努力では難しく、仕組みとして提供されていないと辛い所です。また、J2EEサーバーでの多くの処理は、並行して走ります。いわゆる、マルチスレッドでの処理です。このマルチスレッドからCOBOLを呼び出しても大丈夫であることを保障する必要があります。これも重要な考慮点の一つです。JCAあるいはWebサービスでJ2EEからCOBOLを自由に呼び出す環境を構築するにはこれらのことはしっかりと解決されている必要があるわけです。

実は最新のCOBOL環境では、既にこれらの要求・課題に対する答えを準備してくれています。先のJCA使用のプログラムの例も実際に動くコードです。連携のためにJ2EE標準を意識した拡張が行われているのです。驚くべきことにEJBモジュールやEARファイルを生成する機能まで存在しています。Webサービスにも対応しCOBOLロジックをサービスとして提供することも可能なのです（図2）。J2EEのクライアント・コードは、JCA, Webサービス二つの方法を選択してお目当てのCOBOLロジックを呼び出すことができます。JCAを利用する場合は、その仕様通りトランザクションをCOBOL側に伝播することも可能です。COBOLがアクセスするデータベースをEJBと同じスコープで処理することさえ可能です。必要なことは、JCAリソース・アダプターをアプリケーション・サーバーにインストールし、リソースを定義するだけです。Webサービスの場合は、さらに簡単です。トランザクション処理こそできませんが、アクセスのために特別なモジュールの準備は必要ありません。では先の“型”の問題どうなっているのでしょう？　それは、COBOL側で解決してくれているのです。その辺りの仕組みについては、次回の連載の中でお伝えする予定です。

図2

次回は、このエリアの第一人者、マイクロフォーカス株式会社の小林様から、『進化が止まらない・・・オープンなCOBOL環境』と題してJ2EEと連携を支えるCOBOLサーバーの最新機能について解説頂きます。Java技術者必見、COBOL技術者にも見逃せない内容です。乞うご期待。

次回へ