Movatterモバイル変換

Basic JMS API Concepts

This section introduces the most basic JMS API concepts, the ones you mustknow to get started writing simple JMS client applications:

The next section introduces the JMS API programming model. Later sections cover moreadvanced concepts, including the ones you need to write Java EE applications thatuse message-driven beans.

JMS API Architecture

A JMS application is composed of the following parts.

AJMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features. An implementation of the Java EE platform includes a JMS provider.
JMS clients are the programs or components, written in the Java programming language, that produce and consume messages. Any Java EE application component can act as a JMS client.
Messages are the objects that communicate information between JMS clients.
Administered objects are preconfigured JMS objects created by an administrator for the use of clients. The two kinds of JMS administered objects are destinations and connection factories, which are described inJMS Administered Objects.

Figure 31-2 illustrates the way these parts interact. Administrative tools allow you to binddestinations and connection factories into a JNDI namespace. A JMS client can thenuse resource injection to access the administered objects in the namespace and then establisha logical connection to the same objects through the JMS provider.

Figure 31-2 JMS API Architecture

Diagram of JMS API architecture, showing administrative tool, JMS client, JNDI namespace, and JMS provider

Messaging Domains

Before the JMS API existed, most messaging products supported either thepoint-to-point orthepublish/subscribe approach to messaging. The JMS specification provides a separate domain foreach approach and defines compliance for each domain. A stand-alone JMS provider canimplement one or both domains. A Java EE provider must implement both domains.

In fact, most implementations of the JMS API support both the point-to-point andthe publish/subscribe domains, and some JMS clients combine the use of both domainsin a single application. In this way, the JMS API has extended thepower and flexibility of messaging products.

The JMS 1.1 specification goes one step further: It provides common interfaces thatenable you to use the JMS API in a way that isnot specific to either domain. The following subsections describe the two messaging domains andthen describe the use of the common interfaces.

Point-to-Point Messaging Domain

A point-to-point (PTP) product or application is built on the concept of messagequeues, senders, and receivers. Each message is addressed to a specific queue, andreceiving clients extract messages from the queues established to hold their messages. Queuesretain all messages sent to them until the messages are consumed or untilthe messages expire.

PTP messaging has the following characteristics and is illustrated inFigure 31-3.

Figure 31-3 Point-to-Point Messaging

Diagram of point-to-point messaging, showing Client 1 sending a message to a queue, and Client 2 consuming and acknowledging the message

Each message has only one consumer.
A sender and a receiver of a message have no timing dependencies. The receiver can fetch the message whether or not it was running when the client sent the message.
The receiver acknowledges the successful processing of a message.

Use PTP messaging when every message you send must be processed successfully byone consumer.

Publish/Subscribe Messaging Domain

In a publish/subscribe (pub/sub) product or application, clients address messages to atopic,which functions somewhat like a bulletin board. Publishers and subscribers are generally anonymousand can dynamically publish or subscribe to the content hierarchy. The system takes careof distributing the messages arriving from a topic’s multiple publishers to its multiplesubscribers. Topics retain messages only as long as it takes to distribute themto current subscribers.

Pub/sub messaging has the following characteristics.

Each message can have multiple consumers.
Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.

The JMS API relaxes this timing dependency to some extent by allowing subscribersto createdurable subscriptions, which receive messages sent while the subscribers are not active.Durable subscriptions provide the flexibility and reliability of queues but still allow clients tosend messages to many recipients. For more information about durable subscriptions, seeCreating Durable Subscriptions.

Use pub/sub messaging when each message can be processed by zero, one, ormany consumers.Figure 31-4 illustrates pub/sub messaging.

Figure 31-4 Publish/Subscribe Messaging

Programming with the Common Interfaces

Version 1.1 of the JMS API allows you to use the samecode to send and receive messages under either the PTP or the pub/subdomain. The destinations that you use remain domain-specific, and the behavior of theapplication will depend in part on whether you are using a queue ora topic. However, the code itself can be common to both domains, makingyour applications flexible and reusable. This tutorial describes and illustrates these common interfaces.

Message Consumption

Messaging products are inherently asynchronous: There is no fundamental timing dependency between theproduction and the consumption of a message. However, the JMS specification uses thisterm in a more precise sense. Messages can be consumed in either oftwo ways:

Synchronously: A subscriber or a receiver explicitly fetches the message from the destination by calling thereceive method. Thereceive method can block until a message arrives or can time out if a message does not arrive within a specified time limit.
Asynchronously: A client can register amessage listener with a consumer. A message listener is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener’sonMessage method, which acts on the contents of the message.