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
• Topics

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/.