0

ESBを介してJMSベースのメッセージングのみを実行します。ESBには、クライアントがSOAPラッパーを使用してサービス要求を送信する専用のREQUESTキューがあります。ラッパーは、サービスの名前とバージョン、レジストリルックアップ、サービスQUEUEへのルートについて解釈されます。サービスは、専用のESBREPLYキューでESBに応答します。次に、TMPキュー上のクライアントに応答を送り返すために、保存された要求を修正するために相関させる必要があります。サービスSentMsgIDをキーとして使用して、元のJMSリクエストのTMPキューをある種のキャッシュに保存して、元のリクエストのメッセージIDとTMPキューを取得する方法がわかりません。

だから2つの質問。プロキシ設定のjmsmsgヘッダーにアクセスする方法。ある種のキャッシュを設定する方法、または応答で使用されるデータを格納して、それらを要求に関連付けて応答を設定する方法。ドキュメントには純粋なJMSサンプルはまったくありません。

4

1 に答える 1

0

これは多かれ少なかれ流れですか？

CLIENT --> request-queue --> ESB --> service-queue --> SERVICE
then
SERVICE --> response-queue --> ESB --> tmp-queue --> CLIENT

私が提案する：

  1. クライアントがSessionを呼び出します。createTemporaryQueue . 返された一時キューは、同じ接続の使用中に再利用できるため、これは接続ごとに 1 回の操作になります。
  2. クライアントはリクエストを送信し、 Messageを呼び出して一時キューを返信先として追加します。setJMSReplyTo (tempTopic)。
  3. ESB はリクエストを受信し、そのレジストリ処理を行い、リクエストを SERVICE に転送し、メッセージの JMSReplyTo をクライアントの一時キューに再度設定します。
  4. サービスはその役割を果たし、メッセージ JMSReplyToHeader で応答を宛先に直接送信します。(応答が ESB を経由しなければならない特定の理由はありますか?)

したがって、実際の流れは次のようになります。

CLIENT --> request-queue --> ESB --> service-queue --> SERVICE
then
SERVICE --> tmp-queue --> CLIENT

すぐに思いつくことができる落とし穴が 2 つあります (そして、押されて、私はもっと思いつくことができると確信しています....)

  • サービスは別のブローカーで動作しており、クライアントの一時キューに直接送信できません。

この場合、メッセージ ID をキーとするクライアント一時キューのキャッシュを ESB に維持させます。ESB がその要求をサービスに送信するときに、JMSCorrelationId ヘッダーを CLIENT から受信したメッセージのメッセージ ID に設定します。SERVICE は、受信したメッセージから JMSCorrelationId を読み取り、ESB に送り返す応答メッセージに追加する必要があります。(まだ混乱していますか?) ここで、ESB は SERVICE から応答を受信し、JMSCorrelationId をアンパックし、対応する一時キューを検索して応答を送信します。

CLIENT が常に一意の client-id を提供できる場合は、messageId によって一時キューをキャッシュするのではなく、それによって一時キューをキャッシュすることができます (粒度が低くなります)。サービスとのコントラクトは、JMSCorrelationId から client-id に切り替わります。ただし、私の経験では、要求応答 JMS サービスが提供されたcorrelationId を常に返すことは礼儀正しいと考えられています。

于 2013-02-14T21:28:34.053 に答える