Implementing a queue manager alias and cluster with WebSphere MQ

This article shows you how to set up queue manager aliases in WebSphere MQ V6 and V7, and describes their significance for clustered environments and load balancing. It then covers two load balancing scenarios -- a queue manager outside a cluster communicating with queue managers inside it, and a queue manager inside a cluster communicating with queue managers outside it.

Gautam K. Bhat (gautambh@in.ibm.com), Senior Certified IT Specialist, IBM

Photo of Gautam K. BhatGautam K. Bhat is an IBM Senior Certified IT Specialist, Chief Architect for Americas clients, and Global Subject Matter Expert for Messaging, Integration, and Middleware. He is involved in training and coaching at the Middleware Center of Excellence (CoE) for IBM Global Technology Services for strategic outsourcing in India. His professional certifications include Sun Certified Business Component Developer, Sun Certified Java Programmer, Sun Certified Web Component Developer, Service Oriented Architecture Associate, WebSphere Message Broker Administrator, and WebSphere MQ Administrator. You can contact Gautam at gautambh@in.ibm.com.



Arundeep B. Veerabhadriah (arundeepbv@in.ibm.com), Certified IT Specialist, IBM

Photo of Arundeep B. VeerabhadriahArundeep B. Veerabhadraiah is a Certified IT Specialist focusing on WebSphere Message Broker and WebSphere MQ. He has an M.S. Degree in Computer Science from the University of Illinois, and has seven years of experience in Enterprise Application Integration.



09 January 2013

Also available in Chinese

Introduction

Suppose a client has critical applications using IBM® WebSphere® MQ as a messaging system, and needs to upgrade the existing distributed queuing environment to handle new business and ensure high availability. As a part of the upgrade, some of the queue managers in the existing environment will be made part of a cluster, and some will remain standalone. This article describes a Proof-of-Concept design proposed by IBM.

Queue manager alias definitions

Queue manager alias definitions have three uses:

  • When sending messages, remapping the queue manager name
  • When sending messages, altering or specifying the transmission queue
  • When receiving messages, determining whether the local queue manager is the intended destination for those messages

Outbound messages: Remapping the queue manager name

Queue manager alias definitions can be used to remap the queue manager name specified in an MQOPEN call. For example, an MQOPEN call specifies a queue name of APPQ and a queue manager name of EARTH. The destination queue manager has a queue manager alias definition like this:

DEFINE QREMOTE (EARTH) RQMNAME(MARS)

This definition specifies that the queue manager to be used when an application puts messages to queue manager EARTH is MARS. If the local queue manager is EARTH, it puts the messages to the local queue APPQ. If the local queue manager is not called EARTH, then it routes the message to a transmission queue called MARS, by changing the transmission header to say MARS instead of EARTH.

Inbound messages: Determining the destination

A receiving message channel agent (MCA) opens the queue referenced in the transmission header. If a queue manager alias definition exists with the same name as the queue manager referenced, then the queue manager name received in the transmission header is replaced with the RQMNAME from that definition. This mechanism has two uses:

  • Direct messages to another queue manager
  • Alter the queue manager name to be the same as the local queue manager

Outbound messages: Altering or specifying the transmission queue

Figure 1 shows a scenario in which messages arrive at queue manager QM1 with transmission headers showing queue names at queue manager QM3. QM3 is reachable by multi-hopping through QM2:

Figure 1
Figure 1

All messages for QM3 are captured at QM1 with a queue manager alias named QM3 and containing the definition QM3 via transmission queue QM2. The definition looks like this:

DEFINE QREMOTE (QM3) RNAME(' ') RQMNAME(QM3) XMITQ(QM2)

The queue manager puts the messages on transmission queue QM2, but does not change the transmission queue header, because the name of the destination queue manager, QM3, does not change.

All messages arriving at QM1 and showing a transmission header containing a queue name at QM2 are also put on the QM2 transmission queue. In this way, messages with different destinations are collected onto a common transmission queue to an appropriate adjacent system, for onward transmission to their destinations.

Communicating with queue managers inside the cluster

There are four queue managers in the environment: MERCURY, VENUS, EARTH, and MARS. These queue managers are part of the cluster called PLANETS. APP.LOCAL queue is an application queue defined on all four queue managers. The application called APP1 is connecting to a queue manager JUPITER. The application is putting messages on the remote queue called APP1.REMOTE. The destination queue is the cluster queue APP.LOCAL, hosted on the four queue managers in the cluster. The messages will be load balanced across the queue managers. The queue manager MARS acts as a gateway queue manager. The configuration is shown in Figure 2:

Figure 2
Figure 2

