Scenarios

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
Tunnelling configuration
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
Using messages from a MQe source application to drive a target MQ application
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
Using messages from a MQe source application to drive a target MQ application

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
Using messages from a MQe source application to drive a target MQ application

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.


Terms of use | WebSphere software

(c) Copyright IBM Corporation 2004, 2005. All rights reserved.