WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > How messages are passed between service integration and a WebSphere MQ network
How to address bus destinations and WebSphere MQ queues
To understand how to access a service integration bus destination from WebSphere MQ, and a WebSphere MQ queue from a service integration bus, it is important to understand the different conventions that govern how these two resources are addressed.
For queue-type destinations, WebSphere MQ has a two-level addressing structure:
- queue manager name
- queue name
The equivalents for the service integration bus are:
- bus name
- destination name (identifier)
In WebSphere MQ, the queue manager name and queue name are each limited to 48 characters, and use of certain characters is restricted. For more information, see WebSphere MQ naming restrictions.
The service integration bus equivalents do not have these restrictions, so (for example) messages from a WebSphere MQ application sent to a bus destination with a name longer than 48 characters must have some means of using the shorter name (used in WebSphere MQ) to address the longer name (used in the service integration bus). The service integration bus uses an alias destination to map between the shorter name and the long name. Similarly, an alias can also be used to send a message from a WAS application using a long name (greater than 48 characters) and route it to a WebSphere MQ queue. For more information about alias destinations, see Foreign destinations and alias destinations.
Service integration queue@queueManager notation for WebSphere MQ queues
When service integration sends a message across a WebSphere MQ link, it must know the foreign bus that corresponds to the gateway queue manager or queue-sharing group; and when the send-to queue is defined in a different queue manager or queue-sharing group (not the gateway), service integration must know the location of the send-to queue so that it can save the correct name in the MQXQH RemoteQMgrName field.
One way to achieve this is to define two foreign buses, an indirectly-connected bus (where the queue is defined) and a directly-connected bus (the gateway).
The following figure shows an example of this. In the figure, the target queue for a message is Q2 in queue manager QM2. The service integration configuration in the local bus defines QM2 as an indirectly-connected foreign bus and QM1 as the directly-connected intermediate bus. It defines Q2 as a foreign destination with bus name QM2 and destination name (identifier) Q2. The service integration configuration for the local bus does not include any information about the connection between QM1 and QM2.
Figure 1. Addressing a WebSphere MQ queue in an indirectly connected foreign bus
Accessing a foreign WebSphere MQ queue in this way works perfectly well. However, when there are a large number of queue managers or queue-sharing groups that connect to the service integration bus through one gateway, you might find it inconvenient to define every one of them as an indirectly-connected foreign bus. Therefore service integration supports the following special destination name format for WebSphere MQ queues that includes both the queue name and the queue manager name joined by the at-sign (@): queue@queueManager. Using this special format, we do not have to define a separate indirectly-connected foreign bus for service integration because the name is part of the service integration destination name.
The following figure shows an example of this. In the figure, the target queue for a message is Q2 in queue manager QM2. The service integration configuration in the local bus does not define QM2 as a foreign bus. It defines Q2 as a foreign destination with bus name QM1 and destination name (identifier) Q2@QM2. The service integration configuration for the local bus does not include any information about the connection between QM1 and QM2.
Figure 2. Addressing a WebSphere MQ queue using queue@queueManager notation
Automatic mapping of the JMSReplyTo field of a JMS message
There are two fields in the JMS API used for sharing information about the destination to which a message is sent (JMSDestination) and the destination to which replies should be sent (JMSReplyTo). The JMSReplyTo field of a JMS message passing from a service integration bus to WebSphere MQ (or from WebSphere MQ to a service integration bus) is automatically mapped so that a consuming application in WebSphere MQ can reply to the original WAS application.
Reference:
Map destinations to and from WebSphere MQ queues, topics, and destinations
WebSphere MQ naming restrictions