Home > Articles > Programming > Java

Enterprise Messaging with the Java Message Service (JMS)

  • Print
  • + Share This
Learn the fundamentals of JMS in this sample chapter by Michael Girdley, Sandra Emerson, and Rob Woollen. They cover: JMS queuing mechanisms for point-to-point messaging, JMS topic creation for publish-and-subscribe messaging, how to configure JMS messages, JMS and transactions, how JMS works in a WebLogic Server cluster, JMS exception handling, and the best practices for using JMS in WebLogic Server applications.
This sample chapter is excerpted from J2EE Applications and BEA WebLogic Server, by Michael Girdley, Sandra Emerson, and Rob Woollen.
This chapter is from the book

The Java Message Service (JMS) provides a standard enterprise messaging service for Java 2 Enterprise Edition (J2EE) applications. JMS acts as an intelligent switchboard for routing messages among application components and processes in a distributed application. JMS queues messages and can deliver them asynchronously: Messaging need not take place in real time; and messages can be sent and consumed at different times.

Benefits of JMS

There are a number of reasons to use a messaging system for interprocess communication instead of making direct method calls. A messaging system provides a clean way to connect disparate systems within an application. Messaging systems also help divide long-running work into multiple transactions for greater efficiency. When communication is asynchronous, the client need not wait for all of the processing to complete.

Messaging systems also provide reliability. JMS can optionally save a message to a persistent store. There is, however, a trade-off between reliability and performance. The messaging system runs faster if messages are not persistent, but the application must tolerate lost messages in the event of a server crash. Messaging systems also enable clients to disconnect and reconnect to the server without losing work. JMS can be configured to save messages while the client is disconnected and deliver them once the client has reconnected. Unlike method calls on a single object, JMS allows sending a single message to many recipients.

Interprocess Communication

Most large systems are divided into several separate functional units. JMS provides reliable communication between these separate processes. For instance, an e-commerce application might include a Web front-end for customer order entry. A warehouse then receives the order, packages the appropriate items, and forwards the order to the shipping department. Finally, the shipping department sends the package and updates the customer's account records.

JMS provides the communication backbone for workflow applications.

Point-to-Point Messaging

The order fulfillment application uses JMS's point-to-point (PTP) messaging model to provide reliable communication within this multi-stage application. In PTP communication, JMS delivers each message to a single message consumer. For instance, in this application, the Web front-end sends a message including the new order information. A single warehouse receives the message and processes the order. The message system guarantees that multiple warehouses do not fill the same order. This application also uses JMS's reliability guarantees. Because customer orders are important information that should be retained, the developer will request JMS to mark these messages as persistent. With persistent messages, JMS saves the message contents to a persistent storage such as a database or file store.

Publish/Subscribe Messaging

In addition to PTP communication, JMS provides a publish-and-subscribe messaging model. With publish/subscribe messaging (also known as pub/sub), a message is sent to a named topic. There might be multiple message listeners subscribed to each topic. The JMS subsystem delivers a copy of the message to each of the topic's subscribers. For instance, an e-commerce site might define a frequent-customer topic. When a customer makes several purchases, a message is sent to this topic. The site can then send "special deals" messages to a select group of listeners, the frequent customers. Because there might be several message listeners, each offering a separate special deal, it is appropriate to use pub/sub instead of PTP communication.

  • + Share This
  • 🔖 Save To Your Account