Java Magazine - January/February 2012

LISTING 11 LISTING 12 LISTING 13 LISTING 14

tor parameter, and it can be used easily for the selection of the desired message type (see Listing 11).

This behavior is identical to a message processed by a message-driven bean bound to a javax.jms.Destination.

Synchronous or Asynchronous

CDI events are delivered synchronously. The sender has to wait until the listener method completes. A RuntimeException inside the message body is propagated to the message sender. If the message sender is an EJB 3. 1 bean (or at least in the invocation call stack), the transaction is automatically rolled back. This is convenient in cases where the sender would like to be decoupled from the listener but perform multiple tasks in one transaction consistently. Documenting the state of the business process by writing audits to a database with CDI events is an example of synchronous, transactional events.

Delivering events asynchronously is the natural way of publish-subscribe communication. The sender does not need to block until the event is delivered and processed. Also, JMS works asynchronously.

Events can be asynchronously consumed with a no-interface EJB 3. 1 bean. You need to declare only the message listener as a @Stateless session bean and an @Asynchronous method. Listing 13 shows asynchronous event consumption in an EJB 3. 1 bean.

The @Asynchronous annotation also changes the transactional behavior. The method onImportantMessage is executed in a new, independent transaction. An exception thrown in the @Asynchronous onImportantMessage method will not cause the transaction initiated in the MessageBroadcaster EJB bean to roll back.

When Lightweight Is Not Enough

Asynchronous CDI events are similar to JMS topics without the availability of durable subscribers. Messages are stored persistently for a durable subscriber while it is inactive. On the next sign-in, all messages are redelivered to the subscriber.

A CDI event can be cached transiently in the thread pool’s queue, and it can get lost after an application server crash or a transaction rollback caused, for example, by RuntimeException. Neither CDI nor @Asynchronous EJB 3. 1 beans offer durable subscribers out of the box.

Also, event redelivery is not available in CDI. In contrast to JMS, the repetition of a failed transaction needs to be implemented by the application, not the infrastructure.

Although a JMS publish-subscribe implementation is more powerful and flexible, it also requires that significantly more code be written. For the implementation of an Observer pattern, CDI is well suited. Events are usually transient and do not require persistence or redelivery. A local CDI event distribution can be implemented with a fraction of the code required for adequate JMS functionality.

@Stateless
public class MessageBroadcaster {
@Inject
Event<String> event;
public void broadcast(String message){
}

JAVA IN ACTION

See all listings as text

replace JMS with CDI eventing, there is only a small overlap between JMS and CDI. Only JMS provides you with “once and only once” delivery semantics. To meet the “once and only once” delivery quality you have to set up a persistent (backed by a database) queue. In the “sending” transaction, the message is persisted in the database first and delivered in subsequent transactions. Also in a publish-subscribe scenario the messages can be stored on the server during the subscriber’s offline periods.

Neither use case above can be implemented with CDI events. CDI events are not persistent and would require you to implement “once and only once” delivery and, thus, to reinvent the wheel.

The old JMS specification is planned to
be completely refurbished and shipped
with Java EE 7. The main goals of JMS 2.0
will be simplicity and tight integration
with the Java EE 7 specifications, espe-
cially with CDI. Listing 14 shows a pre-
view of JMS 2.0 (this could change at any
time) that is as lightweight as CDI.

ABOUT US

Real Messaging and JMS Strikes Back CDI eventing with the EJB 3. 1 bean @Asynchronous combination makes the Service Activator pattern obsolete. Although it looks tempting to entirely