Intercommunication

Distributed queuing components

This section describes the components of distributed queuing. These are:

Message channels
Message channel agents
Transmission queues
Channel initiators and listeners
Channel-exit programs

Message channels

Message channels are the channels that carry messages from one queue manager to another.

Do not confuse message channels with MQI channels. There are two types of MQI channel, server-connection and client-connection. These are discussed in the WebSphere MQ Clients book.

The definition of each end of a message channel can be one of the following types:

Sender
Receiver
Server
Requester
Cluster sender
Cluster receiver

A message channel is defined using one of these types defined at one end, and a compatible type at the other end. Possible combinations are:

Sender-receiver
Requester-server
Requester-sender (callback)
Server-receiver
Cluster sender-cluster receiver

A sender in one system starts the channel so that it can send messages to the other system. The sender requests the receiver at the other end of the channel to start. The sender sends messages from its transmission queue to the receiver. The receiver puts the messages on the destination queue. Figure 5 illustrates this.

Figure 5. A sender-receiver channel

Messages are sent from the transmission queue at the sender end, to destination queues at the receiver end.

Requester-server channel

A requester in one system starts the channel so that it can receive messages from the other system. The requester requests the server at the other end of the channel to start. The server sends messages to the requester from the transmission queue defined in its channel definition.

A server channel can also initiate the communication and send messages to a requester, but this applies only to fully qualified servers, that is server channels that have the connection name of the partner specified in the channel definition. A fully qualified server can either be started by a requester, or can initiate a communication with a requester.

Figure 6. A requester-server channel

Messages are sent from the transmission queue at the server end to the destination queues defined in the channel definition at the requester end, The channel is usually initiated by the requester, which requests the server end to start. However,a fully-qualified server, defined in the text before the figure, can itself initiate the channel.

Requester-sender channel

The requester starts the channel and the sender terminates the call. The sender then restarts the communication according to information in its channel definition (this is known as callback). It sends messages from the transmission queue to the requester.

Figure 7. A requester-sender channel

The requester starts the channel. The sender ends the call, and restarts the communication according to information in its channel definition. Messages are sent from the sender's transmission queue to and put on the destination queues at the requester end.

Server-receiver channel

This is similar to sender-receiver but applies only to fully qualified servers, that is server channels that have the connection name of the partner specified in the channel definition. Channel startup must be initiated at the server end of the link. The illustration of this is similar to the illustration in Figure 5.

Cluster-sender channels

In a cluster, each queue manager has a cluster-sender channel on which it can send cluster information to one of the full repository queue managers. Queue managers can also send messages to other queue managers on cluster-sender channels.

Figure 8. A cluster-sender channel

A cluster-sender channel is defined from one queue manager to another within the cluster. Messages can be sent from the cluster transmission queue at the sender end to destination queues at the cluster-receiver end.

Cluster-receiver channels

In a cluster, each queue manager has a cluster-receiver channel on which it can receive messages and information about the cluster. The illustration of this is similar to the illustration in Figure 8.

Message channel agents

A message channel agent (MCA) is a program that controls the sending and receiving of messages. There is one message channel agent at each end of a channel. One MCA takes messages from the transmission queue and puts them on the communication link. The other MCA receives messages and delivers them onto a queue on the remote queue manager.

A message channel agent is called a caller MCA if it initiated the communication, otherwise it is called a responder MCA. A caller MCA may be associated with a sender, cluster-sender, server (fully qualified), or requester channel. A responder MCA may be associated with any type of message channel, except a cluster sender.

Transmission queues

A transmission queue is a special type of local queue used to store messages before they are transmitted by the MCA to the remote queue manager. In a distributed-queuing environment, you need to define one transmission queue for each sending MCA, unless you are using WebSphere MQ Queue Manager clusters.

You specify the name of the transmission queue in a remote queue definition, (see Remote queue definitions). If you do not specify the name, the queue manager looks for a transmission queue with the same name as the remote queue manager.

You can specify the name of a default transmission queue for the queue manager. This is used if you do not specify the name of the transmission queue, and a transmission queue with the same name as the remote queue manager does not exist.

Channel initiators and listeners

A channel initiator acts as a trigger monitor for sender channels, because a transmission queue may be defined as a triggered queue. When a message arrives on a transmission queue that satisfies the triggering criteria for that queue, a message is sent to the initiation queue, triggering the channel initiator to start the appropriate sender channel. You can also start server channels in this way if you specified the connection name of the partner in the channel definition. This means that channels can be started automatically, based upon messages arriving on the appropriate transmission queue.

