IBM MQ SERIES

IBM MQ Series

IBM MQ Series

Introduction

MQSeries is an IBM software family whose components are used to tie together other software applications so that they can work together. This type of application is often known as business integration software or middleware.

MQSeries consists of three products

MQSeries Messaging, which provides the communication mechanism between applications on different platforms

MQSeries Integrator, which centralizes and applies business operations rules

MQSeries Workflow, which enables the capture, visualization, and automation of business processes

The point of business integration is to connect different computer systems, diverse geographical locations, and dissimilar IT infrastructures so that a seamless operation can be run. IBM's MQSeries supplies communications between applications, or between users and a set of applications on dissimilar systems (Henkenius 2003 28). It has grown in popularity as applications are made available over the Internet because of its support of over 35 platforms and its ability to integrate disparate automation systems.

An additional helpful feature is that its messaging scheme requires the application that receives the the message to confirm receipt. If no confirmation materializes, the message is re-sent by the MQSeries. IBM asserts that MQSeries can connect any two commercial systems that are in current business use.

Discussion

It's commonplace for a business application to be designed as a group of related programs, each of which handles a single, well-defined component of the whole. Often, the programs that make up a business application run in a | single environment (such as the OS/2 environment) on single or multiple processors. And sometimes they run in multiple, unlike environments. Many businesses go a step further and distribute programs around the data-processing network, rather than run them all on one processor. For | example, a single application could be distributed between an AIX/6000 | environment on a RISC System/6000 processor and an OS/400 environment | on an AS/400 processor. There are many advantages in this approach, (Dana and Hancock 2007 21) most of which are related to making better use of resources: 5 It's often a good idea to put a program near the data it's processing, so that network traffic is kept to a minimum. (“My database is in Washington, so if I put my customer accounts program in Miami, my network is going to be kept busy just moving data between the two.”) 5 Load balancing—rescheduling and relocating the workload to complete it | as efficiently as possible—is another reason for distributing an application. (“My London branch is running at capacity, but I've got an underused machine in Rome. Why can't I just move some of the work to Rome?”) 5 Sometimes “rightsizing”—moving an application from one large machine to several smaller machines—is the trigger. (“We've installed a midrange processor in each of our branches, so we need to share the workload among them.” 

 Of course, when you distribute a single application, whether to unlike environments on a single processor or to different nodes of a network, you must have a way of getting the parts of the application to communicate with each other. This can be challenging enough when the components of the network are from a single vendor, when there are no variations in the operating systems you're using, when programs are ...