はじめに

このマニュアルでは、BEA WebLogic Integration ソリューションをプロダクション環境にデプロイする方法について説明します。以下の節では、WebLogic Integration を組織にデプロイする際の主要な概念およびタスクを紹介します。

• デプロイメントの目標

• 主要なデプロイメント タスク

• 統合ソリューション デプロイメントのロール

• デプロイメントのアーキテクチャ

• 主要なデプロイメント リソース

 

---

デプロイメントの目標

WebLogic Integration は、企業が新しいアプリケーションを開発し、それらを既存システムに統合し、ビジネス プロセスを効率化し、トレーディング パートナに接続するための機能を提供する、単一の統合化されたプラットフォームです。WebLogic Integration ソリューションをデプロイする場合は、以下の目標について検討してください。

• 高可用性。デプロイメントは、ハードウェアやネットワークで障害が発生したときにはフェイルオーバーが機能し、可用性が十分に確保されていなければなりません。

• パフォーマンス。デプロイメントでは、負荷のピーク時でもそれ以外のときでも十分なパフォーマンスが発揮されなければなりません。

• スケーラビリティ。デプロイメントでは、コードの変更ではなくハードウェア リソースを追加するだけで、予期される負荷の増加に対応できる必要があります。

• セキュリティ。デプロイメントでは、無認可アクセスや改ざんからデータが十分に保護されなければなりません。

WebLogic Integration デプロイメントでは、これらの目標やそれ以外の目標も達成することができます。

 

---

主要なデプロイメント タスク

WebLogic Integration のデプロイには、以下のタスクの一部またはすべてを実行する必要があります。

1. WebLogic Integration デプロイメントの目標の定義。デプロイメントの目標を参照してください。

2. WebLogic Integration アプリケーションのクラスタへのデプロイ。そのためには、まず、クラスタを設計する必要があり、設計に着手するにあたっては、WebLogic Integration デプロイメントのコンポーネントを理解する必要があります。WebLogic Integration クラスタについてで、用途に最適の環境を設計する上で役立つこれらのコンポーネントについて説明します。

3. 高可用性を実現するための、クラスタ環境への WebLogic Integration アプリケーションのデプロイ。そのためには、アプリケーションをクラスタ デプロイメントのコンフィグレーションの説明に従ってコンフィグレーションする必要があります。

4. WebLogic Integration デプロイメントのセキュリティ設定。WebLogic Integration セキュリティの使い方を参照してください。

5. パフォーマンスのチューニングの説明に従ったシステム全体のパフォーマンスの最適化（WebLogic Integration デプロイメントの起動後）。

 

---

統合ソリューション デプロイメントのロール

統合ソリューションのデプロイメントを成功させるには、デプロイメント チームに、以下のロールを遂行するメンバーが参加している必要があります。

• デプロイメント スペシャリスト

• WebLogic Server 管理者

• データベース管理者

一人で複数のロールを担当することができ、また、すべてのロールがあらゆるデプロイメント シナリオで等程度の関連性を持つわけではありませんが、デプロイメントを成功させるには、各ロールを担当するメンバーによる協力が必要です。

デプロイメント スペシャリスト

デプロイメント スペシャリストは、デプロイメント作業を調整します。デプロイメント スペシャリストは、WebLogic Integration 製品の機能について十分な知識を持っています。1 つまたは複数のサーバ上で WebLogic Integration の各種の機能をコンフィグレーションする方法についての知識に基づいて、統合ソリューションのデプロイメント トポロジの設計に際して専門的な判断を下します。デプロイメント スペシャリストは、以下の分野の経験を持っています。

• リソース要件の分析

• デプロイメント トポロジの設計

• プロジェクトの管理

WebLogic Server 管理者

WebLogic Server 管理者は、組織にデプロイされている WebLogic Server に関する深い技術知識と運用知識を提供します。ハードウェアおよびプラットフォームに関する知識があり、インストール、コンフィグレーション、モニタ、セキュリティ、パフォーマンスのチューニング、トラブルシューティングなどの管理作業をはじめとする WebLogic Server デプロイメントのあらゆる面を管理した経験があります。

データベース管理者

データベース管理者は、組織にデプロイされているデータベース システムに関する深い技術知識と運用知識を提供します。WebLogic Server 管理者は、以下の分野の経験を持っています。

• ハードウェアおよびプラットフォームに関する知識

• リレーショナル データベース（RDBMS）のあらゆる側面を管理した経験。インストール、コンフィグレーション、モニタ、セキュリティ、パフォーマンスのチューニング、トラブルシューティングなどの管理作業が含まれます。

 

---

デプロイメントのアーキテクチャ

