Network Deployment (Distributed operating systems), v8.0 > Applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using a WebSphere MQ link
Messaging between two application servers through WebSphere MQ
We can use WebSphere MQ links to send a WAS message from one application server to another through a WebSphere MQ network.
We can exchange messages between two application servers through an intermediate WebSphere MQ network, as shown in the following figure:
Figure 1. Exchanging messages between two application servers through an intermediate WebSphere MQ network.
In this case, the WebSphere MQ network includes two gateway queue managers. One connects to the local bus by using a WebSphere MQ sender-receiver pair of message channels, known to the local bus as a WebSphere MQ link. The other connects to the indirect foreign bus by using another WebSphere MQ sender-receiver pair of message channels, known to the indirect foreign bus as a WebSphere MQ link. In the simplest case, the same gateway queue manager connects to both the local bus and the indirect foreign bus.
The WebSphere MQ network must be configured to route messages as required between the local bus and the indirect foreign bus. Details of this configuration are not normally important to WAS administrators, but can be found in WebSphere MQ Intercommunication.
Configuration and operation of messaging between two service integration buses through an intermediate WebSphere MQ network is much more straightforward if you choose bus names that comply with WebSphere MQ queue manager naming restrictions, and if you choose bus destination names that comply with WebSphere MQ queue naming restrictions:
- Queue managers in the WebSphere MQ network "see" the local bus and the indirect foreign bus as queue managers, and refer to them by their virtual queue manager names. If the service integration bus names comply with WebSphere MQ restrictions for queue manager names, the virtual queue manager name that WebSphere MQ uses can (and should) be the same as the bus name used by service integration.
If the virtual queue manager name that WebSphere MQ uses for a foreign bus is not the same as the service integration bus name used by that foreign bus, the local bus must define the foreign bus by the virtual queue manager name of that foreign bus, not the actual service integration bus name (because the intermediate WebSphere MQ network does not know the actual service integration bus name and cannot route messages directed to that name). Reply-to destinations can always use the local bus name, because the WebSphere MQ link automatically substitutes the virtual queue manager name when passing the message to the WebSphere MQ network.
- While messages are being transported through the WebSphere MQ network, WebSphere MQ treats the names of service integration queue type destinations as WebSphere MQ queue names. This means that WebSphere MQ cannot transport service integration destination names that do not comply with WebSphere MQ queue name restrictions correctly.
If the target destination name does not comply with WebSphere MQ queue name restrictions, the local bus must define an alias destination that maps the actual bus destination name to a name that does comply with WebSphere MQ queue name restrictions. Alternatively, applications on the local bus can use the WebSphere MQ-compliant name instead of the actual bus destination name.
In either case, the remote bus must define an alias destination that maps the WebSphere MQ-compliant name to the actual bus destination name. If the reply-to destination name does not comply with WebSphere MQ queue name restrictions, applications on the local bus must use a WebSphere MQ-compliant name instead of the actual bus destination name. The local bus must define an alias destination that maps the WebSphere MQ-compliant name to the actual bus destination name.
While messages are being transported through the WebSphere MQ network, important context information is transported in the MQRFH2 header. Configure the application so that the MQRFH2 header is included.
Messages with topic style reply-to destinations must have the appropriate publish/subscribe bridge topic mappings defined in the relevant direction so that reply messages can be transferred between a WebSphere MQ network and WAS. This is not automatic, as it is for messages with queue reply destinations.
Concept topic