JBoss ESBおよびLegStarによるメインフレーム統合

はじめに

「Is Your Next Generation Language COBOL?（次世代言語はCOBOLか?）」というタイトルの付いた2008年10月発行の『Dr Dobbs』(リンク)で、Michael Swaine氏は、レガシーメインフレームアプリケーションの規模と強みが継続していることの証拠として「毎年、数十億行もの新しいCOBOLコードが記述されている」と述べています。これに関連して、メインフレームアプリケーションと分散システム、特にJavaベースのシステムとの統合が重要な話題であり続けているのも不思議ではありません。

メインフレーム統合は、業界がここ数年でかなりの経験を積んでいる分野です。身をもって学んだ1つの教訓は、密結合は悪であるということです。もちろんこれはすべての統合システムについて言えることですが、メインフレームアプリケーションでは、技術格差がさらに大きく、一方ではCOBOL、CICS/IMS、TSO、もう一方ではJava、J2EE、Eclipseというようになります。ライフサイクル、開発者の考え方、ツールなどが全く異なるアプリケーション間に依存性を作り過ぎると、脆弱で不安定なシステムにつながります。

メインフレーム統合ベンダーは、非常に早い段階でサービス指向アーキテクチャ（SOA; Service Oriented Architecture）を導入し、SOAに基づいたメインフレーム統合ソリューションの第一世代をもたらしました。これらのソリューションの多くは、COBOLとXMLおよびSOAPメッセージングとのバインディングがメインフレーム上で直接動作するという意味ではメインフレーム中心です。

大規模ITコミュニティによる最近のEnterprise Integration Patterns（エンタープライズ統合パターン）(リンク)の導入と、最適なSOAインフラストラクチャとしてのエンタープライズサービスバス（ESB; Enterprise Service Bus）(リンク)の登場は、メインフレーム統合の新たなアーキテクチャ上の機会を生み出しました。この記事では、新しい、ESB中心のメインフレーム統合の見解を推奨し、アーキテクチャなどを実装するオープンソースソリューション、LegStar for JBoss ESBを紹介します。

第一世代の、メインフレーム中心の統合は、その制限とコストを示している

Michael Swaine氏は、COBOL言語自体がXMLをサポートするように進化していて、CICSなどのシステムが現在SOAPサポートを提供していると述べています。IBMのほか、多くのベンダーがメインフレーム上でのCOBOLとXMLおよびSOAPスタックとのバインディングを提供しています。ここ数年、レガシー統合システムを専門とするアナリストは、メインフレーム上でネイティブに動作するXMLおよびSOAPとの統合に対し、このメインフレーム中心のアプローチを支持しています。

当時、ネイティブのメインフレームSOAPスタックは存在しなかったため、ほとんどのメインフレーム中心の統合ベンダーは自家製のSOAPスタックを開発せざるを得ないと感じていました。一部のベンダーは、独自のXMLパーサを開発するほどでした。

しかし、その後SOAとWebサービスは急速に進化しました。数年前、基本的なXML処理とSOAP1.1の提供はサービス指向を要求するのに十分でした。その後、SOAに対する顧客の期待と認識が高まり、WS-*などの新しい標準が採用されました。結果として、自家製のSOAPスタックの維持費は急速に増加しています。

メインフレーム開発者には、大規模コミュニティとオープンソースで提供される共同リソースが不足していました。そのため、いくつかのメインフレームSOAPスタックは、多くのWS-*仕様の前提条件であるSOAP 1.2またはWS-Addressingをまだ提供していません。比較として、Apacheの最新のAxis2リリースは20 Mbダウンロードであり、SAAJ（SOAP 1.1およびSOAP 1.2）、XML Schema、WSDL 1.1およびWSDL 2.0、WS-Addressing、Fastinfoset、WS-MetadataExchange、MTOM、WS-Policy、その他を網羅する59ライブラリが含まれています

