IBM WebSphere MQ请求/答复场景 [英] IBM WebSphere MQ request/reply scenario

问题描述

我目前正在一个项目中，我需要与一个通过WebSphere MQ与外界进行通信的IBM系统进行交互.我需要使用队列以请求-响应"方式查询系统，而我将通过队列管理器来执行此操作.

I'm currently working on a project where I need to interface with an IBM system which communicates with the outside world through WebSphere MQ. I need to query the system in a "request-response" fashion using queues, and I will be doing this through a queue manager.

但是，我不太了解实际的工作原理.

However, I can't quite get my head around how this works in practical terms.

说我有同一个应用程序的多个实例，该实例将一条消息放入请求队列.离开应用程序后，该消息将得到CorrelationId和MessageId，并且在每条消息上都设置了ReplyToQueue属性，以确保队列管理器知道将响应放入哪个队列.

Say I've got multiple instances of the same application which puts a message onto a request queue. The message gets a CorrelationId and MessageId upon leaving the application, and a ReplyToQueue property gets set on each message to make sure that the queue manager knows which queue to put the response onto.

但是，队列管理器如何操作响应队列?关于响应的时间不能保证，那么正确的响应又如何返回到发出相应请求的应用程序实例呢?

However, how does the queue manager operate the response queue? There is no guarantee with regards to the timing of responses, so how is it that the correct response gets back to the application instance which issued the corresponding request?

我一直认为消息队列是一个FIFO队列，在该队列中必须逐一选择消息.但是，这意味着实例A可以选择实例B的响应.显然，这不是它的工作方式.

I keep thinking of message queues as a FIFO queue where messages must be picked one by one. However, this would mean that instance A could pick a response meant for instance B. Obviously, this can't be how it works.

然后，当我查看API(com.ibm.mq.MQQueue)时，我看到要选择一条消息，我有机会提供请求消息的CorrelationId和MessageId.这是否意味着当我向队列管理器查询消息(已设置了这些ID)时，队列管理器遍历队列中的消息并返回匹配的消息?另一方面，这是否意味着我们不是在谈论FIFO队列?

Then, when I look at the API (com.ibm.mq.MQQueue) I see that to pick a message I have the chance to provide the CorrelationId and MessageId of the request message. Does this mean that when I query the queue manager for a message (with these ID's set), the queue manager iterates through the messages in the queue and returns the matching message? This, on the other hand, would mean that we're not talking about a FIFO queue?

推荐答案

通常使用CorrelationId关联请求和响应消息.它是这样工作的:

It is common practice to use CorrelationId to relate request and response messages. It works this way:

1)假设有两个队列，一个REQQ-请求队列，用于放置消息以请求另一个应用程序(服务应用程序)进行提取和处理，以及一个RESPQ(服务应用程序对其进行答复).

1) Let's assume there are two queues, a REQQ - request queue where messages are put asking another application, service application, to pick up and process and a RESPQ to which the service application puts replies.

2)请求者应用程序(我们将其称为REQAPP)将请求消息(REQMSG)放入请求队列(REQQ).在发送消息之前，REQAPP将消息上的ReplyToQ属性设置为RESPQ.发送请求消息后，JMS提供程序将使用唯一的MessageId更新发送的消息.请求者应用程序将缓存此唯一的MessageId供以后使用.

2) The requester application (let's call it as REQAPP) puts a request message (REQMSG) to request queue (REQQ). Before sending the message the REQAPP sets ReplyToQ property on the messages to RESPQ. When the request message is sent, the JMS provider updates the sent message with a unique MessageId. The requester application caches this unique MessageId for later use.

3)在世界的另一端，服务应用程序从REQQ检索REQMSG，从该消息中读取MessageId和ReplyToQ属性，处理请求并准备适当的响应消息RESPMSG.然后，它将RESPMSG的CorrelationId属性设置为从REQMSG读取的MessageId，并将答复放入ReplyToQ.

3) On the other side of the world, the service application retrieves the REQMSG from REQQ, reads the MessageId and ReplyToQ property from that message, processes the request and prepares appropriate response message RESPMSG. It then sets the CorrelationId property of the RESPMSG to the MessageId read from the REQMSG and puts the reply to ReplyToQ.

4)请求者应用程序在阅读答复时，将使用MessageId缓存并按如下所示设置选择标准来读取答复消息

4) The requester application when reading replies, it uses the caches MessageId and sets selection criteria as below to read reply message

GET MESSAGE FROM RESPQ WHERE RESPMSG.CORRELATIONID==REQMSG.MESSAGEID

此选择标准可确保检索到正确的响应消息.这里的关键是服务应用程序必须将响应消息上的CorrelationId设置为请求消息的MessageId.

This selection criteria makes sure that correct response messages is retrieved. The key here is the service application must set the CorrelationId on the response message to the MessageId of request message.

尽管队列是FIFO类型，但是MQ实现在优先级的基础上提供消息传递，优先级高的消息首先传递；在FIFO的基础上，队列顶部的消息首先传递.如上例中所述，还可以使用选择标准来检索消息.

Although Queue is FIFO type, MQ implementation provides message delivery on a Priority basis where messages with high priority are delivered first or FIFO basis where message on top of the queue is delivered first. Messages can also be retrieved using selection criteria as explained in above example.

希望这对您有帮助

这篇关于IBM WebSphere MQ请求/答复场景的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！