Package javax.jms

The Java Message Service (JMS) API provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages.

See: Description

Package javax.jms Description

The Java Message Service (JMS) API provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages.

JMS Applications

A JMS application is composed of the following parts:

Administration

JMS providers differ significantly in their implementations of underlying messaging technology. There are also major differences in how a JMS provider's system is installed and administered.

For JMS clients to be portable, they must be isolated from these proprietary aspects of a provider. This is done by defining JMS administered objects that are created and customized by a provider's administrator and later used by clients. The client uses them through JMS interfaces that are portable. The administrator creates them using provider-specific facilities.

There are two types of JMS administered objects:

Administered objects are placed in a Java Naming and Directory InterfaceTM (JNDI) namespace by an administrator. A JMS client typically notes in its documentation the JMS administered objects it requires and how the JNDI names of these objects should be provided to it.

Two Messaging Styles

The JMS specification defines two styles of messaging: the point-to-point (PTP) or the publish-and-subscribe (Pub/Sub). These styles can be combined in a single application, or a given application can use just one of these styles.

The JMS API defines these two styles because they represent two of the dominant approaches to messaging currently in use. While the domains have many similarities, they also have some differences. JMS provides a unified programming interface to allow the client programmer to easily send and receive message using either domain, but the client programmer must also be aware of the differences between the domains. The key differences relate to how message persistence is handled, and the meaning of certain message attributes.

JMS Interfaces

When programming an application client, the programmer may either program using the domain specific interfaces, or may use the common interfaces. The key interfaces are listed in the table below. The preferred model is to use the common interfaces. The advantage to using the common interfaces is that both point-to-point and pub/sub tasks can be combined in one session, allowing transactions to operate over both domains.

In earlier versions of JMS, there were separate class hierarchies for the pub/sub and point-to-point programming models that had to be used. These class hierarchies are retained to support backward compatibility with earlier versions of the JMS API, but client developers are encouraged to use the common interfaces.

Relationship of PTP and Pub/Sub interfaces
JMS Common PTP Domain Pub/Sub Domain
ConnectionFactory QueueConnectionFactory TopicConnectionFactory
Connection QueueConnection TopicConnection
Destination Queue Topic
Session QueueSession TopicSession
MessageProducer QueueSender TopicPublisher
MessageConsumer QueueReceiver TopicSubscriber

The following provides a brief definition of these JMS concepts. See the PTP and Pub/Sub chapters of the JMS specification for more information.

The term consume is used in this document to mean the receipt of a message by a JMS client; that is, a JMS provider has received a message and has given it to its client. Since the JMS API supports both synchronous and asynchronous receipt of messages, the term consume is used when there is no need to make a distinction between them.

The term produce is used as the most general term for sending a message. It means giving a message to a JMS provider for delivery to a destination.

Developing a JMS Application

Broadly speaking, a JMS application is one or more JMS clients that exchange messages. The application may also involve non-JMS clients; however, these clients use the JMS provider's native API in place of the JMS API.

A JMS application can be architected and deployed as a unit. In many cases, JMS clients are added incrementally to an existing application.

The message definitions used by an application may originate with JMS, or they may have been defined by the non-JMS part of the application.

Developing a JMS Client

A typical JMS client executes the following setup procedure:

At this point a client has the basic setup needed to produce and consume messages.

Package Specification

Java Message Service Specification - Version 1.1

Related Documentation

Java Message Service Tutorial

Copyright © 2013. All Rights Reserved.