さらに、RESTful Webサービスなどの新しい技術が出現しています。Google、Yahoo、Amazonの支援によって、この種のアーキテクチャは人気を得ており、RESTful Webサービス用のJava APIであるJSR 311の採用がその信頼性に貢献しました。また、JSONはXMLに代わる軽量のフォーマットとして躍進を遂げています。たとえばAxis2はJSONをサポートしています。メインフレームアプリケーションとRESTful WebサービスおよびJSONサポートとの統合は、近い将来に必須となり、すでに長いバックログにさらに項目を追加すると予想されます。基本のWebサービス機能を超えて、オーケストレーションまたはスクリプト言語の要件が出現し、メインフレーム中心開発チームにさらに圧力をかけています。

メインフレーム中心ソリューションは機能に関して遅れをとっているだけでなく、多くの場合はSOAPの登場時に急いで決定された不十分な設計です。

たとえば、メインフレーム中心ソリューションはたいてい、バインディング層、メッセージング層、およびトランスポート層を密結合します。一方でオープンソースコミュニティは、トランスポートとメッセージングから言語バインディング（たとえばJavaとXMLのバインディング）をきっちり切り離すという重要な決定を行いました。Java世界では、JSR 222 Java Architecture for XML binding（JAXB）は通常、Webサービス技術とは独立して実装されます。つまり、SOAPまたはRESTful Webサービスと一緒に使用できます。同様に、メッセージングとトランスポートは通常、明確に切り離されており、従来のHTTP/HTTPSに加えてJMSやTCPソケットを介したSOAPメッセージの送信を可能にします。結果として、メインフレーム中心ソリューションは、変化するSOAランドスケープに適応しにくいです。

また、メインフレーム中心の統合ソリューションは、メインフレームをITインフラストラクチャの中心として見なすように設計されました。分散アプリケーションは周辺機器として見なされました。これにより、メインフレーム統合の非対称的ビジョンが生じました。ここで、唯一必要な、または少なくとも最も重要なことは、これらの周辺アプリケーションにとってメインフレームリソースを利用することでした。分散アプリケーションの重要性が増していますが、メインフレームアプリケーションはこれ以上孤立し続けることはできません。多くのメインフレーム中心の統合ベンダーは最近、脅威に気付き、アウトバウンド機能を提供し始めましたが、ITインフラストラクチャにおけるメインフレームアプリケーションの役割の、よりバランスのとれたビジョンをサポートするために必要な抜本的な見直しにあまり取り組んでいません。SOAPクライアント機能は一般にメインフレームにおいて非常に脆弱で制限されており、分散サービスへのアウトバウンドアクセスは厳しく制限されます。

最後に、メインフレーム中心の統合の重要な側面は、コストです。メインフレームにおいてソフトウェアライセンスと維持費は高価です。オープンソースはまだその世界に到達しておらず、決して到達しないでしょう。また、XMLおよびSOAP処理は、CPUに負担をかけるアクティビティです。この事実を軽減するためのIBMによるいくつかのイニシアチブにもかかわらず、メインフレームにおけるCPUコストは割高なままです。

要約すると、メインフレーム中心の統合ベンダーにとって、最新のWebサービス標準に追いつき、新しい要件に対応し、メインフレームアプリケーションの変化する役割と、オープンソースソフトウェアによって広まる新しいコスト構造に適応することは、ますます困難になっています。

次世代の、ESB中心のメインフレーム統合

オープンソース世界では、エンタープライズサービスバス（ESB; Enterprise Service Bus）がSOAをサポートする最高のインフラストラクチャとして登場しました。ESBは、多数のトランスポート、レジストリサービス、高度なメッセージ変換、オーケストレーションなどに対するサポートを提供します。ある意味で、ESBは、Enterprise Application Integration（EAI）専用プラットフォームが以前に占有していた範囲をカバーします。

ESB中心のメインフレーム統合ソリューションは、ESBアーキテクチャ上に構築することでこれらの利点を活用します。たとえば、COBOLとJavaまたはXMLとのバインディングは、ESB内での変換アクティビティとして処理されます。メインフレームとのメッセージ交換には、ESB標準のトランスポートを使用するか、既存のトランスポート上に構築します。メインフレームアプリケーションはESBを意識することなく、別のメインフレームともデータを交換できます。

