JMS taking a place in the enterprise
- By John K. Waters
Messaging middleware has become something of a solution of choice for a range
of enterprise computing problems. It is now the basis of such diverse
applications as workflow, network management, communication services, customer
care, weather forecasting and supply-chain management, among many others. Sally
Hudson, an analyst at Framingham, Mass.-based IDC, predicted in a recently
published report that standards-based messaging will be one of the few growth
areas in the middleware market as a whole over the next few years.
A key driver of this messaging middleware revolution is the Java Message
Service (JMS). Since it was first unveiled by Sun Microsystems at the 1998
JavaOne Developers' Conference, JMS has emerged as a key enterprise messaging
technology in these and similar applications. The JMS API defines a common set
of messaging concepts and programming strategies for the development of
portable, message-based applications in Java. In other words, the JMS API allows
message-oriented middleware (MOM) systems to communicate using Java objects.
''JMS is much less complex and lighter-weight than proprietary messaging
systems,'' Hudson said. ''It's a very important element in enabling Web
The first implementation of JMS faced much criticism from observers, some of
whom predicted it could be overtaken by Microsoft messaging technology. Other
observers noted that JMS remains an emerging and improving technology. ''The
loopholes are closing,'' Hudson said. ''A year or two ago, [JMS] was not good with
guaranteed reliable delivery, but it has overcome those problems.''
''We've seen [JMS] emerge as a pervasive cornerstone of e-business
infrastructure for the better part of a decade,'' said George Kassabgi, vice
president of product development at BEA Systems Inc., San Jose, Calif. ''For us,
JMS has been a crucial element of a J2EE-capable e-business infrastructure
BEA is one of a number of companies that collaborated with Sun to define the
first draft of the JMS spec, and one of the first to implement JMS in a
commercial application server. The company implemented support for Java
SOAP-based Web services using JMS and Message-Driven Beans in the 7.0 version of
its WebLogic Workshop, an integrated development framework that allows
developers to create, test and deploy enterprise-class Web service applications
on the BEA WebLogic Platform.
That list of early JMS supporters also includes, among others,
Hewlett-Packard Co., Palo Alto, Calif.; IBM Corp., Armonk, N.Y.; Macromedia
Inc., San Francisco; Oracle Corp., Redwood Shores, Calif.; Pramati Technologies,
San Jose, Calif.; SilverStream Software Inc., Billerica, Mass.; SpiritSoft Ltd.,
Milford, Mass.; Talarian Corp., Los Altos, Calif.; Tibco Software Inc., Palo
Alto, Calif.; Fiorano Software Inc., Los Gatos, Calif.; and Sonic Software
Corp., Bedford, Mass.
Sonic has been in the market with a JMS enterprise messaging product since
1999. The 5.0 version of its flagship SonicMQ middleware was scheduled to ship
early this month.
''In 2002, we saw that JMS had become firmly established in major projects as
the API of choice,'' said Steve Trythall, director of product management at
Sonic. ''Large corporations were coming to us during their hunt for technology,
telling us that they had decided they were not going to go with a proprietary
interface for their messaging. Even when they chose a messaging solution from a
vendor that had it, they planned to use JMS.''
One of the first -- if not the first -- implementation of JMS was seen in
Fiorano Software's flagship product, FioranoMQ, a JMS server first released in
1998. The product is now in its 6.0 version, and the company claims that more
than 250 customers use the software. The latest version is JMS 1.1-compliant and
includes features such as XML content-based routing, client-side persistence and
the addition of a GUI-based cluster admin tool.
''The JMS market is stable and very mature,'' said Sachin Bhardwaj, Fiorano's
director of business development. ''Most companies today who are buying messaging
middleware are buying JMS for enterprise messaging.'' The appeal of this
technology is particularly visible in large industries, which Bhardwaj said have
'targeted' the technology, including financial institutions, telecom, retail,
manufacturing and travel services.
BEA's Kassabgi agrees: ''The investment right now is in further integrating
messaging into the broad e-business infrastructure. It's not to come up with the
latest and greatest JMS implementation. It is pretty well evolved already.''
Messaging is the message
According to John Wetherill, staff
engineer and technology evangelist at Sun, a messaging system is
message-oriented middleware that allows separate, uncoupled applications to
reliably communicate asynchronously. The messaging system architecture generally
replaces the client/server model with a peer-to-peer relationship between
individual components, where each peer can send and receive messages to and from
The term enterprise messaging refers to messaging middleware in a corporate
network, not to be confused with e-mail or other systems that are sometimes
referred to as ''messaging.'' Messaging middleware and e-mail systems do provide
similar transport functionality, but while messaging middleware deals with
transactions among applications, e-mail systems, of course, support
communications among human users. ''Messages'' in this context are the events,
requests and replies that are created by and delivered to enterprise
applications through the messaging system.
Enterprise messaging solutions have emerged as the most popular form of
asynchronous communication among heterogeneous applications. Other distributed
computing technologies, such as Common Object Request Broker Architecture
(CORBA) and the Component Object Model (COM), are based on the Remote Procedure
Call (RPC) architecture and are synchronous operations. Synchronous
communication is accomplished with the traditional request-reply protocol found
in client/server systems. Think of Web surfing: A client (your Web browser)
makes a request of a server (the Web site), and that server responds with a
reply (it sends you a Web page). Applications that interface with traditional
databases process queries in the same way, through interfaces and APIs provided
by the database management systems. A synchronous operation requires that the
requesting application stop running and wait until the data from the other
In asynchronous mode, which is the default mode for JMS, clients do not have
to be connected all the time because the message is delivered to a message
server. The sender and receiver do not have to be up and running at the same
Sun describes JMS messages as ''asynchronous requests, reports, or events that
are consumed by enterprise applications, not humans.'' These messages contain
information needed to coordinate these systems, and they carry data that
describes specific business actions. Through the exchange of these messages,
each application tracks the progress of the enterprise.
The JMS advantage
JMS is a standard, vendor-neutral API for
accessing enterprise-messaging systems. Basically, it is a standard interface
for accessing enterprise-messaging systems that facilitate the exchange of
messages among software applications over a network. JMS acts as a wrapper
around messaging vendor technologies, freeing developers from having to focus on
networking details, and allowing them to concentrate instead on the business
logic of their applications.
According to Deepak Nohwal, senior engineer at Fiorano, JMS is analogous to
the Java Database Connectivity (JDBC) programming interface. ''The JDBC is an API
that provides vendor-independent access [to] many different relational
databases,'' he explained. ''JMS gives you the same vendor-independent access, but
to enterprise messaging systems -- MOMs.''
In the 1.2 version of Sun's Java 2 Enterprise Edition (J2EE) platform,
vendors were not required to implement the JMS API; it was an add-on product.
But JMS has been an integrated part of J2EE since the 1.3 release, and Sun's
Enterprise JavaBeans (EJB) components are able to use the JMS API. The 1.3
version of the Java 2 software development kit (Enterprise Edition) includes the
Message-Driven Bean, which allows an enterprise application to receive messages
asynchronously. (It acts as a JMS message listener, something like an event
listener. The messages may be sent by any J2EE component -- another enterprise
bean, an application client or a Web component -- or by a JMS application or
system that does not use J2EE technology.)
The JMS API also uses the Java Naming and Directory Interface (JNDI) API for
administration. And JMS clients may use the JDBC API and Java Transaction (JTA)
Software applications that use the JMS API for sending or receiving messages
are portable across brands of JMS vendors. Java applications that use JMS are
called clients. The messaging system that handles routing and delivery of
messages is called the JMS provider. JMS clients that send messages are called
producers. The JMS clients that receive those messages are called consumers. A
single JMS client can be both a producer and a consumer.
The JMS architecture follows a hub-and-spoke topology in which all the
applications connect to a central message server. The message server handles all
communication among connected applications. The message server is responsible
for routing messages correctly, authenticating and authorizing user access, and
guaranteeing the delivery of the messages. Each application client can be a
sender, a receiver or both.
JMS defines only how a Java client accesses the messaging capabilities of an
enterprise messaging system. Other aspects of a messaging system, including
administration and security, are not defined by JMS. Each vendor is expected to
provide support for administration of the messaging system using proprietary
methods and tools.
JMS messages contain formatted data with specific business meaning. JMS
supports six kinds of messages, which are used to carry different types of
payload/data. The header of a message is the same regardless of payload, which
means that filtering is the same for all six message types. A message supports a
number of properties to set priority, reliability and other QoS properties,
which will be interpreted and handled by JMS. To support durable messages, JMS
uses the notion of a durable subscriber. This is only necessary in the
publish-subscribe model, because messages on a queue are consumed by any queue
receiver that connects to the queue in question. A durable subscriber is
identified by a name, and the same operation is conveniently used to both create
and re-create the subscriber.
The JMS API supports the two primarily messaging system models:
point-to-point and publish-subscribe. A publish-subscribe messaging system
supports an event-driven model in which information consumers and producers
participate in the transmission of messages. Producers ''publish'' events and
consumers ''subscribe'' to them and, well, consume them. Producers associate
messages with a specific topic, and the messaging system routes messages to
consumers based on the topics the consumers register interest in.
This model enables multiple users or applications to sign up for an event
through a message broker; when that event occurs, those users or applications
are sent the appropriate notification or data. A message broker is defined as
either a complete messaging system or software that works with existing
messaging transports to add routing intelligence and data conversion
In a point-to-point messaging system, messages are directed to a particular
consumer, which maintains a queue of incoming messages. Messages are sent to a
specified queue, and the client retrieves messages from that queue.
A key advantage can be seen here in the loose component coupling provided by
the messaging model. This loose coupling makes for a high degree of anonymity
between producer and consumer. In other words, it does not really matter to the
consumer who produced the message, where the producer exists on the network, or
when the message was produced.
The ascendance of JMS in the enterprise is not surprising when you consider
its advantages in distributed systems, Sonic's Trythall explained. By decoupling
resources, JMS allows business components to be combined into dependable,
adaptable systems with loosely coupled parts. The resulting applications are
more modular and reusable, and they are more reliable because a failure of one
component is less likely to affect an unrelated part of the application. In
fact, entire collections of sub-applications can be modified without affecting
the rest of the system. Also, Trythall said, applications built around a
messaging architecture scale very well, both as clients and servers are added to
the system and as the volume of messages increases. Finally, JMS camouflages
both heterogeneity and change.
''Keep in mind that the message is the common element in these applications,''
Trythall said. ''As long as components can read and understand the message, the
platforms on which they reside and the languages in which they're written are
all but irrelevant.''
Sonic officials say corporate IT organizations are closely watching whether
JMS can meet the scalability needs of large organizations. These officials
contend that JMS technology has already reached a level of scalability that can
support large-scale corporate requirements.
Meanwhile, Sonic officials said that the next version of SonicMQ will further
support JMS with the addition of a management console built to exploit the Java
standard for management.
The proliferation of messaging middleware in the enterprise suggests that IT
managers are a MOM-savvy group. At least that is BEA's Kassabgi's conclusion:
''Chances are, any readers who are interested in enterprise messaging are very
well-informed on the subject,' he said. 'The technology has been in place long
enough to have some highly sophisticated users.''
For IT managers who are still considering a messaging middleware
implementation, JMS alone is unlikely to provide the best solution, Kassabgi
''We do not see it as a standalone play,'' he continued. ''In [the] past, you
thought of [messaging middleware] as a separate piece. You bought [Tibco]
Rendezvous or [IBM] MQSeries. But the paradigm shift to Web services has taken
over. The Web brings about this natural asynchronous state that makes it
impossible to deal with messaging as an afterthought, or as a solution concerned
only with trading systems that need real time. Now, if you want an asynchronous
SOAP interaction, you're into messaging. As soon as you need one asynchronous,
reliable Web services interaction between two business systems, you're suddenly
in a thousand feet of water with your requirements. Nowadays, companies buying
enterprise infrastructure solutions expect messaging to be a part of it.
Kassabgi advises IT managers to evaluate messaging in the strict context of
their enterprise infrastructures. ''You're making significant investments in your
infrastructure,'' he said. ''You should evaluate messaging as a critical component
of that infrastructure. Pay attention to how it spans J2EE, XML and Web
services; you want to make sure that messaging is woven into those things. Make
sure that it fits into your infrastructure in a way that does not burden your
organization with additional integration or administrative nightmares, or
security concerns. Then you'll want to look at how messaging is integrated into
your enterprise infrastructure with respect to transactions, scalability,
handling failover and managing things dynamically. And you should definitely
look beyond the marketing benchmarks.''
Kassabgi sees the evolution of enterprise messaging moving beyond traditional
implementations. ''We see customers using messaging across the enterprise for Web
services,'' he said. ''And it's playing a key role in the overall effort of
integration and connecting business systems, whether [a company] is using Web
services or not.''
In the modern corporate IT environment, where widely distributed systems are
the norm, concerns about synchronization, reliability, scalability and security
abound. Increasingly, corporate IT is addressing these concerns with messaging
middleware. Widely recognized today as an essential component of enterprise
solutions, messaging provides a flexible service for the asynchronous exchange
of business data and events throughout an organization. Simply put, through
messaging, an enterprise can establish essential communication channels among
disparate applications that were not designed to work
See the related story 'JMS vendors' for more information.