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 codebase 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. Chapter 4, Message delivery, of the WebSphere MQ Everyplace Application Programming Guide provides detailed information on client/server connections.

The following diagrams show some typical WebSphere MQ Everyplace 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 WebSphere MQ client channels that enable communications between WebSphere MQ Everyplace and WebSphere MQ.
Diagram showing a single WebSphere MQ Everyplace queue manager

(a) Shows a standalone queue manager being used to support one or more applications that use queues to exchange data.
A diagram of six WebSphere MQ Everyplace queue managers joined together into a network using client/server connections

(b) 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. A single queue manager can initiate either client or server connections, and respond as a server. In this case, the listener and the standard listener must have different port numbers.
A diagram showing twoWebSphere MQ Everyplace queue managers, each connected to a third WebSphere MQ Everyplace queue manager that is bridge-enabled. The bridge-enabled queue manager is connected to a WebSphere MQ server which is also connected to two WebSphere MQ client channels.

(c) A WebSphere MQ Everyplace 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 WebSphere 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, WebSphere MQ Everyplace 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 a WebSphere MQ Everyplace network.

As with most WebSphere 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 WebSphere MQ Everyplace.

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 WebSphere MQ Everyplace, depending upon the information to be flowed. Transporters are the WebSphere MQ Everyplace 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, WebSphere MQ Everyplace 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.

Connection styles

WebSphere MQ Everyplace supports client/server operation. A client can initiate communication with a server. A server can respond only to the requests initiated by a client. The components involved are:

Listener
Listens for incoming connection requests.

Queue manager
Supports applications through the provision of messaging and queuing capabilities.

Table 3 shows the relationship between these components and the connection style. The client/server connection style describes the situation where WebSphere MQ Everyplace can operate in either client or server mode. The servlet option describes the case where WebSphere MQ Everyplace is configured as an HTTP servlet with the HTTP server itself responsible for listening for incoming connection requests.

Table 3. Connection styles


Queue manager Listener
Client Yes No
Client/server Yes Yes
Server Yes Yes
Servlet Yes No

WebSphere MQ Everyplace applications are not directly aware of the connection style used by the queue managers. However, the style is significant in that it affects what resources are available to the parties, which queue managers can connect with other queue managers, how much memory WebSphere MQ Everyplace uses, and which connections can concurrently exist.



© IBM Corporation 2002. All Rights Reserved