次の図は、WebLogic Integration デプロイメントのアーキテクチャの概要を示しています。

図1-1 WebLogic Integrationデプロイメントのアーキテクチャ

 

次の節では、図で説明したこれらのリソースについて説明します。

 

---

主要なデプロイメント リソース

ここでは、デプロイメント時に変更可能なリソースの概要を説明します。

• WebLogic Server リソース

• Business Process Management リソース

• B2B Integration リソース

• Application Integration リソース

• リレーショナル データベース管理システム リソース

• ハードウェア、オペレーティング システム、およびネットワークのリソース

WebLogic Server リソース

この節では、WebLogic Integration ソリューションのデプロイメントに最も関連性の高い BEA WebLogic Server リソースの概要を説明します。これらのリソースをコンフィグレーションするには、WebLogic Server Administration Console または EJB デプロイメント記述子を使用します。

WebLogic Server には、WebLogic Integration ソリューションをサポートされている環境に合わせてデプロイするためのコンフィグレーション オプションおよび調整可能な設定が用意されています。以下の節では、WebLogic Integration デプロイメントに最も関連性の高い WebLogic Server でコンフィグレーションできる機能について説明します。

• クラスタ化

• Java Message Service

• EJB プールおよびキャッシュ

• JDBC 接続プール

• 実行スレッド プール

• J2EE コネクタ アーキテクチャ

クラスタ化

負荷処理能力を拡大するため、WebLogic Server をクラスタ、つまり 1 つの単位として管理可能な一群のサーバ上で実行することができます。クラスタ化すると、1 つのサーバよりもスケーラブルなデプロイメント プラットフォームを実現できます。クラスタ化の詳細については、WebLogic Integration クラスタについてを参照してください。

Java Message Service

WebLogic Java Message Service (JMS) を使用すると、メッセージを交換（作成、送信、および受信）するメッセージング システムを Java アプリケーション間で共有できます。WebLogic JMS は、Sun Microsystems, Inc. の Java Message Service 仕様バージョン 1.0.2 に基づいています。

JMS サーバはクラスタ化できるので、接続ファクトリを WebLogic Server の複数のインスタンス上にデプロイすることができます。また、JMS イベントの送り先をコンフィグレーションして、ワークフローの通知およびメッセージを処理することもできます。Business Process Management リソースを参照してください。

WebLogic JMS の詳細については、以下のトピックを参照してください。

• 次の URL にある『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の概要」

  http://edocs.beasys.co.jp/e-docs/wls/docs70/jms/intro.html

• JMS のコンフィグレーションおよびモニタの詳細については、次の URL にある『BEA WebLogic Server 管理者ガイド』の「JMS の管理」を参照してください。

  http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/jms.html

EJB プールおよびキャッシュ

WebLogic Integration デプロイメントでは、EJB の数がシステムのスループットに影響します。システム内の EJB の数を調整するには、EJB の型に応じて、EJB プールまたは EJB キャッシュを使用します（プールおよびキャッシュのサイズのコンフィグレーションについては、その他の EJB のプール サイズおよびキャッシュ サイズをコンフィグレーションするを参照）。次の表では、EJB のタイプとそれらに関連付けられた調整可能なパラメータについて説明します。

表1-1 EJB の調整に使用するパラメータ

グループ名	説明	リソース グループの種類
イベント リスナ メッセージ駆動型 Bean	max-beans-in-free-pool 1.	キューから作業を取り出すリスナの最大数。
ステートレス セッション Bean	max-beans-in-free-pool1	作業要求に利用できる Bean の最大数
ステートフル セッション Bean	max-beans-in-cache	同時にアクティブにできる Bean の数設定値が小さすぎると、CacheFullExceptions が発生します。設定値が大きすぎると、メモリ使用量が非常に大きくなります。
エンティティ Bean

¹WebLogic Server マニュアルでは、max-beans-in-free-pool ではなく、実行スレッドの数を設定することを推奨しています。ただし、WebLogic Integration 環境では、実行スレッドの数を設定するよりも、イベント リスナ メッセージ駆動型 Bean の max-beans-in-free-pool 設定を指定することによって負荷を制御する方が効率的です。

 

JDBC 接続プール

Java Database Connectivity (JDBC) を使用すると、Java アプリケーションから SQL データベース内のデータにアクセスできます。データベース接続の確立に関連するオーバーヘッドを抑えるため、WebLogic JDBC には、DBMS との接続ですぐに利用できる接続プールが用意されています。