ESBは、オープンソース市場の非常に動的なセグメントであり、若い開発者コミュニティによってメインフレームよりもはるかに良く理解されています。ESBは大規模なオープンソースコミュニティから恩恵を受けており、BPM、動的言語、RESTful Webサービスなどの新生技術の課題に直接さらされています。いまだメインフレーム中心の統合ソリューションの課題であるBPMおよびBPELは、ESBにおいて広く利用可能です。ESB中心の統合では、メインフレームインタラクションは複雑なビジネスプロセスに容易に参加できます。

メインフレーム中心の統合ツールと同様、ESB中心のメインフレーム統合ツールは設計時と実行時の機能を特徴としています。設計時ツールは、COBOLをオープンワールドな複雑なタイプにマッピングするために必要です。違いは、ESB中心の設計時ツールは、明確にESBをターゲットにした成果物を生成するということです。そのESBに配備されると、これらの成果物はメインフレームデータのストリームをオープンワールドなオブジェクトに変換します。変換はESBタスク内という形で行われ、マルチスレッドのスケーラブルなESBアーキテクチャの恩恵を受けます。

また、ESB中心のメインフレーム統合は、XML関連のアクティビティのCPU使用率だけでなく、メモリーフットプリントを削減するためにオープンワールドで現在利用可能な豊富なXML最適化手法の恩恵を受けます。ほぼ間違いなく、分散プラットフォームのCPUはメインフレームよりもすでにチープですが、さらに、Java世界で広く利用可能なプロファイラーなどの高度なツールは、メインフレームではあまり一般的ではありません。ESB中心のソリューションは、CPUやメモリ使用率を監視および制御し、さらに統合コスト全体を削減する態勢がより良く整っています。

ESB中心のソリューションでは、生成された成果物はESBに配備可能などんなものとも（Java、XML、jars ...）調和します。つまり、オープンワールドの豊富な管理ツールでこれらの成果物を管理でき（ソースコントロール、ビルドコントロール、依存性管理、継続的統合...）、単体テストを行い、インストルメント化し、安全確保できます。統合成果物は開発成果物であり、非常にセンシティブです。これらはたいてい高容量のトランザクションシステムの重要な部分であり、極秘データにアクセスできます。ESB中心のソリューションでは、これらを開発エコシステムのfirst class citizen（第一級市民）として扱うことができます。

またESBは、メインフレーム中心のSOAPスタックよりも優れた絶縁レベルを提供します。この点を明らかにするために、次のユースケースを考察してください。メインフレームコードは、分散プラットフォーム上で、メインフレームの外部で提供されるサービスを利用する必要があります。分散環境は機能が豊富になって、ITポートフォリオにおいてより顕著な役割を担っているため、参照データとプロセスが分散環境からもたらされることがますます一般的になっています。そのような状況で、メインフレームの残りのプロセスは、これらの分散機能にアクセスする必要があります。メインフレーム中心の統合ソリューションでは、COBOLプログラムはSOAPリクエストを発行する必要があります。一方、ESB中心の統合ソリューションでは、COBOLプログラムは特定のメッセージングに関する知識が全くなく、さらには分散プラットフォームと通信さえします。これは単に、メインフレームデータをWebSphere MQキューまたはHTTPペイロードに置きます。ターゲットのサービスとプロトコルの知識はESB内に保たれます。これはまさにESBの役割です。ESB中心のソリューションは、統合システムの最も望ましい品質である、高いレベルの分離（decoupling）を提供します。

LegStarおよびJBoss ESB、ESB中心のメインフレーム統合ソリューション

オープンソースのメインフレーム統合技術であるLegStar for JBoss ESB(リンク)は、統合プラットフォームとして明確にESBをターゲットにした最初のものです。この記事では、メインフレームのCOBOLプログラムが外界にアクセスできるようにLegStarを使用してオープンソースのESBであるRedhat JBossをどのように利用できるかを実証します。統合したアーキテクチャは、同期または非同期メッセージングを使用し、最小のメインフレーム技術が関与し、分散プロセスからメインフレームプログラムを効果的に分離します。

