Использование JMS в качестве службы запроса / ответа

Question

Существуют различные реализации для использования JMS в качестве службы запроса / ответа.Я хотел бы знать идеальную реализацию.Ниже приведены эти различные реализации.

---

1) Постоянная очередь запросов, очередь динамических ответов

Все сообщения запросов публикуются в одной очереди запросов с указанием очереди ответов.Служба использует сообщение запроса и публикует сообщение обратно в очередь динамического ответа.

• Нет необходимости в идентификаторе корреляции.
• Несколько потребителей из соответствующих им очередей ответов

2) Постоянная очередь запросов, Постоянная очередь ответов

Все сообщения запроса публикуются в одной очереди запросов с указаниемуникальный идентификатор в свойствах jms.Уникальный идентификатор хранится локально.Сервис использует сообщение запроса и публикует сообщение обратно в очередь ответов.Потребитель с одним ответом будет использовать сообщение и действовать в соответствии с уникальным идентификатором.

• Требуется идентификатор корреляции.
• Единственный получатель очереди ответов

3) Постоянная очередь запросов, тема постоянных ответов

Все сообщения запросов публикуются в одной очереди запросов с указанием уникальногоid в свойствах jms.Служба использует сообщение запроса и публикует сообщение с тем же уникальным идентификатором в свойствах jms обратно в тему.Потребители ответа установят селектор сообщений для выбора только того сообщения, которое содержит уникальный идентификатор.

• Требуется идентификатор корреляции.
• Несколько потребителей темы ответа

Кто-нибудь знает другие реализации?И какая из этих реализаций является идеальным решением для использования JMS в качестве службы запроса / ответа?

Answer 1

Это то, что я обычно делаю: запрос отправлен в «постоянную», «известную» очередь. В запросе отправитель сообщения указывает очередь replyTo, которая может быть постоянной или динамической в ​​зависимости от вашего приложения. требование.

Разумно уникальный идентификатор / идентификатор корреляции всегда должен использоваться, по крайней мере, для отслеживания сообщений в файлах журнала и т. Д. Это может быть на уровне заголовков JMS или на уровне полезной нагрузки (например, SOAP messageId) в зависимости от ваших требований.

Answer 2

Я использовал как первую, так и третью реализации.Я не уверен насчет второго, поскольку единая очередь для нескольких потребителей может вызвать проблему, когда один потребитель может голодать от других потребителей.Чтобы избежать этого, нам может понадобиться диспетчер , который снова может привести к проблеме масштабируемости, поскольку для каждого потребителя потребуется добавить новую очередь.