Using JMS as a request/response service

There are various implementations for using JMS as a request/response service. I would like to know the ideal implementation. Below are these various implementations.

---

1) Permanent request queue, Dynamic response queue

All request messages are published into a single request queue specifying the reply queue. The service consumes the request message and publishes a message back onto a dynamic reply queue.

• No need for a correlation id.
• Multiple consumers of their corresponding response queues

2) Permanent request queue, Permanent response queue

All request message are published into a single request queue, specifying a unique id in the jms properties. Unique id is stored locally. Service consumes request message and publishes message back onto response queue. A single response consumer will consume the message and act appropriately based on the unique id.

• Correlation id required.
• Single consumer of the response queue

3) Permanent request queue, Permanent response topic

All request messages are published into a single request queue, specifying a unique id in the jms properties. The service consumes the request message and publishes a message with the same unique id in the jms properties back onto the topic. Consumers of the response will set a message selector to select for only the message the contains the unique id.

• Correlation开发者_开发技巧 id required.
• Multiple consumers of the response topic

Does anyone know other implementations? And which of these implementations is the ideal solution for using JMS as a request/response service?

---

This is what I usually do: Request posted to the 'permanent', 'well-known' queue. In the request message sender specifies replyTo queue which can be permanent or dynamic depending on your app. requirement.

Reasonably unique id/correlation id should always be used at least for traceability of the messages in the log files etc. It could be on JMS headers level or on payload level (e.g. SOAP messageId) depending on your requirements.

---

I have used both first and third implementations. I am not sure about the second one as single queue for multiple consumers can cause issue when one consumer can starve another consumers. To avoid that, we might need to have a dispatcher in place which again can lead to scalability issue as new queue will need to be added for each consumer.