Connections

A connection provides a queue manager with information to establish communication links with a remote queue manager. Queue managers then use connections to exchange information. Connection definitions are stored locally at each queue manager.
Note: The C code base is a device queue manager only.
Some of the key features of connections are:
Support for both synchronous and asynchronous messaging
Synchronous messaging provides a transmission service directly from the source application to the target queue, without queuing at the source queue manager. Asynchronous messaging is a transmission service from the source queue manager to the target queue, with possible queuing at the source queue manager.
End-to-end service provision
Connections go from the source queue manager to a destination queue manager, possibly running through intermediate queue managers. The underlying transport protocol used can change as the connection passes through these intermediates. Several connections can link together to form end-to-end connections.
Support for compression, encryption, and authentication
Connections have these security characteristics to protect the data in transit.
Support for client/server operation
Client/server connections are request/response. The client makes a request of the server and the server responds to that request. Note that this does not restrict the message flow. Messages can flow from client to server and from server to client. See Messaging for more detailed information on client/server connections.

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. A stand-alone MQe queue manager
Diagram showing a single MQe queue manager

Figure 1 shows a standalone queue manager being used to support one or more applications that use queues to exchange data.

Figure 2. Small network configuration
A diagram of six MQe queue managers joined together into a network using client/server connections

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. An integrated MQ family network
A diagram showing two MQe queue managers, each connected to a third MQe queue manager that is bridge-enabled. The bridge-enabled queue manager is connected to an MQ server which is also connected to two MQ client channels.

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.


Terms of use | WebSphere software

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