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

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

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

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

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

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

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

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

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

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

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

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


request java response service jms
person onejigtwojig    schedule 04.11.2010    source источник
comment
Почему при первом подходе несколько потребителей могут читать из очереди динамических ответов? Только один потребитель должен читать из заданной очереди ответов, потому что сообщение может быть прочитано из очереди только один раз, и поэтому, если непреднамеренный получатель прочитает сообщение, предполагаемый получатель никогда не получит это сообщение.   -  person Derek Mahar    schedule 31.01.2011
comment
Извините, я не разъяснил это правильно. Несколько потребителей используют свои собственные (разные) очереди динамических ответов. Они не читают из одной очереди.   -  person onejigtwojig    schedule 04.02.2011

Ответы (2)


arrow_upward
2
arrow_downward

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

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

person maximdim    schedule 04.11.2010

arrow_upward
0
arrow_downward

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

person Rishabh Agarwal    schedule 14.08.2018