The following diagrams show some typical MQe configurations. For the purpose of clarity, the diagrams show only the direct connections that have been defined. You can also define indirect connections that exploit the direct connections. In the diagrams, a line with the arrow pointing to the server represents a client/server connection. Clients can use the client/server connection both to send messages to the server and to pull messages destined for themselves from that server. Lines with no arrows indicate MQ client channels that enable communications between MQe and MQ.
Figure 1 shows a standalone queue manager being used to support one or more applications that use queues to exchange data.
Figure 2 shows a small network configuration, where the central server queue managers use a pair of direct client/server connections to exchange information. Each client queue manager uses a direct client/server connection to link to one of the server queue managers.
Figure 3 (Figure 3) shows an MQe configuration where one of the queue managers has been configured with the bridge option and the pool of client channels has been directed at a single target MQ host/distributed server.
As connections typically define the access to a remote queue manager, they are sometimes referred to as remote queue manager definitions.
You can also specify indirect connections. In this case, MQe routes the connection through other queue managers (which can be chained), and the protocol can change en route. Indirect connections are particularly useful in enabling devices to have a single point of entry to an MQe network.
As with most MQ elements, you can define aliases for connections. Use a local connection, defined as a connection with a name matching that of the local queue manager, to define alias names for the local queue manager itself.
Connections support bidirectional flows and are established by the queue manager as required. Asynchronous and synchronous messaging both use the same connections and the protocol used is unique to MQe.
Connection definitions determine the links and protocols to be used for a particular connection. At each intermediate node any messages flowing through are passed to the queue manager at that point. The queue manager will handle the messages according to the resources it has. So a message may be placed on a queue which might be a local queue, a remote queue, or a store-and-forward queue. Messages placed on remote queues will continue their journey according to the type of remote queue. Synchronous remote queues will move the messages onward immediately. Asynchronous remote queues will store their messages before moving them.
Connections are not directly visible to applications or administrators and are established by the queue manager as required. Connections link queue managers together and their characteristics are changed by MQe, depending upon the information to be flowed. Transporters are the MQe components that exploit connections to provide queue level communication. Again, these are not visible to the application programmer or administrator.
When assured messaging is demanded, MQe delivers messages to the application once, and once-only. It achieves this by ensuring that a message has been successfully passed from one queue manager to another, and acknowledged, before deleting the copy at the transmitting end. In the event of a communications failure, if an acknowledgment has not been received, a message can be retransmitted, as once-only delivery does not imply once-only transmission. However, duplicates are not delivered.