request - リクエスト/リプライパターンで JMS ルーターを実装する方法

Question

JMS を使用して相互に通信する必要があるアプリケーションがいくつかあります。それらをサーバーとクライアントとして説明します。次の手順が実行されます。

この2つだけなら大丈夫です。

(コンテンツベースの) ルーターを導入すると、次の手順が実行されます。

JMS仕様に準拠しながら、ルーターを正しく実装する方法を一生理解することはできません。

私は次のことを考え出しましたが、これがベストプラクティスであるかどうかはわかりません:

JMS ルーターはどのように機能する必要がありますか? / 私の設計は正しいですか?

score 0 · Accepted Answer

公式ドキュメントへの参照を含む可能性のある、より信頼できる回答を探していたので、さらに調査を行いました。これが私が見つけた最高のものです。

参照されているドキュメントには、次の2つのパターンが記述されています。

メッセージIDパターン

次の画像は、メッセージIDパターンを実装し、ルーターをプロキシとして実装するというアイデアを私に与えました。

メッセージIDパターンの例

つまり、私は最初のアイデアを採用しました。

score 0 · Accepted Answer

コンテンツベースのルーターを使用しているときに機能しない理由は、コンテンツベースのルーターが新しいメッセージ ID を持つ新しいメッセージオブジェクトを作成していて、元のメッセージから相関 ID が設定されていないためです。

これが私が過去に行った方法です。次のキューがあるとします。

チャネル A - クライアントはここにリクエストを送信します
チャネル S - サーバーはここでリクエストを取得します
1. クライアントはチャネル A に要求を送信し、クライアント固有の相関 ID を設定してキューに応答します
2. ルーターは A でメッセージを消費し、相関 ID が設定され、キューへの応答が設定された S へのメッセージを作成します
3. サーバーは、クライアント相関 ID を使用してキューへの応答に応答します

そのため、ルーターは応答メッセージの処理にまったく関与しないでください。ここで、このパターンを実装する際の一般的なエラーをいくつか紹介します。