COBOLコンソーシアム情報発信分科会
上野 浩一 (株式会社日立製作所 ＩＴプラットフォーム事業本部)
たとえ基幹システムであっても，WWW（World-Wide Web）技術を使い、Webシステムとして構築することはもはや珍しくありません。Webブラウザをクライアントとして使うため、その管理が容易になることなどがメリットです。構築済みのCOBOLシステムも、そこで稼働するプログラムをWebシステムから連携すれば，同様のメリットが得られます。開発済みで信頼性が高いビジネス・ロジックを流用するので、システムの信頼性も上げやすい。また、蓄積してきたCOBOL開発のノウハウも生かせます。
COBOLプログラムを連携するWebシステムには、さまざまな形態があります。ここでは、J2EE（Java2 Platform，Enterprise Edition）を取り上げます。Webシステムへの連携に当たり、既存のCOBOLプログラムには変更を加えないことが基本です。
既存のCOBOLプログラムをWebシステムから連携すれば、Webブラウザから利用できるようになります。これにより、クライアントにアプリケーション配布が不要になる、ユーザーを拡大しやすい、といったメリットが生まれます。
Webシステムの構築に欠かせないのが、Webアプリケーション・サーバー（APサーバー）です。製品のタイプはいくつかありますが、現在の代表格はJ2EEをベースにしたものです。J2EEとは、サーバー・サイドでJavaを使い、システムを構築するためのAPI（Application Programming Interface）の総称です。J2EE準拠のAPサーバーから、COBOLアプリケーションを連携する手法を説明します。
APサーバーを使ったシステム構築では、論理的にはWebサーバー、アプリケーション・サーバー、データベース・サーバー（DBサーバー）の3階層で構成されます（図1）。APサーバーとは、一般的にはWebサーバーおよびアプリケーション・サーバーを形成する基盤ミドルウエア群の総称です。
J2EEに準拠したAPサーバーの場合、Webサーバーは、HTTPサーバーと、HTTPサーバーと連動して動作するアプリケーション・コンポーネントであるJSPならびにJavaサーブレットから構成されます。Webサーバーの役割は、クライアント（Webブラウザ）とアプリケーション・サーバー間の、問い合わせ/応答を中継することです。3階層システムにおける機能層としては、プレゼンテーション層に位置付けられます。
アプリケーション・サーバーは、Webサーバーからのリクエストに応じてビジネス・ロジックを実行します。J2EEにおいては、このビジネス・ロジックはEJBコンポーネントなどで作成します。アプリケーション・サーバーが、EJBコンテナ上でロジックを実行します。なお、アプリケーション・サーバーが担うのは、3階層の中のビジネス・ロジック層です。
アプリケーション・サーバーは、JavaサーブレットやJSPを実行する「サーブレット・コンテナ」、およびEJBコンポーネントを実行する「EJBコンテナ」を備えています。これらのコンテナの実行エンジンは、JavaVM上で動作するコンポーネントとして作成されているので、開発生産性を向上し、運用マシンを選ばないプラットフォーム独立性を実現しています。
図1●EJBに準拠したAPサーバーの論理構成
図2●MVCモデルを使ったWebシステムの例
Webシステムの構成を検討するには、処理すべき業務データ/作業内容/連携システム（バックエンド）を分析した上で、システムのビジネス・モデルを明確にする必要があります。構成を検討する上では、「MVC（Model-View-Controller）モデル」と呼ばれるデザイン・パターンが役に立ちます（図2）。各コンポーネントの役割を見ていきましょう。
モデル（Model）は、業務処理を行うシステムの本体部分にあたり、Java BeansやEJBのコンポーネントとして実装します。このビジネス・ロジック部分にCOBOLを活用します。ビジネス・ロジックとは、製品の在庫確認や保険料計算、残高照会といった処理です。このような処理は、既存のコンピュータ環境でCOBOLプログラムとして存在していることが多い。システム構築の形態や環境が変化しても、保険料算定など業務処理の中核部分は変わりません。これらをモデル部分に流用／活用できれば、開発は容易になります。加えて、アプリケーションの信頼性が高いことも期待できます。なお、モデルでは入出力や表示処理は行いません。
ビュー（View）は、入出力や表示処理を担う部分であり、JSPやJavaサーブレットで実装します。HTML表示に関してはJSP、バイナリ・データを出力する特殊処理の場合はJavaサーブレットを用いるのが一般的です。
コントローラ（Controller）は、モデルとビューを制御します。表示処理や業務処理は実行せず、ビューからの入力に対応する業務処理の実行をモデルに依頼し、その結果表示をビューに依頼するなどコンポーネントの制御を行います。
MVCモデルに沿ってシステム構成を検討することで、コンポーネントの機能分担が明確になります。加えて、コンポーネント間の依存性が低く抑えられるため、他のコンポーネントの変更による影響を受けにくくなり、コンポーネントの再利用性が高まります。また、各コンポーネントの機能が明確になるため、セッション管理の方法やセキュリティ・ポリシーの検討が容易になり、Webシステムの全体構成が考えやすくなるといったメリットも出てきます。
Javaプログラム（Javaサーブレット）からCOBOLプログラムを連携するパターンは、大きく以下の2つがあります。
①APサーバーと同じマシン上にCOBOLプログラムを導入し、JavaサーブレットやJSPなどから直接呼び出す。
②APサーバーが、別のマシン（サーバー）にあるOLTP (OnLine Transaction Processing) 環境で構築されたCOBOLプログラムと通信する。
①Javaプログラムから手続き型のCOBOLプログラムを呼び出す場合、Javaの他言語インターフェース機能「JNI (Java Native Interface)」を利用します（図3）。これにより、COBOLプログラムをJavaVM中にロードし、呼び出すことができます。ただし、JNIからCOBOLプログラムを直接呼び出すため、データ型変換などの問題をプログラミングで解決する必要があります。開発負荷を抑えるには、後述する、各ベンダーが提供しているJavaとCOBOLとの連携機能を使用することをお勧めします。
②では、COBOLプログラムと通信するために、JCA (Java Connector Architecture) や、JTA (Java Transaction API) などから各ベンダーが提供するOLTP機能を連携します（図4）。この形態では、オープンシステムで構築した業務システムを活かしながら、COBOLプログラムのWeb化が図れます。
図3●JavaからCOBOLプログラムを直接呼び出す
JNI経由で呼び出し、JavaVM上にCOBOLプログラムをロードする
図4●OLTP機能で連携する
JCA/JTAを使い、他プラットフォーム上のOLTP機能と通信し、COBOLプログラムを連携する
JavaとCOBOLでは、データ定義の取り扱いが異なります。そのため、JavaからCOBOLプログラムを呼び出す場合は、データ変換が必要になります。例えば、Javaの文字列型はすべてStringクラス・オブジェクトですが、COBOLでは文字列の格納データ定義となります。このため、JavaプログラムからCOBOLプログラムを呼び出す場合、Stringクラス・オブジェクトのデータをいったんバイト配列に転記し、その配列をCOBOLプログラムに渡す必要があります。さらに、COBOLプログラムの多くはSJISまたはEUCの文字データを処理する一方で、Java内部では文字列の処理にUnicodeを使いますので、両者の連携には文字コードの変換が必要です。たとえば図5のように文字コードを使い分けるシステム構成で、データの中に機種依存文字や外字が含まれる場合、COBOLの環境とJavaの環境の間で文字コードが正しく変換され、Webブラウザでも期待どおり表示される必要があります。
また、連携パターンによっては次の注意点もあります。
図5●外字データ、特殊文字データを取り扱うシステムの構成例
| システムの 構成要素 | 文字コード体系 |
|---|---|
| Webブラウザ | Windowsで使われるSJISには、機種依存文字として、NEC特殊文字、NEC選定IBM文字、IBM拡張文字が割り当てられている |
| APサーバー | Java が、SJISとUnicode の変換を行う。JavaプログラムはすべてUnicodeである |
| OLTP呼び出し | UnicodeとSJIS（またはEUC）の変換を行う |
| OLTPサーバー | UNIXの種類によっては、NEC特殊文字、NEC選定IBM文字、IBM拡張文字が割り当てられないコード体系の場合がある |
図6●メモリー上でデータの格納形式が異なる
バイナリ形式のデータをメモリー上に配置した際、WindowsとUNIXではデータの格納形式が異なる。
そのような環境では、メモリー上のデータ格納形式を変換する必要がある