JMS taking a place in the enterprise -- ADTmag

JMS taking a place in the enterprise

By John K. Waters
January 31, 2003

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 services.''

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 solution.''

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 other peers.

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 application arrives.

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 time.

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) API.

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 capabilities.

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 said.

''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. Period.''

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 together.

See the related story 'JMS vendors' for more information.