Java Message Service
With distributed computing, many software components of one working system may be separated geographically. The need for these components to communicate is obvious, and this need drives many software design decisions. For instance, you might choose to use CORBA, SOAP, or message-oriented middleware for intercomponent communication.
SOAP-based web-service development continues to grow, and uses XML and HTTP to remove the implementation details from remote procedure calls. But while SOAP has broken new ground in distributed computing, message-oriented middleware such as the Java Message Service (JMS) is still my tool of choice when reliability, performance, and security are top priorities.
JMS is a specification (java.sun.com/products/jms) that describes the properties and behavior of an information pipe for Java software. It also describes how Java client applications interact with the information pipe. In this article, I examine messaging concepts and implement a JMS application.
What Is Messaging?
The concept of messaging begins with the goal of delivering data.
Enterprise messaging forms the basis for an infrastructure dedicated to
communication between disparate components in distributed software
systems. The important components in messaging systems—producers,
consumers, and the messages themselves—are abstracted via interfaces.
The result is a set of loosely coupled components that are part of a
cohesive software system.
Components that are loosely coupled have as few direct interactions with one another as possible. This isolation leads to more robust software, as changes to one part of the system do not ripple through to other parts. A good messaging system does this by abstracting the components from one another in the system. (For more information, see my book Java Messaging, Delmar-Thomson Learning Inc., 2006.)
Every messaging system consists of a broker component that is
responsible for delivering messages to and from the various components
interacting with the messaging system. Messaging brokers generally
treat messages as opaque, meaning they tend to ignore the content
within the message.
In fact, the broker does not need to know the purpose or content of
a message to deliver it. In turn, the software components that
send/receive the messages don't need to know how the messages are
delivered, or which components sent them. The important part is that
they are sent and received reliably.