Point-to-point messaging with an IBM MQ network
The IBM MQ link, defined on a messaging engine in the service integration bus, describes the attributes required to connect to, and send or receive messages to or from, an IBM MQ queue manager or (for IBM MQ for z/OS ) queue sharing group that acts as a gateway to the IBM MQ network.
Point-to-point messaging might be:
- A request from WAS to IBM MQ, optionally followed by an IBM MQ reply.
- A request from an IBM MQ network, optionally followed by a WAS reply.
Figure 1. Exchanging messages between IBM MQ link sender and receiver channels, and a gateway queue manager with receiver and sender channels.
See Request-reply messaging through an IBM MQ link.
Point-to-point messaging might also include:
- A request from WAS through an IBM MQ network to another WAS, and a reply from that WAS, again through IBM MQ.
- A request from an IBM MQ network through a WAS to another IBM MQ network, and a reply from that IBM MQ network, again through a WAS.
The following figure shows how messages can be exchanged between applications and messaging engines that are on the same bus, as well as between the IBM MQ link and queue managers connected to the gateway queue manager in the IBM MQ network.
Figure 2. Exchanging messages between messaging engines on a bus that has an IBM MQ link that is connected to a gateway queue manager on a foreign bus.
- If our WAS application sends point-to-point messages to an IBM MQ application that is not JMS, such as an IBM MQ message-driven application in CICS (using the CICS MQ bridge) or IMS (using the IMS Q bridge), then our WAS application has to use special techniques to ensure that the service integration messages (most likely JMS messages) are presented to the non-JMS application in a way that the application can understand. For more information, see Programming for interoperation with IBM MQ, How service integration converts messages to and from IBM MQ format, and How to process IBM MQ message headers, which describes WAS helper classes that assist in the creation of suitable headers and body content.
- Some IBM MQ applications can process messages that include an MQRFH2 header (generally these are JMS or XMS or IBM MQ Version 7 applications) and some applications cannot do so (generally these are IBM MQ applications that predate the MQRFH2 header). We must set the destination context to inhibit adding an MQRFH2 header when messages are destined for an IBM MQ application that cannot handle this header. For information about setting the destination context, see Specify whether messages are forwarded to IBM MQ as JMS messages. The MQRFH2 header contains fields unique to the service integration bus. For details of these fields, see Mapping additional MQRFH2 header fields in service integration.
- Any IBM MQ queue name is also valid as a bus destination name and, as a general rule, we should configure a bus destination that is an IBM MQ queue to use the IBM MQ queue name. If our bus applications have to use a different name, we can achieve this using an alias destination.
- IBM MQ channel or conversion exits (for example, for data conversion) are not supported by the IBM MQ link.
Related:
Message reliability levels - JMS delivery mode and service integration quality of service Specify whether messages are forwarded to IBM MQ as JMS messages Mapping the message body to and from IBM MQ format Mapping the message header fields and properties to and from IBM MQ format Mapping additional MQRFH2 header fields in service integration Mapping the JMS delivery option and message reliability to and from the IBM MQ persistence value