Comments
Description
Transcript
【 【【 【連載 連載
【連載】 連載】SOA 時代の 時代の COBOL 資産活用術 第 2 回 「進化が止まらない...オープンな COBOL 環境」 • 超入門「COBOL」 • レガシーの COBOL 資産は手強いか？ COBOL のアプリケーション・サーバー Java からレガシーCOBOL データを受け渡しするには？ • • • • • Java 界の人にやさしい COBOL 環境 トランザクション・マネジャーとしての COBOL サーバー 次回予告 超入門「 超入門「COBOL」 COBOL」 Java と COBOL、二つの世界はまったく相容れないもののように思えます。この二つを 連携させる技法について解説するわけですが、その前に COBOL という言語がどん なものかをおさらいしておきましょう。細かな話は置いておき、ここでは COBOL がいか に Java と違っているかを、Java プログラマー向けに端的に説明することを試みます。 Java の普及につれてプログラミング言語に対する常識も変化してきたように見受けら れます。プラットフォームに依存しないバイトコードは Java の最大の特徴ですが、少な くとも Java が登場するまでは、これはプログラミング言語の常識ではありませんでし た。COBOL や C、FORTRAN といった言語はほとんどの場合、コンパイラによってター ゲットマシンのネイティブコードに変換され、オペレーティング・システム上の実行形式 モジュールにリンクされて実行されます。「えっ？パソコンでコンパイルしたプログラム を UNIX マシンにコピーして動作させることはできないの？」そんな素朴な疑問も聞か れるようになってきました。Java の影響力の大きさを物語っています。 さて、プログラミングの面から見ると、Java と COBOL の最も大きな違いは、COBOL が 徹底的に static な言語であることです。基本的には COBOL プログラムは、main()メソ ッドと static なメンバーのみを持っている Java クラスみたいなものです。2002 年に国 際標準化された COBOL の最新規格では、COBOL もオブジェクト指向になっていて、 クラスメソッドの定義や動的なインスタンス化ができるようになっています。しかし現存 する膨大な COBOL 資産のほとんどはそんなふうに書かれてはいません。 もう一つ、COBOL の極めて特徴的な点は、非常に多くの機能を言語の文法でサポー トしていることです。Java や C、C++では、コンパイラが構文解析する文法の要素は COBOL に比べて非常に少ないです。言語としての Java の文法は、パッケージやクラ ス、メソッドなどの宣言を行う基本的なプログラムの枠組みに、ループや条件分岐な どの制御構造を表す構文、それに若干の既定義データ型（基本型）、これがすべてで す。にもかかわらず Java プログラマーがシステム資源にアクセスするために豊富な 手段を享受できるのは、文法以外に用意された膨大なクラス・ライブラリーがあるから です。これに対して、COBOL は、時代の要求にこたえるためにデータ処理に必要な 機能を次々に言語に取り込んで 40 年以上発展し続けてきました。 例えば、COBOL にはファイルのソートを行う SORT 文、文字列の連結を行う STRING 文などが文法としてサポートされています。 レガシーの レガシーの COBOL 資産は 資産は手強いか 手強いか？ いか？ 次に COBOL のデータ型についてです。COBOL では数字データを表現するために非 常に豊富なバリエーションの型が利用できます。 Java では、プログラマーが操作の対象とするのはオブジェクトであり、例えば BigDecimal のオブジェクトは、持っている桁数で表現される抽象的な数値のみを表し ています。ところが、COBOL プログラマーは自分が宣言した数字タイプの変数 （COBOL では「データ項目」と呼びます）が、メモリ上で物理的にどのようなバイト並び で格納されているかを知っています。例えば「パック十進形式」という数字のデータ型 があります。これは 1 バイトを 2 つの 4 ビットのフィールドで区切って、それぞれに 10 進数の位取りを格納するものです。 また、COBOL では複数の基本型の変数を階層構造でまとめて一つの複合構造を定 義できます。これを「レコード」と呼びます。Java で複数の基本型メンバーを持つクラス を作成して処理するのに似ていますが、COBOL のレコードはメモリ上の物理的なレイ アウトが意識されています。宣言された順番にメモリ上に並んでいることが言語として 保証されているので、プログラマーはそれを意識したプログラミングを行うことができ ます。例えば「再定義」という機能を使うとメモリ上の同じ領域を異なる形式のレコード として取り扱うことができます。 こんな「物理的な」データ形式を前提として、外部からデータを受け取るようなレガシ ーの COBOL プログラムが大量に存在しています。このような COBOL 資産に J2EE 環境からデータを受け渡して動作させることができるのか？とちょっと不安になりませ んか。 さらに、半角カタカナという意外な強敵がいます。メインフレームでは歴史的な理由で 半角カタカナが多用されてきていて、今でも多く利用されています。メインフレームで は英数字と半角カタカナは一文字 1 バイト、漢字は一文字 2 バイトでしたので、多くの COBOL プログラムはこのことを前提にして書かれています。この前提は Unicode にな った途端に崩れます。 COBOL のアプリケーション・ アプリケーション・サーバー これらの不安はこの後のパートで解消します。しかし、他にも不安を感じた方がいる かもしれません。 COBOL は static な言語です、と書きましたが、それではどうやってマルチスレッドの J2EE アプリケーションと共存できるのでしょうか。もっともな疑問です。 JCA や Web サービスで J2EE から COBOL ロジックを呼び出す場合には、COBOL プ ログラムは J2EE の外側で、COBOL 専用のアプリケーション・サーバー（以下、 COBOL サーバー） （※1）の上で動作させます。COBOL サーバー提供 JCA リソース・ア ダプターは J2EE 側にいて Java アプリケーションが発行する JCA サービス要求を、 Socket を経由して COBOL サーバーリスナーに送信します。COBOL サーバーマネジ ャーはサービス要求を受信すると、その配下で管理しているプロセスプールから待ち 状態になっているプロセスに処理を振り分け、COBOL プログラムを実行させます。こ のプールされたプロセスを COBOL コンテナと呼んでいます。【図 1】 COBOL サーバーはスレッドプール方式ではなくプロセスプール方式なので、static な COBOL プログラムでも問題なく並行稼働させることができるのです。このやり方は CICS などの COBOL 言語をサポートする TPMonitor がどれも採用している方法です。 ※1：マイクロフォーカスでは COBOL 専用アプリケーション・サーバーとして「Micro Focus Enterprise Server」を提供しています。 図 1 Java Connector としての COBOL サーバー Web サービスの場合も同様です。この場合は COBOL サーバーが装備している SOAP リスナーがサービス要求を受け付けます。COBOL プログラムを COBOL サーバーに Web サービスとしてディプロイするときには、COBOL のディプロイ・ツールが WSDL を 自動生成してくれますので、J2EE アプリケーションからは COBOL であると意識する ことなしに呼び出すことができます。 当然ながら COBOL サーバーは、J2EE と同じマシンで稼働している必要はありません。 また J2EE と同じ機種や OS で稼働している必要もありません。例えば J2EE は Linux、 COBOL は Windows、データベースは AIX というような構成もできます。COBOL サーバ ーは COBOL 専用のアプリケーション・サーバーですので、COBOL のことは大得意で す。サーバー下で動作するサービスを対話型デバッガでステップ実行してデバッグす ることもできます。また、COBOL 特有の例外が発生した場合も、サーバーが監視して おり、適切な再ロギングの後に COBOL コンテナを初期化して運転を続行します。 Java からレガシー からレガシーCOBOL レガシーCOBOL にデータを データを受け渡しするには？ しするには？ この連載の第一回で、JCA を使用して COBOL サーバー上のサービスを呼び出す Java プログラミングの実例を見ました。これで呼び出せることはわかりましたが、どう もレガシーの COBOL 資産はそう簡単に使いこなせないのではないか、という不安が あります。 始めから J2EE から呼び出されることを意識して書かれた COBOL プログラムならば、 入り口点・出口点で受け渡しするデータを Java プログラマーに対して親切に作るかも しれませんが、もともと COBOL からしか呼び出されない前提で書かれたプログラムで あれば、COBOL 特有の「ややこしい」データ形式を含んでいるかも知れません。この 問題は COBOL サーバーのサービス・ディスパッチャーとディプロイ・ツールに相当す る開発環境が解決してくれます。 COBOL サーバーマネジャーは、サービス要求を受信すると空いている COBOL コンテ ナに処理をディスパッチしますが、このときに J2EE アプリケーションから渡されてきた 入力データを、COBOL のデータ型に変換します。例えば、Java の基本数字型と BigDecimal オブジェクトは、それが表現する数学的な数値を基にして、対応する COBOL の数字型に変換されます。String オブジェクトは Unicode から COBOL サーバ ーの実行ロケールにあわせてコード変換され COBOL の文字型に格納されます。 byte[]を使用して無変換でバイナリデータを渡すこともできます。この型変換の規則は 開発者によって自由に設定することもできます。レガシーCOBOL プログラムの入出力 データを Java からどのように取り扱うかは、Java、COBOL 双方のプログラマーの都 合で変わりますので、事情に合わせて自由に対応付けを設定できる必要があります。 COBOL サーバーのためのディプロイ・ツールを使用すると、既存の COBOL プログラ ムに記述されている入出力データの定義に、Java のデータ型をどのように対応付け るかをポイント&クリックで定義することができます。（※2）この定義情報は、COBOL サ ーバーへのディプロイ時にコンパイル済み COBOL プログラムとともにサーバーに配 備されますので、COBOL サーバーのディスパッチャーはこれを参照して正しい型変 換を行います。【図 2】 図2 ※2：マイクロフォーカスでは COBOL サーバーのためのディプロイ・ツールとして 「Interface Mapping Toolkit」を COBOL 開発環境に含めて提供しています。 Java 開発者にやさしい 開発者にやさしい COBOL 環境 さて、JCA を使用した Java プログラミング自体は、Connector の JavaAPI 仕様にした がってコーディングすれば良いわけですが、COBOL サーバー上のサービスを呼び出 す目的であればある程度定型的なコーディングとなります。逆に必ず行わなければい けない決まり事もあります。そこで、COBOL サーバーのためのディプロイ・ツールは、 ディプロイ時に同時に、この Java 側のコーディングも自動生成してくれます。幸いにも ディプロイ・ツールは、開発者が指定した Java データ型と COBOL データ型との型変 換規則を知っていますので、規則に従って Java から COBOL にデータを渡す順番も 正しく生成します。生成された Java コードは、一つの完成された EJB としてプログラマ ーに提供されます。この EJB にはビジネスロジックとして JCA 経由で COBOL サーバ ーにサービス要求を投げるメソッドが含まれていますから、プログラマーは JCA のクラ ス仕様を一切気にせずに単にこのメソッドに Java データ型のインスタンスを添えて呼 び出すだけです。これであたかも COBOL プログラムを直接呼び出したように処理が 行えるわけです。なお、ディプロイ・ツールはこの EJB を.jar や.ear にまでパッケージ化 して生成してくれます。お使いの J2EE アプリケーション・サーバーによってディプロイメ ント記述子の形式が異なりますが、生成時のオプションで WebSphere と指定すれば WebSphere にそのままインストールできるパッケージが生成されます。【図 3】 図3 レガシーCOBOL プログラムは往々にして膨大な量の入出力データを持っています。 普通はレコードとして受け渡ししますが、基本型で数百個というのはざらにあります。 これをそのまま Java 基本型に対応付けて EJB を生成すると、数百のインスタンスを 持つ EJB メソッドが生成されてしまいます。これでは使えません。 このような場合に対応するためにディプロイ・ツールは COBOL レコードを一つの Java クラスに対応付けることをサポートしています。COBOL レコード中の個々の基本型は Java クラスのメンバーに対応します。この方法によれば、Java 側では各メンバーに値 をセットしてから EJB メソッドのクラスインスタンスとして渡すことができます。 トランザクション・ トランザクション・マネジャーとしての マネジャーとしての COBOL サーバー J2EE では、JCA は JTA トランザクションのリソースマネジャーとしてサポートしなけれ ばならないことが規定されています。従って COBOL サーバー提供 JCA リソース・アダ プターも JTA の XATransaction インターフェイスを実装しています。これを使用すると、 J2EE 側のトランザクションスコープと、COBOL サービス内でのデータベース更新とが 同期します。J2EE 側でトランザクションがロールバックされれば、COBOL サーバー上 のデータベース更新もロールバックされます。また、COBOL サービスの実行時に例 外が発生すれば、それは J2EE 側にも例外としてスローされますので JTA トランザク ションもロールバックされます。つまり COBOL サービスの呼び出しも JTA の分散トラ ンザクションの一つとして自然に 2 層コミットの対象になっているわけです。COBOL プ ログラマーは従来どおりの方式でトランザクションプログラムを書くことができ、Java プ ログラマーは JTA に従って、JDBC や JMS のトランザクションと混在して COBOL サー ビスを使用することができます。 どうでしょうか？Java と COBOL は二つの相容れない世界ではなくなっていることがわ かってきましたね。 次回予告 最終回である次回は、再び日本アイ・ビー・エム様にバトンを渡し、「COBOL プログラ ム活用の Hint&Tips」と題して、このテクノロジーに関する J2EE 側の注意点などを語っ ていただきます。ご期待ください。 *【連載】SOA 時代の COBOL 資産活用術は、マイクロフォーカス株式会社と 日本アイ・ビー・エム株式会社のリレー形式による連載記事です。