お問い合わせ

ホーム > COBOLのはなし > Webシステムへの移行手順

Webシステムへの移行手順

COBOLコンソーシアム情報発信分科会
上野 浩一 (株式会社日立製作所 ITプラットフォーム事業本部)

たとえ基幹システムであっても,WWW(World-Wide Web)技術を使い、Webシステムとして構築することはもはや珍しくありません。Webブラウザをクライアントとして使うため、その管理が容易になることなどがメリットです。構築済みのCOBOLシステムも、そこで稼働するプログラムをWebシステムから連携すれば,同様のメリットが得られます。開発済みで信頼性が高いビジネス・ロジックを流用するので、システムの信頼性も上げやすい。また、蓄積してきたCOBOL開発のノウハウも生かせます。

COBOLプログラムを連携するWebシステムには、さまざまな形態があります。ここでは、J2EE(Java2 Platform,Enterprise Edition)を取り上げます。Webシステムへの連携に当たり、既存のCOBOLプログラムには変更を加えないことが基本です。

1.J2EEからCOBOLを連携

既存のCOBOLプログラムをWebシステムから連携すれば、Webブラウザから利用できるようになります。これにより、クライアントにアプリケーション配布が不要になる、ユーザーを拡大しやすい、といったメリットが生まれます。

1.1 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サーバーの論理構成

1.2 MVCモデルで開発を効率化する



図2●MVCモデルを使ったWebシステムの例

Webシステムの構成を検討するには、処理すべき業務データ/作業内容/連携システム(バックエンド)を分析した上で、システムのビジネス・モデルを明確にする必要があります。構成を検討する上では、「MVC(Model-View-Controller)モデル」と呼ばれるデザイン・パターンが役に立ちます(図2)。各コンポーネントの役割を見ていきましょう。

モデル(Model)は、業務処理を行うシステムの本体部分にあたり、Java BeansやEJBのコンポーネントとして実装します。このビジネス・ロジック部分にCOBOLを活用します。ビジネス・ロジックとは、製品の在庫確認や保険料計算、残高照会といった処理です。このような処理は、既存のコンピュータ環境でCOBOLプログラムとして存在していることが多い。システム構築の形態や環境が変化しても、保険料算定など業務処理の中核部分は変わりません。これらをモデル部分に流用/活用できれば、開発は容易になります。加えて、アプリケーションの信頼性が高いことも期待できます。なお、モデルでは入出力や表示処理は行いません。

ビュー(View)は、入出力や表示処理を担う部分であり、JSPやJavaサーブレットで実装します。HTML表示に関してはJSP、バイナリ・データを出力する特殊処理の場合はJavaサーブレットを用いるのが一般的です。

コントローラ(Controller)は、モデルとビューを制御します。表示処理や業務処理は実行せず、ビューからの入力に対応する業務処理の実行をモデルに依頼し、その結果表示をビューに依頼するなどコンポーネントの制御を行います。

MVCモデルに沿ってシステム構成を検討することで、コンポーネントの機能分担が明確になります。加えて、コンポーネント間の依存性が低く抑えられるため、他のコンポーネントの変更による影響を受けにくくなり、コンポーネントの再利用性が高まります。また、各コンポーネントの機能が明確になるため、セッション管理の方法やセキュリティ・ポリシーの検討が容易になり、Webシステムの全体構成が考えやすくなるといったメリットも出てきます。

1.3 JavaからCOBOLプログラムを連携

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との連携機能を使用することをお勧めします。

Aでは、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プログラムを連携する

1.4 JavaとCOBOLのデータ型の違いに注意

JavaとCOBOLでは、データ定義の取り扱いが異なります。そのため、JavaからCOBOLプログラムを呼び出す場合は、データ変換が必要になります。例えば、Javaの文字列型はすべてStringクラス・オブジェクトですが、COBOLでは文字列の格納データ定義となります。このため、JavaプログラムからCOBOLプログラムを呼び出す場合、Stringクラス・オブジェクトのデータをいったんバイト配列に転記し、その配列をCOBOLプログラムに渡す必要があります。さらに、COBOLプログラムの多くはSJISまたはEUCの文字データを処理する一方で、Java内部では文字列の処理にUnicodeを使いますので、両者の連携には文字コードの変換が必要です。たとえば図5のように文字コードを使い分けるシステム構成で、データの中に機種依存文字や外字が含まれる場合、COBOLの環境とJavaの環境の間で文字コードが正しく変換され、Webブラウザでも期待どおり表示される必要があります。

また、連携パターンによっては次の注意点もあります。

① JavaからJNI経由でCOBOLプログラムを呼び出す場合

●COBOLプログラムを選別する
COBOLプログラムはDLL(Windows)や共用ライブラリ(UNIX)として呼び出されるため、処理が閉じているもの、サブルーチン化しているものが既存資産として活用しやすい。画面制御が含まれているCOBOLプログラムを活用したい場合は、画面制御処理とビジネス・ロジックを分離する必要があります。
●マルチスレッド対応にする
J2EEの基盤となっているJavaVMはマルチスレッドで動作します。そのため、そのスレッドの延長として呼び出されるCOBOLプログラム、およびCOBOLプログラムが呼び出すライブラリもマルチスレッドで動作する必要があります。

②JavaからJCA/JTAでOLTP上のCOBOLプログラムと通信する場合

●メモリー上のデータ形式の違いを知る
2進数項目および内部浮動小数点項目データを、Windows環境のAPサーバーから、UNIX環境のOLTPサーバーに送信する場合、データ格納形式の変換が必要となります。
WindowsとUNIXでは、メモリー上に格納されるデータ形式が異なります。具体的には、バイナリ形式のデータ(2進数項目および内部浮動小数点項目)がメモリー上に配置された場合、両者ではデータの並び順が反対になります(図6)。そのため、2進項目および内部浮動小数点項目のデータを、Windows環境のAPサーバーとUNIX環境のOLTPサーバー間でやり取りする場合、データ格納形式も変換する必要があります。



図5●外字データ、特殊文字データを取り扱うシステムの構成例

表1●システムの構成要素による文字コード体系の違い
システムの
構成要素
文字コード体系
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ではデータの格納形式が異なる。
そのような環境では、メモリー上のデータ格納形式を変換する必要がある