nterprise messaging has become an increasingly important component of loosely coupled, reliable enterprise frameworks. This is due in large part to the proliferation of enterprise applications (CRM, ERP, SCM, etc.) and disparate enterprise resources (RDBMS/OODBMS, legacy data store, data warehouse, XML/flat file repository, etc.), and the increasing need to integrate these applications into cohesive systems.
Enterprise Java Beans have served as a solution for this new messaging paradigm. The Enterprise Java Beans 2.0 specification defines a new type of enterprise bean to complement the four types of Enterprise Java Beans (EJBs) currently available (two session types and two entity types). The new bean type, Message-Driven Beans (MDBs), provides a reusable J2EE messaging component that can leverage existing investments in J2EE application servers, specifically EJBs.
This second article in a two-part series examining the messaging options available to EJB developers explores Message-Driven Beans. (The first explored the Java Message Service and JavaMail APIs as enterprise resources.)
Author’s Note: This 10-Minute Solution is intermediate to advanced. It requires a fundamental knowledge of several Enterprise Java APIs, including EJB, JMS, JavaMail, and JNDI. 
What are Message-Driven Beans and how do they compare with the other EJB messaging components? 
EJB 2.0 Message-Driven Beans are a new bean type. They provide a reusable J2EE messaging component that can leverage existing investments in J2EE application servers, specifically EJBs. They can offer a more robust and scalable enterprise messaging solution.
MDBs: EJB and JMS Interfaces in One
Message-Driven Beans do not follow the typical pattern for EJB interface implementation, because an MDB is a cross between a stateless session EJB and a JMS client. Rather than defining EJB component interfaces, MDBs implement two interfaces: one is an EJB interface and the other is a JMS interface. The following code is a sample of an MDB class signature:
public class MessageBean implements MessageDrivenBean,
MessageListenerThe first interface, javax.ejb.MessageDrivenBean, is the bean’s interface to the container. It allows the EJB container to manage the MDB, just as the container manages session and entity beans. The second interface, javax.jms.MessageListener, allows the bean to register with a JMS-enabled MOM (messaging-oriented middleware) server as a JMS listener.
As full-fledged JMS clients, MDBs can both send and receive messages asynchronously via a MOM server. As enterprise beans, MDBs are managed by the container and declaratively configured by an EJB deployment descriptor:
MyMessageBean com.gabhart.ejb.messaging.MessageBean Container javax.jms.Queue … …. All of these element names should look familiar except for two:
When an EJB application server starts, it parses the deployment descriptors and then loads and initializes the declared beans. In the case of a message bean, the container establishes a connection with the messaging provider (MOM server). Clients access message beans through the bean’s JMS interface (javax.jms.MessageListener), which exposes a single method:
public void onMessage(javax.jms.Message message)The JMS specification defines this interface as a standard interface for listening on a JMS destination. This allows the bean to asynchronously receive JMS messages published to the destination (topic or queue) with which this bean has registered. In this way, the message bean functions as a full-fledged JMS client, indistinguishable from any other JMS client.
When a message arrives, the container ensures that a message bean corresponding to the message topic/queue exists (instantiating it if necessary) and calls its
onMessage() method passing the client’s message as the single argument into the method.
In addition to functioning as asynchronous JMS clients, message beans also support message concurrency. Since message beans are stateless and managed by the container, they can both send and receive messages concurrently (the container simply grabs another bean out of the pool). This, combined with the inherent scalability of EJB application servers, produces a very robust and scalable enterprise messaging solution.
MDBs vs. JMS vs. JavaMail for EJB Messaging
So how do message-driven beans stack up against other EJB messaging options? It depends upon what your architecture requires. Below are a sampling of architectural requirements and the appropriate EJB messaging component (MDB, JMS Resource, JavaMail Resource) to meet that requirement:
The above list represents only a handful of the architectural possibilities and various considerations when selecting an appropriate EJB messaging component. In practice, you will often find yourself using a combination of these components to arrive at a particular messaging solution.
Messaging Provides Abstraction Layer
Enterprise messaging is a powerful tool that lends tremendous flexibility and reliability to any enterprise architecture. In our world of increasingly disparate components and backend systems, messaging provides a clean abstraction layer that affords the right balance between system coupling and effective system communication.
