Jump to content

IBM MQ: Difference between revisions

Listen to this article
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
No edit summary
Sconaomi (talk | contribs)
70 edits
No edit summary
Line 1: Line 1:
'''IBM MQ''' is a family of [[computer network|network]] [[message-oriented middleware]] products that [[IBM]] launched in December 1993. It was originally called '''MQSeries''' (for "Message Queue"), and was renamed '''WebSphere MQ''' in 2002 to join the suite of [[IBM WebSphere|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, and IBM MQ for z/OS.
'''IBM MQ''' is a family of [[computer network|network]] [[message-oriented middleware]] products that [[IBM]] launched in December 1993. It was originally called '''MQSeries''' (for "Message Queue"), and was renamed ''WebSphere MQ'' in 2002 to join the suite of [[IBM WebSphere|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.


MQ allows independent and potentially non-concurrent applications on a [[distributed computing|distributed system]] to securely communicate with each other. MQ is available on a large number of platforms (both IBM and non-IBM), including [[z/OS]] ([[Mainframe computer|mainframe]]), [[OS/400]] ([[IBM System i|IBM System i or AS/400]]), [[Transaction Processing Facility]], [[UNIX]] ([[IBM AIX|AIX]], [[HP-UX]], [[Solaris (operating system)|Solaris]]), HP [[NonStop]], [[OpenVMS]], [[Linux]], [[Unisys OS 2200 operating system|OS 2200]], and [[Microsoft Windows]].
MQ allows independent and potentially non-concurrent applications on a [[distributed computing|distributed system]] to securely communicate with each other. MQ is available on a large number of platforms (both IBM and non-IBM), including [[z/OS]] ([[Mainframe computer|mainframe]]), [[OS/400]] ([[IBM System i|IBM System i or AS/400]]), [[Transaction Processing Facility]], [[UNIX]] ([[IBM AIX|AIX]], [[HP-UX]], [[Solaris (operating system)|Solaris]]), HP [[NonStop]], [[OpenVMS]], [[Linux]], [[Unisys OS 2200 operating system|OS 2200]], and [[Microsoft Windows]].


==MQ Components==
==Message-oriented middleware==
{{Main|Message-oriented middleware}}
IBM MQ was the most popular<ref>Typically reported as ~40% market share http://www.capitalware.biz/forecast_AI_market.html</ref> system for messaging across multiple platforms in 2000, including Windows, Linux, OS/2, IBM mainframe and midrange, and Unix.


The core components of MQ are:
The core components of MQ are:
* '''Message''': Messages are collections of [[binary file|binary]] or character (for instance [[ASCII]] or [[EBCDIC]]) data that have some meaning to a participating program. As in other [[communications protocol]]s, storage, routing, and delivery information is added to the message before transmission and stripped from the message prior to delivery to the receiving application.
* '''Message''': Messages are collections of [[binary file|binary]] or character (for instance [[ASCII]] or [[EBCDIC]]) data that have some meaning to a participating program. As in other [[communications protocol]]s, 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''': 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 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 (API) across all platforms.
Programs integrated with IBM MQ use a consistent application program interface (API) across all platforms.

==Support of service-oriented architecture==
IBM MQ is a key component in IBM's [[Service-oriented architecture|service-oriented architecture (SOA)]] strategy, providing the universal messaging backbone across 80 different platforms.{{citation needed|date=March 2014}} The growing importance of SOA and the growth of [[Web Services]]{{citation needed|date=March 2014}} and other connectivity mechanisms are clearly important developments. Because of the loosely coupled nature of the message queuing model, a large number of existing MQ customers feel that they are already adopting SOA principles. The MQ Service definition support pack MA93<ref>{{cite web | url = http://www-01.ibm.com/support/docview.wss?uid=swg24017518 | title = MA93: WebSphere MQ - Service Definition
| accessdate = 2011-09-09}}</ref> allows MQ applications to be catalogued as software assets that can be reused and composed as [[Web Services]].


==APIs==
==APIs==
⚫
APIs directly supported by IBM include:
There are many ways to access IBM MQ facilities.

⚫
Some of the APIs directly supported by IBM are:
* IBM Message Queue Interface (MQI) for [[C (programming language)|C]], [[COBOL]], [[PL/I]], [[Java (programming language)|Java]], [[Rexx]],<ref>{{cite web | url = http://www-01.ibm.com/support/docview.wss?uid=swg24021549 | title = MA95: A REXX interface to WebSphere MQ | accessdate = 2014-10-09}}</ref> [[IBM RPG|RPG]], and [[C++]]
* IBM Message Queue Interface (MQI) for [[C (programming language)|C]], [[COBOL]], [[PL/I]], [[Java (programming language)|Java]], [[Rexx]],<ref>{{cite web | url = http://www-01.ibm.com/support/docview.wss?uid=swg24021549 | title = MA95: A REXX interface to WebSphere MQ | accessdate = 2014-10-09}}</ref> [[IBM RPG|RPG]], and [[C++]]
* [[Java Message Service]] (JMS)
* [[Java Message Service]] (JMS)
Line 29: Line 21:
* [[SOAP]]
* [[SOAP]]


Additional APIs (not officially supported) are also available via third parties, for example:
Additional APIs (not officially supported) are also available via third parties, including:
* [[Perl]] interface (developed and contributed by Hildo Biersma), available from [[CPAN]].<ref>[http://search.cpan.org/~hbiersma/MQSeries/MQSeries.pm MQSeries - Perl extension for MQSeries support - search.cpan.org<!-- Bot generated title -->]</ref>
* [[Perl]] interface (developed and contributed by Hildo Biersma), available from [[CPAN]].<ref>[http://search.cpan.org/~hbiersma/MQSeries/MQSeries.pm MQSeries - Perl extension for MQSeries support - search.cpan.org<!-- Bot generated title -->]</ref>
* [[Python (programming language)]] interface ''PyMQI'' (originally developed by Les Smithson), available from [[PyPI]]<ref>[http://packages.python.org/pymqi/ PyMQI Documentation]</ref>
* [[Python (programming language)]] interface ''PyMQI'' (originally developed by Les Smithson), available from [[PyPI]]<ref>[http://packages.python.org/pymqi/ PyMQI Documentation]</ref>
Line 35: Line 27:


==Features==
==Features==
'''One-time delivery''': MQ uses once and once only delivery. This quality of service typically prevents message loss or duplication.
IBM MQ provides assured one-time delivery of messages across a wide variety of platforms. The product emphasizes reliability and robustness of message traffic, and ensures that a message should never be lost if MQ is appropriately configured.

It needs to be remembered that a message in the context of MQ has no implication other than a gathering of data. MQ is very generalized and can be used as a robust substitute for many forms of intercommunication. For example, it can be used to implement reliable delivery of large files as a substitute for [[FTP]].


MQ provides [[Middleware analyst|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 (computing and electronics)|FIFO]] order of receipt at the local queue within priority of the message.
'''Asynchronous messaging''': MQ provides [[Middleware analyst|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 (computing and electronics)|FIFO]] order of receipt at the local queue within priority of the message.


It provides a means for transforming data between different architectures and protocols, such as [[Endianness#Big-endian|Big Endian]] to [[Endianness#Little-endian|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.
'''Data transformation''': e.g. [[Endianness#Big-endian|Big Endian]] to [[Endianness#Little-endian|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.


IBM MQ allows receipt of messages to "trigger" other applications to run, and thus provides the framework for a message driven architecture.
'''Message-driven architecture framework''': IBM MQ allows receipt of messages to "trigger" other applications to run.


It implements the [[Java Message Service]] (JMS) standard API, and also has its own proprietary API, known as the Message Queuing Interface (MQI), which preceded the JMS several years in existence. As of version 8.0.0.4, MQ also supports the MQ Light API.
'''Range of APIs''': It implements the [[Java Message Service]] (JMS) standard API, and also has its own proprietary API, known as the Message Queuing Interface (MQI), 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.
Unlike email, MQ itself is responsible for determining the destination of messages by the definition of queues, so processing of sent messages can be moved to a different application at a different destination. MQ provides a robust routing architecture, allowing messages to be routed via alternative paths around a network of MQ managers. MQ can be implemented as a cluster, where multiple MQ implementations share the processing of messages to allow higher performance and load balancing.'''


==Communication==
==Communication==
Queue managers communicate with the outside world either through:
The primary component of an ''IBM MQ installation'' is the Queue Manager. The queue manager handles storage, timing issues, triggering, and all other functions not directly related to actual movement of data.
*'''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===
Queue managers communicate with the outside world either via a direct software connection, referred to by IBM as a "bindings" connection, or via a network or "client" connection. The bindings connection is limited to programs running on the same physical host as the queue manager, whereas applications using a client connection can connect to a queue manager on any other host in the network.
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:
⚫
Bindings connections are generally faster, but client connections allow for a more robust, easily changeable application design. For instance, with a client connection, the physical location of the queue manager is irrelevant, as long as it is reachable over the network.
*'''Sending channel''': has a defined destination and is associated with a specific transmission queue (the mechanism by which messages are queued awaiting transmission on the channel).
*'''Receiving channel''': receives data from any other queue manager with a sending channel of the same name.


'''Communication between queue managers 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 will send or receive data on a specific port. A sending channel has a defined destination and is associated with a specific transmission queue, the mechanism by which messages are queued awaiting transmission on the channel; a receiving channel will receive 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.
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" has the function of detecting connections from incoming channels and managing the connection of the sending to the receiving channels. It is the application's network interface to the queue manager. In a TCP/IP network, the listener will "listen" for connections on a specific port.
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===
⚫
Local queues represent the location where data is stored awaiting processing.
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.


⚫
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.
⚫
Remote queues represent a queue on another queue manager. They define the destination queue, which is one element of the routing mechanism for messages.

⚫
To transmit data to a queue on another queue manager, a message is placed on a remote queue. A remote queue is sent via the temporary storage transmission queue associated with a channel. On placing a message on a remote queue, the message will be 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 will examine the message to determine whether the message is for itself or is required to forward on to another queue manager. If it is the destination, the required queue will be checked, and if it exists, the message will be placed on this queue, if not, placed on the [[dead letter queue]]. MQ has features to manage efficient transmission of data across a variety of communication media, so 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.
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, the mechanism used to create the robustness. 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 will be 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.
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===
MQ supports a wide variety of approaches to application development. 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.
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.


==High availability==
==High availability==
Line 81: Line 82:
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.
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.


'''Shared Queues (z/OS only):'''
'''Queue Sharing Queues (z/OS only):'''
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.
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.


Line 91: Line 92:
===Version release dates===
===Version release dates===


⚫
Please see the [http://www-01.ibm.com/software/support/lifecycle/ IBM Software Support Lifecycle] site for up to date information on End of Support dates
{| class="wikitable sortable"
{| class="wikitable sortable"
|-
|-
! Version name !! Release date
! Version name !! Release date
|-
| IBM MQ 9.1 || 27 July 2018<ref>{{cite web|url=https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/6/897/ENUS218-246/index.html&request_locale=en|title=IBM announcement of IBM MQ 9.1|publisher=International Business Machines (IBM)|access-date= 6 August 2018|}} </ref>
|-
| IBM MQ on IBM Cloud || 13 March 2018<ref>{{cite web|url=https://www.ibm.com/blogs/bluemix/2018/03/off-mq-ibm-cloud/|title=IBM announcement of IBM MQ on IBM Cloud|publisher=International Business Machines (IBM)|access-date= 6 August 2018|}} </ref>
|-
|-
|IBM MQ for HPE Nonstop 8.0
|IBM MQ for HPE Nonstop 8.0
Line 163: Line 167:


===Version EOS===
===Version EOS===
⚫
Please see the [http://www-01.ibm.com/software/support/lifecycle/ IBM Software Support Lifecycle] site for up to date information on End of Support dates.
|-
|-
! Version name !! General Availability !! End of Marketing !! End of Support
! Version name !! General Availability !! End of Marketing !! End of Support
Line 214: Line 219:
* [ftp://ftp.software.ibm.com/software/integration/wmq/WS_MQ_Messaging_Backbone_for_SOA.pdf Introductory Whitepaper]
* [ftp://ftp.software.ibm.com/software/integration/wmq/WS_MQ_Messaging_Backbone_for_SOA.pdf Introductory Whitepaper]
* [http://www.redbooks.ibm.com/abstracts/sg247128.html IBM Redbook: WebSphere MQ V6 Fundamentals]
* [http://www.redbooks.ibm.com/abstracts/sg247128.html IBM Redbook: WebSphere MQ V6 Fundamentals]
* [http://www.tinet.org/~sag/mq.htm MQ commands]
* [https://developer.ibm.com/messaging/ibm-mq/ MQ on Developerworks]
* [https://developer.ibm.com/messaging/ibm-mq/ MQ on Developerworks]

* [https://www.mindboxtrainings.com/IBM-Websphere-MQ-Series-Online-Training.html]


[[Category:Message-oriented middleware]]
[[Category:Message-oriented middleware]]

Revision as of 11:00, 6 August 2018

IBM MQ is a family of network message-oriented middleware products that IBM launched in December 1993. It was originally called MQSeries (for "Message Queue"), 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.

MQ allows independent and potentially non-concurrent applications on a distributed system to securely communicate with each other. MQ is available on a large number of platforms (both IBM and non-IBM), including z/OS (mainframe), OS/400 (IBM System i or AS/400), Transaction Processing Facility, UNIX (AIX, HP-UX, Solaris), HP NonStop, OpenVMS, Linux, OS 2200, and Microsoft Windows.

MQ Components

The core components of MQ are:

  • Message: Messages are collections of binary or character (for instance ASCII or EBCDIC) data that have some meaning to a participating program. As in other communications 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 (API) across all platforms.

APIs

APIs directly supported by IBM include:

Additional APIs (not officially supported) are also available via third parties, including:

Features

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 (JMS) standard API, and also has its own proprietary API, known as the Message Queuing Interface (MQI), 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 (the mechanism by which messages are queued awaiting transmission on the channel).
  • 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.

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.

High availability

There are several software-based High Availability solutions available with IBM MQ; Replicated Data Queue Managers, Queue Manager Clusters, Shared Queues, and Multi-Instance Queue Managers.

Replicated Data Queue Manager (RDQM / 'Easy HA'- MQ Advanced on distributed only): 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 Queues (z/OS only): 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 (available from v7.0.1): 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 name Release date
IBM MQ 9.1 27 July 2018[6]
IBM MQ on IBM Cloud 13 March 2018[7]
IBM MQ for HPE Nonstop 8.0 23 June 2017
IBM MQ 9.0 2 June 2016[8]
IBM MQ 8.0 23 May 2014
WebSphere MQ 7.5 15 June 2012
WebSphere MQ 7.1 November 2011
WebSphere MQ 7.0 z/OS June 2008
WebSphere MQ 7.0 (Distributed, iSeries) May 2008
WebSphere MQ 6.0 z/OS June 2005
WebSphere MQ 6.0 (Distributed, iSeries) May 2005
WebSphere MQ 5.3 z/OS June 2002
WebSphere MQ 5.3 (Distributed, iSeries) June, July, Oct, Nov 2002
MQSeries 5.2 (Distributed) Dec 2000
MQSeries for OS/390 V5.2 Nov 2000
MQSeries for AS/400 V5.1 July-Aug 2000
MQSeries for OS/390 V2.1 Feb 1999
MQSeries 5.1 April (NT), June 1999
MQSeries for AS/400 V4.2 Feb 1998
MQSeries 5.0 October 1997
MQSeries for MVS/ESA 1.2 August 1997
MQSeries for MVS 1.1.4, June 1996
MQSeries 2.2 (Sun OS/Solaris, DC/OSx) June, July 1996
MQSeries 2.0 Windows NT 2Q 1996
MQSeries 2.2 (HP, SCO) 4Q 1995
MQSeries for MVS 1.1.3 May 1995
MQSeries 2.0 (OS/2, AIX) Feb 1995 (the beginning of the end of ezBridge)
MQM/400 V3 4Q 1994
ezBridge Transact for MQSeries 3.0 July 1994
MQSeries for MVS 1.1.2 June 1996
MQM/400 V2.3 Feb/April 1994
ezBridge Transact for MQSeries March, Sept, Nov, Dec 1993 (different platforms)
MQM MVS/ESA V1.1 GA (MVS) December 31, 1993

Version EOS

Please see the IBM Software Support Lifecycle site for up to date information on End of Support dates.

Version name General Availability End of Marketing End of Support
IBM MQ 9.0 02-Jun-2016 - -
IBM MQ 8.0 13-Jun-2014 17-Apr-2020 30-Apr-2020
WebSphere MQ 7.5 06-Jul-2012 16-Dec-2016 30-Apr-2018
WebSphere MQ 7.1 25-Nov-2011 12-Jul-2016 30-Apr-2017

Background architectural reference

With the advent of computers, IBM saw an opportunity to apply new technology to the need for message switching.

In the early 1960s, IBM marketed the IBM 7740 Communication Control System and the IBM 7750 Programmed Transmission Control, which were programmable message switching systems.

The IBM System/360 was announced in April 1964 and with it came communication access methods such as BTAM and QTAM (Basic and Queued Telecommunications Access Methods). In 1971, TCAM, the Telecommunications Access Method, offered its users a more advanced form of message switching or message routing. TCAM was widely accepted, especially in the financial and brokerage industries. It supported asynchronous messaging, as with the later MQ. TCAM 3.0 added in reusable disk message queues for recovery soon thereafter, as with MQ. A high-level PL/I program could be used to access TRANSIENT datasets (dynamic message queues). Reading a message from a transient dataset resulted in that message being removed from the queue, as with a non-browse READ with MQ.

In the late 1970s, transaction management systems came into being, each trying to achieve a leadership position in the industry. Within IBM, CICS and IMS were chosen as strategic products to address the need for transaction management. Within both CICS and IMS, each had its version of message switching, IMS being a front-end queued system and CICS having its Transient Data facility as the possible basis for message switching.[citation??]

CICS established itself as a popular transaction management system in the 1968-1971 timeframe. Those users who had adopted TCAM for its message handling capabilities, now wanted a combined use of TCAM with CICS. In December 1971, IBM announced CICS support of TCAM as part of the CICS/OS-Standard product, to be delivered in December 1972. For interested customers, this enabled them to use TCAM for its message handling strengths and also have TCAM-connected terminals or computers interface with CICS online applications.[citation??]

In January 1973, TCAM continued to be supported by CICS/OS-Standard Version 2.3. However, TCAM support was omitted from the initial release of CICS/VS, announced in February 1973 and delivered in June 1974. Needless to say, many CICS-TCAM customers were not happy with that product direction.

With considerable pressure from CICS-TCAM customers, the CICS support of TCAM was reinstated in the CICS/VS 1.1 product, as of September 1974. In addition to the previous DCB support, with this reinstatement of TCAM support, CICS began to support TCAM access via VTAM, also known as the ACB support. CICS TCAM ACB support was discontinued as of the CICS/ESA Version 3 product in 1990.

In 1992, IBM announced a new product called MQSeries. This brand name was later renamed to "WebSphere MQ" (sometimes shortened to WMQ) in 2002 to support the WebSphere family name and the product. In 2014, it was renamed "IBM MQ". MQ was to be the extension of TCAM functionality from IBM-only systems to all other platforms. MQ has an architecture that enables heterogeneous systems to communicate with each other (e.g. IBM, HP, Sun, Tandem, etc.). MQ can be used with CICS systems to send and receive data to/from any other MQ-eligible system. MQ can be used to initiate work in a CICS system or a CICS transaction can initiate work in another CICS or non-CICS system.

IBM MQ now supports 80 different environments and has become the leading message assured delivery switching/routing product in the industry.[9]

MQ and web services

IBM MQ can be used as a foundation for creating service-oriented architectures. Several additional product options exist to help convert legacy programs into functioning web services through the use of MQ. Larger, heterogeneous enterprises often appear as a federation of somewhat autonomous domains based on lines of business, functional or governance areas. In such environments, some services may be shared or reused only within a single domain, while others may be shared or reused throughout the enterprise. IBM MQ provides the means by which communication exists between lines-of-business or otherwise separate business domains.

A related product in the IBM MQ product family, called IBM Integration Bus (formerly WebSphere Message Broker), enables a diverse and robust set of extensions to queue-based architectures. Using IBM Integration Bus, users can implement a WebServices front-end, complete with WSDL file support that can interact with any queue-based application.

See also

References

  1. ^ "MA95: A REXX interface to WebSphere MQ". Retrieved 2014-10-09.
  2. ^ "Introducing XMS -- The IBM Message Service API". Retrieved 2007-12-06.
  3. ^ MQSeries - Perl extension for MQSeries support - search.cpan.org
  4. ^ PyMQI Documentation
  5. ^ "MO74: WebSphere MQ - Windows Powershell Library". Retrieved 2007-12-06.
  6. ^ "IBM announcement of IBM MQ 9.1". International Business Machines (IBM). Retrieved 6 August 2018. {{cite web}}: Cite has empty unknown parameter: |1= (help)
  7. ^ "IBM announcement of IBM MQ on IBM Cloud". International Business Machines (IBM). Retrieved 6 August 2018. {{cite web}}: Cite has empty unknown parameter: |1= (help)
  8. ^ "IBM announcement of IBM MQ 9.0". International Business Machines (IBM). Retrieved 17 June 2016. {{cite web}}: Cite has empty unknown parameter: |1= (help)
  9. ^ http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS211-395 IBM MQ is the market-leading, message-oriented middleware product that delivers a reliable, proven universal messaging backbone for almost 10,000 organizations of different sizes, spanning many industries around the world.
Listen to this article
(2 parts, 22 minutes)
  2. Part 2
Spoken Wikipedia icon
These audio files were created from a revision of this article dated
Error: no date provided
, and do not reflect subsequent edits.
(Audio help · More spoken articles)
Retrieved from "https://en.wikipedia.org/w/index.php?title=IBM_MQ&oldid=853689521"