Read an Excerpt
Chapter 7: Enterprise Messaging with the Java Message Service (JMS)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 JMSThere 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 CommunicationMost 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 MessagingThe 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 MessagingIn 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.
JMS FundamentalsThe JMS specification defines both PTP and pub/sub APIs. A JMS Server can implement one or both of these APIs. The WebLogic Server's JMS implementation includes both the PTP and pub/sub APIs.
The JMS APIs define a set of fundamental objects. Each object is separately defined in the PTP and pub/sub domains, but their function is nearly identical in both domains.
Connection FactoriesConnection factories are created by the server administrator and bound into the Java Naming and Directory Interface (JNDI) tree. A JMS client uses JNDI to look up the ConnectionFactory and then uses the ConnectionFactory to establish a JMS connection. The PTP connection factory is javax.jms.QueueConnectionFactory while the pub/sub domain uses javax.jms.TopicConnectionFactory.
The WebLogic Server binds a standard connection factory with the name weblogic.jms.ConnectionFactory. It also is possible to define additional connection factories with the WebLogic Server's Administration Console. An application uses a user-defined ConnectionFactory if needed to impose additional security constraints on the ConnectionFactory.
ConnectionsA JMS connection represents the active connection between the JMS client and the WebLogic Server. The JMS client creates the JMS connection by calling the createQueueConnection or the createTopicConnec-tion methods on the ConnectionFactory. A JMS connection is a rela-tively heavyweight object and normally each client uses a single JMS connection. Each JMS connection can be associated with many JMS destina-tions. The PTP connection is javax.jms.QueueConnection while the pub/sub connection is javax.jms.TopicConnection.
SessionsThe JMS session represents a client's conversational state with a JMS Server. A session is created from the JMS connection, and it represents a single thread of conversation between a JMS client and server. Sessions define mes-sage ordering, and JMS uses sessions for transactional messaging. The PTP model uses javax.jms.QueueSession while the pub/sub model uses javax.jms.TopicSession.