Getting Started with Enterprise JavaBeans™

G

Message-Driven Beans

Tutorial Home Section Home Previous Section Next

Get

Get

Overview

     Message-driven processing is a very effective, and often underused, technique for programs that do not need to operate directly in response to user requests (that is, batch rather than interactive type processing). For example, how can a program know that it should shut down gracefully, or automatically react to some other external event? Messaging is a good solution in these cases. It is also useful for processing that is not time critical, including some interactive applications. After all, why should a user wait for a process to complete when it doesn't matter if the task is done exactly at that moment? Many data entry tasks in which a set of data (debits/credits, invoices, or receipts, for instance) is entered, then reviewed, and finally posted, are appropriate examples. Messaging can also be useful for interprocess communication and systems integration using text or XML data, even when programs are written in different languages. From the messaging client's perspective, it just sends a message and immediately goes on to other tasks, relying on the message's receiver to perform operations against the message data.

     Message-driven beans (MDBs) are a new type of bean introduced with the EJB 2.0 specification. MDBs are stateless in terms of client-conversational state. They are used for asynchronous processing of Java Message Service (JMS) messages, and go into action upon the receipt of a client message, although they are not linked to any specific client. In fact, since the messages come from a queue or a topic, a single bean may act on behalf of many clients. In contrast to the other bean types, MDBs have no home or component interfaces, and are invoked by the container in response to the arrival of JMS messages. From the client view, an MDB is a message consumer that performs one or more tasks on the server, based on its interpretation of the message.

     Notice that MDBs are all about asynchronicity; session and entity beans could, and still can, process synchronous messages. Prior to the advent of message-driven beans, however, there was no real way that EJBs could process asynchronous messages; generally, an external application was necessary.


Figure MDB-1: The javax.ejb.MessageDrivenBean interface
Interface javax.ejb.MessageDrivenBean


     All message-driven beans must implement the javax.ejb.MessageDrivenBean interface shown in Figure MDB-1. An MDB's life cycle is very similar to that of stateless session beans (see Stateless Session Beans) in that they only have two states: Does Not Exist and Ready. The container is responsible for creating instances of MDBs before message delivery begins. To place an MDB in the Ready state, the container:

     At this point, the bean enters the method-ready pool and can be called upon to process messages. When the container no longer requires the bean, it calls the bean's ejbRemove() method. After this action, the bean is effectively destroyed and back to the Does Not Exist state.


Figure MDB-2:
The javax.jms.MessageListener interface
Interface javax.jms.MessageListener      Message-driven beans must also implement the javax.jms.MessageListener interface shown in Figure MDB-2. The interface consists of a just one callback method, onMessage(), which has a single javax.jms.Message input argument. The callback feature means that the the bean doesn't have to spend CPU cycles and time polling for messages, leading to more scalable and potentially higher performance applications. If you wondered why other bean types couldn't handle asynchronous messages, the reason is that the EJB 2.0 specification states that they are not "permitted" to implement MessageListener. This ban is not simply a specification mandate, several technical reasons exist for the restriction.

     onMessage() is really where all of the action occurs, but before discussing that method and message-driven beans further, an understanding of Java Message Service concepts, lingo, and basic operations is required. The next few panels briefly cover the necessary JMS background.



Tutorial Home Section Home Previous Section Next