MQe connection definitions

Explains how logical connections between queue managers are established

MQe supports a method of establishing logical connections between queue managers, in order to send or receive data.

MQe clients and servers communicate over connections called client/server channels.

Client/server channels have the following attributes:
  • They are dynamic, that is created on demand. This differentiates them from MQ connections which have to be explicitly created.
  • You can only establish the connection from the client-side.
  • A client can connect to many servers, with each connection using a separate channel.
  • The server-side queue manager can accept many connections simultaneously, from a multitude of different clients, using a listener for each protocol.
  • They work through a Firewall, if the server-side of the connection is behind the Firewall. However, this depends on the configuration of the Firewall.
  • They are unidirectional and support the full range of functions provided by MQe, including both synchronous and asynchronous messaging.
    Note: Unidirectional means that the client can send data to, or request data from the server, but the server-side cannot initiate requests of the client.

Standard connections, used for the client/server connection style, are unidirectional, but depend on a listener at the server, as servers cannot initiate data transfer. The client initiates the connection request and the server responds. A server can usually handle multiple incoming requests from clients. Over a standard connection, the client has access to resources on the server. If an application on the server needs synchronous access to resources on the client, a second connection is required where the roles are reversed. However, because standard connections are themselves bidirectional, messages destined for a client from its server's transmission queue, are delivered to it over the standard (client/server) connection that it initiated.

A client can be a client to multiple servers simultaneously. The client/server connection style is generally suited for use through Firewalls, because the target of the incoming connection is normally identified as being acceptable to the Firewall.

Note: Supposing there are two server queue managers, SQM1 and SQM2. SQM2 has listener address host 2: 8082. Also, suppose that SQM1 has a connection to SQM2 and a listener addresss, host 1:8081. If you create a connection definition on a client queue manager, named SQM2 with address host 1: 8081, this transports commands for SQM2 to SQM1, which then transports them to SQM2. Avoid this construct, as it is inefficient.

Because of the way channel security works, when a specific attribute rule is specified for a target queue, it forces the local queue manager to create an instance of the same attribute rule, examples.rules.AttributeRule and com.ibm.mqe.MQeAttributeRule are treated as the same rule. If this is not a desirable behaviour, you can specify a null rule for the target queue. In this case, com.ibm.mqe.MQeAttributeDefaultRule takes effect.

Connections can have various attributes or characteristics, such as authentication, cryptography, compression, or the transmission protocol to use. Different connections can use different characteristics. Each connection can have its own value set for each of the following attributes:

Authenticator
This attribute causes authentication to be performed. This is a security function that challenges the putting application environment or user to prove their identity. It has a value of either NULL or an authenticator that can perform user or connection authentication.
Cryptor
This attribute causes encryption and decryption to be performed on messages passing through the channel. This is a security function that encodes the messages during transit so that you cannot read them without the decoding information. Either null or a cryptor that can perform encryption and decryption.

The simplest type of cryptor is MQeXorCryptor, which encrypts the data being sent by performing an exclusive-OR of the data. This encryption is not secure, but it modifies the data so that it cannot be viewed. In contrast, MQe3DESCryptor implements triple DES, a symmetric-key encryption method.

Channel
The class providing the transport services.
Compressor
This attribute causes compression and decompression to be performed on messages passing through the channel. This attempts to reduce the size of messages while they are being transmitted and stored. Either null or a compressor that can perform data compression and decompression. The simplest type of compressor is the MQeRleCompressor, which compresses the data by replacing repeated characters with a count.
Destination
The server and port number for the connection. The target for this connection, for example SERVER.XYZ.COM

Typically, authentication only occurs when setting up the connection. All flows normally use compressors and cryptors.

Figure 1. MQe connection
Diagram showing an MQe connection with Cryptor, compressor, and authenticator parameters being transmitted through a communications protocol.
You can establish MQe connections using a variety of protocols allowing them to connect in a number of different ways, for example:
  • Permanent connection, for example a LAN, or leased line
  • Dial out connection, for example using a standard modem to connect to an Internet service provider (ISP)
  • Dial out and answer connection, using a CellPhone, or ScreenPhone for example

MQe implements the communications protocols as a set of adapters, with one adapter for each of the supported protocols. This enables you to add new protocols.


Terms of use | WebSphere software

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