Messaging helps move Java into the enterprise

Find out how the Java Message Service API helps developers create more robust enterprise applications

Messaging is playing an increasingly important role in enterprise computing. Its advantages are a natural result of several factors: the trend toward peer-to-peer computing, greater platform heterogeneity, and greater modularity, coupled with the trend away from synchronous communication between processes.

In its effort to stay on top of important industry trends, Sun announced last April (at the 1998 JavaOne Developer Conference) its plans to publish the Java Message Service (JMS) API, an interface for using existing enterprise messaging systems in a uniform manner. The version 1.0 specification, which was released in July, provides a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.

Since its release, almost twenty vendors have stepped up to endorse the specification (including companies like IBM, Oracle, and BEA) and four companies have produced implementations: Etsee Soft, Fiorano Software, Modulus Technologies, and Push Technologies.

Messaging services

Rather than communicate directly with each other, the components in an application based around a message service send messages to a message server. The message server, in turn, delivers the messages to the specified recipients. This might seem like an extra, unnecessary layer of software, but the advantages a message service provide often outweigh this single disadvantage. The message service model is much like the model behind the postal service. We could directly deliver our own mail, but letting someone else do it greatly simplifies our life.

The common building block of a messaging service is the message. Messages are events, requests, and replies that are created by and delivered to enterprise applications. Messages contain formatted data with specific business meanings.

Beyond the message, however, messaging services display a surprising degree of diversity. For example, a messaging service may:

  • Allow messages to be prioritized

  • Deliver messages either synchronously or asynchronously

  • Guarantee messages are delivered once and only once

  • Support message delivery notification

  • Support message time-to-live

  • Support transactions

In addition, every messaging service packages these capabilities slightly differently.

How does the JMS API fit in?

A key goal of the JMS API is to unify the packaging of these capabilities and to minimize the set of concepts a Java programmer must learn in order to use messaging products. As its secondary goal, it strives to maximize the portability of messaging applications.

Specific goals of the JMS API specification are to:

  • Provide a single, unified message API

  • Provide an API suitable for the creation of messages that match the format used by existing, non-JMS applications

  • Support the development of heterogeneous applications that span operating systems, platforms, architectures, and computer languages

  • Support messages that contain serialized Java objects

  • Support messages that contain XML pages

The JMS API is divided into two nearly identical pieces. One implements the point-to-point model of messaging, and the other implements the publish/subscribe model of messaging. Each of these models is called a domain. The APIs are almost identical between domains. This greatly improves the feeling of cohesiveness throughout the API.

The point-to-point and publish/subscribe models were selected because they represent the two largest paradigms behind existing messaging services. While sharing many characteristics, they differ in enough ways that they can be thought of as two separate services. They're not necessarily incompatible -- both can be used in an application. However, most applications tend to use one or the other. The separation of the API into two domains relieves vendors that support only one messaging model from providing facilities their product doesn't natively support.

The advantages of messaging

Messaging provides three clear advantages when used in an enterprise application.

First, it decouples resources. Messaging allows business components to be combined into a reliable, flexible system with extremely loose coupling between components. This characteristic is desirable for two reasons: it makes the application more modular (and therefore more open to reuse) and it makes the application more reliable (a failure in one part of the application is less likely to affect an unrelated part of the application).

Second, messaging provides scalability. An application built around a messaging architecture scales well as both clients and servers are added to the system. It will also scale well as the volume of messages increases.

Third, messaging masks both heterogeneity and change. Remember, the common element in a messaging application is the message. As long as components can read and understand the message, the platform on which they reside and the languages in which they're written is unimportant.

Putting theory into practice

The following two examples should help clarify the role and the function of messaging services in applications.

This first figure illustrates one typical messaging-based application. This application is a modification of the traditional client/server architecture. The major difference is the presence of a messaging product between client and server layers. Thus, rather than communicating directly, clients and servers communicate via the messaging service.

The addition of the messaging service adds another layer to the application, but it greatly simplifies the design of both the clients and the servers (they are no longer responsible for handling communications issues), and it greatly enhances scalability (more about this later).

This second figure illustrates another messaging-based application -- this one based on a point-to-point architecture.

This type of application almost demands a centralized messaging service. Without one, each component would be responsible for creating and maintaining connections with the other components. A possible alternative approach would be to architect the system around a communication bus, but this would still leave each component in charge of message delivery issues.

These two examples illuminate the advantages of messaging services mentioned earlier:

  • The application scales well. In the first example above, all that is required to increase server capacity is to add servers to the pool. The application itself doesn't have to be rearchitected. Likewise, when components fail the application degrades gracefully.

  • Communication is asynchronous. Components can perform other tasks while not busy handling requests. They can either poll the message server when ready or receive notification via a callback when a message is waiting. It is unnecessary to wait in a loop. This is an important consideration in applications like those in the second example.

  • The application is modular. The messaging service is responsible for quality of service issues such as reliable delivery. This frees the components (which may be custom built) of the application from having to deal with these fairly generic issues.

  • The application is flexible. Because the application API is defined by the format of the messages exchanged, components of the system can run on almost any platform and can be written in almost any programming language. They can also be replaced with minimal system impact.

Note that the introduction of a messaging component admits a potential bottleneck and a single-point-of-failure into the system. Both of these issues can be address by replicating the messaging server and its content.


Based on vendor comments at this year's Java Business Expo, it appears likely that we'll see additional implementations of the JMS API over the next two quarters or so, so stay tuned for more on this simple, versatile enterprise technology.

Todd Sundsted has been writing programs since computers became available in convenient desktop models. Though originally interested in building distributed object applications in C++, Todd moved on to the Java programming language when it became the obvious choice for that sort of thing. In addition to writing, Todd is president of Etcee which offers training, mentoring, consulting, and software development services.

Learn more about this topic

  • Java Message Service home page
  • Vendors and supporters
  • JMS specification
  • Michael Shoffner's May 1998 Step-by-Step column on message-oriented middleware