ユースケース

私たちは、Javaオブジェクト（Plain Old Java ObjectすなわちPOJO）をCOBOL利用者に公開します。

また、LegStar for JBoss ESBは、COBOLプログラムがJava利用者に公開される古典的なユースケースをカバーできますが、COBOLコードがクライアントとして機能する必要がある場合、特に疎結合が最重要である場合に、いくつかの固有の課題があります。

LegStar for JBoss ESBはまた、COBOLコードがESBサービスおよびWebサービスを利用することを可能にします。物事を簡単に保つために、私たちはPOJOを利用することを選択しました。

アーキテクチャ

メインフレーム側では、COBOLを開発言語として、WebSphere MQを転送メカニズムとして見なします。

サーバー側では、無料で利用可能なオープンソース技術のJBoss ESB(リンク)およびLegStar(リンク)を使用します。

配備アーキテクチャは、次のようになります。

このアーキテクチャの選択についていくつか触れる価値のあることがあります。

WebSphere MQはJBoss ESB間での生データの転送を行う

また、HTTPを使用してESBと通信することも可能ですが、WebSphere MQはメインフレームに広く行き渡っているため、HTTPよりも非同期メッセージングをより良くサポートします。COBOLコードは、TSOで動作可能で、バッチプログラムとして、CICSまたはIMSで動作可能です。WebSphere MQ APIは、これらの環境その他のいずれでも利用可能です。

COBOLプログラムは生のメインフレームデータをWebSphere MQメッセージに投入します。この内容はメインフレームでは変換されません。つまり、JBoss ESBは生のメインフレームデータを受信します。それには、次の2つの利点があります。

• メインフレームのCPU使用率が低い（データ変換が行われない）
• メインフレームは、非メインフレームプラットフォームと通信していることを把握する必要がない

この2つ目の点は、分離に関して特に重要です。

アーキテクチャ図では、z/OS上に単一のWebSphere MQ Managerが示されていますが、恐らく分散プラットフォーム上に別のWebSphere MQ Managerが存在します。便宜上と、厳密には必ずしも必要ではないため、別のマネージャについては示しませんでした。

ESBの観点から、私たちはJBoss ESB付属の標準のリスナーを使用します。これは、メインフレームから入ってくる並列リクエストの高い負荷をサポートできる、高性能なマルチスレッドのリスナーです。
 

メインフレーム側で、クライアントコードは同期的または非同期的に相互作用する

COBOLクライアントコードは、標準のWebSphere MQ APIを使用して、自由に応答を待機できます。または単にリクエストのポスト後にリターンします。非同期メッセージングパターンは、別のCOBOLプログラムが応答を処理できるWebSphere MQ標準のトリガーメカニズムを使用して実装されます。

非同期性は、システム間の依存性をあまり生み出さないため望ましいです。この種の交換パターンはESBモデルによく適しています。

JBoss ESBサービスはCOBOLクライアントプログラムとPOJO間のプロキシである

JBoss ESBは様々な転送をサポートし、私たちがここで利用している多彩なパイプライン概念を提供します。

標準のJBoss ESBリスナーであるJMS Gatewayは、WebSphere MQ Queueを監視し、メッセージが受信されると一連のアクションをトリガーします。JBossには、私たちがここで使用しているObject InvokerやJMSルータなどのすぐに使えるアクションがいくつか用意されています。

マーシャル/アンマーシャルな生のメインフレームデータに必要な変換アクションは、次のセクションで説明するとおり、設計時にLegStarによって生成されます。LegStarによって生成される成果物は、JBoss ESBに固有であり最適化されています。

ある程度は、ESBプロキシサービスは、ターゲットのPOJOに影響を与える可能性のある変更からCOBOLクライアントを保護します。最初に、COBOLクライアントはPOJOのロケーションまたはパッケージ名の変更によって影響を受けません。また、クライアントに影響を与えずに、新しいプロパティをPOJOに追加できます。プロパティの削除やタイプの変更といった、より重大な変更は、もちろん依然としてCOBOLコードに影響を与えます。

