| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > WebLogic Integration ソリューションのデプロイメント > WebLogic Integration クラスタについて |
|
WebLogic Integration ソリューションのデプロイメント
|
WebLogic Integration クラスタについて
以下の節では、WebLogic Integration をクラスタ環境でコンフィグレーションおよびデプロイメントする方法について説明します。内容は以下のとおりです。
WebLogic Integration クラスタについて
クラスタ化すると、1 つの単位として管理可能なサーバ群で WebLogic Integration を実行できます。クラスタ環境では、複数のマシンが負荷を分担します。WebLogic Integration は、リソース要求がすべてのマシン間で均等に分散されるようにロード バランシング機能を提供します。WebLogic Integration デプロイメントでは、クラスタ化とロード バランシングを使用してノード間で負荷を分散することで、スケーラビリティを向上できます。クラスタ化すると、1 つのサーバよりもスケーラブルなデプロイメント プラットフォームを実現できます。
WebLogic Server ドメインは、ただ 1 つの管理サーバと 1 つまたは複数の管理対象サーバで構成されます。WebLogic Integration ドメイン内の管理対象サーバをクラスタにまとめることができます。WebLogic Integration のクラスタ対応リソースをコンフィグレーションする場合、そのリソースのデプロイ対象とするクラスタを指名します。クラスタをリソース デプロイメントの対象として指定すると、管理対象サーバをクラスタに追加することによって能力を動的に増大できるという利点が得られます。
ここでは、クラスタ環境で WebLogic Integration をコンフィグレーションする場合に必要な情報について説明します。WebLogic Server がクラスタをサポートする方法についても背景知識として取り上げますが、クラスタ環境に合わせた WebLogic Integration のコンフィグレーションに固有の手順が中心です。
読み進む前に、WebLogic Server マニュアルの以下の節の内容を確認し、クラスタ化について十分に理解しておくことをお勧めします。
http://edocs.beasys.co.jp/e-docs/wls/docs70/cluster/index.html
http://edocs.beasys.co.jp/e-docs/wls/docs70/cluster/config.html
http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/WLSTuning.html
クラスタ デプロイメントの設計
以下の節では、クラスタ デプロイメントの設計に必要な情報について説明します。
WebLogic Integration ドメイン入門
クラスタ化したドメインに合わせてアーキテクチャを設計する前に、WebLogic Server クラスタがどのように運用されるかを知っておく必要があります。
ドメインを作成する
ドメインおよびクラスタの作成は、WebLogic Integration、Business Process Management (BPM)、または Enterprise Application Integration (EAI) の機能に基づいて、ドメイン テンプレートからドメインが生成ができるConfiguration Wizardにより簡素化されています。ユーザのクエリに基づいて、Configuration Wizard によって、ドメイン、サーバ、エンタープライズ アプリケーションなどが、コンフィグレーション済みの適切なコンポーネントおよび資産を含めて生成されます。さまざまなドメインに利用できるテンプレートの詳細については、次のURLにある『コンフィグレーション ウィザード テンプレート リファレンス』を参照してください。
http://edocs.beasys.co.jp/e-docs/platform/docs70/template/index.htm
Configuration Wizardによる WebLogic Integration ドメイン作成の詳細については、クラスタ デプロイメントのコンフィグレーションを参照してください。
クラスタ サーバ
サーバには管理対象サーバと管理サーバがあります。管理サービスを実行する WebLogic Server は管理サーバと呼ばれ、Administration Consoleのホストとなります。複数の WebLogic Serverが稼働しているドメインでは、そのうち 1 つのみが管理サーバで、他のサーバは管理対象サーバと呼ばれます。各管理対象サーバは、起動時に管理サーバからコンフィグレーションを取得します。
概要については、次の URL にある WebLogic Server マニュアルの『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/cluster/index.html
推奨する基本的な多層プロキシ アーキテクチャの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アーキテクチャ」を参照してください。
クラスタおよび管理ドメインに関する注意
WebLogic Server の管理ドメインがクラスタ ドメインとは別のものである場合、（WebLogic Server クラスタが別の管理ドメインに属するノードを持つ場合）もありますが、WebLogic Integration デプロイメントの場合は、クラスタ ドメインが管理ドメインとなるように設計する必要があります。
WebLogic Integration リソースのデプロイメント
クラスタ化されたドメインの各サーバに対して、そのドメイン内のサーバの機能を定義するさまざまな属性をコンフィグレーションできます。これらの属性は Administration Console の Servers ノードを使用してコンフィグレーションされます。
この節では、WebLogic Integration リソースおよびクラスタ内でのそれらのパーティショニングと分散化について説明します。内容は以下のとおりです。
クラスタ対応リソース
表 2-1 では、WebLogic Integration デプロイメントのリソースについて説明します。内容は以下のとおりです。
リソース グループには 2 種類あります。
一部のリソース名には、以前のリリースの WebLogic Integration から受け継いだ略語が使用されているので注意してください。
次の表では、WebLogic Integration デプロイメントのリソースについて説明します。
WebLogic Integration の 2 段階デプロイメント システムのメッセージ処理が開始される前にすべての WebLogic Integration アプリケーション コンポーネントをデプロイすることが大切です。それを保証するため、WebLogic Integration デプロイするときはを TwoPhase 属性を指定します。サンプルの config.xml ファイルからの次の抜粋は、WebLogic Integration のデプロイメントを指定する application 要素を示しています。 コード リスト 2-1 WebLogic Integration アプリケーションのデプロイメント 分散に関するガイドライン WebLogic Integration クラスタ デプロイメントは以下のガイドラインに従って行われます。
1リソース名はユーザ定義パッケージまたはリソース グループを表しています。
2wlai-admin.ear は、WebLogic Integration をクラスタにデプロイする場合にのみデプロイする必要があります。シングル ノード環境にデプロイする場合はデプロイしないでください。Application Integration コンポーネントの詳細については、クラスタにおける Application Integration 機能のロード バランシングを参照してください。
3たとえば、DBMS サンプル イベント アダプタはシングル ノードにデプロイされます。詳細については、アダプタのマニュアルを参照。
4イベントおよびサービス アダプタは 1 つの EAR ファイルに格納されますが、別々にデプロイされ、WebLogic Server Administration Console では別個のリソースとして示されます。詳細については、WebLogic Integration の 2 段階デプロイメントの節を参照してください。
<Domain Name="MyCluster">
...
<Application Name="WebLogic Integration" Path="WLI_HOME/lib"
TwoPhase="true">
...
リソースの対象としてクラスタを指定する
WebLogic Integration リソースのデプロイメントで示したとおり、ほとんどの WebLogic Integration リソースは、クラスタ内のすべてのサーバにデプロイされます。このデプロイメントは、使用ドメインのコンフィグレーション ファイル（config.xml）で指定されます。
WebLogic Server Administration Console を使用して、コンポーネントの対象としてクラスタ内のノードを指定することができます。詳細については、クラスタ デプロイメントのコンフィグレーションを参照してください。
次のリストは、クラスタ ドメイン用のコンフィグレーション ファイルの抜粋で、BPM コンポーネントが指定されています。このリストは、これらのコンポーネントの対象として、MyCluster というクラスタが指定されていることを示しています。
コード リスト 2-2 WebLogic Integration コンポーネントの対象としてクラスタを指定する
<Application Deployed="true" Name="WebLogic Integration"
Path="C:/bea/weblogic700/integration/lib" TwoPhase="true">
<!--Repository-->
<EJBComponent Name="WLI Repository" Targets="MyCluster"
URI="repository-ejb.jar" />
<!--BPM-->
<EJBComponent Name="WLI-BPM Server" Targets="MyCluster"
URI="wlpi-ejb.jar" />
<EJBComponent Name="WLI-BPM Event Processor"
Targets="MyCluster" URI="wlpi-mdb-ejb.jar" />
<EJBComponent Name="WLI-BPM Master Components"
Targets="MyServer-1" URI="wlpi-master-ejb.jar" />
<EJBComponent Name="WLI-BPM Initialization"
Targets="MyCluster" URI="bpm-init-ejb.jar"/>
...
</Application>
上のリストでは、WLI-BPM マスタ コンポーネント（wlpi-master-ejb.jar）以外のすべての BPM コンポーネントの対象として、このクラスタが指定されています。表 2-1 で指定されているとおり、クラスタ内の 1 つのサーバ（この場合は MyServer-1）に、WLI-BPM マスタ コンポーネントをデプロイする必要があります。
WebLogic Integration アプリケーションにおけるデプロイメントの順序
次のファイルでは、WebLogic Integration のすべてのコンポーネントが指定されています。
WLI_HOME¥lib¥META-INF¥application.xml
コンポーネントは、application.xml にリストされている順序でデプロイされるので、ファイルにリストする順序は変更しないでください。指定された順序は、コンポーネント間の依存関係を表しているので重要です。このアプリケーションには、BPM 機能がアクセスする必要のある EJB プラグインおよび BPM プラグインが組み込まれています。
カスタム リソース（カスタムのプラグインや EJB、message-driven bean など）を WebLogic Integration アプリケーションにデプロイする場合は、application.xml ファイルを編集して新しいコンポーネントを指定する必要があります。
警告: カスタムの新しいリソースが BPM へのプラグインでない場合は、カスタムリソースは、application.xml ファイルの最後のエントリとして指定することができます。それがBPM へのプラグインである場合は、新しいコンポーネントは最後から 2 番目のエントリとして指定します。すなわち、bpm-init-ejb.jar モジュールの直前、アプリケーション内の他のすべてのモジュールの後に指定してください。
bpm-init-ejb.jar モジュールは、application.xmlの最後に指定されます。
<module>
<ejb>bpm-init-ejb.jar</ejb>
</module>
デフォルト Web アプリケーションをデプロイする
デフォルトでは、WebLogic Integration ドメイン テンプレートのいずれかに基づいてドメインを作成すると、そのドメインには、管理サーバにデプロイされる Web サーバのコンフィグレーションが格納されます。すると、この Web サーバのコンフィグレーションによって、デフォルトの Web アプリケーション（DefaultWebApp）が指定されます。
このデフォルトの Web アプリケーションに対するデプロイメント記述子（web.xml）は、次の場所にあります。
DOMAIN_HOME¥applications¥DefaultWebApp_myserver¥WEB-INF¥
上の行で、DOMAIN_HOME は作成したドメインのパス名を表しています。
Web アプリケーションには、サーブレット、Java Server Pages (JSP)、JSP タグ ライブラリなどのアプリケーションのリソースや HTML ページおよびイメージ ファイルなどの静的リソースが格納されます。
カスタム JSP および HTML ページをデプロイする
カスタムの JSP または HTML ページを WebLogic Integration アプリケーションの一環としてデプロイする場合は、それらの JSP や HTML ページは、次のディレクトリに配置する必要があります。
DOMAIN_HOME¥applications¥DefaultWebApp_node
上のパスで、 DOMAIN_HOME は、Configuration Wizard を使用して作成したカスタム ドメインのルート ディレクトリを表し（手順 2. WebLogic Integration ドメインの作成参照）、node はクラスタ内の WebLogic Server インスタンスの名前を表しています。
Web サーバは、クラスタ内のノードごとにコンフィグレーションする必要があります。config.xml ファイルからの以下の抜粋は、次の要素を示しています。
（関係のある情報は強調するため、以下のリストでは太字で表記されている）。
コード リスト 2-3 config.xml ファイルに格納された管理対象サーバ用 WebServer 要素
<Server Name="managedserver1" ...
...
<WebServer Name="managedserver1" DefaultWebApp="DefaultWebApp_node"
HttpsKeepAliveSecs="120" KeepAliveSecs="60"
LogFileName="C:/bea/user_projects/mydomain/logs/access.log"
LoggingEnabled="true"/>
...
</Server>
:
<Application Deployed="true" Name="DefaultWebApp_node"
Path="C:/bea/weblogic700/samples/integration/config/samples/RN2Security/
config/peer2/applications"
StagedTargets="" TwoPhase="false">
<WebAppComponent IndexDirectoryEnabled="true"
Name="DefaultWebApp_node" Targets="managedserver1"
URI="DefaultWebApp_node"/>
</Application>
上のリストでは、WebServer 要素の DefaultWebApp 属性は、デフォルトの Web アプリケーション コンポーネントを参照します。このリストには、デフォルト Web アプリケーションのコンフィグレーションも示されています。このデフォルト Web アプリケーションは、JSP および HTML ページが格納されているディレクトリを参照します（node はクラスタ内のサーバ名を表している）。
Web アプリケーションのデプロイメントに関する詳細は、次の URL にある『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/webapp/index.html
管理サーバに関する注意
あるクラスタの管理サーバが使用できなくなると、デプロイ要求やアンデプロイ要求は中断されますが、管理対象サーバは要求の処理を続行します。管理対象サーバは、既存のコンフィグレーションを使用して起動および再起動することができます。ただし、管理サーバが復帰するまで、クラスタのコンフィグレーションを変更することはできません（たとえば、クラスタへの新しいノードの追加などは不可）。詳細については、Administration Server に対するバックアップとフェイルオーバを参照してください。
WebLogic Integration クラスタにおけるロード バランシング
WebLogic Integration アプリケーションをクラスタ化する目的の 1 つは、スケーアラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバを十分に活用する必要があります。ロード バランシングにより、クラスタ内のすべてのサーバ間で負荷が均等に分散され、各サーバがそれぞれ最大能力で動作できるようになります。以下の節では、さまざまな機能分野についての、WebLogic Integration クラスタでのロード バランシングについて説明します。
クラスタにおける WebLogic Server 機能のロード バランシング
WebLogic Server は、HTTP セッション ステートおよびクラスタ オブジェクトのロード バランシングをサポートしています。詳細は、次の URL にある『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/cluster/features.html
クラスタにおける BPM 機能のロード バランシング
BPM ワークフローには、イベントベースのワークフローを処理するためのイベント キューが必要です。詳細については、Business Process Management リソースを参照してください。
イベント キューと関連プール
各 BPM イベント キューには次の 2 種類のプールが関連付けられます。
次の図は、イベント キューとその関連プールを示しています。
図2-1 イベント キューと関連プール
順序付けされていないメッセージ駆動型 Bean は、非決定的な順序でメッセージを処理します。メッセージの読み出しは先入れ先出し（FIFO）方式ですが、読み出し後は、スレッドのスケジューリングおよび処理時点の負荷に応じて、任意の順序でメッセージを処理できます。 順序付けされたイベント リスナ メッセージ駆動型 Bean では、特定の順序キー（WLPIOrderKey）に従ってメッセージが処理されます。このために、クラスタ内で 1 つのイベント リスナ メッセージ駆動型 Bean を、WLPIOrderKey に関するメッセージ処理用にコンフィグレーションする必要があります。 順序キーは整数値でなければならず、その値は受け取った順序で処理させたいすべてのイベントで同じでなければなりません。また、順序指定メッセージは、同じ JMSキューに送信する必要があります。メッセージ プロデューサは、正しい順序でメッセージをキューに転送する必要があります。 WLPIOrderKey は、BPM で使用するカスタム JMS プロパティです。このプロパティは、WebLogic Integration Studio で設定するか、次のように、プログラム的に設定します。
1 つの JAR ファイル（wlpi-mdb-ejb.jar）には、特定のキューに関して順序付けされたイベント リスナ メッセージ駆動型 Bean と順序付けされていない イベント リスナ メッセージ駆動型 Bean が格納されています。wlpi-mdb-ejb.jar ファイルで定義されている message-driven bean は、デフォルトの EventQueue からのメッセージを消費します。この JAR ファイルは、クラスタを対象とする必要があります。
BPM のロード バランシングは、wlpi-mdb-ejb.jar をクラスタにデプロイすることによって達成されます。この JAR ファイルには、5 つの順序付きイベント リスナ メッセージ駆動型 Bean と 5 つの順序なしイベント リスナ メッセージ起動型 Bean が格納されています。message-driven bean は、分散送り先からのメッセージを消費してイベントキューを検証するか、検証を拒否します。分散送り先には、JMS サーバごとに物理送り先が 1 つ、WebLogic Server のインスタンスごとに JMS サーバが 1 つ指定されています。分散キューの各メッセージ プロデューサは、それぞれ 1 つの物理送り先にバインドされています。メッセージ駆動型 Bean は、デプロイ先のサーバ内の物理送り先にバインドされています（サーバ親和性がある、という）。サーバ親和性の利用とは、メッセージが、その処理中に、同じ JVM および WebLogic Server インスタンス内に保持されることになります。したがって、あるプロデューサから分散送り先に送信された順序付きメッセージは、同じ順序付きmessage-driven bean によって消費されることが保証されます。このプロセスによって、メッセージの順序付き配信が保証されます。
新しいプールを作成する
1 つのサーバに十分な処理能力がある場合は、メッセージ駆動型 Bean 数の確認するで説明するように、wli-mdb-ejb.jar ファイルのイベント リスナ メッセージ駆動型 Bean のサイズおよび範囲を大きくすることができます。
カスタムの JMS キューおよびイベント リスナの作成方法の詳細については、『WebLogic Integration の起動、停止およびカスタマイズ』、「WebLogic Integration のカスタマイズ」の「カスタム Java Message Service キューのコンフィグレーション」を参照してください。
BPM 機能のロード バランシングの要件
WebLogic Integration クラスタで BPM 機能をロード バランシングする場合、以下の要件を考慮してください。
注意: この記述は、XML 検証実行中の検証キューにも当てはまります、デフォルトの検証 イベント キューは com.bea.wlpi.ValidatingEventQueue です。
時限イベント
イベントおよび検証イベントキュー用のmessage-driven bean 同様、時限イベント リスナも、wlpi-mdb-ejb.jar ファイルで指定されたクラスタにデプロイされます。これらのmessage-driven bean は、com.bea.wli.bpm.TimerQueueから作業を取り出します。
時限イベントは、JMS 配信時刻を使用して実装されます。時限イベントは、次の 2 種類のプールによって実行されます。
クラスタにおける Application Integration 機能のロード バランシング
すべて同種のクラスタ、つまりすべてのリソースが同じ管理対象サーバを対象としているクラスタをコンフィグレーションすることができます。ただし、アダプタ自身の制約があります。
BPM 機能とは対照的に、JMS キューおよびサーバを使用して、クラスタ内で Application Integration の機能をロード バランシングできます。
クラスタ デプロイメントでは、1 つの EJB （wlai-admin-ejb.jar）を管理サーバのみにデプロイする必要があります。この EJB はwlai-admin.ear アーカイブファイルからデプロイされます（WebLogic Integration リソースのデプロイメントの表 2-1 を参照）。
注意: wlai-admin-ejb.jar はクラスタ デプロイメントのみに必要です。WebLogic Integration を単独のサーバにデプロイする場合、wlai-admin.ear はデプロイしないでください。
以下のコードは、クラスタ ドメイン用の config.xml ファイルの抜粋です。クラスタにおけるwlai-admin.ear ファイルのデプロイメント指定を示しています。
コード リスト 2-4 config.xml ファイルにおける wlai-admin EJB のデプロイメント
<Application Name="WLI-AI Admin Server Only"
Path="WLI_HOME/lib/wlai-admin.ear" TwoPhase="true">
<EJBComponent Name="WLI-AI RAR Upload" Targets="admin_server_name"
URI="wlai-admin-ejb.jar"/>
</Application>
クラスタにおける B2B Integration 機能のロード バランシング
B2B Integration 機能は、クラスタ内での作業のパーティショニングを要求しません。そのような機能をサポートするためには、完全に同質的なクラスタをコンフィグレーションする必要があります。言い換えれば、すべての B2B リソース（JMS のコンシューマ、送り先、およびプロデューサ）を、クラスタ内のすべてのノードで利用できます。
クラスタにおける B2B Integration 機能のロード バランシングを、デフォルトの JMS キューおよびサーバを使用して行うことができます。
B2B Integration リソースは、クラスタ内のすべてのノードに対して均一にデプロイされます。したがって、B2B エンジンをシャット ダウンする必要が生じた場合、クラスタ内のすべてのノードの B2B エンジンがシャット ダウンされます。クラスタ内の 1 つのノードの B2B エンジンのみをシャット ダウンすることはできません。その場合は、まず、そのノードをクラスタから削除する必要があります。
WebLogic JMS は、分散送り先を使用することによって、複数の物理送り先にわたるメッセージング負荷を均衡することができ、その結果、リソースがより効果的に活用され、応答時間が短縮されます。WebLogic JMS のロード バランシング アルゴリズムは、メッセージの送信先となる物理送り先（分散送り先のセット内の）およびコンシューマが割り当てられる物理送り先を決定します。メッセージ駆動型 Bean は、デプロイ先のサーバ内の物理送り先にバインドされています（サーバ親和性）。メッセージが、特定のサーバ上の特定の物理送り先（キュー）に送信されると、そのサーバがメッセージを処理します。
B2B Integration 機能は、クラスタ環境におけるサーバ親和性を備えたヒューリスティクなインメモリ キャッシュ機能を利用しています。B2B のメッセージ処理を実行する際は、B2B デコーダがその B2B メッセージのメッセージ エンベロープを、BPM JMS イベント キューに追加します。BPM message-driven bean は、そのメッセージをキューから取り出し、その後の処理を実行するために B2B 固有プラグインが呼び出されます。B2B 固有プラグインは、メッセージ ID、トレーディング パートナ、配信チャネル（URI） を使用して、MessageStore インメモリ キャッシュからメッセージ ペイロードを取り出します。このように、B2B Integration 機能はインメモリ キャッシュ機能を活用することができ、その結果、パフォーマンスが向上します。
WebLogic Integration クラスタの高可用性
メッセージ駆動型 Bean は、JMS の送り先からのメッセージを消費します。各 WebLogic Integration 送り先にはいくつかのmessage-driven bean が各送り先にデプロイされています。WebLogic Integration 送り先（JMS キューとトピック）の詳細なリストについては、JMS サーバと JMS 送り先を参照してください。
高可用性を備えた JMS
WebLogic JMS の実装により、複数の物理送り先を単一の分散送り先のメンバーとしてコンフィグレーションできる能力を通じて、きわめて高い可用性がもたらされます。具体的には、管理者は、クラスタ内の各ノードに対して、各分散送り先に対する物理送り先を 1 つ、コンフィグレーションする必要があります。クラスタ内のあるノードに障害が発生して、そのノードの物理送り先が使用できなくなった場合、分散送り先のメンバーとしてコンフィグレーションされた他の物理送り先が、JMS のプロデューサとコンシューマにサービスを提供することができます。
JMS サーバおよびそのすべての送り先は、クラスタ内の別の WeLogic Server に移行できるため、クラスタ環境で単独の送り先としてデプロイされる必要のある送り先についても、高可用性を実現することができます。ただし、そのための移行は手動で行われるので、送り先の単独デプロイはお勧めできません。
メッセージ駆動型 Bean は、分散送り先からのメッセージを消費します。分散送り先には、WebLogic Server のインスタンスごとに、物理送り先が 1 つ格納されています。分散キューの各メッセージ プロデューサは、それぞれ 1 つの物理送り先にバインドされています。メッセージ駆動型 Bean は、デプロイ先のサーバ内の物理送り先にバインドされています（サーバ親和性）。したがって、あるプロデューサから分散送り先に送信された順序付きメッセージは、同じ順序付きmessage-driven bean によって消費されることが保証されます。このプロセスにより、メッセージの順序付けられた配信、および クラスタにおける B2B Integration 機能のロード バランシングで説明した B2B キャッシュ機能が保証されます。
クラスタ内の管理対象サーバに障害が発生した場合、そのサーバのmessage-driven beanはアトミックに移行されますが、複数のメッセージ処理を防止するため、自動的移行は行われません。
次の節では、WebLogic Integration がクラスタ デプロイメントにおいて、分散送り先およびサーバ親和性を利用して高可用性を実現する例を説明します。
非同期サービス要求に対する高可用性
WebLogic Integration クラスタでは、WLAI_ASYNC_REQUEST_QUEUE キューおよび WLAI_ASYNC_RESPONSE_QUEUE キューが、分散送り先としてデプロイされます。非同期サービス要求プロセッサは、関連付けられたメッセージ駆動型 EJB で、クラスタ内のすべてのサーバにデプロイされます。非同期の要求および応答は、それらを受け入れた JMS サーバがクラッシュした後でも、処理されます。
message-driven bean が同期サービス要求を受信する前に物理キューに障害が発生すると、その要求は、この物理キューが再びオンラインに復帰するまで使用できなくなります。非同期サービス応答についても同様です。
同期呼び出しおよび非同期呼び出しの処理に関する詳細については、Application Integration リソースを参照してください。
イベント転送に対する高可用性
Application Integration アダプタは、BPM 機能または WebLogic Workshop によって消費されるイベントを生成します。イベントは、アプリケーション ビューから JMS キュー（WLAI_EVENT_QUEUE）へ転送されます。
イベントについてのメタデータを取得するには、イベント ルータが HTTP を使用して WebLogic Integration インスタンスと会話する必要があります。イベント ルータのコールバック交信に対してロード バランシングと高可用性を実現したいが、クラスタ アドレスに DNS 名は使用していないという場合は、wlai.clusterFrontEndHostAndPort プロパティを設定する必要があります。このプロパティの詳細については、wlai.clusterFrontEndHostAndPort プロパティの設定（オプション）を参照してください。
WLAI_EVENT_QUEUE は、複数の物理送り先が格納された分散送り先です。message-driven bean (AI Event プロセッサ) は WLAI_EVENT_QUEUE 分散送り先でリスンします。このキューのメッセージ処理には複数のサーバが関与するので、1 つのサーバに障害が発生しても対応できます。アダプタ イベントの WebLogic Integration による処理については、イベントを参照してください。
JMS リソース
この節では、クラスタ環境で WebLogic Integration アプリケーション用の JMS リソースをコンフィグレーションする方法について説明します。具体的には、以下のリソースのコンフィグレーション方法について説明します。
JMS リソースは、WebLogic Server Administration Console でコンフィグレーションされます。コンソールを起動するには、『WebLogic Integration の起動、停止およびカスタマイズ』、「WebLogic Integration 管理ツールと設計ツール」の「WebLogic Server Administration Console の起動」を参照してください。
JMS 接続ファクトリ
以下の JMS 接続ファクトリは、管理サーバおよびクラスタ化された管理対象サーバのある WebLogic Integration ドメインでコンフィグレーションされます。
次のリストは、WebLogic Integration クラスタにおける JMA 接続ファクトリのサンプル仕様を示しています。接続ファクトリの Target と JNDI name は太字で表記されています。
コード リスト 2-5 config.xml ファイルの JMSConnectionFactory 要素
...
<!--Application Integration Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="false"
DefaultDeliveryMode="Persistent" DefaultPriority="4"
DefaultTimeToLive="0"
JNDIName="com.bea.wlai.JMSConnectionFactory"
MessagesMaximum="10" Name="WLIJMSConnectionFactory"
OverrunPolicy="KeepOld" Targets="MyCluster"
UserTransactionsEnabled="true"/>
<!--B2B Integration Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wli.b2b.server.TopicConnectionFactory"
Name="B2BTopicFactory" Targets="MyServer-1"
UserTransactionsEnabled="true"/>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wli.b2b.rosettanet.QueueConnectionFactory"
Name="RNQueueFactory" Targets="MyCluster"
UserTransactionsEnabled="true"/>
<!--BPM Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wlpi.TopicConnectionFactory"
Name="wlpiFactory" Targets="MyCluster"
UserTransactionsEnabled="true"/>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wlpi.QueueConnectionFactory"
Name="wlpiQueueFactory" Targets="MyCluster"
UserTransactionsEnabled="true"/>
...
JMS JDBC ストア
JMS JDBC ストアは、デプロイメント内の JMS サーバごとに定義する必要があります。
次のリストは、config.xml ファイルの抜粋で、myserver 管理サーバの管理下にある 2 つの管理対象サーバ（MyServer-1 および MyServer-2）を含むクラスタ（MyCluster）の JMS JDBC ストアを定義しています。接続プールの対象（Target）として、クラスタと管理サーバの両方がリストされている点に注意してください。
コード リスト 2-6 config.xml ファイルの JMSJDBCStore 要素
<JMSJDBCStore ConnectionPool="wliPool"
Name="JMSWLCStore-MyServer-1" PrefixName="MyServer_1"/>
<JMSJDBCStore ConnectionPool="wliPool"
Name="JMSWLCStore-MyServer-2" PrefixName="MyServer_2"/>
<JMSJDBCStore ConnectionPool="wliPool" Name="JMSWLCStore-myserver"
PrefixName="myserver"/>
...
<JDBCConnectionPool CapacityIncrement="1"
DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="1"
LoginDelaySeconds="1" MaxCapacity="15" Name="wliPool"
Properties="user=scott;password=tiger;dll=ocijdbc8;protocol=thin
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="myserver,MyCluster"
URL="jdbc:oracle:thin:@machine:port:name"/>
JMS サーバと JMS 送り先
JMS サーバは、クラスタ内の各管理対象サーバに対して 1 つずつ、管理サーバに対して 1 つコンフィグレーションする必要があります（管理サーバとしてコンフィグレーションされた JMS サーバには、表 2-2で示されているように、送り先（B2B トピック）は 1 つのみデプロイされる）。JMS サーバについては、以下の命名規約の使用をお勧めします。WLI_JMSServer_node。ここで、node は JMS サーバがデプロイされているサーバの名前を表します。
次の表では、WebLogic Integration が使用する送り先（JMS キューとトピック）について説明し、それらが単独の送り先として指定されているのか、分散送り先として指定されているのか示します。
次のリストは、config.xml ファイルの抜粋です。管理サーバ（myserver）の管理下にある 2 つの管理対象サーバ（MyServer-1 および MyServer-2）を含むクラスタ コンフィグレーションとして選択された要素を示しています。 コード リスト 2-7 config.xml ファイルの JMSServer 要素 このリストの以下の点に注意してください。
1com.bea.wli.FailedEventQueue 送り先は、WebLogic Integration のすべてのコンポーネントによって使用されます。この送り先は、JTA UserTransaction のメッセージを消費する JMS 送り先のエラー送り先として使用します。エラー キューに関する詳細については、エラー送り先を参照してください。
<!--Distributed Destinations-->
<JMSDistributedQueue JNDIName="com.bea.wli.bpm.EventQueue"
Name="WLI_BPM_Event" Targets="MyCluster"> <JMSDistributedQueueMember JMSQueue="WLI_BPM_Event_MyServer-1"
Name="WLI_BPM_Event_MyServer-1"/>
<JMSDistributedQueueMember JMSQueue="WLI_BPM_Event_MyServer-2"
Name="WLI_BPM_Event_MyServer-2"/></JMSDistributedQueue>
<!--Administration Server-->
<JMSServer Name="WLI_JMSServer_myserver"
Store="JMSWLCStore-myserver" Targets="myserver"
TemporaryTemplate="TemporaryTemplate">
<JMSTemplate Name="TemporaryTemplate"/>
<JMSTopic JNDIName="com.bea.wli.b2b.server.B2BTopic"
Name="B2BTopic"/>
</JMSServer><!--Managed Server-->
<JMSServer Name="WLI_JMSServer_MyServer-1"
Store="WLI_JMSJDBCStore_MyServer-1" Targets="MyServer-1 (migratable)" <JMSQueue JNDIName="com.bea.wli.bpm.Event.MyServer-1"
Name="WLI_BPM_Event_MyServer-1" StoreEnabled="true"
Template="WLI_JMSTemplate-1"/>...
<JMSTopic JNDIName="com.bea.wli.bpm.EventTopic"
Name="wlpiEvent" StoreEnabled="false"/>...
</JMSServer>
エラー送り先
com.bea.wli.FailedEventQueue は、JTA User Transaction に格納されているメッセージを消費する JMS 送り先に対するエラー送り先です。たとえば、EventQueue、ValidatingEventQueue、TimerQueue などのエラー送り先となります。対象とする BPM ワークフロー インスタンスが見つからないメッセージや、1 分間に何回も再試行に失敗するメッセージは、FailedEventQueue に送信されます（デフォルトの再試行回数は 10 回ですが、別の回数に設定することもできる）。JMS メッセージが FailedEventQueue に到着すると、そのキューでリスンする message-driven bean (com.bea.wli.common.errorlistener.ErrorListenerBean) が、WebLogic Server ログにログ エントリを書き込みます。
エラー キューが使用する JMS テンプレートである WLI_JMSTemplate-node で再配信のための属性をコンフィグレーションして、再試行の回数を指定することができます。エラー キューは、分散送り先で、再配信属性はノード固有の物理送り先に対してコンフィグレーションされ、WLI-FailedEvent-node と名付けられます（この名前については、node は名前このクラスタ内の WebLogic Server インスタンスを表している）。
JMS テンプレートの再配信属性をコンフィグレーションする方法の詳細については、次の URL にある『Adminstration Console オンライン ヘルプ』の「JMS」で、「[JMS テンプレート] → [コンフィグレーション] → [再配信]」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/domain_jmstemplate_config_redelivery.html
さらに、カスタム メッセージ リスナを作成するオプションもあり、それをクラスパスに追加して、FailedEventQueue message-driven bean のデプロイメント記述子でリフレッシュできます。そうすることで、エラー メッセージを永続化するようにシステムをコンフィグレーションできます。
ストアを作成して接続プールと関連付ける
ストアを作成し、接続プールに関連付けるには、次の手順を実行します。
JMS サーバを作成しストアを関連付ける
JMS サーバを作成し、JMSJDBCStore に関連付けるには、次の手順を実行します。
アダプタのデプロイ
Application Integration リソースで説明した実行時 Application Integration 機能（同期サービス呼び出し、非同期サービス呼び出し、およびイベント）をクラスタ化することにより、スケーラビリティと可用性を高めることができます。設計時に利用できる Application Integration 機能（アプリケーション ビューおよび接続ファクトリ）をクラスタ化することにより、スケーラビリティを高めることができますが、可用性を高めることはできません。つまり、クラスタ内に実行されていないサーバがあれば、アプリケーション ビューをデプロイまたはアンデプロイ（編集）することができません。言い換えれば、デプロイおよびアンデプロイ（編集）は、健全なクラスタにおいてのみ可能です。
Application Integration アダプタは通常、次の 3 つのコンポーネントで構成されています。
リソース アダプタ ファイル（RAR）と設計時 Web アプリケーション（WAR）ファイルは、クラスタにデプロイする必要があります。イベント ジェネレータ Web アプリケーション（WAR）ファイルは、ほとんどの場合、クラスタ内の 1 つのサーバにデプロイします（具体的な説明は、アダプタのマニュアルを参照）。
たとえば、DBMS アダプタが使用されている場合、DbmsEventRouter Web アプリケーションは、クラスタ内の 1 つのサーバを対象としている必要があります。次のリストは、config.xml ファイルの抜粋です。ここでは、DBMS アダプタをデプロイするためのコンフィグレーションを指定する application 要素が示されています。
コード リスト 2-8 Application Integration アダプタをデプロイするためのコンフィグレーション
<Application Deployed="true" Name="BEA_WLS_DBMS_ADK" Path="/bea/weblogic700/integration/adapters/dbms/lib/
BEA_WLS_DBMS_ADK.ear" StagingMode="stage" TwoPhase="true">
<ConnectorComponent Name="BEA_WLS_DBMS_ADK" Targets="MyCluster" URI="BEA_WLS_DBMS_ADK.rar"/>
<WebAppComponent Name="BEA_WLS_DBMS_ADK_Web" Targets="MyCluster" URI="BEA_WLS_DBMS_ADK_Web.war"/>
<WebAppComponent Name="DbmsEventRouter" Targets="MyServer-1" URI="BEA_WLS_DBMS_ADK_EventRouter.war"/>
</Application>
このリストの以下の点に注意してください。関係のある情報は強調するため、太字で表記されています。
デプロイメントに備えたアダプタのコンフィグレーション
リソース アダプタのコンフィグレーションは、Configuration Wizard によって作成された WebLogic Integrationドメインで定義されます。Configuration Wizard によって作成されたコンフィグレーションでは、アダプタの 3 つのコンポーネントは、クラスタへのデプロイメントを目標としています。前の節（特にリスト2-8）で説明したとおり、イベント ジェネレータ Web アプリケーション（WAR）ファイルは、ほとんどの場合、クラスタ内の 1 つのサーバにデプロイします。この要件を満足するため、ドメインのコンフィグレーションを変更する必要があります。ドメイン コンフィグレーションの変更方法の詳細については、手順 5. アダプタ用イベント ルータ WAR ファイルのコンフィグレーションを参照してください。
また、リソース アダプタをクラスタ内のサーバを起動した後でデプロイすることもできます。クラスタ デプロイメントの設定および起動の詳細については、クラスタ デプロイメントのコンフィグレーションを参照してください。weblogic.Deployer コマンドライン ユーティリティまたは WebLogic Server Administration Console を使用して稼働中のクラスタにアダプタをデプロイする方法については、リソース アダプタのデプロイを参照してください。
WebLogic Integration環境でのアダプタのデプロイに関する詳細は、『アダプタの開発』の「アダプタのデプロイ」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