Configuring the queue manager alias

  1. Create a gateway queue manager named MARS using the following command:
    crtmqm MARS
  2. Add MARS to the cluster PLANETS (partial repos) by creating the cluster sender and cluster receiver channels to the EARTH queue manager:
    DEFINE CHANNEL(TO.MARS) CHLTYPE(CLUSRCVR) CONNAME(’10.7.0.100(1415)’) +  
         CLUSTER(PLANETS)
    DEFINE CHANNEL(TO.EARTH) CHLTYPE(CLUSSDR) + CONNAME(’10.7.0.112(2222)’)  
         CLUSTER(PLANETS)
  3. Create bidirectional connectivity between the application queue manager JUPITER and the MARS queue managers.
  4. Define a remote queue APP1.REMOTE on the JUPITER queue manager with an RQMNAME of MARS:
    DEFINE QR(APP1.REMOTE) RNAME(APP.LOCAL) RQMNAME(PLANETSGW) XMITQ(MARS)
  5. Define a cluster local queue – APP.LOCAL on the MERCURY, VENUS, and EARTH queue managers.
  6. Define a queue manager alias on the cluster gateway queue manager MARS:
    DEFINE QR(PLANETSGW) RNAME(‘ ‘) RQMNAME(‘ ‘)

You have now set up load balancing between the four queue managers using the queue manager alias.

Communicating with queue managers outside the cluster

There are a total of seven queue managers: MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, and URANUS. These queue managers are not part of any clusters.

The proposed design requires the four queue managers MERCURY, VENUS, EARTH, and MARS to be a part of the cluster called PLANET, with the JUPITER queue manager acting as a gateway queue manager. The other queue managers will be standalone.

Three applications -- App1, App2, and App3 -- will connect to the cluster queue managers MERCURY, VENUS, and EARTH respectively. These applications put messages on a remote queue defined on their queue managers, which in turn point to the application queues hosted on the queue managers running outside the clusters. The following table and diagram summarize which applications are putting the messages and the final destination of the messages:

Application NameLocal queue managerRemote queueDestination queue managerDestination queue name
APP1MERCURYAPP1.QR1JUPITERAPPA.QL1
APP2VENUSAPP2.QR1SATURNAPPB.QL1
APP3EARTHAPP3.QR1URANUSAPPC.QL1
Figure 3
Figure 3

The messages are routed to the destination queue managers through the gateway queue manager MARS. The concept of a queue manager alias is used to route the messages to the destination queue manager. Table 2 below shows the required queue manager alias on the application queue managers and the gateway queue manager MARS. It shows which application is pointing to which queue, and the final destination of the messages put by the applications:

App nameQueue manager nameApplication queue definitionQueue manager alias definition on MARS
APP1MERCURYDefine QR(APP1.QR1) RNAME(APPA.QL1) rqmname (CLUSS00) cluster(PLANETS) REPLACEDEFINE QR(CLUSS00) RQMNAME(JUPITER) RNAME(' ') XMITQ(JUPITER)
APP2VENUSVENUS Define QR(APP2.QR1) RNAME(APPB.QL1) rqmname (CLUSS01) cluster(PLANETS) REPLACEDEFINE QR(CLUSS01) RQMNAME(SATURN) RNAME(' ') XMITQ(SATURN)
APP3EARTHDefine QR(APP3.QR1) RNAME(APPC.QL1) rqmname (CLUSS02) cluster(PLANETS) REPLACEDEFINE QR(CLUSS02) RQMNAME(URANUS) RNAME(' ') XMITQ(URANUS)

