Heterogeneity is a hallmark of today's information systems in all but the smallest of enterprises. Business, non-profit, and government organizations typically run several disparate applications that were developed in-house and/or bought from a variety of vendors. Each application may use a different DBMS, run under a different operating system, and reside on different hardware. Tying these diverse systems together so that they function as a cohesive whole that efficiently serves the enterprise, its supply chain, and its customers--integrating information in near real-time when necessary, without the need to redundantly enter data at different points--can be a challenge. One way to meet this challenge is through the use of messaging as supported by IBM's WebSphere MQ.
WebSphere MQ is not new. It was launched by IBM as MQ Series more than a decade ago and was rebranded as WebSphere MQ in May 2001. The latest release, V6.0, was announced in April of this year, with general availability provided in June.
WebSphere MQ is middleware that can connect disparate applications through the exchange of messages, without regard to platform differences between the sender and receiver systems. Using the Message Queue Interface (MQI), a consistent, multi-platform API provided by WebSphere MQ, applications can share information without having a common architecture. Because messages are sent and received through the API rather than exchanged directly with other applications, programmers do not have to be aware of the design of the applications with which their programs will communicate.
In addition to MQI, WebSphere MQ also supports the industry-standard Java Message Service (JMS), including its publish-and-subscribe model for directing message flows.
WebSphere MQ supports most of the major hardware and operating systems used by businesses today.
A key feature of WebSphere MQ is its guarantee that every message will be delivered not more than once. This is clearly critical for most applications. For example, in banking systems, unwittingly repeating a message could result in the double crediting or debiting of funds to or from a customer's account.
"Not more than once" is not the same as "always once." In WebSphere MQ, messages can be either persistent or nonpersistent. Persistent messages are logged and can be recovered in the event of a WebSphere MQ failure. Thus, persistent messages are guaranteed to be delivered once and only once. Nonpersistent messages are not logged. WebSphere still guarantees to deliver them not more than once, but it does not promise to deliver them once.
Some terms are essential to understanding WebSphere MQ. First and most obvious is the concept of a message. A message is simply a string of data of almost any size, up to 100 megabytes. Each message consists of two parts, a header and the application data. The header consists of a mandatory component, the MQ Message Descriptor (MQMD), and some optional headers specific to the type of message and its use. The application data portion of the message, which is determined solely by the application, is private to the sending and receiving applications.
WebSphere MQ stores messages in queues. Because messages go into an intermediate store, application interaction doesn't happen in real-time. However, under normal circumstances, the time that messages reside in a queue is generally insignificant. Thus, the total end-to-end message transmission is close enough to real-time for most applications. In fact, many banks use it for debit transactions in their ATM networks. Typically, messages stay in queues for lengthy periods only if the network or the receiving application is unavailable.
WebSphere MQ supports a number of types of queues, the following being among the most common:
- As the name implies, a local queue resides on the local system.
- A remote queue is a queue managed by a different queue manager. (Queue managers are described below.)
- A transmission queue holds messages before they move across a network. Transmission queues are solely for WebSphere MQ's use and, as such, applications do not put messages directly into them.
- An alias queue is not a physical queue, but rather a pointer to a local queue.
The use of queues means that the sending and receiving applications can operate asynchronously. A sending application that does not require a response to a message, such as a human resources application informing a payroll application of a salary increase, can continue to operate normally even if the receiving application or the network is unavailable, confident in the knowledge that messages will be sent as soon as the receiving application comes back online.
By default, messages in a queue are processed on a FIFO basis, but this is configurable.
Message queueing services are provided by queue managers, which control the administration of objects such as queues and channels. Queue managers can also start required applications or channels when messages arrive in the queues. Queue managers can be run on a variety of operating systems, including AIX, OS/400, i5/OS, HP-UX, Solaris, Windows NT/2000/XP, and Linux on Intel-compatible systems, zSeries, and iSeries.
WebSphere MQ communicates between queue managers or between queue managers and client applications using channels. Message channels, required for communication between two queue managers, are unidirectional and, as such, are typically defined in pairs.
To simplify setup, administration, and load balancing, WebSphere MQ provides for the definition of clusters, which are named collections of queue managers connected through special channels. Each queue manager can operate standalone or belong to one or more clusters.
WebSphere MQ supports both point-to-point and publish/subscribe messaging models. Point-to-point messaging establishes a direct line between two applications through a message queue. Using this model, a message's destination application is identified by the source application or in the messaging artifacts defined locally to the source; thus, modifying the destination of the message will affect the source application.
Integrating more than one application in this fashion requires the definition of individual point-to-point connections between all participating applications. Using this model, if all applications must be connected directly to all others, the number of connections grows exponentially with the number of applications.
Point-to-point architectures can be set up in a number of ways. For example, a hub-and-spoke structure, which connects all points to a central application but not to each other, can be used to reduce the number of required connections. Using request/reply messaging, an application sends a message that includes a request for a reply and information on where the reply should be sent (the sending application can then either continue processing or wait for the reply). Using fire-and-forget messaging, the source application sends a message and does not expect a reply or a confirmation that the message has been received.
In the publish/subscribe model, applications publish data, which can be categorized into topics, to a message broker. Receiving applications send subscriptions for the data, along with the necessary delivery information, to the message broker. The message broker is then responsible for managing these subscriptions. This provides a much more flexible structure in that the sending application does not need to know anything about the recipients. Furthermore, changing the destinations of the messages will not have any effect on the sending application.
With WebSphere MQ, client applications can connect to a remote queue manager, although the definition of clients and servers in WebSphere MQ may not be entirely intuitive. The primary distinction between a client and a server in WebSphere MQ is that a client doesn't have any local queues and, therefore, can't store messages. If the network is unavailable, the client can't connect to the server queue manager, meaning that the application must try to connect again later or resolve the issue in some other way. While there may be some efficiency, storage, and platform reasons for choosing to use a client, it should not be used on a network that is frequently unavailable or for an application that needs assured delivery of messages.
WebSphere MQ can be used as a transport mechanism in a Web Services environment. The latest version provides for the flow of industry-standard Simple Object Access Protocol (SOAP) interactions between Web Services requesters and providers. In addition, because it is platform neutral, WebSphere MQ can also be used to provide connectivity between J2EE and .NET.
Using WebSphere MQ as the transport layer for SOAP messages, rather than the more common HTTP protocol, offers the benefit of guaranteeing once-and-only-once delivery of messages, something that HTTP does not offer.
Security and Administration
To ensure the security and privacy of messages, WebSphere MQ supports the use of Secure Sockets Layer (SSL) for the authentication, message integrity checking, and encryption of data sent across the Internet.
An available upgrade to WebSphere MQ, WebSphere MQ Extended Security Edition, enhances this security by enabling enterprise-wide, remote management of security policies. It can be deployed without modifying existing WebSphere MQ applications.
Configuration, monitoring, and administration of WebSphere MQ is accomplished through a console, WebSphere MQ Explorer. The console enables the administration of all WebSphere MQ environments from a single point. That point can, if necessary, be remote to the various applications that use messaging.
New in V6
With V6.0, IBM has replaced the Windows-based MQ Explorer administration console with an Eclipse-based WebSphere MQ Explorer console. Eclipse is an open-source platform for tool integration that is supported by the Eclipse Foundation, a non-profit corporation that includes a number of major software vendors among its strategic developers and consumers. The new console runs on Windows and Linux86 systems, but it is not currently supported on Linux for iSeries.
V6.0 adds support for sending files using the FTP protocol, meaning that organizations no longer need separate FTP software. A further benefit is that, using this feature, FTP transfers operate under the more secure WebSphere MQ security environment.
To improve performance, V6.0 adds support for 64-bit addressing on many platforms and supports data compression on all channel types. WebSphere MQ also now supports more messaging queues and larger queue sizes, including up to 4 GB queues.
V6.0 has also enhanced connectivity with CICS, including support for multiple CICS bridges. In addition, it is now possible to emit messages directly from CICS to WebSphere MQ.
- WebSphere Business Integration Message Broker (formerly WebSphere MQ Integrator Broker) is an information broker that provides a one-to-many connectivity model that, like WebSphere MQ, facilitates the exchange of messages among applications, but it also allows for the transformation of messages before delivery (so that not only the platforms, but also the message designs can differ between the sending and receiving applications), intelligent routing, and information flow modeling across multiple, disparate business systems. It also offers remote telemetry devices and a publish/subscribe model that can support mobile clients.
- WebSphere MQ Everyplace connects mobile and wireless applications to enterprise applications while providing assured message delivery and WebSphere MQ levels of security. It is complementary to WebSphere MQ, adding functions designed specifically for lightweight platforms, devices, and unmanaged networks.
- WebSphere MQ Workflow is a business process management system that allows administrators to define, initiate and change complete business processes that can span disparate systems and applications.
- WebSphere Business Integration Server Foundation provides a standards-based integration platform for building and deploying Business Process Execution Language for Web Services (BPEL) and Web Service-based composite applications.