Use aliases and remote-queue definitions with clusters

 

Overview

There are three types of alias:

  1. queue-manager
  2. reply-to queue aliases
  3. queue

These apply in a clustered environment just as well as in a distributed-queuing environment. This section describes how to use aliases with clusters. When reading this section, you might need to refer to the WebSphere MQ Application Programming Guide.

 

Queue-manager aliases

The concept of queue-manager aliasing is described in detail in the WebSphere MQ Intercommunication book.

Queue-manager aliases, which are created using a remote-queue definition with a blank RNAME, have four uses:

     

  1. Remapping the queue-manager name when sending messages

    2. For example, if you define... 

    DEFINE QREMOTE(QUEUE) +
       RNAME(' ') +
       RQMNAME(QMGR)

    ...causes messages put to QUEUE to be resolved to QMGR. If QMGR does not exist locally, messages are put on the cluster transmission queue to be moved to QMGR.

    To advertise the alias to the whole cluster, add the CLUSTER attribute to the remote-queue definition.

     

  2. Altering or specifying the transmission queue when sending messages

    3. This method of aliasing can be used to join a cluster to a non-cluster system. For example, for queue managers in the cluster HOLLAND to communicate with the queue manager called HAARLEM, which is outside the cluster, one of the queue managers in the cluster must act as a gateway. From this queue manager, issue the command: 

    DEFINE QREMOTE(AMSTERDAM) +
       RNAME(' ') +
       RQMNAME(HAARLEM) +
       XMITQ(X) +
       CLUSTER(HOLLAND)

    This is a queue-manager alias definition, which defines and advertises AMSTERDAM as a queue manager over which messages from any queue manager in the cluster HOLLAND can multi-hop to reach their destination at HAARLEM. Any message put to a queue opened with the queue-manager name set to AMSTERDAM in the open handle, is sent to the gateway queue manager, where the queue manager alias definition was made. Once there, it is put on the transmission queue X and moved by conventional, non-cluster channels to the queue manager HAARLEM.

    The choice of the name AMSTERDAM in this example is not significant. The values for QREMOTE and RQMNAME could both be the same.

     

  3. Determining the destination when receiving messages

    4. When a queue manager receives a message, it looks in the transmission header to see the name of the destination queue and queue manager. If it has a queue-manager alias definition with the same name as the queue manager referenced, it substitutes the RQMNAME from its definition for the queue manager name in the transmission header.

    There are two reasons for using a queue-manager alias in this way:

    1. To direct messages to another queue manager
    2. To alter the queue manager name to be the same as the local queue manager

     

  4. Using a queue manager as a gateway into the cluster.

    5. This enables workload balancing for messages coming from outside the cluster.

    Suppose you have a queue called EDINBURGH on more than one queue manager in the cluster, and you want the clustering mechanism to balance the workload for messages coming to that queue from outside the cluster.

    A queue manager from outside the cluster needs a transmit queue and sender channel to one queue manager in the cluster, which is called a gateway queue manager. To take advantage of the default workload balancing mechanism, the gateway queue manager must not contain an instance of the EDINBURGH queue.

    For an example of this see Putting from a queue manager outside the cluster - alternative

 

Reply-to queue aliases

A reply-to queue alias definition is used to specify alternative names for reply information. Reply-to queue alias definitions can be used in conjunction with clusters just the same as in a distributed queuing environment. For example:

  • Queue manager VENICE sends a message to queue manager PISA using the MQPUT call and specifying the following in the message descriptor: 
    ReplyToQ='QUEUE'
ReplyToQMgr=''

  • So that replies sent to QUEUE can be received on OTHERQ at PISA, create a reply-to queue alias definition on VENICE: 
    DEFINE QREMOTE(QUEUE) RNAME(OTHERQ) RQMNAME(PISA)

    This form of remote-queue definition creates a reply-to alias. This alias is effective only on the system on which it was created.

RQMNAME and QREMOTE can specify the same names, even if RQMNAME is itself a cluster queue manager.

See the WebSphere MQ Intercommunication book for more information.

 

Queue aliases

A QALIAS definition is used to create an ALIAS by which a queue is to be known.

To create: 

DEFINE QALIAS(ALIAS.QUEUE.NAME) +
       TARGQ(REAL.QUEUE.NAME) +
       CLUSTER(CLUSTER.NAME)

REAL.QUEUE.NAME must be a local queue.

 

Replying to a queue manager outside the cluster

To form a return path for replies, the gateway (QMGR.B) advertises a queue-manager alias for the queue manager outside the cluster. It advertises this alias to the whole cluster by adding the cluster attribute to its queue-manager alias definition. (Remember that a queue-manager alias definition is like a remote queue definition, but with a blank RNAME.) For example: 

DEFINE QREMOTE(QMGR.A) RNAME(' ') RQMNAME(QMGR.A) CLUSTER(CLUSTER.AP)

Again, because QMGR.A is not part of a cluster, it must communicate using distributed queuing techniques. Therefore, QMGR.B must also have a sender channel and a transmission queue to QMGR.A. QMGR.A needs a corresponding receiver channel.

When the application (app2) on QMGR.C issues an MQPUT call to send a reply to INVOICE.A.QUEUE at QMGR.A, the reply is sent to the gateway, which uses its queue-manager alias to resolve the destination-queue and queue-manager name.