JDBC 接続プールは、DBMS 接続を最適化するために使用されます。JDBC 接続プールのサイズをコンフィグレーションすることで、WebLogic Integration のパフォーマンスをチューニングできます。WebLogic Integration クラスタにおける JDBC 接続プールのサイズの決定に関する詳細は、JDBC 接続プールのサイズをコンフィグレーションするを参照してください。設定値が小さすぎると、接続が利用可能になるまでの WebLogic Integration の待機時間が長くなります。設定値が大きすぎると、DBMS のパフォーマンスが低下します。

WebLogic JDBC 接続プールの詳細については、以下の節を参照してください。

• 次の URL の『WebLogic JDBC プログラマース ガイド』、「WebLogic JDBC の概要」の「接続プールの概要」

  http://edocs.beasys.co.jp/e-docs/wls/docs70/jdbc/intro.html

• 次の URL の『BEA WebLogic Server 管理者ガイド』の「JDBC接続の管理」

  http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/jdbc.html

実行スレッド プール

実行スレッド プールによって、WebLogic Server 上で同時に実行可能なスレッド数が決まります。設定値が小さすぎると、順次処理が行われるようになるので、デッドロックが発生する可能性があります。設定値が大きすぎると、メモリ使用量が非常に大きくなり、スラッシングが発生する可能性があります。

実行スレッド プールは、実行する可能性のあるすべてのスレッドを実行できるだけの大きさに設定しますが、システム内でのコンテキストの過剰な切り替えによりパフォーマンスが低下するほどには大きくしないでください。実行スレッド数によって、着信ソケット メッセージを読み出すスレッド（socket-reader スレッド）の数も決まります。この数は、デフォルトでは、実行スレッド数の 3 分の 1 です。数が小さすぎると、ソケットを読み出すスレッドの競合が発生し、デッドロックが発生する場合があります。稼働システムを監視して、スレッド プールの最適の値を経験的に決定してください。

実行スレッド プールのコンフィグレーションについては、実行スレッド プールをコンフィグレーションするを参照してください。

実行スレッド プールの調整に関するこれらの推奨事項は、WebLogic Integration のパフォーマンスの最適化に役立ちます。ただし、WebLogic Integration 環境では、メッセージ駆動型 Bean の数を制御することが負荷を抑える方法として最適です（EJB プールおよびキャッシュ参照）。

J2EE コネクタ アーキテクチャ

WebLogic J2EE コネクタ アーキテクチャ（JCA）は、J2EE プラットフォームと 1 つまたは複数の異種エンタープライズ情報システム（EIS）を統合します。WebLogic JCA は、Sun Microsystems, Inc. の J2EE コネクタ仕様、バージョン 1.0、最終草案 2 に基づいています。

WebLogic J2EE-CA の詳細については、次の URL にある『BEA WebLogic Server 管理者ガイド』の「WebLogic J2EE コネクタ アーキテクチャの管理」を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/jconnector.html

Business Process Management リソース

WebLogic Integration では、Business Process Management (BPM) 機能を使用して、ビジネス プロセスを定義および実行します。BPM 機能の概要については、『WebLogic Integration 入門』の「Business Process Management」を参照してください。

以下の節では、WebLogic Integration ソリューションをデプロイするための BPM 機能について説明します。

• BPM リソースの概要

• BPM リソースの種類

• BPM 作業シーケンス

BPM リソースは、クラスタ、つまり 1 つの単位として管理可能な一群のサーバ上で動作するようにコンフィグレーションできます。クラスタ化および BPM の詳細については、WebLogic Integration クラスタについてを参照してください。

BPM リソースの概要

次の図は、クラスタ内の 1 つのノード用の BPM リソースを示しています。

図1-2 BPM EJB リソース

 

次のBPM リソースの種類,の節では、これらのリソースについて説明します。

BPM リソースの種類

BPM では、WebLogic JMS（Java Message Serviceを参照）を使用して、エラーや監査メッセージだけでなく、ワークリスト、時刻、およびイベント通知もやり取りします。BPM クライアント アプリケーションは、これらのメッセージを XML イベントとして JMS イベント キューに送信します。BPM では、イベント リスナ メッセージ駆動型 Bean を使用して、イベント キューに送られた XML イベントを処理し、BPM エンジンの実行中のインスタンスに配信します。

WebLogic Server Administration Console を使用してカスタム メッセージ キューを作成し、MDB Generator ユーティリティを実行して、キューでイベントをリスンするイベント リスナ Bean を生成し、新しいイベント リスナ Bean を認識するよう BPM のコンフィグレーションを更新します。詳細については、新しいプールを作成するを参照してください。

以下の節では、BPM をクラスタ環境に合わせてコンフィグレーションしたり、BPM のパフォーマンスをチューニングしたりする際に使用できるリソースの種類について説明します。

• ワークフロー プロセッサ Bean

