| Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング 11g リリース1 (10.3.6) B61425-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング 11g リリース1 (10.3.6) B61425-04 |
|
前 |
次 |
この節では、MDBをデプロイするための様々な手法とMDBがリスニングするJMS宛先について説明します。
リスニング元または個別のサーバー・インスタンス上のJMS宛先として、同一のサーバー・インスタンス上でMDBをデプロイできます。これらの選択肢は、それぞれcollocationまたはnon-collocationとして参照されます。
MDBとそのリスニング対象の宛先を連結すると、メッセージ・トラフィックが常にローカルになり、ネットワークの往復がなくなります。連結は、WebLogic Server JMSを使用し、メッセージ処理の待機時間とネットワーク・トラフィックを最小限に抑えたい場合に最適です。
MQ SeriesなどのWebLogic Serverで動作できないサード・パーティJMSプロバイダを使用する場合は、MDBとJMS宛先を連結できません。
図4-1および図4-2は、関連付けられたJMS宛先をホストするサーバー・インスタンスにMDBアプリケーションがデプロイされるアーキテクチャを示します。これらのアーキテクチャは、前者には分散宛先が含まれ、後者には含まれないという点で異なります。分散宛先を使用するアプリケーションでは、MDBは分散宛先セットのメンバーをホストする各サーバー・インスタンスにデプロイされます。分散宛先の詳細は、「JMS分散宛先」を参照してください。図4-1で示されるように、メッセージ「M1」は、分散宛先およびMDB_AがデプロイされるMDB_Aのインスタンスに送信されます。図4-1は、One-Copy-Per-Serverトピック・メッセージ宛先モード・パターンを示しています。トピック・パターンは、第10章「topicMessagesDistributionModeの設定」でさらに詳しく説明します。
図4-1 連結された宛先/MDB、分散トピック、One-Copy-Per-Serverパターン
図4-3は、リスニング対象のJMS宛先とは別のサーバー・インスタンスでMDBが動作するアーキテクチャを示しています。
リスニング対象のJMS宛先とは別のサーバー・インスタンスでMDBを実行するのが適切なのは、以下の場合です。
アプリケーションでサード・パーティ製のJMSプロバイダ(MQ Seriesなど)が使用されます。
JMSのインフラストラクチャからアプリケーション・コード(MDB)を分離する必要があります。JMS宛先とMDBを別々のサーバー・インスタンスに配置することで、アプリケーションの問題(たとえばMDBが仮想マシンのメモリーをすべて消費するなど)でJMSインフラストラクチャの処理が妨げられるのが防止されます。
MDBアプリケーションが非常にCPUを消費します。別のマシンにあれば、アプリケーションはJMSインフラストラクチャの処理に影響を与えずにCPUパワーを100%使用することができます。
構成中の1つのマシンが、同じ構成の他のマシンよりも処理能力、ディスク領域やメモリーの点で優れています。
JMS宛先とMDBは、非クラスタ化サーバー、同じクラスタ内の複数のサーバー、または別々のクラスタのサーバーにもデプロイできます。
MDBアプリケーションがWebLogic Serverクラスタで動作している場合は、複数の物理的宛先(キューまたはトピック)を、メッセージ・プロデューサやコンシューマからは1つの宛先に見える分散宛先として構成できます。
分散宛先を構成する場合、WebLogic JMSは、分散宛先の使用可能なメンバー全体に渡ってメッセージング・ロードを分散します。宛先のメンバーがサーバー障害によって使用できなくなる場合、メッセージ・トラフィックは、分散宛先セットにある他の使用可能な物理的な宛先にリダイレクトされます。weblogic-ejb-jar.xmlファイルのdistributed-destination-connection要素またはdistributedDestinationConnectionアノテーションを使用して、同一クラスタ内のWebLogic分散キューにアクセスするMDBが、すべての分散宛先メンバーから消費するか、または現在のWebLogic Serverに対してローカルのメンバーのみから消費するかどうかを管理できます。同様に、第10章「JMSトピックを使用したMDBの構成とデプロイ」および付録A「トピック・デプロイメント・シナリオ」で説明されているように、この設定は一部のトピックMDBシナリオの動作を管理します。
MDBおよび関連する分散キューを同一のクラスタにデプロイする場合、WebLogic Serverは自動的に分散キュー・メンバーを列挙し、各メンバーが少なくとも1つのMDBプールによってサービスされることを保証します。分散キューについては、distributedDestinationConnectionがLocalOnly(デフォルト)のとき、各ローカル・メンバーに1つのMDBプールがあることになります。それ以外の場合、キューについては、distributedDestinationConnectionがEveryMemberに設定されているとき、各WebLogic Serverインスタンスは複数のローカルMDBプール(各ローカル・メンバーに1つ + 各リモート・メンバーに1つ)を作成します。
MDBおよびその関連付けられたキューを異なるクラスタにデプロイする場合、WebLogic Serverは自動的に分散キュー・メンバーを列挙し、各メンバーがMDBクラスタ内の各サーバー上にあるMDBプールによってサービスが提供されることを保証します。たとえば、分散キューに3つのメンバーが含まれる場合、MDBクラスタ内の各JVMは3つのMDBプールを作成します。
分散トピックの詳細は、第10章「JMSトピックを使用したMDBの構成とデプロイ」を参照してください。
WebLogicクラスタリングおよびWebLogic JMS分散宛先は、拡張性と高可用性を増加します。適切にロード・バランシングされたメッセージ処理を保証するために、クラスタをホストするマシンが同一または同程度の処理能力、ディスク容量、およびメモリーを持つことをお薦めします。同様に、特定のWebLogicクラスタ内のWebLogic Serverインスタンスは、均一のJMS構成およびMDBデプロイメントを持つことをお薦めします。
例については、図4-1を参照してください。分散宛先の詳細は、『Oracle WebLogic Server JMSのプログラミング』の「分散宛先の使用」を参照してください。
