Messaging between two application servers through IBM MQ

Use IBM MQ links to send a WebSphere Application Server message from one application server to another through an IBM MQ network.

We can exchange messages between two application servers through an intermediate IBM MQ network, as shown in the following figure:

In this case, the IBM MQ network includes two gateway queue managers. One connects to the local bus using an IBM MQ sender-receiver pair of message channels, known to the local bus as an IBM MQ link. The other connects to the indirect foreign bus using another IBM MQ sender-receiver pair of message channels, known to the indirect foreign bus as an IBM MQ link. In the simplest case, the same gateway queue manager connects to both the local bus and the indirect foreign bus.

The IBM 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 IBM MQ Intercommunication.

Configuration and operation of messaging between two service integration buses through an intermediate IBM MQ network is more straightforward if we choose bus names that comply with IBM MQ queue manager naming restrictions, and if we choose bus destination names that comply with IBM MQ queue naming restrictions:

• Queue managers in the IBM 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 IBM MQ restrictions for queue manager names, the virtual queue manager name that IBM MQ uses can (and should) be the same as the bus name used by service integration.

  If the virtual queue manager name that IBM 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 IBM 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 IBM MQ link automatically substitutes the virtual queue manager name when passing the message to the IBM MQ network.

• While messages are being transported through the IBM MQ network, IBM MQ treats the names of service integration queue type destinations as IBM MQ queue names. This means that IBM MQ cannot transport service integration destination names that do not comply with IBM MQ queue name restrictions correctly.

  If the target destination name does not comply with IBM 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 IBM MQ queue name restrictions. Alternatively, applications on the local bus can use the IBM MQ-compliant name instead of the actual bus destination name.

  In either case, the remote bus must define an alias destination that maps the IBM MQ-compliant name to the actual bus destination name. If the reply-to destination name does not comply with IBM MQ queue name restrictions, applications on the local bus must use an IBM MQ-compliant name instead of the actual bus destination name. The local bus must define an alias destination that maps the IBM MQ-compliant name to the actual bus destination name.

While messages are being transported through the IBM 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 an IBM MQ network and WAS. This is not automatic, as it is for messages with queue reply destinations.