Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Should you go with JMS?

Why JMS isn't always the best solution for distributed system development

By Thomas Laramee, JavaWorld.com, 10/25/02

Distributed system development is growing rapidly as software developers build systems that must keep up with the ever-increasing requirements imposed by e-business. But, never before has the design and implementation of a message-processing layer within a distributed system been as complex as it is today. This is mostly due to the dramatic increase in potential functionality enabled by standards like Java Message Service (JMS) that connect many vendors' technologies in a single system. In addition, the proliferation of the Internet has given rise to new, expansive user bases and has made available several protocols for communication within a distributed system. Such protocols include CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distributed Component Object Model), and Java RMI (Remote Method Invocation).

The natural evolution of these protocols has led to the introduction of message-oriented middleware (MOM), which allows for looser coupling within distributed systems by abstracting translation, security, and the underlying communications protocols from clients and servers. Middleware solutions include SOAP (Simple Object Access Protocol) and JMS. Proprietary, middle-layer transaction processing has existed since the early days of COBOL (Common Business Oriented Language), but it wasn't very complex because of early messaging technologies' limitations.

With the advent of standards like JMS, developers can now connect numerous technologies. Distributed-system design decisions are more difficult, and their implications on data integrity and distribution are critical to system success or failure.

A pervasive and tacit assumption is that the introduction of technology is an asset while its liabilities are oftentimes ignored. Not accounting for the liabilities often results in a system that is either unnecessarily complicated and/or over-engineered. A basic understanding of JMS and its inherent qualities (system-independent qualities), followed by a careful analysis in relation to specific distributed-system scenarios can indicate how well JMS might solve system requirements versus either altering existing problems or even introducing new ones.

JMS overview

JMS, introduced by Sun Microsystems in 1999 as part of the Java 2 Platform, Enterprise Edition (J2EE) specification, is a set of standards that describe the foundations for a message-processing middleware layer. JMS allows systems to communicate synchronously or asynchronously via both point-to-point and publish-subscribe models. Today, several vendors provide JMS implementations such as BEA Systems, Hewlett-Packard, IBM, Macromedia, and Oracle, thereby allowing JMS to interact with multiple vendor technologies.

Figure 1 shows a simple JMS-based system with an outgoing queue populated with messages for clients to process, and an incoming queue, which collects the client processing results for insertion into a database.

Figure 1. JMS translates database rows into messages for distribution

As mentioned above, MOM (like JMS) allows looser coupling within distributed systems by abstracting translation, security, and the underlying communications protocols from the clients and servers. One of the message-processing layer's main assets is that, because it introduces this abstraction layer, the implementation of either the client or server can change, sometimes radically, without affecting other system components.

Two specific scenarios

In this section, I present two distributed systems that are potential candidates for JMS and explain each system's goals and why the systems are JMS candidates.

Scenario 1

The first candidate is a distributed encoding system (shown in Figure 2). This system has a set of N clients that retrieve encoding jobs from a central database server. The clients then execute the actual transformation (encoding) from digital master to encoded files, and finish by reporting their post-processing status (e.g., success/failed) back to the central database server.

Figure 2. Scenario 1

The types of encoding (e.g., text, audio, or video) or transformations (e.g., .pdf to .xml, .wav to .mp3, .avi to .qt) do not matter. It is important to understand that encoding is CPU-intensive and requires distributed processing across multiple clients to scale.

At a glance, this system is a potential JMS candidate because:

  • Processing must be distributed as it is extremely processor (CPU) intensive
  • It may be problematic, from a system performance standpoint, to connect multiple clients directly to a single database server


Scenario 2

The second JMS candidate system is a global registration system for an Internet portal. Global registration handles requests for new user creation (registration), login, and authentication.

Figure 3. Scenario 2

Specific registration information (e.g., name, address, favorite color) and user-authentication methods (e.g., server-side user objects, HTTP cookies) are unimportant. However, it is important that this system scale to handle millions of users, and usage patterns are difficult, if not impossible, to predict. (During a televised ESPN World Cup game the announcer says, "Log in and vote in our online poll. We'll present the results at the end of the show." All of a sudden, 500,000 users log in within a three-minute interval. 3 minutes = 180 seconds; 500,000 user logins/180 seconds = 2,778 user logins/sec.)

This system is a potential JMS candidate for the following reasons:

  • The system must be distributed to scale the transaction volume
  • Transactions are atomic (e.g., login), so they are stateless and therefore candidates for distribution


The two systems are architecturally alike. Several client machines extract data from a central database server (possibly replicated out to M read-only database servers), execute some logic on the client, and then report the status back to the central database server. One system delivers encoded files to a filesystem over UNC/FTP; the other delivers HTML content to Web browsers over HTTP. Both systems are distributed.

This is as far as many engineers go with their analyses before applying JMS. In the rest of this article, I explain that, although these systems share many characteristics, the appropriateness of JMS becomes clearer and more divergent as we examine each system's requirements, including system performance, data distribution, and scalability.

Resources