要求側アプリケーションのローカル・キュー・ポイントへの応答メッセージの制限

JMS キューが応答キューとしてサービス統合バス・キューを識別し、そのサービス統合バス・キューに複数のキュー・ポイントがある場合、JMS キューを参照したアプリケーションのローカル・キュー・ポイントにメッセージを制限するように JMS キューを構成することができます。これを行うと、応答メッセージがクラスター・バス・メンバーの適切なキュー・ポイントに送られるようになります。

サービス統合バス・キューは、複数のメッセージング・エンジンを持つ (一般的にはワークロード共有またはスケーラビリティーを提供するため) クラスター・バス・メンバーによって所有されていれば、複数のキュー・ポイントを持つことができます。ローカル・キュー・ポイントとは、アプリケーションの接続先のメッセージング・エンジン上にあるキュー・ポイントです。

例: 「Reply」という JMS キューは、使用するサービス統合バス・キューを応答キューとして識別するように構成されています。 JMS キューは、ローカル・キュー・ポイントにメッセージを制限するように構成されています (詳細については「関連タスク」を参照)。

図 1. 要求側 JMS アプリケーションがクラスター・バス・メンバー内のメッセージング・エンジンの 1 つに接続する
要求側 JMS アプリケーションがクラスター・バス・メンバー内のメッセージング・エンジンの 1 つに接続しています。

バス・メンバーは、応答キューとして使用されるサービス統合バス・キューも所有するため、各メッセージング・エンジンには、応答キューのキュー・ポイントが構成されています。

要求側アプリケーションは、JMS メッセージを作成して、JMS キュー「Reply」に JMSReplyTo 宛先を設定します。要求側アプリケーションは、別の JMS キュー「Service」を使用して、サービスのキューに要求メッセージを送信します。(「Service」では特別な構成は不要です)。デフォルトでは、このメッセージは、通常はローカル・キュー・ポイントに送信されますが、「Service」に所属するすべてのキュー・ポイントに送信される可能性があります。 ただし、この例を詳細に説明すると、システムは、メッセージを別のキュー・ポイントに送信します。

要求メッセージを送信したアプリケーションが、それに構成されている基盤のサービス統合バス応答キューのキュー・ポイントも持ったメッセージング・エンジンに接続されていて、 オプションが使用可能になっている場合、応答キューのその単一のキュー・ポイントの ID が、メッセージ内の JMSReplyTo キューの情報に追加されます。

図 2. 要求側アプリケーションが別の JMS キューを使用して、サービスのキューに要求メッセージを送信する
要求側アプリケーションは、別の JMS キューを使用して、サービスのキューに要求メッセージを送信します。

要求メッセージは、サービスのキュー「Service」に送信され、サービスによって処理されます。完了すると、サービスは、要求メッセージで指定された応答キュー (JMS Message.getJMSReplyTo メソッドを使用して取得) に JMS メッセージを送信します。 ここで、メッセージング・システムは、デフォルトでは「Reply」のキュー・ポイントのいずれかに応答メッセージを送信しますが、要求側が応答キューをローカル・キュー・ポイントにスコープしているため、応答側が接続されている先のメッセージング・エンジン上にある単一のキュー・ポイントに応答は送信されます。

図 3. 応答側アプリケーションに応答キューのローカル・キュー・ポイントが存在しても、メッセージは要求側アプリケーションのローカル・キュー・ポイントに送信される
応答側アプリケーションに応答キューのローカル・キュー・ポイントが存在しても、メッセージは要求側アプリケーションのローカル・キュー・ポイントに送信されます。

システムは、サービス統合バス・キューにキュー・ポイントが 1 つしかないかのように振る舞います。 応答がスコープされているキュー・ポイントが使用できない場合には、メッセージは他のキュー・ポイントに送信されません。

この方法には、以下の利点があります。
  • 応答メッセージが常に要求側アプリケーションのローカル・キュー・ポイントに戻される。 これによってメッセージのルーティングが軽減されます。
  • バス・メンバー内の別のメッセージング・エンジンに接続された要求側アプリケーションで同じ JMS キュー定義を使用することができる。 これによって、クラスター全体での動的ワークロード・バランシングが可能になります。
この方法には、以下の欠点があります。
  • 要求側アプリケーションが、応答メッセージを受け取る前に切断して再接続する場合には、 アプリケーションは、接続先のメッセージング・エンジンを認識して、再接続時に同じメッセージング・エンジンに接続する必要がある。これは、JMS 接続ファクトリーで、メッセージング・エンジンをターゲットにして、JMS 接続ファクトリーを使用して再接続することによって実現します。 この構成では、ワークロード・バランシングが除外されます。
  • 要求側アプリケーションが、サービス統合バス応答キューを所有するバス・メンバー内のメッセージング・エンジンに接続されている必要がある。 それ以外の場合は、応答メッセージをスコープするローカル・キュー・ポイントが存在しないため、システムがデフォルトのメッセージ・ルーティング動作に従います。

改良

アプリケーションの切断と再接続を可能にする一方で、 バス・メンバー内のすべてのメッセージング・エンジンでの複数の要求側アプリケーションのワークロード・バランシングを実現するには、 以下の構成が必要になります。
  • それぞれが別のメッセージング・エンジンをターゲットにする、複数の接続ファクトリー。
  • 複数の接続ファクトリー間で分散される、要求側アプリケーション。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0023_
ファイル名:cjt0023_.html