You need a channel listener program to start receiving (responder) MCAs. Responder MCAs are started in response to a startup request from the caller MCA; the channel listener detects incoming network requests and starts the associated channel.

Figure 9 shows how channel initiators and channel listeners are used.

Figure 9. Channel initiators and listeners

The figure shows message flow using a channel initiator and a listener. A message is put on the initiation queue of queue manager 1 (QM1), which triggers the channel initiator for that queue manager. This starts the sender channel. The channel listener at queue manager 2 (QM2) receives the session request, and starts the receiving MCA. Messages can then be transmitted from QM1 to QM2.

The implementation of channel initiators is platform specific.

In z/OS native distributed queuing, there is one channel initiator for each queue manager and it runs as a separate address space. You start it using the WebSphere MQ command START CHINIT, which you would normally issue as part of your queue manager startup. It monitors the system-defined queue SYSTEM.CHANNEL.INITQ, which is the initiation queue that is recommended for all the transmission queues.
On z/OS, if you are using CICS for distributed queuing, there is no channel initiator. To implement triggering, use the CICS trigger monitor transaction, CKTI, to monitor the initiation queue.
On other platforms, you can start as many channel initiators as you like, specifying a name for the initiation queue for each one. Normally you need only one initiator. WebSphere MQ for AIX, iSeries, HP-UX, Solaris and Windows systems, and MQSeries for Compaq Tru64 UNIX, and OS/2 Warp allow you to start up to three channel initiators (the default value), but you can change this value. On platforms that support clustering, when you start a queue manager, a channel initiator also is automatically started.

The channel initiator is also required for other functions. These are discussed later in this book.

The implementation of channel listeners is platform specific.

Use the channel listener programs provided by WebSphere MQ if you are using z/OS native distributed queuing, MQSeries for Compaq (DIGITAL) Open VMS, and Compaq NonStop Kernel.
Note:
On z/OS, The TCP/IP listener can be started many times with different combinations of port number and address to listen on. For more information, see Listeners .
If you are using CICS for distributed queuing on z/OS, you do not need a channel listener because CICS provides this function.
On iSeries, use the channel listener program provided by WebSphere MQ if you are using TCP/IP. If you are using SNA, you do not need a listener program. SNA starts the channel by invoking the receiver program on the remote system.
On OS/2 and Windows systems, you can use either the channel listener program provided by WebSphere MQ, or the facilities provided by the 'operating system' (for example, Attach manager for LU 6.2 communications on OS/2). If performance is important in your environment and if the environment is stable, you can choose to run the WebSphere MQ listener as a trusted application as described in Running channels and listeners as trusted applications. See the WebSphere MQ Application Programming Guide for information about trusted applications.
On UNIX systems, use the channel listener program provided by WebSphere MQ or the facilities provided by the 'operating system' (for example, inetd for TCP/IP communications).

Channel-exit programs

If you want to do some additional processing (for example, encryption or data compression) you can write your own channel-exit programs, or sometimes use SupportPacs. The Transaction Processing SupportPacs library for WebSphere MQ is available on the Internet at URL:

WebSphere MQ calls channel-exit programs at defined places in the processing carried out by the MCA. There are six types of channel exit:

Security exit: Used for security checking, such as authentication of the partner.
Message exit: Used for operations on the message, for example, encryption prior to transmission.
Send and receive exits: Used for operations on split messages, for example, data compression and decompression.
Message-retry exit: Used when there is a problem putting the message to the destination.
Channel auto-definition exit: Used to modify the supplied default definition for an automatically defined receiver or server-connection channel.
Transport-retry exit: Used to suspend data being sent on a channel when communication is not possible.

The sequence of processing is as follows:

The security exits are called after the initial data negotiation between both ends of the channel. These must end successfully for the startup phase to complete and to allow messages to be transferred.
The message exit is called by the sending MCA, and then the send exit is called for each part of the message that is transmitted to the receiving MCA.
The receiving MCA calls the receive exit when it receives each part of the message, and then calls the message exit when the whole message has been received.

This is illustrated in Figure 10.

Figure 10. Sequence in which channel exit programs are called

The figure shows the sequence in which channel--exit programs are called. After initial data negotiation, the MCAs call the security exits. If these are successful, the startup phase can complete, and message transfer can take place. The sending MCA calls the message exit, and the send exit is called for each part of the message to be transmitted. The receiving MCA can then call the receive exit. If transmission is unsuccessful, the receiving MCA calls the message-retry exit.

The message-retry exit is used to determine how many times the receiving MCA will attempt to put a message to the destination queue before taking alternative action. It is not supported on WebSphere MQ for z/OS.

For more information about channel exits, see Chapter 45, Channel-exit programs.