Blueprint
Enterprises in today’s world will typically be making use of multiple cloud platforms.
IBM MQ may have been around for a while – but hybrid cloud is all the better for its experience!
Evolving from on premise 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.
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.
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.
IBM MQ Working Example
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.
IBM MQ – 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
IBM MQ – 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
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.
If you have a problem setting this up then please contact us with a description of the problem. Or, if you just want to learn more about IBM MQ and cloud, get in touch!
*By pressing submit you agree to receiving communication from Responsiv. You may unsubscribe from communications at any time.
