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
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.
Content-based routing
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.
Conclusions
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 >>