8.6. Design Guidelines and Patterns

Java Message Service (JMS)

JMS is an excellent solution for asynchronous data transfers in enterprise programming. JMS is appropriate with architectures requiring either a one-to-many broadcast (publish/subscribe), a point-to-point communication (PTP), or both. Because JMS is a centralized message server, JMS client components are loosely coupled.

Publish/Subscribe Pattern

The publish/subscribe pattern allows one client to broadcast information to multiple recipients. This pattern is an integral part of a JMS messaging domain. With message-driven beans, the EJB container uses the bean's deployment descriptor to subscribe the bean. Publishers and subscribers use topic destinations for messages.

Point-to-Point Pattern

The point-to-point (PTP) pattern allows a client producer to send a message to a single receiver. PTP is also part of the JMS messaging domain. As with publish/subscribe, the EJB container creates a receiver for you from the bean's deployment descriptor. Senders and receivers use queue destinations for messages.

Publish/Subscribe vs. Point-to-Point

One key difference between pub/sub and PTP is the number of receivers. pub/sub broadcasts messages to multiple message consumers. With PTP, a message is sent to only one receiver. Another key difference is the status of a receiver's connection. With PTP queues, a message consumer does not have to be currently connected to receive messages. With pub/sub topics, however, this is only true for durable subscribers.

Pub/sub delivers messages without subscribers requesting them. In our example where the school broadcasts course topics to students, the school doesn't really care if anyone is listening. From the publisher's standpoint, information is broadcast out to anyone who wants to listen. Pub/sub messaging is therefore a “push-based” model. This means you may consider using pub/sub messaging when it's not a strict requirement for information to be read. If it's important that a listener receive a message, make sure that the consumer is a durable subscriber.

With PTP, a message is always delivered to a receiver. When a message is sent, it doesn't matter if the receiver is connected or not. When the receiver reconnects, the message is received (assuming another receiver hasn't already read it from the same queue). PTP is therefore a “pull-based” model, meaning messages are requested from a queue instead of being pushed by the client. This means you should consider using PTP messaging with one-on-one communications, where it is important that the recipient receives your message.

Message-Driven Beans

Message-driven beans combine the features of EJB and JMS. Each bean has a deployment descriptor enabling the container to deploy a message bean as a JMS consumer. Message beans may receive messages from multiple producers but do not store conversational state, so in this respect they are similar to stateless session beans. Message beans, however, do not have direct clients, nor do they have a local or remote interface with business methods. Message beans are easy to implement and deploy because the container does most of the setup work. They are highly scalable and can respond to a large number of concurrent messages.

When to Use Message-Driven Beans

When designs require asynchronous data transfers, you should consider using a message-driven bean in your architecture. This approach decouples clients from EJBs and other programs, since clients only interact with a JMS server.

A message bean can use a topic with pub/sub messaging or a queue for PTP processing. Message beans are good candidates for off-loading tasks. Instead of having the client call a remote method of an EJB and wait for it to complete, you can have a message bean perform this task. Message beans, on the other hand, are limited to what they can do based on the fact that they are stateless. This is, however, their strong point, since message beans are highly scalable.

Transactions

One of the key advantages of using message-driven beans is that the onMessage() method can execute within a transaction. This allows the message-driven bean to invoke one or more methods from an entity or session bean within a single transaction. Because a message-driven bean executes under the auspices of the EJB container, we can use the services (such as transactional support) that the container provides.