|
|
以下の節で説明するように、WLI アプリケーションのデプロイ、実行、および保守に関するいくつかのベスト プラクティスがあります。
開発モードを使用する場合は、WLI IDE を使用してアプリケーションのビルドとデプロイを行うことができます。この IDE には、Ant スクリプトを生成してプロダクション用のビルドを作成する際に役立つ機能が用意されています。また、コマンド プロンプトから、ビルド スクリプトを IDE の外部で実行して、単一の EAR ファイルを生成することもできます。この EAR ファイルは、コマンド プロンプトまたは WebLogic Server Console を使用してデプロイできます。詳細については、『WebLogic Integration ソリューションのデプロイメント』を参照してください。
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 モードの詳細については、WebLogic Server の起動と停止の管理の「サーバ障害の回避とサーバ障害からの回復」にある管理対象サーバ独立モードについてを参照してください。
WLI アプリケーションをクラスタ化する目的の 1 つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバを十分に活用する必要があります。ロード バランシングにより、クラスタ内のすべてのサーバ間で負荷が均等に分散され、各サーバがそれぞれ最大能力で動作できるようになります。ロード バランシングは、WLI クラスタのさまざまな機能分野で必要になります。機能は以下のとおりです。
Web サービス (SOAP over HTTP または XML over HTTP) と WebLogic Trading Partner Integration プロトコルでは、HTTP ロード バランシングを使用できます。外部ロード バランシングは、WebLogic HttpClusterServlet、Web サーバ プラグイン、またはハードウェア ルータによって実現できます。
WLI または WLI アプリケーションは、ほとんどの場合、分散送り先としてコンフィグレーションされた JMS キューを利用します。このルールの例外は、JMS キューの対象を単一の管理対象サーバにすることです。
WLI ソリューションに同期クライアントと非同期ビジネス プロセス間の通信が含まれる場合は、weblogic.jws.jms.QueueConnectionFactory のサーバ アフィニティを有効にできます。これがデフォルトの設定です。
| 警告 : | JMS のロード バランシングをチューニングしようとして、同期クライアントと非同期ビジネス プロセス間の通信を含むソリューションのサーバ アフィニティを無効にすると、結果としてのロード バランシング動作は予測不可能になります。 |
RDBMS イベント ジェネレータには、wli.internal.egrdbms.XAQueueConnectionFactory という専用の JMS 接続ファクトリがあります。この接続ファクトリのロード バランシングはデフォルトで有効になっています。RDBMS イベントのロード バランシングを無効にするには、wli.internal.egrdbms.XAQueueConnectionFactory のロード バランシングを無効にし、サーバ アフィニティを有効にする必要があります。
Application Integration では、クラスタ内の同期サービスと非同期サービスおよび同期イベントと非同期イベントのロード バランシングが可能です。同期サービスと非同期サービスの使用法については、以下の節で詳しく説明します。
同期サービスは、セッション EJB のメソッド呼び出しとして実装されます。同期サービスのロードバランシングは、EJB のロード バランシング ルールに従ってクラスタ内で行われます。EJB は設計時にパブリッシュされ、各アプリケーション ビューは 2 つのセッション EJB (1 つはステートレスで、もう 1 つはステートフル) として表されます。
通常の操作では、サービスはステートレス セッション EJB によって呼び出されるため、ロード バランシングはサービス単位で発生します。アプリケーション ビューでサービスを呼び出すたびに、異なる WebLogic 管理対象サーバ インスタンスの異なる EJB にルーティングされます。
ローカル トランザクション中にアプリケーション ビューのローカル トランザクション機能を使用すると、ステートフル セッション EJB によってサービスが呼び出されます。ステートフル セッション EJB によって EIS への接続が開かれたままになるため、次のサービスが呼び出されるまでの間、ローカル トランザクションの状態を永続化できます。このモードでは、サービスの呼び出しが、クラスタ内にある 1 つの管理対象サーバの単一の EJB インスタンスに固定されます。トランザクションがコミットまたはロールバックによって完了すると、標準のサービス単位のロード バランシングが適用可能になります。
非同期サービスは、常にステートレス セッション EJB のメソッド呼び出しとして起動されます。非同期サービスの起動には、アプリケーション ビューのローカル トランザクション機能を使用できません。
単独の非同期サービス呼び出しは、2 つの異なるステートレス セッション EJB インスタンスへの 2 つのメソッド呼び出しに変換されます。この場合、非同期サービスのロード バランシングは、2 つの状況で実行されます。すなわち、要求の受け取り時、および要求の実行と応答の配信時に実行されます。
また、非同期サービスの要求と応答は、分散型 JMS キューにポストされます。その結果、JMS ロード バランシングは、要求と応答の両方に適用されます。この場合は、アプリケーション ビューの invokeServiceAsync メソッドは、1 つの管理対象サーバから提供され、要求は、2 つ目の管理対象サーバに送信されて処理され、応答が生成されます。そして応答は、3 つ目のサーバに送信され、クライアントによって取得されます。
|
