JMS несколько потребителей для одной очереди

Question

Один из наших клиентов имеет реализацию на основе JMS, в которой есть очереди для чтения/записи сообщений. Клиент JMS должен записывать в исходящую очередь, и он будет считывать ответ из входящей очереди. Клиент JMS будет развернут на нескольких сайтах и ​​будет разговаривать с одной исходящей очередью для записи сообщений и будет считывать из входящей очереди (только один) для ответов. Рассмотрим сценарий, в котором есть 100 уникальных исходящих запросов, а затем пользователь получает 100 различных ответов для отправленных запросов (предположим, что сообщения были доставлены правильно). Как я могу гарантировать, что сообщения, которые потребитель читает из входящей очереди, предназначены для назначенного получателя? Нужно ли нам писать собственную логику для сопоставления запроса/ответа? или у JMS есть механизм доставки на основе идентификатора соединения ... и т. д., чтобы сообщение доставлялось правильному реквестору. Заранее благодарю вас, вам нужны ваши экспертные материалы для правильного проектирования приложения. Я использую JMS-провайдер Apache ActiveMQ.

С уважением, Sumeet C

Answer 1

Это звучит, как вам нужно REQUEST/REPLY ...

Запрос/Ответ - Синхронные
Отправитель очереди посылает REQUEST сообщение, а затем в том же потоке, получает a REPLY. Посылающий поток блокируется до тех пор, пока получатель не отправит ответное сообщение, гарантируя, что ответ будет выполнен для первоначального запроса. Это базовый набор вверх, который использует временные очереди, REPLY_TO адресацию и JMSCorrelationID ...

Apache ActiveMQ Request/Reply
EAI Patterns for JMS Request/Reply

точка-точка - Асинхронный
Если реализация JMS клиента обеспечивает различные очереди для отправляя запросы и получая ответы, вы можете отправлять сообщения асинхронно с уникальным JMSCorrelationID и при условии, что клиент отправит ответ с тем же идентификатором, вы можете получить ответное сообщение в другом потоке и сопоставить их с исходным запросом на основе t он JMSCorrelationID. Технически говоря, REQUEST/REPLY делает то же самое, кроме того, что он блокирует и использует временные очереди для отправки ответных сообщений обратно запрашивающему, а не с явно указанными очередями.