|
|
WLI アプリケーションのデプロイ、実行、および管理にはいくつかのベスト プラクティスがあります。次の各節でこれについて説明します。
開発モードで作業している場合、WLI IDE を使用してアプリケーションの構築およびデプロイができます。IDE には、プロダクション目的のビルドを作成する Ant スクリプトの生成に役立つ機能があります。また、そうしたビルド スクリプトをコマンド プロンプトを介して IDE の外部で実行し、単一の EAR ファイルを生成することもできます。この EAR ファイルは、コマンド プロンプトまたは Oracle WebLogic Server Console でデプロイできます。詳細については、『WebLogic Integration ソリューションのデプロイメント』を参照してください。
Oracle WebLogic Server クラスタのドメインは、1 台の管理サーバと、1 つまたは複数の管理対象サーバで構成されます。WLI ドメイン内の管理対象サーバはクラスタにまとめられます。クラスタ化できる WLI リソースをコンフィグレーションする場合、そのリソースのデプロイ対象とするクラスタを指名します。リソース デプロイメントの対象としてクラスタを指定する場合、管理対象サーバをお使いのクラスタに追加して動的に処理能力を向上させることができます。クラスタに適用できるベスト プラクティスを次に示します。
Trading Partner Integration のコンポーネントは、クラスタに均一にデプロイする必要があります。シングルポイント障害を回避するため、Trading Partner Integration リソースはすべての管理対象サーバへまったく同じようにデプロイします。
クラスタ内に Trading Partner Integration をコンフィグレーションする際には、次のガイドラインに従います。
クラスタのコンフィグレーションは変更できます。たとえば、クラスタに新しいノードを追加したり、クラスタの管理サーバがアクティブな間に限り Trading Partner Integration のコンフィグレーションを変更したりすることが可能です。
クラスタのデプロイまたは無効化の要求は、管理サーバが非アクティブな場合には中断されますが、要求の処理は管理対象サーバで続行されます。必要なコンフィグレーション ファイル (msi-config.xml、SerializedSystemIni.dat、boot.properties (省略可能) など) を、必ず各管理対象サーバのルート ディレクトリに存在させることができる場合は、既存のコンフィグレーションを使用して管理対象サーバの起動や再起動が可能です。
管理サーバなしで機能する管理対象サーバは、管理対象サーバ独立 (MSI) モードで動作します。MSI モードの詳細については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」にある「管理対象サーバ独立モードについて」を参照してください。
WLI アプリケーション内でクラスタ化する目的の 1 つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバを十分に活用する必要があります。ロード バランシングにより、クラスタ内のすべてのサーバ間で負荷が均等に分散され、各サーバが最大能力で動作できるようになります。ロード バランシングは、WLI クラスタ内のさまざまな機能領域で必要とされます。こうした機能には次のようなものがあります。
Web サービス (SOAP over HTTP または XML over HTTP) と Oracle WebLogic Trading Partner Integration プロトコルでは、HTTP ロード バランシングを使用できます。Oracle WebLogic HttpClusterServlet、Web サーバ プラグイン、またはハードウェア ルータを使用すると、外部ロード バランシングを行えます。
WLI または WLI アプリケーションでは、分散送り先としてコンフィグレーションされている JMS キューが最も多く利用されます。JMS キューが単一の管理対象サーバを対象としている場合は例外です。
お使いの WLI ソリューションで同期クライアントと非同期ビジネス プロセス間の通信が行われる場合、weblogic.jws.jms.QueueConnectionFactory のサーバ アフィニティを有効化できます。これがデフォルトの設定です。
| 警告 : | JMS ロード バランシングの調整中に、同期クライアントと非同期ビジネス プロセス間の通信が行われるソリューションのサーバ アフィニティを無効化すると、結果としてロード バランシングの動作が予期できないものとなります。 |
RDBMS イベント ジェネレータには専用の JMS 接続ファクトリ (wli.internal.egrdbms.XAQueueConnectionFactory) があります。この接続ファクトリのロード バランシングはデフォルトで有効になっています。RDBMS イベントのロード バランシングを無効化するには、ロード バランシングを無効化した上で wli.internal.egrdbms.XAQueueConnectionFactory のサーバ アフィニティを有効化する必要があります。
アプリケーションを統合すると、クラスタ内の同期および非同期のサービスとイベントをロード バランシングできるようになります。同期および非同期のサービスの使用法を、次の各節で詳細に説明します。
同期サービスは、セッション EJB のメソッド呼び出しとして実装されます。それらの呼び出しは、クラスタ内で EJB ロード バランシング ルールに従ってロード バランシングされます。そうした EJB は設計時にパブリッシュされ、各アプリケーション ビューが 2 つのセッション EJB (一方はステートレス、もう一方はステートフル) として表現されます。
標準的な操作では、ステートレス セッション EJB でサービスが呼び出され、サービス単位でロード バランシングが行われます。アプリケーション ビューでサービスを呼び出すたびに、異なる Oracle WebLogic 管理対象サーバ インスタンスの別々の EJB にルーティングされる場合があります。
ローカル トランザクション中にアプリケーション ビューのローカル トランザクション機能を使用する場合、ステートフル セッション EJB でサービスが呼び出されます。ステートフル セッション EJB で EIS への接続をオープンにしておけるので、次のサービスが呼び出されるまでの間、ローカル トランザクションのステートを永続化できます。このモードでは、サービスの呼び出しが、クラスタ内にある 1 台の管理対象サーバの単一の EJB インスタンスに固定されます。コミットまたはロールバックでトランザクションが完了すると、標準的なサービス単位のロード バランシングが適用されます。
非同期サービスは、常にステートレス セッション EJB のメソッド呼び出しとして起動されます。非同期サービスの呼び出しには、アプリケーション ビューのローカル トランザクション機能を使用できません。
単独の非同期サービス呼び出しは、2 つの異なるステートレス セッション EJB インスタンスへの 2 つのメソッド呼び出しに変換されます。この場合、非同期サービスのロード バランシングは、2 つの状況で実行されます。すなわち、要求の受け取り時、および要求の実行と応答の配信時に行われます。
また、非同期サービスの要求と応答は、分散型 JMS キューにポストされます。結果として JMS ロード バランシングは要求および応答の両方に適用されます。この場合、アプリケーション ビューの invokeServiceAsync メソッドは 1 台の管理対象サーバから提供され、要求は 2 台目の管理対象サーバに配信されて処理され、応答が生成されます。そして応答は、クライアントで取得するために 3 台目のサーバに配信されます。
|