WebSphere MQ
From Wikipedia, the free encyclopedia
IBM WebSphere MQ is a network communication technology launched by IBM in March 1992. It was previously known as MQSeries, which is a trademark that was rebranded by IBM in 2002 to join the suite of WebSphere products. WebSphere MQ is IBM's Message Oriented Middleware offering. It allows independent and potentially non-concurrent applications on a distributed system to communicate with each other. MQ is available on a large number of platforms (both IBM and non-IBM), including z/OS (mainframe), UNIX (AIX, HP-UX, Solaris), HP NonStop, Linux, and Microsoft Windows.
Contents |
[edit] Message Oriented Middleware (MOM)
A member of the WebSphere family from IBM. WebSphere MQ (formerly MQSeries) is the de-facto standard[citation needed] for messaging across multiple platforms, including Windows, Linux, IBM mainframe and midrange, and Unix. WebSphere MQ is often referred to as "MQ" or "MQSeries".
There are two parts to message queueing:
- Messages are collections of binary 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.
- Message queues are objects that store messages in an application.
A Queue Manager, although not strictly required for MOM, is a Websphere MQ pre-requisite and system service that provides a logical container for the message queue and is responsible for transferring data to other queue managers via message channels.
There are several advantages to this technology:
- Messages do not depend on pure packet-based transmissions, such as TCP/IP. This allows the sending and receiving ends to be decoupled and potentially operate asynchronously.
- Sufficiently important messages will be delivered once and once only, irrespective of errors and network problems.
[edit] APIs
There are many ways to access WebSphere MQ's facilities. Some of the APIs supported by IBM are:
- IBM Message Queue Interface (MQI) for C, COBOL, PL/I, and Java
- JMS for Java
- XMS for C/C++ and .NET[1]
There are many other APIs (unsupported by IBM) of which the most notable is the Perl interface (developed and contributed by Morgan Stanley), available from CPAN [2]
[edit] Awards
In 2004 WebSphere MQ won the Royal Academy of Engineering's [3] MacRobert prize [4] for technological and engineering innovation [5].
[edit] Features
WebSphere 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 will never be lost.
MQ provides application designers 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. Of course, ordering of all messages will be preserved, generally in FIFO order. This is a feature of all queue managers, not just WebSphere MQ.
It provides a means for transforming data between different architectures and protocols, such as Big Endian to Little Endian, or EBCDIC to ASCII. This is accomplished through the use of message data "Exits". Exits are compiled applications which run on the queue manager host, and are executed by the WebSphere MQ software at the time data transformation is needed.
WebSphere MQ allows receipt of messages to "trigger" other applications to run, and thus provides the framework for a message driven architecture.
It implements the JMS standard API, and also has its own proprietary API, known as the Message Queuing Interface (MQI).
[edit] Communication
The primary component of a WebSphere 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.
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.
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.
Communication between queue managers relies on a separate program, typically referred to as a Channel. The Channel runs on the same host as the queue manager, and handles sending and receiving data over the network. In a TCP/IP based network, a channel will send or receive data on a specific port.
The Listener is a program which handles communication between applications and the queue manager over a Client connection. The Listener 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.
[edit] MQ History
TCAM (Telecommunications Access Method) came along in 1971 with the birth of TSO. It supported asynchronous messaging, just like MQ. TCAM 3.0 added in reusable disk message queues for recovery pretty soon thereafter, just like MQ. You could write a high level PL/I program accessing TRANSIENT datasets (dynamic message queues). Read a message from a transient dataset and that message is removed from the queue, just like a non-browse READ with MQ. 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 computer-like devices such as the 7740 and 7750 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 the late 1960s, still another communication access method became available and it was known as TCAM, the Telecommunications Access Method. TCAM offered its users a more advanced form of message switching or message routing. TCAM was widely accepted, especially in the financial and brokerage industries.
In the late 1960s, 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.
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.
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 family called WebSphere MQ. WebSphere MQ was to be the extension of TCAM functionality from IBM-only systems to all other platforms. WebSphere MQ had an architecture which enabled heterogeneous systems to communicate with each other (e.g. IBM, HP, Sun, Tandem, etc). WebSphere MQ can be used with CICS systems to send and receive data to/from any other MQ-eligible system. WebSphere 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.
WebSphere MQ now supports 80 different environments and has become the leading message switching/routing product in the industry.
 |
This article or section may require cleanup to meet Wikipedia's quality standards. Please help improve this article or replace this tag with a more specific message. This article has been tagged since October 2006. (help, talk) |
