The Java Message Service was developed by Sun Microsystems to provide a means for Java programs to access enterprise messaging systems. Before we discuss JMS, let's take a look at enterprise messaging systems.
Enterprise messaging systems, often known as message oriented middleware (MOM), provide a mechanism for integrating applications in a loosely coupled, flexible manner. They provide asynchronous delivery of data between applications on a store and forward basis; that is, the applications do not communicate directly with each other, but instead communicate with the MOM, which acts as an intermediary.
The MOM provides assured delivery of messages (or at least makes its best effort) and relieves application programmers from knowing the details of remote procedure calls (RPC) and networking/communications protocols.
As shown in the figure below, Application A communicates with Application B by sending a message through the MOM's application programming interface (API).
The MOM routes the message to Application B, which can exist on a completely different computer; the MOM handles the network communications. If the network connection is not available, the MOM will store the message until the connection becomes available, and then forward it to Application B.
Another aspect of flexibility is that Application B might not even be executing when Application A sends its message. The MOM will hold the message until Application B begins execution and attempts to retrieve its messages. This also prevents Application A from blocking while it waits for Application B to receive the message.
This asynchronous communication requires applications to be designed somewhat differently from the way most are designed today, but it can be an extremely useful method for time-independent or parallel processing.
The real power of enterprise messaging systems lies in the loose coupling of the applications. In the diagram on the previous section, Application A sends its messages indicating a particular destination, for example "order processing." Today, Application B provides order-processing capabilities.
But, in the future, we can replace Application B with a different order-processing program, and Application A will be none the wiser. It will continue to send its messages to "order processing" and the messages will continue to be processed.
Likewise, we could replace Application A, and as long as the replacement continued to send messages for "order processing," the order-processing program would not need to know there is a new application sending orders.
Originally, enterprise messaging systems were developed to implement a point-to-point model (PTP) in which each message produced by an application is received by one other application. In recent years, a new model has emerged, called publish and subscribe (or pub/sub).
Pub/sub replaces the single destination in the PTP model with a content hierarchy, known as topics. Sending applications publish their messages, indicating that the message represents information about a topic in the hierarchy.
Applications wishing to receive those messages subscribe to that topic. Subscribing to a topic in the hierarchy that contains subtopics allows the subscriber to receive all messages published to the topic and its subtopics.
This figure illustrates the publish and subscribe model.
Multiple applications can both subscribe and publish messages to a topic, and the applications remain anonymous to one another. The MOM acts as a broker, routing the published messages for a topic to all subscribers for that topic.
The Java Message Service specification 1.1 states:
JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.
Prior to JMS, each MOM vendor provided application access to its product through a proprietary API, often available in multiple languages, including the Java language. JMS provides a standard, portable way for Java programs to send and receive messages through a MOM product. Programs written with JMS can run on any MOM that implements the JMS standard.
The key to JMS portability is the fact that the JMS API is provided by Sun as a set of interfaces. Products that provide JMS functionality do so by supplying a provider that implements these interfaces.
As a developer, you build a JMS application by defining a set of messages and a set of client applications that exchange those messages.
To better understand JMS, it helps to know the objectives set by the authors of the JMS specification.
There are many enterprise messaging products on the market today, and several of the companies that produce these products were involved in the development of JMS.
These existing systems vary in capability and functionality. The authors knew that JMS would be too complicated and unwieldy if it incorporated all of the features of all existing systems. Likewise, they believed that they could not limit themselves to only the features that all of the systems had in common.
The authors believed that it was important that JMS include all of the functionality required to implement "sophisticated enterprise applications."
The objectives of JMS, as stated in the specification, are to:
- Define a common set of messaging concepts and facilities.
- Minimize the concepts a programmer must learn to use enterprise messaging.
- Maximize the portability of messaging applications.
- Minimize the work needed to implement a provider.
- Provide client interfaces for both point-to-point and pub/sub domains. "Domains" is the JMS term for the messaging models discussed earlier. (Note: A provider need not implement both domains.)
In versions of JMS prior to version 1.1, each domain has its own set of client interfaces specific to that domain. JMS version 1.1 provides a single set of interfaces that allows clients to send and receive messages in both domains. These "domain-independent interfaces" retain the semantics and behavior of each domain and are the preferred choice for implementing JMS clients. The domain-specific interfaces are supported for backward compatibility and should not be used for new development.
The benefits of unifying the domains are:
- It presents simpler programming model for client programming.
- Actions on both queues and topics can be part of the same transaction.
- It provides opportunities for JMS providers to optimize their implementations.
The following features, common in MOM products, are not addressed by the JMS specification. Although acknowledged by the JMS authors as important for the development of robust messaging applications, these features are considered JMS provider-specific.
JMS providers are free to implement these features in any manner they please, if at all:
- Load balancing and fault tolerance
- Error and advisory system messages and notification
- Wire protocol
- Message type repository