使用 JMS 作为请求/响应服务
使用 JMS 作为请求/响应服务有多种实现。我想知道理想的实现方式。下面是这些不同的实现。
1) 永久请求队列、动态响应队列
所有请求消息都发布到指定回复队列的单个请求队列中。该服务使用请求消息并将消息发布回动态回复队列。
- 不需要相关 ID。
- 其相应响应队列的多个消费者
2) 永久请求队列、永久响应队列
所有请求消息都发布到单个请求队列中，在 jms 属性中指定唯一的 id。唯一 ID 存储在本地。服务使用请求消息并将消息发布回响应队列。单个响应消费者将消费该消息并根据唯一 ID 采取适当的行动。
- 需要关联 ID。
- 响应队列的单个消费者
3) 永久请求队列，永久响应主题
所有请求消息都发布到单个请求队列中，在 jms 属性中指定唯一的 id。该服务使用请求消息并将 jms 属性中具有相同唯一 ID 的消息发布回主题。响应的消费者将设置一个消息选择器来仅选择包含唯一 ID 的消息。
- 需要关联 ID。
- 响应主题的多个消费者
有人知道其他实现吗？这些实现中哪一个是使用 JMS 作为请求/响应服务的理想解决方案？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这就是我通常所做的：将请求发布到“永久”、“众所周知”队列。在请求消息中，发送者指定replyTo队列，该队列可以是永久的或动态的，具体取决于您的应用程序。要求。
合理唯一的 id/相关 id 至少应始终用于日志文件等中消息的可追溯性。根据您的要求，它可以位于 JMS 标头级别或有效负载级别（例如 SOAP messageId）。
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.