MQe applications on different MQe queue managers communicate with each
through the exchange of messages. In the simplest case, the source and target
queue managers are either directly connected to each other through MQe channels,
or indirectly connected with the messages between them passing through intermediate
MQe queue managers. In all of these cases, the standard MQe message object
class
com.ibm.mqe.MQeMsgObject is used to create these
messages or some appropriate subclass (as in the case of administrative messages).
The situation becomes more complicated when the intermediate queue managers
are not MQe queue managers but are WebSphere
® MQ managers. In this case,
the messages can be regarded as tunnelling across a MQ network; with the passage
across the MQ network having no affect on either the sending or receiving
application. Tunnelling requires the following configuration:
Figure 1. MQe
message tunnelling
The MQe queue manager that passes the messages to an MQ queue manager is
configured as a bridge queue manager. Likewise, the MQe queue manager that
receives messages from an MQ queue manager is also configured as a bridge
queue manager. Bridge queue managers are sometimes referred to as gateway
queue managers. The details of bridge configuration as described elsewhere;
it is sufficient here to understand that a single configured bridge can handle
messages travelling in both directions (for example, to and from MQ) and that
the important determinants in its behavior are: (a) the transformer class
property value (set in the bridge configuration), and (b) for messages passing
from MQe to MQ, the class of the MQe message. In many cases the requirement
is not to transport messages across a MQ network, but to use messages from
a MQe source application to drive a target MQ application, typically returning
the results in a reply message. The configuration involved is of the form
shown below, though the target application can run on any MQ queue manager,
including the one immediately connected to the MQe bridge:
Figure 2. Driving
MQ applications
As before, the important determinants in the behavior of the bridge are:
- The transformer class property value (set in the bridge configuration)
- For messages passing from MQe to MQ, the class of the MQe message
The class of message used by the source must allow complete control over
the generated MQ message being received by the MQ application. Typically the
com.ibm.mqe.mqemqmessage.MQeMQMsgObject class
is used for this purpose; however, if JMS is being used as the messaging model
at both the source and the target, then the
com.ibm.mqe.MQeMsgObject message
class is used, although with very specific content present. For more details
about using JMS, see
Java Message Service (JMS).
An additional requirement is to support the needs of publish and subscribe
applications, where an IBM
® broker is the destination MQ application and manages
both the subscriptions and the publications. The MQe source is liable to be
just one of many sources inputting to the broker. There are two configurations
possible to implement a publish/subscribe network, however only one is now
recommended. This is:
Figure 3. Publish/subscribe via the MQe bridge
Yet again, the important determinants in the behavior of the bridge are:
(a) the transformer class property value (set in the bridge configuration),
and (b) for messages passing from MQe to MQ, the class of the MQe message.
Here, the choice of message used by the source, must allow a publish/subscribe
MQ message to be output by the bridge and subsequently received by the broker.
The com.ibm.mqe.mqemqmessage.MQePubSubMsgObject class
is used for this purpose. For responses back from the broker, the bridge transformer
class detects from the MQ message content that it is a publish/subscribe response
and therefore returns a com.ibm.mqe.mqemqmessage.MQePubSubMsgObject class
message back to the source.
In previous versions of MQe the following configuration was supported:
Figure 4. Publish/subscribe via the MQe broker input node
The source sent a class com.ibm.broker.mqimqe.wrapper.MQeMbMsgObject or
a com.ibm.mqe.MQeMsgObject message to the MQe input node
on the broker. This configuration is no longer recommended; migration scenarios
from earlier implementations are discussed later in this section.