When to Use Message-Driven Beans

J2EE, being a standard for distributed computing, makes cross-function business integration very easy. Using JNDI, J2EE applications can easily be found by one another and invoke each other's services, synchronously or asynchronously.

Synchronous interaction is easier and simpler to implement, but is more susceptible to potential failures. Network communication is an obvious source of problems. Different applications might operate in very different environments and at varied paces, and have their own problems that might or might not be visible to the developers of other applications that use them. For instance, a credit card processing application initiates an external service request across the Internet to verify credit card information before starting a transaction, waits for the response, and returns the success or failure status code to the caller. The caller then completes or aborts its own transaction based on the status. This process could easily take up to a few minutes. For an online Web application, users might experience long waits or even timeout problems. Another potential problem is that invocations could block. For instance, if the service agreement with the credit card processing service provider is single-threaded, only one processing can happen at a time. When multiple customers order books at the same time, they will be queued and the wait or time-out situation will be exacerbated.

Asynchronous interaction is more robust and reliable. Network communication poses little loss risk because a well-designed asynchronous framework is supposed to deliver the message sooner or later. Application discrepancy in pace is generally not an issue either (within a certain range, of course). Asynchronous interaction dictates a system design that's very different from its synchronous counterpart. Take the credit card processing case, for example. Suppose that the online store sells e-books. The original system specification would be that users place orders of books, submit credit card information, wait for the transaction to finish, and download the books. With an asynchronous design, instead of completing the whole transaction in a single shot, the system takes the order and credit card information and finishes with a thank-you page. A credit card processing request is placed, which will eventually return the status to the system. After the result has arrived, an email will be sent to the user, telling him to download the purchased books. This is a very common practice.

Asynchronous interactions are realized by messaging systems. The Java Message Service (JMS), a part of the J2EE standard, is a standard API for utilizing enterprise messaging systems. All J2EE-compliant middleware products are required to fully support the JMS specification; WebLogic is no exception. JMS is discussed extensively in Chapter 12, "Enterprise Messaging with JMS."

The EJB 2.0 specification introduces a new type of Enterprise JavaBean: the Message-Driven bean (or MDB, for short). This is a very welcome feature for asynchronous interaction with the J2EE framework. As we know, to receive and process a message, a JMS client has to take a few steps that involve obtaining the initial context, creating a connection and a session, looking for a JMS queue or topic, and waiting to receive a message. Expectedly, a JMS client runs in its own thread. Imagine that you're required to process any number of JMS messages at any time. You would probably do something very similar to what a servlet container would do: create a pool of JMS handlers, each running in its own thread; have a master listener to listen on a particular queue; for each received message, pick a handler from the pool; when the processing is complete, return the handler to the pool. You also need to device a mechanism to specify which JMS server to connect to, which JMS destinations to listen on, and so on. This is exactly what a Message-Driven bean container does. The container takes care of all the chores, such as listening for the incoming messages, security, concurrency, life cycle management, and so forth. The communication details are declared in the standard deployment descriptors. The developers of Message-Driven beans simply focus on the business logic.

How do Message-Driven beans differ from JMS session pools? They are essentially very similar, but MDBs can listen to only one destination, whereas session pools can subscribe to many. MDBs also provide automatic transaction management.