Java Message Service

The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914.

General idea of messaging

Messaging is a form of "loosely coupled" distributed communication, where in this context the term 'communication' can be understood as an exchange of messages between software components. Message-oriented technologies attempt to relax "tightly coupled" communication (such as TCP network sockets, CORBA or RMI) by the introduction of an intermediary component, which in this case would be a queue. The latter approach allows software components to communicate 'indirectly' with each other. Benefits of this include message senders not needing to have precise knowledge of their receivers, since communication is performed using the queue.

Version history

* JMS 1.0.2b (June 25, 2001)
* JMS 1.1 (March 18, 2002)

Elements

The following are JMS elements: [http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html]

; JMS provider: An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM.; JMS client: An application or process that produces and/or receives messages.; JMS producer: A JMS client that creates and sends messages.; JMS consumer: A JMS client that receives messages.; JMS message: An object that contains the data being transferred between JMS clients.; JMS queue: A staging area that contains messages that have been sent and are waiting to be read. As the name "queue" suggests, the messages are delivered in the order sent. A message is removed from the queue once it has been read.; JMS topic: A distribution mechanism for publishing messages that are delivered to multiple subscribers.

Models

The JMS API supports two models:
* point-to-point or queuing model
* publish and subscribe model

In the point-to-point or queuing model, a "producer" posts messages to a particular queue and a "consumer" reads messages from the queue. Here, the producer knows the destination of the message and posts the message directly to the consumer's queue. It is characterized by the following:
* Only one consumer will get the message
* The producer does not have to be running at the time the consumer consumes the message, nor does the consumer need to be running at the time the message is sent
* Every message successfully processed is acknowledged by the consumer

The publish/subscribe model supports publishing messages to a particular message topic. "Subscribers" may register interest in receiving messages on a particular message topic. In this model, neither the "publisher" nor the subscriber know about each other. A good metaphor for it is anonymous bulletin board. The following are characteristics of this model:
* Multiple consumers can get the message
* There is a timing dependency between publishers and subscribers. The publisher has to create a subscription in order for clients to be able to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected will be redistributed whenever it reconnects.

Using Java, JMS provides a way of separating the application from the transport layer of providing data. The same Java classes can be used to communicate with different JMS providers by using the JNDI information for the desired provider. The classes first use a "connection factory" to connect to the queue or topic, and then use populate and send or publish the messages. On the receiving side, the clients then receive or subscribe to the messages.

Application programming interface

The JMS API is provided in the Java package Javadoc:EE|package=javax.jms|javax/jms.

Javadoc:EE|javax/jms|ConnectionFactory interface

An administered object that a client uses to create a connection to the JMS provider. JMS clients access the connection factory through portable interfaces so the code does not need to be changed if the underlying implementation changes. Administrators configure the connection factory in the Java Naming and Directory Interface (JNDI) namespace so that JMS clients can look them up. In version 1.0, Depending on the type of message, users will use either a queue connection factory or topic connection factory. In version JMS version 1.1 these factories are merged into a single factory

Javadoc:EE|javax/jms|Connection interface

Once a connection factory is obtained, a connection to a JMS provider can be created. A connection represents a communication link between the application and the messaging server. Depending on the connection type, connections allow users to create sessions for sending and receiving messages from a queue or topic.

Javadoc:EE|javax/jms|Destination interface

An administered object that encapsulates the identity of a message destination, which is where messages are delivered and consumed. It is either a queue or a topic. The JMS administrator creates these objects, and users discover them using JNDI. Like the connection factory, the administrator can create two types of destinations: queues for Point-to-Point and topics for Publish/Subscribe.

Javadoc:EE|javax/jms|MessageConsumer interface

An object created by a session. It receives messages sent to a destination. The consumer can receive messages synchronously (blocking) or asynchronously (non-blocking) for both queue and topic-type messaging.

Javadoc:EE|javax/jms|MessageProducer interface

An object created by a session that sends messages to a destination. The user can create a sender to a specific destination or create a generic sender that specifies the destination at the time the message is sent.

Javadoc:EE|javax/jms|Message interface

An object that is sent between consumers and producers; that is, from one application to another. A message has three main parts:
# A message header (required): Contains operational settings to identify and route messages
# A set of message properties (optional): Contains additional properties to support compatibility with other providers or users. It can be used to create custom fields or filters (selectors).
# A message body (optional): Allows users to create five types of messages (text message, map message, bytes message, stream message, and object message).

The message interface is extremely flexible and provides numerous ways to customize the contents of a message.

Javadoc:EE|javax/jms|Session interface

Represents a single-threaded context for sending and receiving messages. A session is single-threaded so that messages are serialized, meaning that messages are received one-by-one in the order sent. The benefit of a session is that it supports transactions. If the user selects transaction support, the session context holds a group of messages until the transaction is committed, then delivers the messages. Before committing the transaction, the user can cancel the messages using a rollback operation. A session allows users to create message producers to send messages, and message consumers to receive messages. [http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html]

Provider implementations

In order to use JMS, one must have a JMS provider that can manage the sessions and queues. There are free, open source and proprietary providers.

Open Source Providers

Articles about open source providers:
* Apache ActiveMQ
* FUSE Message Broker (enterprise ActiveMQ)
* OpenJMS from The OpenJMS Group
* JBoss Messaging from JBoss
* JORAM, from Objectweb
* Sun Java System Message Queue, from Sun Microsystems

Proprietary Providers

Articles about proprietary providers:
* Synchrony Messaging from Axway
* BEA Weblogic, part of the Oracle Fusion Middleware suite
* Oracle AQ
* SAP NetWeaver WebAS Java JMS from SAP AG
* 3260 Content Router from Solace Systems
* SonicMQ from Progress Software
* TIBCO Software
* webMethods Broker Server from webMethods
* WebSphere Application Server from IBM
* WebSphere MQ from IBM (formerly MQSeries)

An exhaustive comparison matrix of JMS providers is available at: http://www.theserverside.com/reviews/matrix.tss (out of date)

All Java EE application servers from version 1.4 and later are required to contain a JMS provider. This can be implemented using the message inflow management of the Java EE Connector Architecture, which was first made available in version 1.4.

External links

* [http://java.sun.com/products/jms/ Sun's JMS Overview]
* [http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html Sun's JMS Tutorial]
* [http://genericjmsra.dev.java.net Generic Resource Adapter for JMS]
* [http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp/]

ee also

* Enterprise Integration Patterns - a book about using messaging, such as JMS, to integrate applications

Other types of messaging technologies, which do not implement the JMS API:
* Amazon Simple Queue Service - commoditized messaging service provided by Amazon.com for a per-use fee. It allows users to rent access to messaging without having to maintain their own server.
* Microsoft Message Queuing - similar technology, implemented for .NET Framework