IBM MQ


IBM MQ is a family of message-oriented middleware products that IBM launched in December 1993. It was originally called MQSeries, and was renamed WebSphere MQ in 2002 to join the suite of WebSphere products. In April 2014, it was renamed IBM MQ. The products that are included in the MQ family are IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ for z/OS, and IBM MQ on IBM Cloud. IBM MQ also has containerised deployment options.
MQ allows independent and potentially non-concurrent applications on a distributed system to securely communicate with each other, using messages. MQ is available on a large number of platforms, including z/OS, IBM i, Transaction Processing Facility, UNIX, HP NonStop, OpenVMS, Linux, and Microsoft Windows.

MQ components

The core components of MQ are:
  • Message: Messages are collections of binary or character data that have some meaning to a participating program. As in other communication protocols, storage, routing, and delivery information is added to the message before transmission and stripped from the message prior to delivery to the receiving application.
  • Queue: Message queues are objects that store messages in an application.
  • Queue Manager: a system service that provides a logical container for the message queue. It is responsible for transferring data to other queue managers via message channels. Although not strictly required for message-oriented middleware, is an IBM MQ prerequisite. Queue managers handle storage, timing issues, triggering, and all other functions not directly related to the actual movement of data.
Programs integrated with IBM MQ use a consistent application program interface across all platforms.

Messaging types

MQ supports point-to-point and publish–subscribe messaging.

APIs

APIs directly supported by IBM include:
Additional APIs are also available via third parties, including:
One-time delivery: MQ uses once and once only delivery. This quality of service typically prevents message loss or duplication.
Asynchronous messaging: MQ provides application designers with a mechanism to achieve non-time-dependent architecture. Messages can be sent from one application to another, regardless of whether the applications are running at the same time. If a message receiver application is not running when a sender sends it a message, the queue manager will hold the message until the receiver asks for it. Ordering of all messages is preserved, by default this is in FIFO order of receipt at the local queue within priority of the message.
Data transformation: e.g. Big Endian to Little Endian, or EBCDIC to ASCII. This is accomplished through the use of message data exits. Exits are compiled applications that run on the queue manager host, and are executed by the IBM MQ software at the time data transformation is needed.
Message-driven architecture framework: IBM MQ allows receipt of messages to "trigger" other applications to run.
Range of APIs: It implements the Java Message Service standard API, and also has its own proprietary API, known as the Message Queuing Interface, which preceded the JMS several years in existence. As of version 8.0.0.4, MQ also supports the MQ Light API.
Clustering: Multiple MQ implementations share the processing of messages, providing load balancing.

Communication

Queue managers communicate with the outside world either through:
  • Bindings: a direct software connection. Generally faster, but limited to programs running on the same physical host as the queue manager.
  • A network or "client" connection: applications using a client connection can connect to a queue manager on any other host in the network. The physical location of the queue manager is irrelevant, as long as it is reachable over the network.

    Communication between queue managers

This relies on a channel. Each queue manager uses one or more channels to send and receive data to other queue managers. A channel is uni-directional; a second channel is required to return data. In a TCP/IP based network, a channel sends or receives data on a specific port.
Channel types:
  • Sending channel: has a defined destination and is associated with a specific transmission queue.
  • Receiving channel: receives data from any other queue manager with a sending channel of the same name.
When a receiving channel receives a message, it is examined to see which queue manager and queue it is destined for. In the event of a communications failure, MQ can automatically re-establish a connection when the problem is resolved.
The listener is the application's network interface to the queue manager. The listener detects connections from incoming channels, and manages the connection of the sending channels to the receiving channels. In a TCP/IP network, the listener will "listen" for connections on a specific port.

Transmitting data to a queue on another queue manager

Queue types:
  • Local queue: represents the location where data is stored awaiting processing.
  • Remote queue: represents a queue on another queue manager. They define the destination queue, which is one element of the routing mechanism for messages.
  • Cluster queue: represents a queue which is reachable via any queue manager in its cluster.
