A Butler Group overview of leading message-based integration technology
Hand-built interfaces may be appropriate for linking enterprise software but when the number of applications increases beyond a handful, a message-based IT architecture may be a better answer. But how do you decide which middleware product to use for this message-based process?
IBM Websphere MQ
Formerly known as the MQSeries, Websphere MQ provides messaging functions for servers and clients and assures once-only message delivery. This is important because if a message were re-sent by mistake it could lead to, for example, a duplicate order on the receiving application.
Websphere MQ is one of the most common messaging services and it is supported by most EAI suppliers, as well as forming the backbone of IBM's integration suite. It is extremely scalable, with IBM quoting throughput of more than 250 million messages per day. It runs on a wide range of platforms, including Unix, Windows and IBM operating systems such as OS/390 for the mainframe, and OS/400 for the iSeries.
Websphere MQ can also generate acknowledgements that a message has been received, making it suitable for B2B environments. It supports transactional messaging, which means that operations on messages can be grouped into units of work, which can then be either committed as a whole, or backed out if there is a problem, ensuring that data is always in a consistent state. It also provides a mechanism to trigger applications to start when certain conditions are met.
Microsoft Message Queuing
MSMQ provides guaranteed message delivery, efficient routing, security, and priority-based messaging, and it can be used for both synchronous and asynchronous scenarios.
It is available on Windows 2000 and XP platforms, and is fully integrated with other Windows features such as the Windows Web Server, Microsoft Internet Information Server, and the Windows 2000 security environment. The most recent version, MSMQ 3.0, is specifically designed for the Windows XP environment.
MSMQ uses a store-and-forward architecture, whereby messages are stored in a database in case the receiving party is not available to consume them. It uses internal sequence numbering and delivery notifications to recover from situations where messages get lost because of interruptions in the network.
Triggers allow an application to be automatically invoked based on message arrival. A trigger is associated with a specific monitored queue, and is invoked for every message that arrives on that queue. A rule associated with that trigger then defines conditions that must be met and actions that should be taken, in terms of an executable file or component.
Java Message Service
JMS is a supplier-agnostic API set developed by Sun in co-operation with leading enterprise messaging suppliers, including Oracle, BEA Systems and Tibco - these suppliers are then licensed to use the technology in their products.
The original JMS specification was published in 1998, and the latest version, 1.0.2b, was released in August 2001. It is part of the Java 2 Enterprise Edition suite.
The original purpose of the JMS API was to enable Java applications to access existing message-oriented systems, such as IBM's Websphere MQ, although it can be used to provide a complete messaging capability and provides most of the functionality of other messaging systems.
JMS provides a simple way of transporting XML and other data between applications. It is a more sophisticated transport mechanism than HTTP and SMTP, in that it includes persistent messaging, internal acknowledgement of message receipt, and rules of engagement regarding transactional recovery and message redelivery.
It helps to provide reliable, asynchronous communications between different components in a distributed computing environment, including between J2EE components and legacy systems. The use of an Enterprise Java Beans container architecture in conjunction with JMS allows the concurrent consumption of messages. JMS can support both point-to-point and publish/subscribe forms of messaging, although not all implementations of the specification will provide both.
While messaging products are inherently asynchronous, in that there is no basic timing dependency between the creation and the consumption of a message, JMS allows messages to be consumed in a synchronous manner by the subscribing party explicitly calling for the message. By doing so, further activity can be blocked until the message arrives or it can time-out if the message does not arrive within a specific time limit.
Asynchronous messaging is provided by the use of a message listener, which waits for a message to arrive and then acts on its contents. JMS uses the Java Naming and Directory Interface to identify the topic of the message in publish/subscribe environments.
Tibco uses the Information Bus (Tib) to transport messages between applications, within its Tibco Rendezvous messaging solution. The company has other messaging options, acquired with its purchase of Talarian earlier this year, as well as a JMS option. Rendezvous is one of the leading proprietary messaging services, with more than 1,000 installations worldwide. It uses a distributed architecture to avoid bottlenecks and single points of failure.
Applications connecting to it can choose to encrypt messages, and select the most appropriate quality of service. Messaging can be request/reply or publish/subscribe, and can be asynchronous or synchronous. Messages can be sent over local networks or via the internet. Rendezvous messages are self-describing and can be used on many platforms, with a user-extensible type system providing support for various data formats, including XML.
Most messaging services route the message to its destination based either on information held within the message header or based on the topic of the message in a publish/subscribe service. Intelligent, or content-based, routing builds on messaging services, usually within a message broker, although there are standalone options on the market.
Based on the content of the message, it may need to be routed to different end points in the wider infrastructure. In a typical application, a message is routed by opening it up and applying a set of rules to its content to determine the parties interested in its content. Content-based routing is often dependant on the message being constructed in XML, and will usually be built on top of MOM or JMS-based messaging.
This type of service is not typically included in basic messaging systems, but may be included in some of the higher-level EAI solutions.
Each type of messaging middleware has it strengths and weaknesses, but two trends dominate: messaging and application servers. JMS in particular has led to a new generation of message-based applications, building on the substantial installed base of IBM Websphere MQ, Tibco Rendezvous and similar products.
Message brokers have become the core of many EAI products, and offer a widening range of capabilities. Alternatively, by building integration solutions on top of an application server, companies can benefit from the reliability, fault tolerance and standards-based approach these platforms offer.
The middleware you select will depend on the type of integration required. With most organisations still tackling integration on a project-by-project basis, it may be appropriate to select a "cheap and cheerful" approach where the benefits of integration do not outweigh the cost of the larger integration brokers or platform solutions. EAI solutions come into their own when an overall strategy of integration between the majority of an organisation's applications has been agreed.
Teresa Jones is a senior analyst at Butler Group
For a full copy of this report click here >>