Overview

JMS stands for Java Message Service. It is a Java API that describes the way messaging clients interface with service providers according to Sun Microsystems specifications. JMS is a significant part of Sun's Java2 Enterprise Edition (J2EE) platform. As such, JMS offers both an application programming interface (API) as well as a service provider interface. The JMS clients, whether components or applications, interact with each other,using a JMS API to send and receive messages. The latest version of JMS, v1.02, supports both the [Point to Point] and [Publish and Subscribe] methods of message transfer, including specific subclasses. JMS, working alongside other J2EE technologies, offers dependable asynchronous communication among components.
The Enterprise Messaging Grid allows you to write client applications using the industry standard JMS API and to use them with any of the messaging products supported by GigaSpaces.

Message Types

The JMS standard indicates five different message types that an application can publish:

• Text – contains a java.lang string for transporting string objects, especially XML documents.
• Object – transports any serializable Java object, either as a Topic or a Queue.
• Map – transports a self-defining set of name-value pairs, where names equal strings and values equal Java primitive types.
• Bytes – transports a stream of uninterpreted bytes, typically used to duplicate the body of one of the other message types. This is useful when one needs to read in raw data from a disk file and transfer it "as is" to another machine and/or location.

Messaging Models

JMS lets a client create a message and deliver it to the JMS provider, which in turn sends it to one or more clients.
There are two different ways to accomplish this:

• Point-to-Point
• Publish-and-Subscribe

For more details, refer to the JMS section.

These two models are the two leading messaging models utilized by existing messaging products.

Point-to-Point Messaging

With Point-to-point (PTP) messaging a queue stores messages for as long as they are specified to live, waiting for a consumer. Multiple clients can send messages to an individual queue, while multiple clients can monitor a specific queue for messages. However, each message can only be delivered to one client, similar to a letter sent to one address with many potential recipients. Point-to-Point messaging employs only a one-to-one process.
The QueueBrowser class allows an application to browse the queue, examine its contents, and observe how message traffic is moving. Queues generally must be created by the administrator before they can be used.
After the message is sent to the queue, if no receivers are waiting for it from a queue, the JMS provider retains it until a receiver retrieves it. Often a queue is persistent, meaning it can be delivered and read by a recipient even if the primary message service fails. In contrast, if a message queue has been defined as non-persistent and is not received, the message will cease to exist after a specified period of time.
The diagram below illustrates how a queue and queue sender operate.

Publish & subscribe

In Publish-and-Subscribe messaging, also called Pub-Sub, a JMS client publishes messages to a specific topic. Other JMS clients subscribe to messages from that topic, and each consumer of that topic receives the message. While Point-to-Point is essentially a one-to-one messaging model, Publish-and-Subscribe is a one-to-many model where topic producers (publishers) exist independently of topic consumers (subscribers). Producers can even publish a topic to a place with no consumers at all. The JMS provider delivers the topic to all clients who are subscribing to it; the analogy is similar to broadcasting.
In general, subscribers only receive those messages published while they are still active, whether those messages are persistent or not. However if a consumer has subscribed to a [durable subscription] for a topic then that consumer can receive all persistent messages of that topic. When the client restarts and re-establishes the durable subscription, the stored messages are sent to the client.
The diagram below illustrates how a Topic Publisher and Subscriber operate.

Generic Terms

The following terms apply to either Point-to-Point or Publish-and-Subscribe models as necessary.

• A destination is used generically for a queue or a topic.
• A producer is used generically for a queue sender or a topic publisher.
• A message consumer is used generically for a queue receiver or a topic subscriber.

Synchronous vs. Asynchronous Messaging

When message consumers wish to receive only certain messages, JMS utilizes a filtering scheme. Such filters distinguish between messages to receive and not to receive. The terms synchronous and asynchronous refer to whether or not the JMS client blocks messages from a producer to a consumer. When JMS blocks all incoming messages to a consumer until they are received, such a transfer is synchronous, meaning all messages arrive to the consumer in sync at once. A synchronous transfer will naturally slow the rate of progression to the consumer.
A typical advantage in JMS protocols is the ability to transfer messages asynchronously, that is, independent of time constraints. TopicSubscribers can receive messages in two ways, either synchronously or asynchronously. It is not advisable, however, for the JMS client to use both methods at once.
To receive a message synchronously, JMS calls one of the receive() methods. This will block the consumer from receiving all other messages until that particular message is received or until a timeout expires.
If a client prefers to receive messages asynchronously, it must register an object that implements the JMS MessageListener interface. Then, when a message arrives, the listener's onMessage() method is called, regardless of the status of other messages.

Persistent Messages

The messages which the JMS client sends to a queue or topic can be either persistent or non-persistent. JMS designates the idea of a persistent message in order to ensure that messages are protected from inadvertent loss or JMS provider failure. The default setting is persistent. There are three primary effects on the JMS provider from such a configuration:

• In Point-to Point messaging – any persistent message sent to a queue with no receivers is retained until a receiver requests it. But if the message is non-persistent, it could be deleted.
• In Publish-and-Subscribe messaging – if a message is persistent and the client has created a durable subscription for that topic, then the JMS provider stores all persistent messages published to that topic. However, non-persistent messages are stored as long as the space is alive and the message hasn't yet expired. The result is that whenever the client restarts and re-establishes the durable subscription, stored messages are sent to it.
• Another advantage of the persistent message is protection against provider failure. Persistent messages get logged to a persistent store on the disk and the server re-delivers them with a re-delivery flag set to true. The persistent delivery continues even if the consumer has already received the message. In contrast, a non-persistent message is delivered one time only; if the system crashes or another type of failure occurs, the message could get lost.

Message Acknowledgement

A JMS provider that delivers a message retains that message until the consumer has acknowledged it. In other words, the provider continues to deliver the message until it is acknowledged.
Consequently, a message consumer does not typically acknowledge a message until it is finished processing it.
There are four ways in which a consumer can acknowledge the receipt of a message:

• With a transaction – when a transaction occurs, all messages consumed during that transaction are acknowledged. But if the transaction is [rolled back], messages are not acknowledged.
• Directly by the consumer – in such a case, the consumer automatically acknowledges any previous messages.
• Automatically acknowledged – occurs in two cases:
  • A successful return from a call to receive().
  • A successful return from the MessageListener call.
• Automatically but slowly – a message is automatically acknowledged, but the acknowledgement is not sent immediately. For example, the client may fail after it has processed a message, even though the acknowledgement was sent. In such a case, the provider may have to deliver the message a second time.

Message Expiry

Usually, a message sent to a queue or published to a topic will contain a pre-specified time to live value. Such a value may limit the ability of the JMS provider to deliver the message beyond that time. If the message was stored in a queue or a durable subscription, it will be removed when its time to live expires.