ステップバイステップ

ここでは、開発者がPOJOに対しESBサービスプロキシを作成するために従う主要な手順について説明します。LegStar for JBoss ESBにはプロセスを単純化するEclipseプラグインが用意されています。また、同じツールがantスクリプトとして利用可能ですが、Eclipseはより扱いやすいため、私たちはEclipseの方法を選びました。

完了したEclipseプロジェクトはこちら(リンク)で入手できます。

ターゲットのJavaオブジェクト（POJO）

この記事のために私たちはPlain Old Java Object（POJO）を使用しますが、JBoss ESBサービスまたはESB以外のWebサービスでも可能です。

ただのJavaオブジェクトではありませんが、単一の複雑なオブジェクトを入力として受け取り、単一のオブジェクトを出力として生成し、何か支障がある場合に例外を発生させる単一の粗粒状のメソッドを、Javaクラスが公開することを期待しています。この振る舞いはリモートファサードパターン(リンク)に関連します。このパターンにおいて、入出力オブジェクトはデータ転送オブジェクト(リンク)として知られています。この記事の残り部分では、このようなオブジェクトをデータオブジェクトと呼びます。

ここでは、固有のメソッドを示します。リクエストを表す入力データオブジェクトは、JVMQueryRequestと呼ばれます。これには、環境変数名の集合が含まれています。JVMQueryReplyと呼ばれる出力データオブジェクトには、リクエストされた環境変数の値の集合と、いくつかのロケール固有の値が含まれています。

public class JVMQuery {

    public JVMQueryReply queryJvm(JVMQueryRequest request) throws JVMQueryException {

        List  envVarValues = new ArrayList ();
        try {
            for (String envVarName : request.getEnvVarNames()) {
                if (envVarName == null) {
                    throw new JVMQueryException("Invalid variable name");
                }
                String value = System.getenv(envVarName);
                if (value == null) {
                    envVarValues.add("Not found");
                } else {
                    envVarValues.add(value);
                }
            }
        } catch (SecurityException e) {
            throw new JVMQueryException(e);
        }

        JVMQueryReply reply = new JVMQueryReply();
        reply.setEnvVarValues(envVarValues);
        Locale locale = Locale.getDefault();
        reply.setCountry(locale.getDisplayCountry());
        reply.setLanguage(locale.getDisplayLanguage());
        reply.setFormattedDate(
                DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL,
                        locale).format(new Date()));
        reply.setCurrencySymbol(Currency.getInstance(locale).getSymbol());
        return reply;
    }

}

JavaデータオブジェクトをCOBOL構造にマッピング

生のメインフレームデータがESBに到達すると、このデータをJavaデータオブジェクトにマーシャル化するアクションが実行されなくてはなりません。これはLegStarが関与するところです。LegStarは、COBOL構造をXML SchemaおよびJavaにマップするための設計時ツールを提供します。また、生のメインフレームデータのマーシャル化/アンマーシャル化を実行するための実行時バインディングフレームワークを提供します。

LegStarには、ユーザーがJavaオブジェクトをピックアップしてCOBOL構造への自動マッピングをリクエストできるEclipseプラグイン一式が用意されています。

その結果は、特別なCOBOLアノテーション付きのXML Schemaになります。以下は、Eclipse標準のXML Schemaエディタで示されるとおりの、JVMQueryReplyデータオブジェクトのマッピングから生じる要素の説明です。

一部のCOBOLプロパティにはデフォルト値があることに気付くでしょう。たとえば、文字列には32のデフォルトサイズがあります。これは、COBOLが固定サイズの文字列しかサポートしていないからです。同様に、COBOLは無制限の配列をサポートしていません。XML Schemaエディタでデフォルト値を簡単に変更できます。

COBOLバインディングクラスの生成

LegStar COBOLバインディングクラスは、Javaデータオブジェクトへの生のメインフレームデータのマーシャル化/アンマーシャル化を実行するJavaクラスです。