• イベント リスナ メッセージ駆動型 Bean

• テンプレート Bean

• テンプレート定義 Bean

• インスタンス Bean

• イベント キュー

• Worklist コンソール（非推奨）

ワークフロー プロセッサ Bean

ワークフロー プロセッサ Bean は、開始/イベント ノードから停止/イベントノード（静止状態から静止状態）まで進むワークフローを実行するステートフル セッション Bean です。ワークフロー プロセッサ Bean は、イベント リスナ Bean、Worklist クライアント、および他のワークフロー プロセッサ Bean からの作業を受け入れます（サブワークフロー使用時）。

ワークフロー プロセッサ Bean はシステムの負荷に基づいて実行時に開始されるため、実行時のワークフロー プロセッサ Bean の正確な数は絶えず変化します。一度にアクティブになるワークフロー プロセッサ Bean の数は、ワークフロー プロセッサ Bean プールのサイズによって決まります。Bean の数がプールのサイズを超えると、プール内の Bean が利用可能になるまで、超過分の Bean のパッシベーションが行われます。一般に、プールのサイズは、小さすぎるよりも大きすぎる方が問題は少なくなります。詳細については、その他の EJB のプール サイズおよびキャッシュ サイズをコンフィグレーションするを参照してください。

ワークフロー プロセッサ Bean はクラスタにデプロイされます。WebLogic Server は、クラスタ内の各ノードがワークフロー プロセッサ Bean のローカル コピーを使用するように、クラスタ化システムを最適化します。

イベント リスナ メッセージ駆動型 Bean

イベント リスナ メッセージ駆動型 Bean は、イベント キューから作業を取り出し、ワークフロー プロセッサ Bean に送信します。イベント リスナ Bean は、ワークフロー プロセッサ Bean が実行を完了するか、新しい作業をキューから取り出す前に静止状態に達するまで、待機します。

イベント リスナ Bean は、順序付けされていないメッセージ用のプール サイズがコンフィグレーションされており、順序付けされているメッセージには一連の単一 Bean（使用可能なプール サイズ 1 を設定した名前付き Bean）からなるプールを使用します。『BPM クライアント アプリケーション プログラミング』の「JMS 接続の確立」にある「複数のイベント キューに対するメッセージ駆動型 Bean の生成」を参照してください。

これらのプールの組み合わせによって、イベントから開始された場合に同時に実行できるワークフロー数が決定されます。

テンプレート Bean

テンプレート Bean は、実行するワークフロー テンプレートを格納するエンティティ Bean です。通常、テンプレート エンティティ Bean プールのサイズは、同時に実行するワークフロー テンプレート（インスタンス数ではなくワークフロー数）の最大数と等しくする必要があります。一般に、プールのサイズは、小さすぎるよりも大きすぎる方が問題は少なくなります。テンプレート エンティティ Bean はクラスタ化できる（クラスタ対応スタブ）ので、クラスタ内の他のノードのワークフロー プロセッサ Bean で使用できます。

テンプレート定義 Bean

テンプレート定義 Bean は、実行するワークフロー テンプレート定義を格納するするエンティティ Bean です。

ビジネス プロセスは、データベースにワークフロー テンプレートとして保存されます。これらのテンプレートは、異なるバージョンのワークフローを保存できるように、基本的には空のコンテナです。また、複数の組織に関連付けることができます。テンプレートには、テンプレート定義が格納されますが、それらは、同じワークフローの異なるバージョンで、有効期限によって区別されます。ビジネス プロセスおよびワークフローの詳細については、『WebLogic Integration Studio ユーザーズ ガイド』を参照してください。

通常、テンプレート定義エンティティ Bean プールのサイズは、同時に実行するワークフロー テンプレート（インスタンス数ではなくテンプレート数）の最大数と等しくする必要があります。一般に、プールのサイズは、小さすぎるよりも大きすぎる方が問題は少なくなります。テンプレート定義エンティティ Bean はクラスタ化できる（クラスタ対応スタブ）ので、クラスタ内の他のノードのワークフロー プロセッサ Bean で使用できます。

インスタンス Bean

インスタンス Bean は、実行中のワークフロー インスタンスを格納するエンティティ Bean です。通常、インスタンス エンティティ Bean プールのサイズは、ワークフロー プロセッサ Bean プールのサイズと等しくする必要があります。インスタンス エンティティ Bean プールのサイズをワークフロー プロセッサ Bean の数より大きくしても利点はありません。一般に、プールのサイズは、小さすぎるよりも大きすぎる方が問題は少なくなります。インスタンス エンティティ Bean はクラスタ化できる（クラスタ対応スタブ）ので、クラスタ内の他のノードのワークフロー プロセッサ Bean で使用できます。

