Acknowledgement Messages in IBM MQ Series (Websphere MQ)

来源:互联网 发布:广联达软件专用电脑 编辑:程序博客网 时间:2024/06/10 00:19

http://www.hitxp.com/comp/tools/MQ110805.htm

消息发到目标队列后的ack。

We know that IBM MQ Series is MOM i.e. Message Oriented Middleware which means that applications located at remote locations communicate across networks communicate with each other by sending messages to each other through MQ.

In this article I assume that the reader has adequate knowledge about communication between applications in a distributed architecture using Websphere MQ.

Obviously, this is a disconnected approach. In other words, an application A which sends messages to another application B located in some remote system does not wait for the application B to receive the messages. Application A just puts the messages into the local remote queue definition of the MQ and proceeds with its other activities. Later MQ forwards this message to its local queue in the remote system where the application B is located and after that the application B picks up the message from the local queue of its MQ. (See Image Below)

Now there might be situations when the distributed architecture is prepared where in application A needs to be ensured that the message sent by it has reached application B. In an asynchronous communication like above there is no way to ensure this immediately when the message is put into MQ of local system by application A.

The failure scenarios here where message does not reach application B might be like:

  • Network connection between the two systems is down.

  • The corresponding queue in remote system is not present or is full.

  • Application B is not running in remote system.

  • MQ is not running in the remote system. MQ Server/ queue manager might be down, etc.

In all these situations it might become necessary to notify application A about the success or failure in message delivery to application B. IBM MQ has an option to achieve this where in the application A could be notified of successful  delivery of messages. These messages which denote the message delivery success are called acknowledgement messages.

To summarize, an application (here A) when it puts messages into MQ can also request MQ to send acknowledgement messages to it (here application A) once the message has been delivered to MQ in remote system or to remote application (here application B).

TYPES OF ACKNOWLEDGEMENT MESSAGES:

As you can observe, there are two types of acknowledgement messages:

  • COA - Confirmation On Arrival

  • COD - Confirmation On Delivery

COA are those acknowledgement messages which are sent back as soon the message is received by the MQ in the remote system. These type of acknowledgement messages can be requested for when it is sufficient to know the successful delivery of messages to the remote system without having to worry about whether the applications in remote system will pick up the messages from their MQ or not.

COD are those acknowledgement messages which are send back only after the message is picked up from the remote MQ by the destination application (in this case application B). These type of acknowledgement messages are required when the source application (here A) has to know that the message has reached the intended target application (in this case B).

Whether to use COA or COD depends on the architecture of your distributed system.

Now how do we tell MQ that we want acknowledgement messages to be sent back?

Well, when you request for a COA or a COD of a message, you also have to specify the Reply-To-Queue Manager and Reply-To-Queue headers of the message. These have to be the queue manager and queue in the remote system, so that the remote MQ puts the acknowledgement messages (COA or COD) into this reply to queue of the reply to queue manager. The reply to queue will usually be a remote queue definition which points back to a local queue of MQ in the system where the application A is residing. Application A will pick up all acknowledgment messages from this local queue.

Hence, before you start sending messages to an application B from an application A by requesting acknowledgement messages, you will first have to setup queues for the acknowledgement messages to arrive in the reverse direction. Note that acknowledgement messages flow in the opposite direction of their messages. So in our case, you need to set up remote queue definition in a queue manager in the system where application B is running and have this remote queue definition to point to a local queue in a queue manager running in the system where application A is running. Then when you send messages from application A to B you need to specify this remote queue definition as the reply-to-queue and its queue manager as the reply-to-queue manager.

Now considering that the acknowledgement messages have arrived back to our system containing application A, how do we know as to which acknowledgement messages belongs to which message sent?

Well, we know the concept of a message header calledMessage ID in MQ. Each message in MQ is identified by a unique identifier which is stored in the message's message id header. What MQ does when it sends an acknowledgement message is that, it copies the message id of the original message into the the correlation id field of the acknowledgement message. So, by comparing the message id of the sent message and correlation id of the received message we can identify the original message of an acknowledgement message.

WHAT TO RECEIVE BACK?

Regarding the contents of the acknowledgement messages, we can specify one of the following three options to be contained in an acknowledgement messages.

  • We can specify that we want only the message headers of the original message to be sent back in an acknowledgement message. When all we want is the acknowledgement, we can use this option as this will save bandwidth and space as the contents of the original message will not be sent back with the acknowledgement message in this case.

  • OR we can also specify initial n bytes of the original message to be sent back in the acknowledgement message along with the headers of the original message

  • OR we can even specify the entire original message to be sent back in the acknowledgement message.