Eclipseでは、プラグインがXML Schemaから複雑なタイプを抽出します。これにより、バインディングクラスを生成したい複雑なタイプを選択することが可能です。次の例では、入力タイプと出力タイプを選択します。

LegStar COBOLバインディングメカニズムは、JAXBまたはJSR 222(リンク)として知られるJavaとXMLのバインディングフレームワークを基礎とします。バインディングプロセスは、追加のCOBOLアノテーション付きのJAXBクラスを生成します。生成されたJAXBクラスの1つを開くと、Javaオブジェクトの各プロパティにCOBOLアノテーションがあるのを確認できます。

JBoss ESBアクションの生成および設定例

最後の手順は、JBoss ESBプロキシサービスの配備とテストに役立つ成果物一式を生成することです。Eclipseで、WebSphere MQ生成オプションを選択し、ターゲットのJBoss ESBサービスを配備すべき場所を指定します。

LegStarは、テストできる状態のパイプラインを処理する完全なアクション付きのJBoss ESB設定ファイル例を作成します。また、JBoss ESBサービスを呼び出して独自の開発をジャンプスタートさせるのに使用できるCOBOLクライアントのコード例も生成します。

結論

LegStar for JBoss ESBは、次世代の、ESB中心のメインフレーム統合ソリューションの一例です。

この新しいタイプのアーキテクチャの特徴を、次にまとめます。

• 真に双方向であり、メインフレームコードは状況に応じてサーバーまたはクライアントとして機能します。
• メインフレームCOBOLプログラムは、分散サービスに対して効果的に疎結合されます。この記事で示した例では、COBOLプログラムはターゲットのサービスをユビキタスなWebSphere MQキュー名を使用して処理します。COBOLプログラムに関する限り、ターゲットのサービスは別のメインフレーム上に存在でき、Java、PHP、さらに言えば、Web上のどこにでも実装可能です。ESBは、サービスがどこに実装されているか、または少なくともリクエストをそこへ転送する方法を把握しています。
• ESBは、ターゲットのサービスの特異性からメインフレームコードを隔離することを担当します。技術が急速に進化する世界で、ターゲットのサービスが変化するときにCOBOLプログラムを修正する必要性が減ります。
• メインフレームプログラムは複雑なワークフローに容易に参加できます。この記事で示した単純化したアクションパイプラインの代わりに、JBoss jBPMまたはActive Endpoints ActiveBPELがプロセスワークフローおよびサービスオーケストレーションに、アクティブな参加者としてメインフレームプログラムを提供します。
• XML Schema、JAXB、JAX-WS、JMS、またはHTTPなどの、標準のオープンな技術の使用により、大規模コミュニティが存続できることを保証します。これは、一部アセンブラで記述された、ブラックボックスで、プロプライエタリで、進化の遅い、現在のメインフレーム中心のSOAPスタックとは全く対照的です。
• 生成された成果物はすべてオープンワールドフレンドリーです。たとえば、Javaコード、XML Schema、XML設定ファイルなどです。このため、統合成果物を、Javaコミュニティに普及している強力なツールで管理することが可能です。
• メインフレームのフットプリントが削減されます。私たちのシナリオでは、メインフレーム上に外国技術は一切存在しませんでした。COBOLコンパイラおよびWebSphere MQで十分でした（代わりに、HTTPを使用できます）。変換やXML処理などの、CPUに負担をかけるアクティビティはすべて、メインフレーム外の、CPUがよりチープなプラットフォーム上で発生します。

COBOLおよびメインフレームアプリケーションは今後ずっと存続するでしょう。こうした多くのアプリケーションは、その目的を非常に効果的に果たします。同時に、オープンワールドなアプリケーションは、SOAおよびESBを礎石として備え、その規模と重大性を拡大しています。このような状況において、ESB中心のメインフレーム統合は、考慮に値する固有の利点をもたらします。

著者について

原文はこちらです：http://www.infoq.com/articles/legacy-integration