A message is placed on a remote queue. The messages goes to a temporary storage transmission queue associated with a channel. On placing a message on a remote queue, the message is transmitted across the remote channel. If the transmission is successful, the message is removed from the transmit queue. On receiving a message, the receiving queue manager examines the message to determine whether the message is for itself or if must go to another queue manager. If the receiving queue manager, the required queue will be checked, and if it exists, the message is placed on this queue. If not, the message is placed on the dead letter queue. MQ has features to manage efficient transmission of data across a variety of communication media. For example, messages can be batched together until a queue reaches a particular depth.

Ordering

Although the queue is FIFO, it is ordered based on the receipt in the local queue, not the committing of the message from the sender. Messages can be prioritized, and by default, the queue is prioritized in order of arrival. Queues will only be in sequence of addition if the message is added locally. Message grouping can be used to ensure a set of messages are in a specific order, aside from that, if sequence is critical, it is the application's responsibility to place sequence data in the message or implement a handshaking mechanism via a return queue. In reality, ordering will be maintained in straightforward configurations.

The log

The other element of a queue manager is the log. As a message is placed on a queue or a configuration change is made, the data is also logged. In the event of a failure, the log is used to recreate damaged objects and recreate messages. Only persistent messages are recreated when a failure occurs—"non-persistent" messages are lost. Non-persistent messages can be sent across a channel set to a fast mode, in which delivery is not assured in the event of a channel failure.
MQ supports both circular and linear logging.

Retrieving messages from queues

Information can be retrieved from queues either by polling the queue to check for available data at suitable intervals, or alternatively MQ can trigger an event, allowing a client application to respond to the delivery of a message.

Availability

IBM MQ offers a variety of solutions to cater for availability:
Replicated Data Queue Manager :
Synchronous replication between three servers that all share a floating IP address.
Queue Manager Clusters:
Groups of two or more queue managers on one or more computers are defined to a cluster, providing automatic interconnection, and allow queues to be shared among them for load balancing and redundancy.
Queue Sharing Groups :
In a Shared Queue environment, an application can connect to any of the queue managers within the queue-sharing group. Because all the queue managers in the queue-sharing group can access the same set of shared queues, the application does not depend on the availability of a particular queue manager. This gives greater availability if a queue manager stops because all the other queue managers in the queue-sharing group can continue processing the queue.
Multi-Instance Queue Managers :
Instances of the same queue manager are configured on two or more computers with their queues and meta data residing on shared storage. By starting multiple instances, one instance becomes the active instance and the other instances become standbys. If the active instance fails, a standby instance running on a different computer automatically takes over.

History

Version release dates

Version nameRelease date
IBM MQ 9.4 LTS18 June 2024
IBM MQ 9.3 LTS23 June 2022
IBM MQ 9.2 LTS23 July 2020
IBM MQ 9.1 LTS23 July 2018
IBM MQ on IBM Cloud13 March 2018
IBM MQ for HPE Nonstop 8.023 June 2017
IBM MQ 9.0 LTS2 June 2016
IBM MQ 8.023 May 2014
WebSphere MQ 7.515 June 2012
WebSphere MQ 7.1November 2011
WebSphere MQ 7.0 z/OSJune 2008
WebSphere MQ 7.0 May 2008
WebSphere MQ 6.0 z/OSJune 2005
WebSphere MQ 6.0 May 2005
WebSphere MQ 5.3 z/OSJune 2002
WebSphere MQ 5.3 June, July, Oct, Nov 2002
MQSeries 5.2 Dec 2000
MQSeries for OS/390 V5.2Nov 2000
MQSeries for AS/400 V5.1July-Aug 2000
MQSeries for OS/390 V2.1Feb 1999
MQSeries 5.1April, June 1999
MQSeries for AS/400 V4.2Feb 1998
MQSeries 5.0October 1997
MQSeries for MVS/ESA 1.229 August 1997
MQSeries for MVS 1.1.4,June 1996
MQSeries 2.2 June, July 1996
MQSeries 2.0 Windows NT2Q 1996
MQSeries 2.2 4Q 1995
MQSeries for MVS 1.1.3May 1995
MQSeries 2.0 Feb 1995
MQM/400 V34Q 1994
ezBridge Transact for MQSeries 3.0July 1994
MQSeries for MVS 1.1.2June 1994
MQM/400 V2.3Feb/April 1994
ezBridge Transact for MQSeriesMarch, Sept, Nov, Dec 1993
MQSeries for MVS V1.1.1December 31, 1993