WebLogic Integration ソリューションのデプロイメント
|
 |
 |
|
以下の節では、WebLogic Integration をクラスタ化環境でコンフィグレーションおよびデプロイする方法について説明します。内容は以下のとおりです。
クラスタ環境の WebLogic Platform アプリケーションの一般情報については、『WebLogic Platform アプリケーションのデプロイメント』の「対象環境について」を参照してください。
クラスタ化によって、WebLogic Integration をサーバのグループで実行でき、そのグループを単体ユニットとして管理できます。クラスタ環境では、複数のマシンが負荷を分担します。WebLogic Integration にはロード バランス機能があるので、リソース要求はすべてのマシンに均等に分散されます。WebLogic Integration デプロイメントは、クラスタ化とロード バランスを使用してノードにワークロードを分散させることにより、スケーラビリティを向上できます。クラスタ化により、単一サーバよりもスケーラビリティの高いデプロイメント プラットフォームを構築できます。
WebLogic Server クラスタのドメインは、1 台の管理サーバと、1 つまたは複数の管理対象サーバで構成されます。WebLogic Integration ドメインの管理対象サーバをクラスタにまとめることができます。WebLogic Integration のクラスタ対応リソースをコンフィグレーションする場合、通常はそのリソースのデプロイ対象とするクラスタを指名します。クラスタをリソース デプロイメントの対象として指定すると、管理対象サーバをクラスタに追加することによって能力を動的に増大できるという利点が得られます。
注意 : WebLogic Integration ドメインは複数のクラスタをサポートすることができます。ただし、WebLogic Integration のシステム リソースおよびアプリケーションは、複数のクラスタで構成されるドメイン内の 1 つの WebLogic Integration クラスタを対象とする必要があります。
ここでは、クラスタ環境で WebLogic Integration をコンフィグレーションする場合に必要な情報について説明します。WebLogic Server でサポートしているクラスタ化についての予備的な情報も含まれていますが、主に、クラスタ化環境で WebLogic Integration をコンフィグレーションする手順を説明します。
読み進む前に、WebLogic Server マニュアルの以下の節の内容を確認し、クラスタ化について十分に理解しておくことをお勧めします。
以下の節では、クラスタ デプロイメントの設計に必要な情報について説明します。
クラスタ化されたドメインに合わせてアーキテクチャを設計する前に、WebLogic Server クラスタがどのように運用されるかを知っておく必要があります。
ドメインとクラスタの作成は、Domain Configuration Wizard を使用して基本および拡張ドメイン テンプレートからドメインを生成することにより、簡単に実行できます。ユーザのクエリに対する応答を基に、Domain Configuration Wizard によって、ドメイン、サーバ、エンタープライズ アプリケーションなどが、コンフィグレーション済みの適切なコンポーネントおよび資産を含めて生成されます。さまざまなドメインに使用可能なテンプレートの詳細については、『コンフィグレーション ウィザードの使い方』の「テンプレート リファレンス」を参照してください。Domain Configuration Wizard を使用して WebLogic Integration ドメインの作成する方法の詳細については、『コンフィグレーション ウィザードの使い方』の「新規 WebLogic ドメインの作成」を参照してください。
Configuration Wizard で作成するドメインには、WebLogic Integration のシステム コンポーネントとアプリケーションを含むデプロイ対象が 1 つだけ存在している必要があります。この対象は、wli-config.properties で weblogic.wli.WliClusterName の値を設定することによって指定できます。weblogic.wli.WliClusterName の値を指定しない場合は、デフォルトにより、WebLogic Integration の対象は最初の WebLogic Integration クラスタになります。クラスタが存在しない場合は、最初の管理対象サーバが対象になります。wli-config.properties ファイルの詳細については、「wli-config.properties コンフィグレーション ファイル」を参照してください。
サーバには管理対象サーバと管理サーバがあります。管理サービスを実行している WebLogic Server は、管理サーバと呼ばれ、WebLogic Server Administration Console のホストとなります。複数の WebLogic Server が稼働しているドメインでは、そのうち 1 つのみが管理サーバで、他のサーバは管理対象サーバと呼ばれます。各管理対象サーバは、起動時に管理サーバからコンフィグレーションを取得します。
WebLogic クラスタの一般情報については、WebLogic Server ドキュメントの『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。このドキュメントでは、推奨される基本、多層、およびプロキシ アーキテクチャの詳細について説明されています。WebLogic クラスタ設計のセキュリティに関する考慮事項については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アーキテクチャ」にある「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。
WebLogic Server の管理ドメインがクラスタ ドメインとは別のものである場合 (WebLogic Server クラスタが別の管理ドメインに属するノードを持つ場合) もありますが、WebLogic Integration デプロイメントの場合は、クラスタ ドメインが管理ドメインおよびセキュリティ ドメインとなるように設計する必要があります。
クラスタ化されたドメインの各サーバに対して、そのドメイン内のサーバの機能を定義するさまざまな属性をコンフィグレーションできます。これらの属性は、Configuration Wizard で WebLogic Integration ドメインを作成すると、自動的にコンフィグレーションされます。また、WebLogic Server Administration Console の [サーバ] ノードを使用して手動でコンフィグレーションすることもできます。
WebLogic Integration デプロイメントのコンフィグレーション可能なリソースの一覧については、「WebLogic Integration デプロイメントのリソース」を参照してください。ここでは、クラスタ化された WebLogic Integration ドメインの各リソースのデフォルト ターゲットについて説明し、WebLogic Server Administration Console の各リソースへの移動方法を示しています。
この節では、以下の WebLogic Integration 追加デプロイメントでのコンフィグレーション要件に関するトピックを取り上げます。
システムのメッセージ処理が開始される前にすべての WebLogic Integration アプリケーション コンポーネントをデプロイすることが大切です。これを確実に行うために、WebLogic Integration デプロイするときには TwoPhase 属性を指定します。サンプルの config.xml ファイルからの次の抜粋は、WebLogic Integration の 2 段階デプロイメントを指定する Application 要素を示しています。
コード リスト 3-1 WebLogic Integration アプリケーションのデプロイメント
<Domain Name="MyCluster">
...
<Application Name="WebLogic Integration" Path="WL_HOME/lib"
TwoPhase="true">
...
Trading Partner Integration のコンポーネントは、クラスタに均一にデプロイする必要があります。冗長化されていない箇所をなくすために、Trading Partner Integration のリソースを各管理対象サーバへまったく同じようにコンフィグレーションします。
Trading Partner Integration をクラスタにコンフィグレーションする場合、以下の点に留意する必要があります。
クラスタのコンフィグレーションを変更できるのは (たとえば、クラスタへの新しいノードの追加や Trading Partner Integration コンフィグレーションの変更など)、その管理サーバがアクティブな場合のみです。
あるクラスタの管理サーバが使用できなくなると、デプロイ要求やアンデプロイ要求は中断されますが、管理対象サーバは要求の処理を続行します。管理対象サーバは、必要なコンフィグレーション ファイル (msi-config.xml および SerializedSystemIni.dat) およびオプションの boot.properties が各管理対象サーバのルート ディレクトリに存在する限り、既存のコンフィグレーションを使用して起動および再起動することができます。
管理サーバなしで起動する管理対象サーバは、管理対象サーバ独立 (MSI) モードで稼働します。MSI モードの詳細については、『WebLogic Server のコンフィグレーションと管理』の「障害が発生したサーバの回復」の「管理対象サーバ独立モード」を参照してください。
WebLogic Integration アプリケーションをクラスタ化する目的の 1 つは、スケーラビリティの実現です。クラスタをスケーラブルなものにするには、各サーバを十分に活用する必要があります。ロード バランスにより、クラスタ内のすべてのサーバ間で負荷が均等に分散され、各サーバがそれぞれ最大能力で動作できるようになります。以下の節では、さまざまな機能分野についての、WebLogic Integration クラスタでのロード バランスについて説明します。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでのロード バランシング」を参照してください。
Web サービス (SOAP over HTTP または XML over HTTP) と WebLogic Trading Partner Integration プロトコルでは、HTTP ロード バランスを使用できます。外部ロード バランスは、WebLogic HttpClusterServlet、WebServer プラグイン、またはハードウェア ルータによって実現できます。
WebLogic Server は、HTTP セッション ステートおよびクラスタ オブジェクトのロード バランスをサポートしています。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでのロード バランシング」を参照してください。
WebLogic Integration または WebLogic Integration アプリケーションで使用されるほとんどの JMS キューは、分散送り先としてコンフィグレーションされます。この例外は、1 台の管理対象サーバを送り先としている JMS キューです。
JMS ロード バランスの詳細については、Administration Console オンライン ヘルプの「JMS : チューニング」の「分散送り先のチューニング」を参照してください。
WebLogic Integration ソリューションに同期クライアントと非同期ビジネス プロセスとの通信が含まれる場合、weblogic.jws.jms.QueueConnectionFactory のサーバ アフィニティを有効にする必要があります。これがデフォルトの設定です。
警告 : 同期クライアントと非同期ビジネス プロセスとの通信機能を持つソリューションのサーバ アフィニティを無効にして JMS ロード バランスを試行した場合の動作は予測できません。
RDBMS イベント ジェネレータには専用の JMS 接続ファクトリ (wli.internal.egrdbms.XAQueueConnectionFactory) があります。この接続ファクトリのロード バランスはデフォルトで有効になっています。RDBMS イベントのロード バランスを無効にするには、wli.internal.egrdbms.XAQueueConnectionFactory のロード バランスを無効にし、サーバ アフィニティを有効にする必要があります。
Application Integration では、クラスタ内のサービスとイベントの両方のロード バランスが可能です。それぞれのタイプについては、次の節で説明します。
同期サービスは、セッション 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 台目のサーバに送信されます。
注意 : WebLogic Integration プロセスまたは WebLogic Workshop Web サービスからアプリケーション ビュー コントロールを使用する場合、非同期応答は、非同期応答の JMS キューに入れられずにプロセスの EJB または Web サービスに直接配信されます。
Application Integration アダプタは、WebLogic Integration プロセスまたは WebLogic Workshop Web サービスによって消費されるイベントを生成します。イベントは、WebLogic Integration クラスタ外の EIS インスタンス内で生成されます。Application Integration では、アダプタ インスタンス内のイベント接続で生成されるイベント オブジェクトによって、これらのイベントが検出されます。これらのアダプタ インスタンスは、クラスタ内の管理対象サーバに個別に置かれます。
EIS の始点から Application Integration に渡されるまでのイベント配信の動作は、各アダプタ独自のもので Application Integration では定義されません。ただし、イベント ジェネレータが Application Integration にイベントを配信すると、ロード バランスが行われて、イベントはクラスタの管理対象サーバ上にあるクライアントに配信されます。
クラスタ内のイベント配信の動作は、次の条件によって異なります。
両方の条件にあてはまる場合、イベントの配信とそれに続くプロセスおよび Web サービスによるイベントの処理は、クラスタに含まれる管理対象サーバの数によって増減します。
クラスタ内で、単体のアプリケーション ビューまたはイベント タイプへの複数のイベント接続をサポートするかどうかは、アダプタの設計により異なります。たとえば、Adapter Development Kit に含まれる DBMS アダプタのサンプルでは、これがサポートされています。使用しているアダプタでサポートされているかどうかを確認するには、アダプタ ベンダに問い合わせるか、アダプタのドキュメントを参照してください。
クラスタ内の複数の管理対象サーバにイベント接続をデプロイするかどうかは、イベント接続とアダプタ インスタンスをコンフィグレーションした方法によって異なります。WebLogic Integration の管理者は、WebLogic Integration Console を使用して、クラスタの管理対象サーバをイベント接続の対象にすることができます。アダプタが、クラスタ内の複数のイベント ジェネレータをサポートする場合には、クラスタのすべての管理対象サーバにイベント接続をデプロイすることをお勧めします。
WebLogic Integration でアダプタ イベントを処理する方法の詳細については、「イベント」を参照してください。
メッセージ駆動型 Bean は、JMS 送り先からのメッセージを消費します。多くのメッセージ駆動型 Bean は、WebLogic Integration のそれぞれの送り先にデプロイされます。WebLogic Integration の送り先 (JMS キューとトピック) をすべて掲載した一覧については、表 D-1 の JMS のサービスのリソース タイプを参照してください。
WebLogic JMS の実装により、複数の物理送り先を単一の分散送り先のメンバーとしてコンフィグレーションできるため、きわめて高い可用性がもたらされます。具体的には、管理者がクラスタ内の各ノードに対して、各分散送り先への物理送り先を 1 つ、コンフィグレーションする必要があります。クラスタ内のあるノードに障害が発生して、そのノードの物理送り先が使用できなくなった場合、分散送り先のメンバーとしてコンフィグレーションされた他の物理送り先が、JMS のプロデューサとコンシューマにサービスを提供することができます。この方法で、Configuration Wizard はクラスタのドメインを生成します。
メッセージ駆動型 Bean は、分散送り先からのメッセージを消費します。分散送り先には、WebLogic Server のインスタンスごとに、物理送り先が 1 つ格納されています。分散キューの各メッセージ プロデューサは、それぞれ 1 つの物理送り先にバインドされています。メッセージ駆動型 Bean は、デプロイ先のサーバ内の物理送り先にバインドされています (サーバ親和性)。
クラスタ内の管理対象サーバに障害が発生した場合、そのサーバのメッセージ駆動型 Bean はアトミックに移行されますが、複数のメッセージ処理を防止するため、自動的移行は行われません。JMS サーバおよびそのすべての送り先は、クラスタ内の別の WeLogic Server に移行できるため、クラスタ環境で単独の送り先としてデプロイされる必要のある送り先についても、高可用性を実現することができます。
次の節では、WebLogic Integration がクラスタ デプロイメントにおいて、分散送り先およびサーバ親和性を利用して高可用性を実現する例を説明します。
Application Integration では、分散型 JMS キュー (wli.internal.ai.async.request) を使用して、アプリケーション ビューのクライアントが入力した非同期要求を管理します。非同期サービス要求プロセッサは、この要求を処理するメッセージ駆動型 EJB で、クラスタのすべてのサーバにデプロイされます。非同期要求をアプリケーション ビュー クライアントに戻すために Application Integration で使用するメソッドは、要求を送信したクライアントのタイプによって異なります。
wli.internal.ai.async.response) に応答が送信される。メッセージ駆動型 Bean が同期サービス要求を受信する前に物理キューに障害が発生すると、その要求は、この物理キューが正常な処理に戻るまで使用できなくなります。非同期サービス応答についても同様です。管理対象サーバのイベントがエラーになると、管理対象サーバの JMS サーバが管理しているメッセージは無効になります。他の管理対象サーバの JMS サーバによって管理されているメッセージは有効で、通常どおりに処理されます。
注意 : 非同期要求の待ち行列に入れられていない非同期サービス要求は、アプリケーション ビューのインスタンスが置かれている管理対象サーバがエラーになると消失します。
非同期要求キューに登録されているすべての非同期要求は、キューから取り出されて JTA トランザクションのスコープで処理されます。要求の高可用処理が必要なアプリケーションは、アプリケーション ビュー コントロールを使用して非同期サービスを呼び出す必要があります。これにより、非同期応答は、非同期要求をキューから取り出し、EIS に対する要求を処理したトランザクションの内部プロセスと Web サービス インスタンスに配信されます。
サーバがエラーになると、その時点で処理中だった非同期要求は、要求キューにロールバックされます。WebLogic トランザクション マネージャによって、エラーになったサーバのトランザクションが回復されるとき、アプリケーション ビューで使用されている XA 対応のリソース マネージャには、作業をロールバックするかどうかの問い合わせが行われます。
アプリケーション ビュー コントロールで作成された WebLogic Integration プロセスのクライアント サービス呼び出しは、JTA トランザクションで実行されます。管理対象サーバがエラーになると、プロセスは最後にコミットされた地点までロールバックされます。メッセージ ブローカまたは、他の永続メッセージ システムによってプロセスが開始されている場合、開始メッセージの配信後にプロセス全体が再試行されます。
AsyncServiceResponseListener インスタンスを使用したアプリケーション ビュー クライアントは、実際は、JMS クライアント確認応答モードを使用してメッセージを受信します。非同期応答をホストしているサーバがエラーになると、メッセージは認識されずにサーバ上に残ります。
Application Integration 機能への同期および非同期呼び出しの詳細については、「Application Integration の機能とクライアント」を参照してください。
Application Integration アダプタは、WebLogic Integration プロセスまたは WebLogic Workshop Web サービスによって消費されるイベントを生成します。イベントは、WebLogic Integration クラスタ外の EIS インスタンス内で生成されます。Application Integration では、アダプタ インスタンス内のイベント接続で生成されるイベント オブジェクトによって、これらのイベントが検出されます。これらのアダプタ インスタンスは、クラスタ内の管理対象サーバに個別に置かれます。
EIS の始点から Application Integration に渡される地点までのイベント配信の動作は、各アダプタ固有のもので、Application Integration では定義されません。イベントが Application Integration に送信されたときアダプタ イベントがどのように処理されるかについては、「イベント」を参照してください。
1 台の管理対象サーバがエラーになると、エラーになったノードの Application Integration に配信されるプロセスのイベントが消失することがあります。以下の条件が満たされる場合は、他のイベントの配信が中断なく続行されます。
クラスタ内で、単体のアプリケーション ビューまたはイベント タイプへの複数のイベント接続をサポートするかどうかは、アダプタの設計により異なります。たとえば、Adapter Development Kit に含まれる DBMS アダプタのサンプルでは、これがサポートされています。アダプタが複数のイベント ジェネレータをサポートしていない場合、そのコンフィグレーションにデプロイすると、複数のイベントが、1 つの EIS イベントのサブスクライバに配信されることがあります。使用しているアダプタでサポートされているかどうかを確認するには、アダプタ ベンダに問い合わせるか、アダプタのドキュメントを参照してください。
クラスタ内の複数の管理対象サーバにイベント接続をデプロイするかどうかは、イベント接続とアダプタ インスタンスをコンフィグレーションした方法によって異なります。WebLogic Integration の管理者は、WebLogic Integration Administration Console を使用して、クラスタの管理対象サーバをイベント接続の対象にすることができます。アダプタが、クラスタ内の複数のイベント ジェネレータをサポートする場合には、クラスタのすべての管理対象サーバにイベント接続をデプロイすることをお勧めします。
WebLogic Integration Administration Console を使用してイベント接続の対象を指定する方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」を参照してください。
WebLogic Integration でアダプタ イベントを処理する方法については、「イベント」を参照してください。
Workshop アプリケーションから EAR ファイルを作成したら、アプリケーションをプロダクション環境にデプロイします。プロセス アプリケーションは、Web サービス アプリケーションと同じ手順でデプロイできます。詳細については、WebLogic Workshop ヘルプの「プロダクション サーバにアプリケーションをデプロイする」を参照してください。
WebLogic Integration アプリケーションをクラスタにデプロイする場合、以下の点に留意する必要があります。
wlw-manifest.xml のキューを JMS 分散キューとしてコンフィグレーションすることが推奨される。これらのキューをコンフィグレーションする方法については、Weblogic Workshop ヘルプの「WebLogic Workshop アプリケーションをプロダクション サーバにデプロイするには」の「プロダクション サーバで必要なリソースを手動で作成する」を参照してください。wlw-manifest.xml で参照している会話状態要素ごとにデータベース テーブルを作成する必要がある。これらのキューをコンフィグレーションする方法については、Weblogic Workshop ヘルプの「WebLogic Workshop アプリケーションをプロダクション サーバにデプロイするには」の「プロダクション サーバで必要なリソースを手動で作成する」を参照してください。アプリケーション デプロイメントの概要については、「WebLogic Server アプリケーションのデプロイメント」を参照してください。WebLogic Platform アプリケーションのソフトウェア ライフサイクルのデプロイメントの詳細については、「WebLogic Platform アプリケーションのデプロイメント」を参照してください。
Application Integration アダプタは通常、次の 2 つのコンポーネントで構成されています。
リソース アダプタ (RAR) ファイルは、クラスタにデプロイする必要があります。少なくともリソース アダプタ (RAR) ファイルは、アダプタを使用しているアプリケーション ビューをデプロイする管理対象サーバにデプロイする必要があります。必要なアダプタがない管理対象サーバにアプリケーション ビューをデプロイする場合には、アプリケーション ビューで使用されたアダプタ インスタンスのデプロイメント、およびアプリケーション ビューのデプロイメントに失敗します。
設計時 Web アプリケーション (WAR) ファイルは、クラスタ内の対象にしないでください。設計時 Web アプリケーション ファイルは、開発目的でのみ使用します。WebLogic Integration のプロダクション環境では、これらのファイルを使用しません。
weblogic.Deployer コマンドライン ユーティリティや WebLogic Server Administration Console を使用して、リソース アダプタを実行中のクラスタにデプロイする方法については「リソース アダプタのデプロイ」を参照してください。WebLogic Integration 環境でアダプタをデプロイする方法については、『アダプタの開発』の「アダプタのデプロイ」を参照してください。
WebLogic Integration イベント ジェネレータ (電子メール、ファイル、HTTP、JMS、MQSeries、RDBMS、タイマー) は、WebLogic Integration Administration Console を使用してデプロイできます。WebLogic Integration Administration Console を使用してイベント ジェネレータをデプロイする方法の詳細については、『WebLogic Integration ソリューションの管理』の「イベント ジェネレータ」の「イベント ジェネレータの作成とデプロイ」を参照してください。
イベント ジェネレータを WebLogic Scripting Tool (WLST) でデプロイすることもできます。以下の 3 つの WLST スクリプトは、イベント ジェネレータを作成、デプロイ、およびコンフィグレーションする方法を示しています。
注意 : WLST Offline および WLST Online は BEA の dev2dev サイトからダウンロードおよび評価することができますが、正式な WebLogic Platform 8.1 製品には含まれません。WLST は BEA ニュースグループのみでサポートされ、ユーティリティと API は変更される場合があります。WebLogic Platform の将来のリリースではこの機能を正式にサポートする予定です。
WLST スクリプトの次の抜粋は、JMS イベント ジェネレータの作成方法を示しています。
コード リスト 3-2 WLST によるイベント ジェネレータの作成
import com.bea.wli.mbconnector.jms as eggen
eggen.JmsConnGenerator.main([
"-inName", "myEgName",
"-outfile", "mydomain/myEgName.jar",
"-destJNDIName", "myQueueName",])
イベント ジェネレータを作成したら、次の例のようなスクリプトで適切なターゲットにデプロイできます。
コード リスト 3-3 WLST によるイベント ジェネレータのデプロイ
wlst.deploy( "WLIJmsEG_myEgName", "mydomain/myEgName.jar", myServer )
デプロイしたイベント ジェネレータのプロパティをコンフィグレーションするには、以下の例のようなスクリプトを使用します。
コード リスト 3-4 WLST によるイベント ジェネレータのコンフィグレーション
import com.bea.wli.management.configuration as wlicfg
# Must have wli.jar in classpath
egCfgMBean = wlst.getTarget("JMSEventGenerators/JMSEventGenerators")
egMBean = egCfgMBean.newJMSEventGenConfigurationMBean( "myEgName")
cData = jarray.zeros( 1, wlicfg.JMSEventGenChannelConfiguration )
cData[0] = wlicfg.JMSEventGenChannelConfiguration()
cData[0].setChannel( "myChannel" )
cData[0].setComment("Default channel")
egMBean.setChannels(cData);
WLST などのユーティリティによるデプロイメントの自動化については、『WebLogic Platform アプリケーションのデプロイメント』の「WebLogic Platform デプロイメントの概要」の「プロモーション プロセスの自動化」を参照してください。
注意 : コード サンプルおよびユーティリティは dev2dev に掲載されていますが、BEA のサポート対象外の製品です。
以下の節では、イベント ジェネレータの補足情報について説明します。
電子メール、ファイル、タイマーの各イベント ジェネレータでは、クラスタを対象にしないでください。これらのジェネレータは、特定のイベント ジェネレータ (たとえば、電子メール イベント ジェネレータの wli.internal.egmail.queue) に関連付けられたキューによって移行可能なサーバを含んだ管理対象サーバ上でアクティブになります。
以下の節では、JMS イベント ジェネレータをデプロイするときに考慮する必要がある対象指定とエラー処理の問題について説明します。
次の表で示すように、JMS イベント ジェネレータは、JMS イベント ジェネレータの送り先 JNDI 名に応じて対象に割り当てる必要があります。
JMS イベント ジェネレータに明示的なエラー処理メカニズムはありません。エラー処理は、JMS イベント ジェネレータ キューをエラー キューに関連付けることによって提供されます。
エラー キューをコンフィグレーションする方法については、『Administration Console オンライン ヘルプ』の「JMS : コンフィグレーション」の「JMS キューおよびトピック送り先のタスク」を参照してください。
注意 : JMS エラー キューの [再配信の制限] に、環境に応じた実際的なメッセージ数を設定することが重要です。デフォルトでは、JMS キューのエラー メッセージおよび警告の再配信回数は無制限です。
メッセージの [再配信の制限] を設定する方法の詳細については、『Administration Console オンライン ヘルプ』の「[JMS キュー] --> [コンフィグレーション] --> [再配信]」を参照してください。
MQSeries イベント ジェネレータは、WebSphere MQ キューのメッセージをポーリングし、メッセージ (メタデータとしての MQMD ヘッダとメッセージのペイロード) をメッセージ ブローカ チャネルにパブリッシュします。コンテンツのフィルタ処理、およびその他の処理条件は、イベント ジェネレータのチャネル ルールで指定します。
HTTP イベント ジェネレータは、HTTP リクエストを受け取り、内容のタイプを調べ、メッセージをメッセージ ブローカ チャネルにパブリッシュするサーブレットです。
RDBMS イベント ジェネレータは、データベース テーブルをポーリングして、追加、削除、または更新された行を確認し、結果をメッセージ ブローカ チャネルにパブリッシュします。また、このイベント ジェネレータを使用すると、データベース テーブルにカスタム クエリを実行し、メッセージ ブローカ チャネルに結果をパブリッシュすることもできます。
クラスタに RDBMS イベント ジェネレータをデプロイする場合、各 RDBMS イベント ジェネレータの JMS キューの [再配信遅延のオーバライド] の値を 20000 (20 秒)、[再配信の制限] の値を -1 (制限なし) に手動で設定する必要があります。クラスタのイベントを生成する前に、これらの再配信の設定をコンフィグレーションする必要があります。
警告 : [再配信遅延のオーバライド] と [再配信の制限] の値をデフォルトのままにしておくと、エラーが発生したときに、ただちに 2 回の再配信が試行されます。2 回目の再配信が失敗すると、メッセージは破棄されます。
クラスタ内の RDBMS イベント ジェネレータの JMS キューに再配送の設定をコンフィグレーションするには、次の手順を実行します。
WebLogic Server Administration Console (必要な場合は管理サーバ) を起動する手順については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server システム管理の概要」の「Administration Console の起動」を参照してください。
単一サーバ デプロイメントでは、[再配信遅延のオーバライド] の値を 20000 (20 秒) に設定する必要があります。単一サーバ デプロイメントで [再配信遅延のオーバライド] の値をコンフィグレーションするには、次の手順を実行します。
WebLogic Server Administration Console (必要な場合は管理サーバ) を起動する手順については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server システム管理の概要」の「Administration Console の起動」を参照してください。
単一サーバ デプロイメントでは、[再配信の制限] の設定を手動でコンフィグレーションする必要はありません。単一サーバ デプロイメントの [再配信の制限] は、デフォルトで適切な値に設定されています。
|
|
|