イベント キュー

1 つの JAR ファイルには、特定のキューに関して順序付けされたイベント リスナ メッセージ駆動型 Bean と順序付けされていない イベント リスナ メッセージ駆動型 Bean が格納されています。WebLogic Integration をインストールすると、デフォルトの EventQueue からのメッセージを消費するmessage-driven bean が入った wli-mdb-ejb.jar ファイルが提供されます。この JAR ファイルは、クラスタを対象とする必要があります。また、新しいプールを作成するで説明するように、新しいイベント キューを作成することもできます。クラスタ内の BPM イベント キューの詳細については、クラスタにおける BPM 機能のロード バランシングを参照してください。

注意: クラスタでの BPM 機能の規模を拡大するには、新しいイベント キューを作成する必要があります。

Worklist コンソール（非推奨）

Worklist クライアントには、BPM API からワークフローを作成するユーザ コードだけでなく、Swing ベースの WebLogic Integration Worklist コンソールも含まれています。図1-2 には、コンテキストのみに関して示されています。Worklist コンソールは実行時にコンフィグレーション可能なリソースではないからです。

BPM 作業シーケンス

次の図は、イベントを処理する場合の BPM EJB 間の会話を示しています。

図1-3 イベント処理時の BPM EJB 間の会話

 

BPM イベント リスナ Bean は、デフォルトまたはユーザ定義のイベント キューから作業要求を受け取ると、ワークフロー プロセッサ Bean を作成してその要求を処理します。ワークフロー プロセッサ Bean は、ワークフローが停止ノードまたはイベント ノードに達するまで、ワークフローを実行します。ワークフローが別のワークフローを呼び出した場合、新しいワークフロー プロセッサ Bean が作成され、呼び出し元ワークフローはそのワークフロー プロセッサ Bean を終了しません。

テンプレート Bean とテンプレート定義 Bean は、ワークフローの実行開始時に読み出されます。インスタンス Bean はワークフロー実行の開始時に読み出され、ワークフローがトランザクション境界（イベント ノードや終了ノードなど）で静止したときに書き込まれます。

イベント駆動型ワークフローの場合、ワークフロー プロセッサ Bean を追加作成してもデプロイメントの作業量は変わりません。同時に処理可能なワークフロー インスタンスの数は、イベント リスナ Bean の数によって制限されます。

B2B Integration リソース

WebLogic Integration をクラスタ化ドメインにデプロイする際、すべての B2B Integrationリソースは、管理サーバ用リソースを除いて、クラスタ内の同種サーバに均一にデプロイする必要があります。つまり、高可用性、スケーラビリティ、パフォーマンスの向上を実現するためには、B2B integration リソースは、1 つのドメイン内でクラスタ化されたすべてのサーバを対象とする必要があります。クラスタ化および B2B Integration の詳細については、クラスタ デプロイメントの設計を参照してください。

B2B Integration リソースは必要に応じて動的に割り当てられる場合が多く、デプロイメントを事前にコンフィグレーションすることはできません。B2B の負荷に対応してにコンフィグレーションできるリソースの詳細については、『B2B Integration 管理ガイド』の「コンフィグレーション要件」を参照してください。

B2B Integration の機能を使用するクラスタには、共用ファイル システムが必要です。Storage Area Network (SAN) またはマルチポート型のディスク システムをお勧めします。

注意: XOCP ビジネス プロトコルに基づく WebLogic Integration アプリケーションは、クラスタ環境ではサポートされません。

Application Integration リソース

以下の節では、WebLogic Integration がサポートしている Application Integration リソースの種類について説明します。

• 同期サービス呼び出し

• 非同期サービス呼び出し

• イベント

• アプリケーションビューと接続ファクトリ

クラスタ化および Application Integration の詳細については、WebLogic Integration クラスタについてを参照してください。

Application Integration 機能は、WebLogic Integration 製品に統合されていますが、単独の独立した J2EEear ファイルとしても入手できます。したがって、任意の有効な WebLogic ドメイン上に Application Integration をデプロイすることができます。たとえば、Web サービス開発者 や WebLogic Portal 開発者は、アプリケーション ビューを使用して、EIS アプリケーションと会話することができます。WebLogic Integration 環境の外部への Application Integration のデプロイに関する詳細については、『Application Integration ユーザーズ ガイド』の「Application Integration のモジュラ デプロイメント」を参照してください。

同期サービス呼び出し

同期呼び出しを使用するのは、基盤となる EIS が要求に迅速に応答できる場合、またはクライアント アプリケーションが待機できる場合です。

