A common topology is to allow messages to flow between MQ and a client
MQe queue manager. This cannot happen directly, but requires an intermediate
bridge-enabled MQeQueue manager. The client can then be a small footprint
device with no knowledge of MQ. Additions are needed to allow a client (MQeMoonQM,
on a device called moon) to communicate with MQ, as shown in the following
diagram:
Figure 1. A client communicating with MQ
This adds the following:
- (Host)moon
- (QueueManager) MQeMoonQM on (Host)moon
- A connection definition from MQeMoonQM to a matching listener on MQeEarthQM
to provide the connectivity between the two MQe queue managers.
- A store and forward queue on MQeEarthQM that accepts and holds messages
for MQeMoonQM, and a home server queue on MQeMoonQM that pulls messages from
the store and forward queue.
- A remote queue definition on the MQ queue manager that routes messages
for MQeMoonQM to the transmission queue MQeEarth.XMITQ. This allows messages
for MqeMoonQM to be placed on the transmission queue, from where they are
pulled to MQeEarthQM.
The topology is more readily seen as message routes, as shown in the following
diagram:
Figure 2. Simplified pull routes from MQ through an MQe gateway
to an MQe device style queue manager
Messages can be pushed to MQ by using a via connection to chain remote
queues, as shown below:
Figure 3. Pushing messages using a via connection
Here a via connection has been added to route messages destined for MQSaturnQM
vian MQeEarthQM, and a remote queue definition for MQSaturnQ@MQSaturnQM has
been added. The messages can now flow from the client to MQ, as shown in the
following diagram:
Figure 4. Pushing messages to MQ
This topology is more easily understood as a collection of message routes,
as follows:
Figure 5. Simplified view showing routes which push messages
from a device style MQe queue manager to an MQ queue manager