クラスター・バス・メンバーによる JMS 要求/応答メッセージング
標準的な JMS メッセージング・パターンでは、メッセージング・サービス (例えばメッセージ駆動型 Bean) による処理のために、要求側アプリケーションが JMS キューにメッセージを送信します。
要求側アプリケーションが要求メッセージを送信する場合、メッセージでは、サービスが応答メッセージを送信する先の、別の JMS キューを指定します。 要求メッセージの送信後、要求側アプリケーションは、応答メッセージが到着するまで待機するか、後から再接続して応答メッセージを取得します。
図 1. 標準的 JMS メッセージ・パターン

要求/応答パターンには以下の条件が必要です。
- サービスが応答メッセージを送信する必要がある宛先を、要求側アプリケーションが要求メッセージで識別できる。
- 要求側アプリケーションが応答ロケーションからの応答メッセージを消費できる。
JMS キューは、サーバー・バス・メンバーまたはクラスター・バス・メンバーで定義されたサービス統合バス宛先を参照することができます。
- バス・メンバーが (1 つのメッセージング・エンジンしか持つことができない) サーバーであるか、1 つのメッセージング・エンジンを持つクラスターである場合、JMS キューが単一のサービス統合バス・キュー・ポイントを指定する。
- バス・メンバーが複数のメッセージング・エンジンを持つ (一般的にはワークロード共有またはスケーラビリティーを提供するため) クラスターである場合、JMS キューが複数のキュー・ポイント (バス・メンバー内の各メッセージング・エンジンに 1 つずつ) を指定する。
図 2. アプリケーション・サーバー・バス・メンバーに定義されたサービス統合バス・キュー宛先

デフォルトでは、以下の振る舞いが発生します。
- アプリケーションがメッセージを送受信する対象のキュー・ポイントは、メッセージング・システムによって決定されます。
- 存続期間を通して、コンシューマー (この場合は、JMS メッセージ・コンシューマー) は、単一のキュー・ポイントからのみ消費します。
この要求/応答の動作によって、応答メッセージを要求側が待機しているキュー・ポイントから別のキュー・ポイントに送信することができます。これによって、応答メッセージが受け取られない可能性が生じます。
図 3. 2 つのメッセージング・エンジンを持つクラスター・バス・メンバーに対して定義されたサービス統合バス・キュー宛先

こうした条件を克服するために、サービス統合バス・システムまたは JMS アプリケーションを構成する際には、以下のようなさまざまなオプションがあります。
各オプションの利点と欠点およびアプリケーションの要件を考慮した上で、方法を選択してください。
要約
要求/応答シナリオの要件を満たす最も単純なソリューションを使用してください。以下に例を示します。
- 応答メッセージが、要求側アプリケーションが最初に接続されている間にのみ必要な場合には、非パーシスタント・メッセージおよび一時キューを使用します。 また、要求側アプリケーションが限られた時間しか応答を待たない場合には、初期要求メッセージの timeToLive の設定を検討します。
- 単一のキュー・ポイント (およびそのメッセージング・エンジン) が要求側アプリケーションのすべての応答メッセージ・トラフィックを処理できるが、他のメッセージング・トラフィック (例えば要求メッセージ) で複数のメッセージング・エンジンを持つクラスター・バス・メンバーが必要な場合、サービス統合バス別名宛先を使用して、メッセージをその単一のキュー・ポイントにスコープします。
必要に応じて、これらのオプションを組み合わせて、アプリケーションの要件を最も満たし、最高のパフォーマンスとスケーラビリティーを実現するソリューションを得ることができます。
例えば、要求側アプリケーションが、通常は初期接続で応答メッセージを受け取るが、特定のごく稀な条件 (例: 障害) で再接続して応答を受け取る必要がある場合には、
以下の方法が適しているでしょう。
- JMS キューの scopeToLocalQP オプションを使用可能にして、 要求側アプリケーションがクラスター・バス・メンバー内のすべてのメッセージング・エンジンに接続する (つまり、バス・メンバーの JMS 接続ファクトリーをターゲットにする) ことができるようにします。 これによって、接続のワークロード・バランシングが可能になりますが、応答メッセージはローカル・キュー・ポイントに制限されます。 結果として、要求を送信するために使用された応答を受け取るのと同じ接続を使用する一方で、応答メッセージを見つけることができます。
- 障害発生後に再接続する場合は、JMS キューのメッセージ収集オプションを使用可能にして、保持されているどこからでも応答メッセージを受け取れるようにします。
この方法によって、メッセージ収集の使用を障害シナリオの発生時に限定することによって、 メッセージ収集によるパフォーマンスへの影響を最小限に抑えながら、要求側アプリケーションの動的ワークロード・バランシングが実現します。