次の図は、同期サービス呼び出しのフローを示しています。

図1-4 同期サービス呼び出し

 

同期サービス呼び出しでは、クライアント（図中ではワークフロー プロセッサ）がアプリケーション ビュー EJB (ステートレス セッション Bean) を呼び出します。アプリケーション ビューは、同期 Common Client Interface (CCI) 呼び出しを使用して サービス アダプタを呼び出します。サービス アダプタは、実際に要求を処理する J2EE-CA サービス アダプタです。

注意: ワークフローが EIS のクライアントとしての役割を果たす場合、ワークフロー プロセッサは、ワークフロー プロセッサ Bean と場合によってはイベント リスナ Bean も一緒に、要求が完了するまでストールします。スループットを最適化するため、基盤となる EIS システムが要求に迅速に応答できない限り、非同期呼び出しを使用することを検討してください。

非同期サービス呼び出し

次の図は、WebLogic Integration の非同期サービス処理を示しています。

図1-5 非同期サービス呼び出し

 

注意: WebLogic Integration クラスタ内の分散送り先として、WLAI_ASYNC_REQUEST_QUEUE キューおよびWLAI_ASYNC_RESPONSE_QUEUE キューがデプロイされています。非同期サービス要求プロセッサはmessage-driven bean (wlai-asyncprocessor-ejb.jar) で、これもクラスタにデプロイされています。高可用性を実現するための Application Integration リソースのデプロイ方法の詳細については、高可用性を備えた JMSを参照してください。

上の図は、Application Integration の非同期サービスの以下に説明するプロセス フローを示したものです。

1. アプリケーション ビューのクライアントがアプリケーション ビューのインスタンスを開始します。

   クライアントには、構築時に恒久 ID を定義するオプションが与えられています。恒久クライアント ID は、非同期応答メッセージに対する相関 ID として使用されます。

   クライアントは invokeServiceAsync メソッドを呼び出して、要求 IDocument を非同期サービス応答（AsyncServiceResponse）リスナに渡して、応答を処理させます。

2. アプリケーション ビューのインスタンスは AsyncServiceRequest オブジェクトを作成して、WLAI_ASYNC_REQUEST_QUEUE に送信します。

   AsyncServiceRequest オブジェクトには、応答リスナが対象とする送り先の名前が格納されています。The AsyncServiceProcessor message-driven bean は、この情報を使用して、応答の物理送り先を決定します。

   応答オブジェクトに、応答の送り先の名前が入っていない場合は、AsyncServiceProcessor message-driven bean は、JMS メッセージ用に指定されている送り先を使用します（JMSReplyTo() メソッドへの呼び出しにより）。

   そのクライアントのみが AsyncServiceResponseListener をアプリケーション ビューに提供しているとします。

   invokeServiceAsync(String serviceName, IDocument request,
   AsyncServiceResponseListener listener);

   このシナリオでは、アプリケーション ビューは、アプリケーション ビュー EJB メソッドの getAsyncResponseQueueJNDIName() によって定義される JNDI ロケーションに結び付けられた JMS キューに受信者を確立します。アプリケーション ビューのインスタンスは、QueueReceiver.getQueue() を使用して、要求メッセージに対して ReplyTo 送り先を設定します。

3. クラスタでは、WLAI_ASYNC_REQUEST_QUEUE キューは分散 JMS キューとしてデプロイされます。ただし、各メッセージは、1 つの物理キューに送信されるので、そのキューからのみ取り出すことができます。その物理キューが、メッセージがそこから取り出される前に使用できなくなると、物理キューが手動 JMS の移行またはサーバの再起動によって再び使用できるようになるまで、そのメッセージ（非同期サービス要求）は、使用できないままになります。

   分散キューにメッセージを送信しただけでは、そのキューの QueueReceiver によって必ず受信されるとはかぎりません。メッセージは 1 つの物理キューにのみ送信されるため、その物理キューでリスンしている QueueReciever が必要です。この要件を満足するため、AsyncServiceProcessor (wlai-asyncprocessor-ejb.jar) をクラスタ内のすべてのノードにデプロイする必要があります。

   AsyncServiceProcessor message-driven bean は、FIFO (先入れ先出し) 方式でメッセージを受信します。

   AsyncServiceProcessor は、JMS ObjectMessage にある AsyncServiceRequest オブジェクトを使用して、アプリケーション ビューの完全修飾名、サービス名、要求ドキュメントおよび応答送り先を決定します。

4. AsyncServiceProcessor は、アプリケーション ビュー EJB を使用して、サービスを同期的に呼び出します。このサービスは、リソース アダプタに対する同期 CCI ベースの要求または応答メッセージに変換されます。

