8.7. Key Point Summary

This chapter shows you how to design message-driven beans with the Java Message Service (JMS). In enterprise systems, message-driven beans communicate with other objects asynchronously (no waiting). Designs with message beans are scalable because message beans are stateless. The container uses instance pooling to handle a large number of messages concurrently.

Here are the key points from this chapter.

• In a synchronous architecture, clients are tightly coupled with each other. A client's thread blocks until a method completes. Adding or removing clients is difficult.

• In an asynchronous architecture, clients are loosely coupled and communicate through a centralized server. Method calls return without blocking. Adding or removing clients is easy.

• Centralized message servers can implement a store-and-forward mechanism to guarantee delivery of data to clients that are temporarily unavailable.

• JMS is a vendor-independent API that can be used on the J2EE platform for enterprise messaging.

• A JMS client that generates a message is a producer, and a JMS client that receives a message is a consumer.

• With JMS, a client producer sends a message asynchronously to a topic or queue destination.

• JMS has two messaging domains: publish/subscribe (pub/sub) and point-to-point (PTP). Pub/sub messaging is a one-to-many broadcast and PTP is a one-to-one communication. Pub/sub uses topic destinations, whereas PTP uses queues.

• Message delivery to one receiver is guaranteed for queues. With topics and multiple subscribers, you must be a durable subscriber to guarantee message delivery.

• Message-driven beans combine the features of EJB and JMS. The container deploys a message bean as a JMS consumer.

• Message-driven beans are stateless and highly scalable. They can forward tasks to other beans or model business processes.

• Every message-driven bean has an onMessage() method which receives messages from topic or queue destinations.

• The life cycle of a message-driven bean alternates between two states. The container does not activate or passivate a message-driven bean because it is stateless.

• Message-driven beans do not have interfaces for direct client access. Because there is no client, application exceptions are not allowed in message-driven beans. The only exception that may be thrown from a message-driven bean is a system exception (which the container receives).

• The SchoolApp client application is a JMS producer that uses pub/sub messaging to broadcast course topics to Student message beans. If a Student is interested in a course, the StudentBean uses PTP messaging to send a reply back to the SchoolApp client.

• The JMSReplyTo destination can be useful with message-driven beans for sending replies. It is also helpful for sending error messages.

• The container uses a message bean's deployment descriptor to generate code and configure the bean. In particular, making a bean a durable subscriber is specified in the deployment descriptor.

• The OrderApp client is a JMS producer that uses point-to-point messaging to send Calendar objects to a queue destination. The ShipOrder MDB is a JMS consumer and a registered listener for the queue destination. It implements the onMessage() method which invokes the CustomerSession EJB business method shipOrdersByDate() with a Calendar object as an argument.