Saturday, February 26, 2005

Message Driven Beans(MDB) - When should I use them?

J2EE introduced Message Driven Beans (or MDBs for short) a few years ago to provide garanteed delivery and asynchronous processing capability while providing all of the benefits of an Enterprise Beans. The intended benefits include:
  • Standard APIs to post and retrieve messages
  • Guaranteed delivery of messages
  • The ability to use alternate providers (undelying implementation of the messaging engine)
  • EJB benefits (Transactions, Security, Persistence, etc..)


JMS, itself a Java standard library has traditionally been used to post messages to a queue. JMS, like Java, is platform independent, relying on the provider (actual implementation) to deal with platform specifics as necessary. Although your organization may have such tools as IBM MQ Series, a robust commercial queueing and messaging system supporting many programming languages, you would usually use MQ via JMS bindings in a Java program. This gives you more flexibility to choose alternate providers in the future should you so decide. This also means that you can use MDBs to read messages off of the queue.

MDBs act on behalf of the sever, not the client

Client applications can be java applications, applets, servlets, or even other EJBs acting in response of a client request. These client applications are responsible for:

  • Creating the message
  • Performing a lookup of the queue (or Topic)
  • Posting the message on the queue

Your MDB is then notified by the underlying messaging provider through the EJB container (you don't care about the provider). The MDB reacts through it's implementation of the onMessage method. Like other EJBs, much of the information available through container supplied context objects let you get additional information.

Security Context vs. MDBs

One problem with using MDBs is that the J2EE specification doesn't specify how to handle the security context. If you were using a Session or Entity Bean, having the propagated EJB context include the security context means that you could get information about the caller and his security role, etc.. This makes sense in the case of Session Beans and Entity Beans, as it is usually the case that these types of beans are running as a result of an on-going conversation between a client (whose credentials have been authenticated) and the server (which has been able to identify the security roles and permissions as defined in descriptors and can then propagate through context objects). MDBs are by nature, asynchronous. Although it is possible that a client is actively engaged in conversation with the server, it may also be the case that messages have been queueing up for a while (e.g.: while a ressource such as a DB is down) and that it is processing messages from a large number of sources. Queuing up credentials in the messages or similar metadata in the queue would cause other kinds of problems. These would be needed for security context propagation, but the cost would be a need to secure the queue. These issues were not resolved as a part of the J2EE specification and as a result, are not handled well in most current day implementations (e.g.: IBM WebSphere). Designers and architects have to find alternate ways to deal with security when using MDBs.