5. AsyncServiceProcessor はその応答を受け取ります。その後、この応答は、AsyncServiceResponse オブジェクトとしてカプセル化され、AsyncServiceRequest オブジェクトで指定された応答の送り先に送信されます（この場合は、WLAI_ASYNC_RESPONSE_QUEUE_myserver1）。

   AsyncServiceProcessor は、分散送り先（WLAI_ASYNC_RESPONSE_QUEUE）ではなく指定された物理送り先（WLAI_ASYNC_RESPONSE_QUEUE_myserver1）に応答を送信する必要があります。物理送り先のキューは、アプリケーション ビュー EJB のgetAsyncResponseQueueJNDIName() メソッドが呼び出されたときにクライアント上で実行されているアプリケーション ビューのインスタンスによって確立されています（詳細は、手順 2. 参照）。

   注意: 受け取るべきすべての応答メッセージを受信する前に、クライアント アプリケーションに障害が発生することもあります。障害からの回復後に、クライアントと JMS 応答キューの関連付けが障害発生前のとおりに回復されていることを確認するには、回復後も、以前と同じクライアント ID を使用する必要があります。次のリストは、回復コードの例です。障害発生前と回復後で同じユニークなクライアント ID を使用することにより、クライアントと JMS 応答キューとのこのような関連付けをサポートしています。

   String uniqueClientID = "uniqueClientID";

   ApplicationView myAppView = new ApplicationView(jndiContext,
   "MyAppView", uniqueClientID);

   myAppView.recoverAsyncServiceResponses(new MyAsyncResponseListener()); 

6. アプリケーション ビューのインスタンス開始時に作成されたアプリケーション ビュー メッセージ リスナのインスタンスは、AsyncServiceResponse メッセージを JMS ObjectMessage として受信し、手順 2. で示した invokeServiceAsync() 呼び出しで指定された AsyncServiceResponseListener に渡します。

イベント

Application Integration アダプタは、BPM または WebLogic Workshop によって消費されるイベントを生成します。イベントは、アプリケーション ビューから JMS キュー（WLAI_EVENT_QUEUE）へ転送されます。このキューは、複数の物理送り先が格納された分散送り先です。message-driven bean (WLI-AI Event プロセッサ) は WLAI_EVENT_QUEUE 分散送り先でリスンします。

WLI-AI イベント プロセッサは以下のタスクを実行します。

• イベントのコピーを、BPM イベント プロセッサに配信（BPM がインストールされていて、サーバ インスタンスで実行されている場合）またはアプリケーション ビューの WebLogic Workshop Control イベント プロセッサに配信（このコントロールを使用している場合）します。

  各イベントのコピーが正確に 1 つずつ BPM または WebLogic Workshop に配信されます。

• イベントのコピーを WLAI_EVENT_TOPIC に公開する。

  WLAI_EVENT_TOPIC は、分散 JMS トピックで、リモートのアプリケーション ビュー クライアントへのイベントの配信を処理します。アプリケーション ビュー クラスが WLAI_EVENT_TOPIC に EventContext を作成します。EventContext クラスによって、アプリケーション ビューの名前に基づいてメッセージのフィルタリングが行われます。アプリケーションビューの名前は SourceKey JMS ヘッダ プロパティに格納されています。SourceType は ApplicationView です。

• 処理に失敗した場合にキューにメッセージがロール バックできるように、トランザクションを通じてイベントをキューから取り出す。

次の図は、WebLogic Integration のイベント処理を示しています。

図1-6 イベント

 

上の図は、次に説明するイベント処理手順のフローを示しています。

1. イベントはエンタープライズ情報システム（EIS）で発生し、次のような仕組みで JMS キューに送信されます。

   1. イベントが EIS で発生します。

   2. イベント データがリソース アダプタのイベント ジェネレータに送信されます。イベント ジェネレータは、EIS 固有データを XML ドキュメントに変換し、IEvent オブジェクトをイベント ルータ（アダプタ イベント ルータ）にポストします。

   3. イベント ルータは、特定のイベント タイプに関心のある各 Application Integration サーバに対して、IEvent オブジェクトを EventContext オブジェクトに渡します。

   4. EventContext は IEvent オブジェクトを JMSObjectMessage としてカプセル化し、JMS QueueSender を使用して、com.bea.wlai.EVENT_QUEUE という JNDI コンテキストにバインドされている JMS キューに送信します。