Setting up the infrastructure

  1. Create the seven queue managers using the seven commands below. Also create the required listeners:
    CRTMQM MERCURY
    CRTMQM VENUS
    CRTMQM EARTH
    CRTMQM MARS
    CRTMQM JUPITER
    CRTMQM SATURN
    CRTMQM URANUS
  2. Add MERCURY and VENUS as full repositories for the cluster PLANETS, and define the required cluster sender channels and cluster receiver channels:
    DEFINE CHANNEL (TO.MERCURY) CHLTYPE (CLUSSDR) CONNAME ('10.7.0.100(1414)')   
         CLUSTER (PLANETS) REPLACE
    DEFINE CHANNEL (TO.MERCURY) CHLTYPE (CLUSRCVR) CONNAME ('10.7.0.100(1414)') 
         CLUSTER (PLANETS) REPLACE
    DEFINE CHANNEL (TO.VENUS) CHLTYPE (CLUSRCVR) CONNAME ('10.7.0.100(1415)') 
         CLUSTER (PLANETS) REPLACE
    DEFINE CHANNEL (TO.VENUS) CHLTYPE (CLUSSDR) CONNAME ('10.7.0.100(1415)')   
         CLUSTER (PLANETS) REPLACE
  3. Make the queue managers EARTH and MARS part of the queue manager cluster PLANETS by making the partial repositories:
    DEFINE CHANNEL (TO.EARTH) CHLTYPE (CLUSSDR) CONNAME ('10.7.0.100(1414)')   
         CLUSTER (PLANETS) REPLACE
    DEFINE CHANNEL (TO.EARTH) CHLTYPE (CLUSRCVR) CONNAME ('10.7.0.100(1416)') 
         CLUSTER (PLANETS) REPLACE
    DEFINE CHANNEL (TO.MARS) CHLTYPE (CLUSRCVR) CONNAME ('10.7.0.100(1417)') 
         CLUSTER (PLANETS) REPLACE
    DEFINE CHANNEL (TO.VENUS) CHLTYPE (CLUSSDR) CONNAME ('10.7.0.100(1415)')   
         CLUSTER (PLANETS) REPLACE
  4. Define remote queues on MERCURY, VENUS, and EARTH with the rqmname as defined in the table above.
  5. Define local queues on JUPITER, SATURN, and URANUS as defined in Table 2 above.
  6. Define a queue manager alias on the cluster gateway queue manager:
    DEFINE QR(CLUSS00) RQMNAME(JUPITER) RNAME(' ') XMITQ(JUPITER)
    DEFINE QR(CLUSS01) RQMNAME(SATURN) RNAME(' ') XMITQ(SATURN)
    DEFINE QR(CLUSS02) RQMNAME(URANUS) RNAME(' ') XMITQ(URANUS)

Conclusion

This article showed you how to use a queue manager alias for load balancing by implementing communications with queue managers both inside and outside a cluster. In this configuration, messages are distributed in "round-robin" fashion.

Acknowledgement

The authors would like to thank James A. Grant Jr., IBM Advisory IT Architect, WebSphere MQ, for his valuable input during the creation of this article.

Resources

  • WebSphere MQ resources
  • WebSphere resources
    • developerWorks WebSphere developer resources
      Technical information and resources for developers who use WebSphere products. developerWorks WebSphere provides product downloads, how-to information, support resources, and a free technical library of more than 2000 technical articles, tutorials, best practices, IBM Redbooks, and online product manuals. Whether you're a beginner, an expert, or somewhere in between, you'll find what you need to build enterprise-scale solutions using the open-standards-based WebSphere software platform.
    • developerWorks WebSphere application integration developer resources
      How-to articles, downloads, tutorials, education, product info, and other resources to help you build WebSphere application integration and business integration solutions.
    • Most popular WebSphere trial downloads
      No-charge trial downloads for key WebSphere products.
    • WebSphere forums
      Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
    • WebSphere on-demand demos
      Download and watch these self-running demos, and learn how WebSphere products and technologies can help your company respond to the rapidly changing and increasingly complex business environment.
    • WebSphere-related articles on developerWorks
      Over 3000 edited and categorized articles on WebSphere and related technologies by top practitioners and consultants inside and outside IBM. Search for what you need.
    • developerWorks WebSphere weekly newsletter
      The developerWorks newsletter gives you the latest articles and information only on those topics that interest you. In addition to WebSphere, you can select from Java, Linux, Open source, Rational, SOA, Web services, and other topics. Subscribe now and design your custom mailing.
    • WebSphere-related books from IBM Press
      Convenient online ordering through Barnes & Noble.
    • WebSphere-related events
      Conferences, trade shows, Webcasts, and other events around the world of interest to WebSphere developers.
  • developerWorks resources
    • Trial downloads for IBM software products
      No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
    • developerWorks business process management developer resources
      BPM how-to articles, downloads, tutorials, education, product info, and other resources to help you model, assemble, deploy, and manage business processes.
    • developerWorks blogs
      Join a conversation with developerWorks users and authors, and IBM editors and developers.
    • developerWorks tech briefings
      Free technical sessions by IBM experts to accelerate your learning curve and help you succeed in your most challenging software projects. Sessions range from one-hour virtual briefings to half-day and full-day live sessions in cities worldwide.
    • developerWorks podcasts
      Listen to interesting and offbeat interviews and discussions with software innovators.
    • developerWorks on Twitter
      Check out recent Twitter messages and URLs.
    • IBM Education Assistant
      A collection of multimedia educational modules that will help you better understand IBM software products and use them more effectively to meet your business requirements.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=852035
ArticleTitle=Implementing a queue manager alias and cluster with WebSphere MQ
publish-date=01092013