これは多かれ少なかれ流れですか?
CLIENT --> request-queue --> ESB --> service-queue --> SERVICE
then
SERVICE --> response-queue --> ESB --> tmp-queue --> CLIENT
私が提案する:
- クライアントがSessionを呼び出します。createTemporaryQueue . 返された一時キューは、同じ接続の使用中に再利用できるため、これは接続ごとに 1 回の操作になります。
- クライアントはリクエストを送信し、 Messageを呼び出して一時キューを返信先として追加します。setJMSReplyTo (tempTopic)。
- ESB はリクエストを受信し、そのレジストリ処理を行い、リクエストを SERVICE に転送し、メッセージの JMSReplyTo をクライアントの一時キューに再度設定します。
- サービスはその役割を果たし、メッセージ 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 を常に返すことは礼儀正しいと考えられています。