2. ObjectMessage WLAI_EVENT_QUEUE に格納されて、WLI-AI Event プロセッサ message-driven bean (wlai-eventprocessor-ejb.jar) によって FIFO で処理されます。

   クラスタでは、 WLAI_EVENT_QUEUE キューは分散 JMS キューとしてデプロイされます。ただし、各メッセージは、1 つの物理キューに送信され、送り先の物理キューからのみ使用できます。その物理キューが、メッセージがそこから取り出される前に使用できなくなると、物理キューが再びオンラインに戻るまでは、そのメッセージ（すなわち、イベント）は使用できないままになります。

   分散キューにメッセージを送信しただけでは、その分散キューの QueueReceiver によって必ず受信されるとはかぎりません。メッセージは 1 つの物理キューにのみ送信されるので、その物理キューでリスンしている QueueReciever が必要です。この要件を満足するため、WLI-AI Event プロセッサ message-driven bean (wlai-eventprocessor-ejb.jar) をクラスタ内のすべてのノードにデプロイする必要があります。

3. WLI-AI Event プロセッサ message-driven bean (wlai-eventprocessor-ejb.jar) がイベントの送り先のリストを決定する。

   1. イベントの送り先が AIDestinationMBean に追加されます。イベント送り先の同一リストが各管理対象サーバのイベントプロセッサ message-driven beanに渡されるように、MBean はクラスタ全体で複製されます。WLI-AI BPM プラグイン（wlai-plugin-ejb.jar）は、デプロイ時に BPM イベント キューをイベントの送り先として追加します。この送り先を追加することにより、EIS イベントを BPM プロセス エンジンに送信することが可能になります。また、アプリケーション ビューのイベント リスナが登録されていると、イベントは WLAI_EVENT_TOPIC に送信されます。

   2. WLI-AI イベント プロセッサ message-driven bean が、イベントを送信するためのイベント送り先のリストを MBean から読み込みます。

4. ObjectMessage イベントが 1 つの JTA ユーザ トランザクション内のすべての登録済みイベント送り先に配信される。メッセージがどのイベント送り先へも配信されない場合は、WLAI_EVENT_QUEUEにロール バックされます。WLAI_EVENT_QUEUE は、不良メッセージは WebLogic Integration エラー送り先（com.bea.wli.FailedEventQueue）に転送するようにコンフィグレーションされています。FailedEventQueue の詳細については、エラー送り先を参照してください。

   注意: イベントの送り先は通常、JMS の送り先なので、システムがイベントの転送に失敗する可能性はほとんどありません。

アプリケーションビューと接続ファクトリ

これまでの節で説明した実行時 Application Integration 機能（同期サービス呼び出し、非同期サービス呼び出し、およびイベント）をクラスタ化することにより、スケーラビリティと可用性が向上します。設計時 Application Integration 機能（アプリケーション ビューおよび接続ファクトリ）をクラスタ化することにより、スケーラビリティが向上しますが、可用性を高めることはできません。つまり、アプリケーション ビューは、クラスタ内のサーバが実行されていない場合はデプロイもアンデプロイ（編集）も不可能です。言い換えれば、デプロイおよびアンデプロイ（編集）は、健全なクラスタにおいてのみ可能です。

リソース アダプタ（RAR）は、wlai-admin.ear アーカイブファイルを、クラスタ化された管理対象サーバにではなく、管理サーバにデプロイすることによりアップロードされます。2 段階デプロイメントが行われます。管理サーバ上のWebLogic Deployer ユーティリティが、管理サーバへのデプロイメントをコントロールします。

次の図は、設計時の接続ファクトリ デプロイメントを示しています。

図1-7 接続ファクトリ デプロイメント

 

アプリケーション ビューのデプロイメントの成否は、接続ファクトリのデプロイメントが正常に行われるかどうかによります。クラスタ化環境への Application Integration アダプタのデプロイメントの詳細については、クラスタにおける Application Integration 機能のロード バランシングおよびアダプタのデプロイを参照してください。

リレーショナル データベース管理システム リソース

WebLogic Integration は、実行時の処理を行うためやアプリケーション データの永続性を保証するためにデータベース リソースを利用します。データベースのパフォーマンスは、WebLogic Integration 全体のパフォーマンスに大きく影響します。詳細については、データベースのチューニングを参照してください。

ハードウェア、オペレーティング システム、およびネットワークのリソース

ハードウェア、オペレーティング システム、およびネットワークのリソースは、WebLogic Integration のパフォーマンスに重要な影響を与えます。したがって、デプロイメントは、『WebLogic Integration リリース ノート』で説明されているハードウェアおよびソフトウェア要件に準拠している必要があります。プロダクション環境で最大限のパフォーマンスを引き出すためのリソースのコンフィグレーションの詳細については、推奨ハードウェアおよびソフトウェアおよびハードウェア、オペレーティング システム、およびネットワークのリソースのチューニングを参照してください。