You can use WebSphere® MQ
links to send a message from one WebSphere Application Server application
server to another through a WebSphere MQ
network.
The following figure shows how you can exchange messages between
two application servers through an intermediate WebSphere MQ network. A local service integration
bus is connected by a WebSphere MQ link to a WebSphere MQ network,
which is a direct foreign bus. The WebSphere MQ network is in turn
connected by a WebSphere MQ link to another service integration bus,
which is a indirect foreign bus.
Figure 1. Exchanging messages between
two application servers through an intermediate WebSphere MQ network.
In the general case, the WebSphere MQ
network includes two gateway queue managers; one connects to the local
bus using a WebSphere MQ
sender-receiver channel pair (known to the local bus as a WebSphere MQ link), the other connects
to the indirect foreign bus using another WebSphere MQ sender-receiver channel pair
(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 WebSphere Application Server administrators,
but can be found in the WebSphere MQ
Intercommunication book (SC34-6059).
Configuration and operation of messaging between two service integration
buses through an intermediate WebSphere MQ
network is much simpler 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 using their virtual queue manager names.
Provided that the service integration bus names comply with WebSphere MQ restrictions
for queue manager names, it is possible (and highly desirable) for
the virtual queue manager name used by WebSphere MQ to be the same as the bus
name used by service integration. If the virtual queue manager name
used by WebSphere MQ for
a foreign bus is not the same as the service integration bus name
used by that foreign bus, then the local bus must define the foreign
bus using 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, the names of service
integration queue type destinations are treated by WebSphere MQ as WebSphere MQ queue names. This means that
service integration destination names that do not comply with WebSphere MQ queue name restrictions
cannot be transported correctly by WebSphere MQ.
If the send-to 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. You should configure
the application so that the MQRFH2 header is included.
WebSphere MQ request
messages contain a single reply-to queue name to which a receiving
application can send responses. The service integration bus has a
more advanced reply path (not just a single queue name).
- The reply path is held in the sib folder
in the MQRFH2 header, which WebSphere MQ
ignores but relays in the message header.
- The reply path is held in the Rto field
of the jms folder in the MQRFH2 header, which WebSphere MQ ignores but relays
in the message header.
You can use reply-to queues for point-to-point messages (queues)
and for topics.
Messages with topic style reply-to destinations must have the appropriate
publish and subscribe bridge topic mappings defined in the relevant
direction in order for reply messages to be transferred between a WebSphere MQ network and WebSphere Application Server. This is not
automatic as it is for messages with queue reply destinations.