responsivstrap transparent positive 300x83 1
Enterprises in today’s world will typically be making use of multiple cloud platforms.  IBM MQ can simplify connectivity.

Introduction

Evolving from private data centres to a hybrid of public and private clouds and possibly topped off with “X-as-a-service” (Software [SaaS], Platform [PaaS], Infrastructure [IaaS]) offerings. With the speed and agility that these services can be procured and provisioned at, applications are being designed to run anywhere and anticipate being separated from data or services it needs to operate.

The Responsiv Unity Integration Node leverages IBM MQ technology for providing secure and reliable messaging between instances ensuring that data is delivered once and only once to its destination efficiently and in a scalable manor. Through utilising a technique called queue manager aliasing, message produces can set routing properties that allow the messaging layer to obfuscate service availability and deployment locations.

With this boom in hybrid multi-cloud architecture, new challenges are presented around efficiently and securely transferring data throughout the enterprises connected systems. To add to this, services and applications may run in more than one location for availability or disaster recovery reasons leading to a need for dynamic message routing.

Using IBM MQ to connect clouds

To put the above into a working example, two queue managers will be created on the Responsiv Unity Integration Node in IBM MQ and will be connected together using a point-to-point connection. Queue manager aliasing will then be implemented and tested in a simple scenario. In the real world there may be many more queue managers in an environment located anywhere in the world. Also, larger MQ infrastructures typically make use of MQ clusters to provide flexible scaling and dynamic load distribution. Whilst not explicitly covered in this example, the principle remains the same – just on a larger scale.

To start things off basic queue manager configuration will be defined to enable communication between them. This involves creating the MQ TCP listener, channels and transmission queues.

Ant 1

QM1

DEFINE LISTENER(‘LISTENER.TCP’) TRPTYPE(TCP) CONTROL(QMGR) PORT(1416) REPLACE

DEFINE QLOCAL(TX) USAGE(XMITQ) REPLACE

DEFINE CHANNEL(‘QM1.QM2’) CHLTYPE(SDR) CONNAME(‘localhost(1417)’) TRPTYPE(TCP) XMITQ(‘TX’) REPLACE

DEFINE CHANNEL(‘QM2.QM1’) CHLTYPE(RCVR) TRPTYPE(TCP) REPLACE

QM2

DEFINE LISTENER(‘LISTENER.TCP’) TRPTYPE(TCP) CONTROL(QMGR) PORT(1417) REPLACE

DEFINE QLOCAL(TX) USAGE(XMITQ) REPLACE

DEFINE CHANNEL(‘QM1.QM2’) CHLTYPE(RCVR) TRPTYPE(TCP) REPLACE

DEFINE CHANNEL(‘QM2.QM1’) CHLTYPE(SDR) CONNAME(‘localhost(1416)’) TRPTYPE(TCP) XMITQ(‘TX’) REPLACE

An application to process requests and replies whilst honouring the Reply-to-queue and Reply-to-queue-manager properties of the MQMD message header. For this a simple Responsiv Unity Integration Node application has been deployed to process messages on QM2.

DEFINE QLOCAL(REQUEST) REPLACE

To verify the application is behaving as expected a local response queue is created on QM2 and is tested using a tool such as rfhutil.

DEFINE QLOCAL(RESPONSE) REPLACE

Ant 2

Finally, the request queue is shared throughout the MQ network and response queues are created. The request queue can be shared by sharing the local queue in a cluster or creating remote queue definitions on connected queue managers. For this example, a remote queue will be created on QM1 to forward requests on to QM2. A response queue will also be created on QM1 to receive dynamic responses to.

DEFINE QREMOTE(‘QM2.REQUEST’) RQMNAME(‘QM2’) RNAME(‘REQUEST’) XMITQ(‘TX’) REPLACE

DEFINE QLOCAL(RESPONSE) REPLACE

This can now be tested by writing a message to the QM2.REQUEST remote queue definition on defined in QM1 and specifying a reply-to-queue of RESPONSE and a reply-to-queue-manager of QM2. Note, specifying a reply-to-queue-manager of QM1 fails due to no queue manager aliasing being in place.

The final piece of the puzzle is to add in a queue manager alias for QM1 to QM2. This takes the form of a remote queue definition named after the target queue manager.

DEFINE QREMOTE(‘QM1’) RQMNAME(‘QM1’) XMITQ(‘TX’) REPLACE

With a final round of testing from QM1 while specifying a reply-to-queue and reply-to-queue-manager messages will be routed as expected. When issuing the reply to QM2, the queue manager alias for QM1 allows it to receive messages destined for the remote queue manager.

Expanding on the above with real world theory, this MQ network could be deployed as is and may be considered suitable for small scale deployments. Equally, this can be scaled up multiple times to many queue managers located globally. Services may be deployed anywhere in the network or in multiple locations with workload distributed through the likes of MQ clustering.

responsiv
responsiv

Responsiv connects people to data, and businesses to markets.
Simple. Effective. Distinctive.

Share This