Note:
You may define more than one route out of a cluster.

 

Putting from a queue manager outside the cluster - alternative

There is another way of putting from a queue manager outside a cluster.

On the gateway queue manager define a queue-manager alias called, for example, ANY.CLUSTER: 

DEFINE QREMOTE(ANY.CLUSTER) RNAME(' ') RQMNAME(' ')

This maps any response to the queue manager ANY.CLUSTER to null, which means the QREMOTE definition in the queue manager outside the cluster can use the queue manager name ANY.CLUSTER instead of having to use the exact queue manager name. Therefore, on the queue manager outside the cluster, the definition: 

DEFINE QREMOTE(INVOICE.B.QUEUE) RNAME(INVOICE.B.QUEUE) RQMNAME(ANY.CLUSTER) XMITQ(QMGR.B)

would cause messages to go to QMGR.B initially, and from there to be routed to any queue manager in the cluster that hosts the cluster queue INVOICE.B.QUEUE.

 

Putting to a queue manager outside the cluster

Now let us consider how to put a message from QMGR.C, which is inside the cluster, to the queue INVOICE.A.QUEUE at QMGR.A, which is outside the cluster.

The gateway, in this example QMGR.B, has a QREMOTE definition that advertises the remote queue (INVOICE.A.QUEUE) to the cluster: 

DEFINE QREMOTE(INVOICE.A.QUEUE) RNAME(INVOICE.A.QUEUE) RQMNAME(QMGR.A) CLUSTER(CLUSTER.AP)

It also has a sender channel and a transmission queue to the queue manager that is outside the cluster. QMGR.A has a corresponding receiver channel.

To put a message, an application on QMGR.C issues an MQPUT call specifying the target queue name (INVOICE.A.QUEUE) and specifying the name of the queue to which replies are to be sent (INVOICE.B.QUEUE). The message is sent to QMGR.B, which uses its remote-queue definition to resolve the queue name to INVOICE.A.QUEUE at QMGR.A.

You may define more than one route out of a cluster.

 

Replying from a queue manager outside the cluster

So that QMGR.A can send replies to the queue managers inside the cluster, it must have a queue-manager alias for each queue manager in the cluster with which it needs to communicate. This queue-manager alias must specify the name of the gateway through which messages are to be routed, that is, the name of the transmission queue to the gateway queue manager. In this example, QMGR.A needs a queue manager alias definition for QMGR.C: 

DEFINE QREMOTE(QMGR.C) RNAME(' ') RQMNAME(QMGR.C) XMITQ(QMGR.B)

QMGR.A also needs a sender channel and transmission queue to QMGR.B and QMGR.B needs a corresponding receiver channel.

The application (app3) on QMGR.A can then send replies to QMGR.C, by issuing an MQPUT call and specifying the queue name (INVOICE.B.QUEUE) and the queue manager name (QMGR.C).

 

Putting across clusters

Instead of grouping all your queue managers together in one big cluster, you can have many smaller clusters with one or more queue managers in each acting as a bridge. The advantage of this is that you can restrict the visibility of queue and queue-manager names across the clusters. (See Overlapping clusters.) You can use aliases to change the names of queues and queue managers to avoid name conflicts or to comply with local naming conventions. 

DEFINE QLOCAL(INVOICE3.QUEUE) CLUSTER(CORNISH)

QMGR.A has defined a cluster queue INVOICE.A.QUEUE, as follows: 

DEFINE QLOCAL(INVOICE.A.QUEUE) CLUSTER(WINDSOR)

QMGR.C has created a namelist called CORNISHWINDSOR, containing the names of both clusters: 

DEFINE NAMELIST(CORNISHWINDSOR)
 DESCR('CornishWindsor namelist')
 NAMES(CORNISH, WINDSOR)

QMGR.C has also defined a cluster queue INVOICE.B.QUEUE, as follows: 

DEFINE QLOCAL(INVOICE.B.QUEUE) CLUSNL(CORNISHWINDSOR)

QMGR.C is a member of both clusters and is the bridge between them. For each queue that you want to make visible across the bridge, you need a QALIAS definition on the bridge. For example on QMGR.C, you need: 

DEFINE QALIAS(MYINVOICE.A.QUEUE) TARGQ(INVOICE.A.QUEUE) CLUSTER(CORNISH) DEFBIND(NOTFIXED)

This means that an application connected to a queue manager in CORNISH (for example QMGR.B), can put a message to a queue, which it refers to as MYINVOICE.A.QUEUE, and this message is routed to INVOICE.A.QUEUE at QMGR.A.

When you open a queue you need to set DEFBIND to either (NOTFIXED) or (QDEF) because if it is left as the default (OPEN) the queue manager will resolve the alias definition to the bridge queue manager that hosts it, and the bridge will not forward the message on.

For each queue manager that you want to make visible, you need a queue-manager alias definition. For example on QMGR.C you need: 

DEFINE QREMOTE(QMGR.B) RNAME(' ') RQMNAME(QMGR.B) CLUSTER(WINDSOR)

This means that an application connected to any queue manager in WINDSOR (for example QMGR.A), can put a message to any queue on QMGR.B, by naming QMGR.B explicitly on the MQOPEN call.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.