JMS: A Solution in Search of a Problem?
Why so many developers are needlessly confused about the purpose of the Java Messaging System
By Brian Maso
When I've described the Java Message Service (JMS) to developers, I've witnessed ready acceptance to individual JMS interface/object fit and function while at the same time a comprehensive resistance to applying JMS to enterprise systems. Unless you've used something similar in the past, JMS strikes the pose of an intricate, well-thought-out solution in search of a problem.
Message-based development is just not something with which most application developers are familiar—if at all, they're familiar mostly within terms of GUI development. It is sort of an odd way to program. I don't think it's intuitively obvious to everybody why messaging and distributed applications go together. What would be the benefits?
After perusing the tutorials and sifting through the javadocs, I sense that a cry of why? is echoing through the forest of architectural illustrations, interfaces, exception types, and call contracts. This article is for those of you who don't see what the big deal is with JMS. It's not about how to do JMS, but why JMS. (In keeping with the "why, not how" theme, there are no code samples or discussions of JMS APIs. There are some excellent sources for APIs and tutorials in the References section.)
The abstract JMS API standardizes a "messaging service" concept that's popular in the distributed applications world. The messaging concept is a network data distribution pattern essential to a successful, scalable enterprise systems. Let me repeat that: This pattern is absolutely essential for enterprise system scalability.
On the other hand, a key alternative pattern is RPC (remote procedure calls), which compares with JMS in terms of efficiency. RPC is generally considered to be messaging's opposing design pattern.
But enterprise is such an overloaded term. My own humble definition—the one I'll be using throughout this article—is this: A software enterprise system is a set of cooperating processes connected by a network. The processes cannot directly share data, since each has separate virtual memory, so instead they exchange (via the network) copies of data structures each generates internally. Unique challenges of enterprise system development include efficient use of the network, which fights against the need to distribute and synchronize data between cooperating processes.
Another important challenge is scalability: that is, each process stabilizing itself and continuing to function within design parameters even under heavy load. This need for process scalability balances against the ever-present need for simplicity in software design.
