6.1 JMS and Communication Modes

An integral part of the J2EE platform, JMS is a standard Java API that can be used across various types of enterprise messaging systems. A Java application uses the JMS API to connect to an enterprise messaging system. Once connected, the application through the API uses the facilities of the underlying messaging system to create messages and to communicate asynchronously with one or more peer applications.

6.1.1 Synchronous and Asynchronous Communication

Communication between applications or components can be either synchronous or asynchronous. Synchronous communication follows a request/response interaction model. A component sends a request to another component and then suspends, or blocks, its processing while it waits for the other component to act on the request and send its response. The component thread continues its processing only after it receives the response.

A synchronous request/response interaction model is typical for most remote function call based APIs, whereby the caller application or component invokes a function on another component. This communication is considered synchronous because the caller waits synchronously while the function executes on the other component. The caller thread continues only when the function returns.

Generally, for synchronous communication to work properly, the sender must have knowledge of both the receiver's availability and its methods. In particular, the sender must know the receiver's methods well enough to send its requests in the proper form. Such shared knowledge required between senders and receivers is considered tightly coupled communication. Synchronous communication results in tight coupling, or increased dependency, between applications and components, a situation that is not always desirable.

Asynchronous messaging, by contrast, is a loosely coupled distributed mode of communication that allows applications to communicate by exchanging messages in a way that leaves senders independent of receivers. The sender sends its message and does not have to wait for the receiver to receive or process that message. In addition, the communication mechanism itself is separate from the sending and receiving components. An application or component sends a request to a destination other than the receiving process, regardless of the receiver's availability. The recipient retrieves the request from this destination. The only requirement is that both processes know the message format and the intermediate destination.

Asynchronous messaging communication using JMS can be either queue-based communication or publish/subscribe messaging. Queue-based communication, also referred to as point-to-point messaging, entails sending messages to a message queue that is independent of both the sender and the receiver. The sender process sends a message to this message queue, and the receiver process receives its messages from the queue. The message queue acts as a message buffer between two communicating processes.

The publish/subscribe messaging mechanism enables a sender to broadcast its message to multiple receivers. Publish/subscribe messaging systems support an event-driven model whereby information producers and consumers participate in the message transmission. A publisher application publishes messages on a specific topic. Any number of applications, called subscribers, can subscribe to this topic and receive the messages published by the publisher. The publish/subscribe facility delivers the published messages to the subscribing applications, based on the subscribed topic. In other words, a publishing application publishes its message to a well-known node, called a topic, within a content-based hierarchy. You can think of a publish/subscribe system as a message broker that gathers and distributes messages. The topic serves as the intermediary between message publishers and message subscribers.

6.1.2 JMS Overview

JMS is a standard Java API that allows applications to send and receive messages asynchronously. JMS has been designed so that messaging systems vendors can easily integrate their products with the Java platform. A Java application uses the set of interfaces and semantics defined by the JMS API to connect to an enterprise messaging-oriented middleware (MOM) system. Once connected, the application, through the JMS API, can use the facilities of the underlying messaging system to create messages and to communicate asynchronously with one or more peer applications. JMS provides a consistent set of interfaces that its clients can use to send and receive messages independently of the underlying messaging system.

Because the JMS API is an integral part of the J2EE platform, any J2EE or Web component can synchronously send or receive a JMS message. By using a message-driven enterprise bean, a J2EE component can asynchronously consume JMS messages. Message sending and receiving can also be made part of a transaction. In addition, JMS providers may implement message-driven beans such that they process messages concurrently.

The JMS API architecture consists of the following:

• JMS provider The implementation of the JMS API for a messaging system. An application uses the JMS provider to access the services of the underlying messaging system.

• JMS client A Java application, either an application client or a J2EE component, that produces and consumes messages. A JMS client application uses the JMS API to access the messaging system's asynchronous messaging services. JMS supports peer-to-peer messaging, so both producer and consumer applications are clients of the JMS provider.

• JMS domain The type of asynchronous message-based communication supported by the JMS provider and messaging system. JMS supports two domain types: queue-based point-to-point messaging and publish/subscribe messaging. Applications use different JMS interfaces, depending on the domain.

• JMS message A JMS message consists of a header, properties, and a body. The message header identifies the message. For example, it might identify the type of subscriber that is interested in the message. The properties of a message are specific to an application and provider. They often provide further identification information. The message body is the content of the message. A message may be one of several formats. A TextMessage format contains only string data and is ideal for XML-based messages. An ObjectMessage format wraps a single arbitrary serializable Java object or a collection of such objects. (JMS supports additional formats to these commonly used formats.)

Clients use JMS to connect to the messaging system provider and send and receive messages. Clients create JMS sessions, or objects, which provide a context, or environment, to produce or receive messages. From within a session, a client can create a MessageProducer object to send messages and a MessageConsumer object to receive messages.

Refer to the section Other Sources of Information on page xviii for additional JMS references.