
z/OS 用の Liberty のための最適化されたローカル・アダプターの使用シナリオ
実践的なシナリオにより、最適化されたローカル・アダプターおよびサポート・ネイティブ API 呼び出し可能サービスが z/OS® プラットフォームでのエンタープライズ・アーキテクチャーおよびアプリケーション開発にどのようにメリットをもたらすことができるのかを示します。
WebSphere® Optimized Local Adapters (WOLA) は、z/OS バッチ、顧客情報管理システム (CICS®)、および UNIX System Services 環境内の既存のネイティブ言語によるビジネス・アプリケーションおよびミドルウェア・アプリケーションに、Liberty でエンタープライズ JavaBeans (EJB) アプリケーションとして実装されている Java™ アプリケーションを呼び出す代替手段を提供します。最適化されたローカル・アダプターを使用することで、Java EE Connect Architecture (JCA) バージョン 1.5 を使用して、ローカルまたは同じ論理区画 (LPAR) 上で実行されている外部サーバー・プログラムに対して Liberty アプリケーションから呼び出すこともできます。
最適化ローカル・アダプターでパフォーマンスを向上させることができるシナリオの 1 つは、サーバーおよびクライアント Web サービスを使用するための CICS サポートです。ターゲットとなるバックエンド・アプリケーションは、XML や SOAP メッセージング・テクノロジーの代わりに最適化ローカル・アダプターを使用して、より効率的に、別の場所にあるビジネス・ロジックを呼び出すことができます。
以下の現実に沿った架空のシナリオで、最適化されたローカル・アダプターがさまざまなビジネス目標を達成するためにどのように役立つかについて説明します。
金融サービス会社のシナリオ
z/OS バッチでビジネス・アプリケーションを実行している IBM® z/OS 金融サービスのお客様が、取引所に株取引をリアルタイムで報告するための新しいサポートを提供する金融処理アプリケーションの購入について決定する必要があります。 このようなスタイルのリアルタイム報告が可能であれば、お客様にとっては収益の増加につながります。
リアルタイムで報告を行うアプリケーションは、Windows 8 上で実行される Liberty サーバー上の Java Enterprise Edition (Java EE) アプリケーションです。アプリケーションは、さまざまな種類の対話のために呼び出すことができるエンタープライズ Bean および関連する Web サービス・インターフェースのセットを提供します。
バッチ COBOL プログラムから Java EE アプリケーションを呼び出すテスト・シナリオが開発され、正常に実装されました。 したがって、お客様はさらに進んで、より厳しいテストを行うことにしました。さらなるテストで、このメカニズムに 1 秒当たり 50-100 超の要求が課されると、応答時間がお客様の要件を満たせない点まで低下することがわかりました。バッチのビジネス・アプリケーションと新しいベンダー・アプリケーションの間でリアルタイムの情報交換を行うための、より現実的な方法が使用可能になるまで、この取り組みは中止されることになりました。
最適化されたローカル・アダプターは、このバッチのお客様に、z/OS 用の Liberty をデプロイし、バッチ・アプリケーションを更新して、最適化されたローカル・アダプターの起動または要求送信の API を使用するオプションを提供できます。これらの API によって、Web サービスのビジネス・ロジックを呼び出す、ローカルの Liberty サーバー上にデプロイされた EJB アプリケーションを呼び出す方法が提供されます。
保険会社のシナリオ
- DB2® から直接収集される情報
- CICS でプログラムを呼び出すことによって収集される情報
- Web サービスを開始して、別の会社が提供するリモート・サービスと通信することによって収集される情報
お客様は、いくつかの理由から Java アプリケーションを使用することを選択しましたが、最も重要な理由は、お客様のプログラミング・スキルの大部分が Java ベースであるためです。新しいアプリケーションをテストしてみると、情報を取得するときの応答時間が長いことがわかりました。 この応答時間の遅さは、Liberty サーバーが分散サーバー上で実行されることと、Web サービスおよび SOAP メッセージを使用して CICS を呼び出すときの DB2 とのリモート通信にかかわる遅延が原因です。
問題を修正するために、お客様は同じ構成内に複数の Liberty サーバーをデプロイし、各サーバーでの 1 秒当たりの要求数を減らし、要求を別々のネットワーク・パスに分散しました。
このお客様は、最適化ローカル・アダプターを使用することで、複数のサーバーをデプロイする以外の方法を選択できます。お客様は、DB2 および CICS 環境に近い、z/OS 上の Liberty サーバーにアプリケーションをインストールできます。Liberty サーバーから CICS への呼び出しで最適化されたローカル・アダプター API を使用すると、Web サービスおよび SOAP ソリューションよりもパフォーマンスが大幅に向上します。z/OS プラットフォームに統合することで、フロア・スペースを占拠し、維持のために電力とリソースを消費する分散サーバーの増設の必要性が低減します。このシナリオでは、データとアプリケーションの場所が決定的要因なので、リモート・サーバーのサイズを使用可能な最も堅固なものにまで増大させても、必ずしも問題は解決しません。
z/OS 用の Liberty へのビジネス・ロジックのマイグレーション
あるお客様が、CICS の内部で COBOL を使用したアプリケーション・ロジックを何年も実行してきました。このお客様は、Java テクノロジーおよび Java EE テクノロジーを活用するためにこれらのアプリケーションの一部を Liberty にマイグレーションし、WebSphere スタック内の他の機能を使用しようと考えています。
アプリケーションの 1 つは一度にマイグレーションするには大きすぎるため、お客様はその部分部分を徐々に Liberty サーバーに移動したいと考えています。CICS が提供するトランザクションおよびセキュリティーのサービス品質をマイグレーション中も維持する必要があり、また、マイグレーションによるパフォーマンスへの悪影響を最小限に抑える必要があります。最適化されたローカル・アダプターを使用すると、アプリケーションの部分を Liberty にマイグレーションし、1 つのステートレス・セッション Bean にラップすることができます。最適化ローカル・アダプターを使用してステートレス・セッション Bean を呼び出すために、COBOL アプリケーション・ロジックを変更できます。 それらの Liberty サーバーへの呼び出しは、CICS 領域内の COBOL プログラムが使用しているのと同じトランザクションおよびセキュリティー・コンテキストの下で実行されます。Web サービスを使用して同様の呼び出しを実行する場合と比較すると、大幅なパフォーマンス向上があります。お客様は、アプリケーションがマイグレーションされるまで、Liberty サーバーへのアプリケーションの部分的な再配置を続けることができます。