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.
Some of the key features of connections are:
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.
(a) Shows a standalone queue manager being used to support one or more
applications that use queues to exchange data.
(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.
(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.
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:
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.
| 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.