Concepts: Java Messaging Service (JMS)
Topics
Introduction
The Java Messaging System, JMS, provides a cross platform standard for asynchronous
communication of business data and events across the enterprise. The communication
is typically across processes and machines. Objects in applications, typically
running on different machines, communicate by accessing the services of the
message-oriented middleware (MOM) through a standard set of interfaces defined
through the JMS.
JMS provides a set of interfaces that isolate the Java programmer (implementing
the message producers and consumers) from the MOM providers.
This content page describes the key concepts and the typical use of JMS.
Messages
A message is a self-contained package of business data. It has three compartments:
- Header: Contains network routing information and message identifiers.
- Properties: Contains meta-data for the message. JMS dictates some of
the properties, but application programmers can also add their own.
- Payload: Contains the actual business data. The payload is entirely
controlled by the application programmer.
In JMS, the message is encapsulated in an object that implements the interface
javax.jms.Message. A Java program can access the compartments thorough
this interface, as shown in the following diagram. The payload comes in several
variations, discussed later.
The header contains properties of the message that must always be there.
The following properties are available from the header:
- MessageID
- Timestamp
- CorrelationID
- ReplyTo
- Destination
- DeliveryMode
- Redelivered
- Type
- Expiration
- Priority
The properties can be used by the application programmer to provide
meta-data for the message. The properties consist of an arbitrary set of name-value-pairs.
There are six kinds of payloads supported by JMS:
- Text messages
- Object messages
- Byte messages
- Map messages
- Stream messages
- Message (no body present)
Types of payloads are reflected in the class hierarchy where interfaces extend the javax.jms.Message. In the following class diagram,
we show the frequently used text, object, and bytes messages. Text messages are commonly the carriers of XML data.
Destinations
JMS defines the concept of a destination. Messages are sent to and received
from destinations. Destinations come in two forms:
Queues are message destinations used when messages are handled by only one receiver.
Imagining that the messages are similar to sending snail-mail, the queues are mailboxes owned by a particular recipient.
Communication using queues is called point-to-point communication.
Topics are message destinations used when messages need to be received
by multiple receivers, each of which express an interest in receiving a particular
kind of message. Using the analogy with snail-mail again, one may think of this
as writing an article in a newspaper; one message is read by any number of receivers.
We often refer to this kind of design as the publish-and-subscribe model.
Message Delivery
The delivery of messages can be performed in two ways:
- Persistent
- Non-persistent
The persistent delivery includes storage of the message into a file or a database,
which enables guaranteed delivery. Non-persistent delivery improves performance
and reduces storage overhead, but there is no guarantee that the message will
be delivered. For most applications that use JMS, persistent delivery is the
commonly chosen way.
JMS Clients
JMS clients are Java objects that use JMS. There are two roles defined:
- Message producers: Java programs that create and send messages.
- Message consumers: Java programs that receive messages.
The following diagram is an overview of how producer, consumers and JMS providers collaborate.
A message producer can be any Java class that has access to a JMS implementation. The message producers create and send messages.
A message consumer can be any Java class that has access to a JMS implementation.
The message consumers receive and handle messages.
A JMS client uses a set of interfaces to access JMS. The objects that implement
the JMS interfaces are created through a set of factories. The initial factory
is the ConnectionFactory. The connection factory is looked up through
JNDI. The JMS client uses the connection factory to create connection object.
The connection object is used to create a session object, which is used as a
factory for the other JMS objects. The following figure illustrates the key
conceptual relationships between the factories, abstracting from the details
of queues and topics.
Connection factories, connections and sessions come in two forms: one for queues and the other one for topics.
The class diagram below shows the interface hierarchy for key JMS concepts.
JMS Providers
A JMS Provider is an implementation that satisfies the JMS specification.
The JMS provider is responsible for receiving, persisting and delivering messages.
More Information
For more information on JMS, visit http://java.sun.com/products/jms/.
|