Java Message Service

The main concepts in JMS are shown in the figure below. The left side illustrates the Point-to-Point (P2P) model and the right side illustrates the Publish and Subscribe (Pub/Sub) model. In P2P messaging senders and receivers are de-coupled by a queue. In Pub/Sub messaging, the publishers and subscribers are de-coupled by a topic.

The names in the boxes in the figure denote Java interfaces, which a client application must use the interact with JMS. Although the Pub/Sub and P2P messaging models are different from a conceptual point of view, there is a high degree of commonality and JMS is centered around a generic messaging model where Pub/Sub and P2P are merely specializations.

A JMS application consists of several components:

In general, JMS applications have to perform the following five steps in order to start sending or receiving messages:

1. Resolve a connection factory and a destination from JNDI. A Pub/Sub application will resolve a topic connection factory while a P2P application will resolve a queue connection factory. A destination is either a queue or a topic.
2. Create a connection using the connection factory. Again, a Pub/Sub application needs to create a topic connection and a P2P application needs to create a queue connection. The connection represents a physical connection to the JMS provider.
3. Use the connection to create a session with the desired properties (topic session for Pub/Sub and queue session for P2P). A session is a single-threaded context for sending and receiving messages, i.e. the session serializes actions of sending and acknowledging messages on behalf of the sessions producers and consumers.
4. If the application is a producer, create a message producer. The producer is called a queue sender in the P2P model and a topic publisher in the Pub/Sub model. If the application is a consumer, create a message consumer. The consumer is called a queue receiver in the P2P model and a topic subscriber in the Pub/Sub model.
5. Start to send or receive messages using the producer or consumer object. A producer will use the session to create different kinds of messages. The consumer will inherit the message acknowledge mode from the session, and can receive messages either synchronously, or asynchronously using a message listener.

The database in the figure above is shown to illustrate that JMS will store persistent messages for recovery purposes in some store. Some JMS vendors might use a file-based store instead of a database. JMS does typically not use a database when handling non-persistent messages.

Messaging Models

JMS defines two message models: Publish and Subscribe (Pub/Sub) and Point-to-Point (PTP). The JMS specification requires that an implementation must support at least one model. Since both models share the same common framework they can both deliver messages synchronously or asynchronously to consumer applications.

Pub/Sub Message Model

The Pub/Sub model publishes (distributes) messages on either a one-to-many or a many-to-many basis. Examples include:

• Stock quotes
• Prices published by parts vendors
• Internet news groups

Messages are published to topics by one or more topic publishers. Interested users subscribe to one or more topics in order to receive those messages. A subscription to a topic can be made either durable or non-durable.

Subscription	Description
Durable	A subscriber receives messages from a specified topic when the subscriber is online. Durable subscriptions require more overhead because messages must be stored until they are delivered.
Non-durable	Messages published to a specified topic exist only for the lifetime of the subscriber. As long as the subscriber is active, it receives messages from subscribed topics. If no subscribers to a topic are online to receive messages, the messages are destroyed.

PTP Message Model

The Point-to-Point (PTP) model distributes messages on a one-to-one basis. Examples include:

• Electronic order entry
• Placing bids in online auctions
• Queries

A message is sent to a specified queue. Messages in a queue are processed on a first-in, first-out (FIFO) basis. Unlike the Pub/Sub model, where one message is delivered to several subscribers, each message in the PTP model can be delivered to only one receiver.

A receiver takes the first message in a queue, then the second, and so on. A receiver can also browse the messages in a queue - for example, to count them - but cannot receive messages out of sequence, or change the messages in any way.

Message Structure

Messages, in the context of message-oriented middleware and JMS, are not traditional e-mail messages. Rather, they are formatted data - requests, events, or status - that are passed between enterprise applications.

JMS provides a single, unified message API that is used to pass messages between otherwise incompatible applications. JMS applications can also pass serializable Java objects to other Java-based applications.

Because JMS provides several message body forms, the message formats used by non-Java applications can be duplicated and passed along. JMS applications do not have to understand the content of the messages they pass.

Message Header

All messages support the same set of header fields. The following table describes some of these fields. Refer to the JMS specification for a complete listing.

Field	Description
Time to expire	The length of time a message can exist before it expires and is destroyed by the provider. Expiration can be set to zero, which means the message will not expire.
Persistent and non-persistent delivery	Persistent (or guaranteed) delivery means that delivery of a message is assured; it will persist until it is received by all subscribers who requested it. The message is delivered once and only once. Nonpersistent (or reliable) delivery means that although a reasonable attempt is made to deliver the message, it can still be lost in the event of a system failure. These messages are delivered at most once. Non-persistent delivery requires lower overhead and is used in situations where guaranteed delivery is not required.
Priority	Messages with a higher priority are delivered before messages with a lower priority; however, this is not guaranteed. There are 10 priority levels - from 0 the lowest to 9 the highest.
Redelivered flag	Notifies the client that this message was probably received by the client before, but for whatever reason, the client did not acknowledge its receipt. This flag is set by the JMS provider application, usually as the result of a recovery operation.
Reply to	Contains a Destination, provided by the client, indicating where a reply to this message should be sent. When this field is filled, a response is generally expected.

Message Properties

Properties are values that can add to the information contained in header fields, or convey vendor- or application-specific information. JMS defines specific properties and reserves a block of names for them. It also provides a naming convention for provider-specific properties.

Properties can be set when a message is sent, or by consumers upon receiving the message. Along with header fields, properties can be used by the application to filter and route messages based on specified criteria.

Property values can be of the type boolean, byte, short, int, long, float, double, and String. JMS provides a method to retrieve an enumeration of all property names and methods to retrieve the values of the named properties.

Message Body

JMS defines six message types:

Form	Content
Message	A plain message with no body. This message consists only of the header and properties.
ByteMessage	A stream of uninterpreted bytes. This form can be used to encode information to match formats used by legacy messaging applications.
MapMessage	A set of name/value pairs. The name is a String and the value is a Java primitive type.
ObjectMessage	A single serializable Java object or a collection of objects.
StreamMessage	A stream of Java primitive values that are entered and read sequentially.
TextMessage	Text formatted as a java.lang.String. This form is well suited to pass XML data.

Administered Objects

An administered object is one that is created by the administrator of the JMS provider application. Administered objects are placed in a JNDI namespace, and can be administered from a common management console. JMS has two types of administered objects, namely destinations and connection factories.

Destination

The Destination object contains address names and configuration information supplied by the JMS provider. The client uses this object to specify a destination for messages it sends, and a location from which the messages it receives originate.

There are two types of Destination interfaces - one for each message model. For the Pub/Sub model, the destination is called a Topic For the PTP model, it is called a Queue

Connection Factory

The ConnectionFactory enables a client to create a connection with the JMS provider. It contains connection configuration information that has been defined by an administrator, and it is retrieved using JNDI.

As the name indicates, the connection factory can create connections to a JMS provideer. In the Pub/Sub model, the connection factory is called TopicConnectionFactory ; in PTP, it's called QueueConnectionFactory.

JMS Interfaces

JMS defines interfaces that create and manage connections. The set of interfaces you use depends on whether your application uses Pub/Sub or PTP.

The JMS specification further defines XA variants of most of these interfaces, which are used for transactional messaging: