Integrating JMS with EJB

JMS-EJB integration is a compelling idea. It would allow EJB components to benefit from the value proposition of messaging, such as non-blocking clients and multinary communications.

To understand the motivations behind introducing a completely different type of bean to consume messages in an EJB application, let us contemplate for a moment what other approaches could we have taken and whether they would have worked:

• Using a Java object that receives JMS messages to call EJB components. Rather than coming up with a whole new type of bean, the Java community could have promoted the idea of a Java object that can receive messages and in turn call the appropriate EJB components, such as session beans and entity beans. The problems with this approach are as follows:

  • You'd need to write special code to register yourself as a listener for JMS messages. This is a decent amount of code (as we demonstrated previously).

  • To increase the throughput of message consumption, you would have to write the multithreading logic such that you can listen to the messages on multiple threads. However, writing multithreaded applications is not a trivial task for a business application developer.

  • Your Java object that listens to messages would need some way of starting up, since it wrapped your other EJB components. If the class ran within the container, you would need to use an EJB server-specific startup class to activate your Java object when the EJB server came up. This is not portable because EJB specification does not define a standard way of activating a given logic.

  • Your plain Java object wouldn't receive any services from an EJB container, such as automatic life cycle management, clustering, pooling, and transactions. You would need to hard-code this yourself, which is difficult and error-prone.

  • You would need to hard-code the JMS destination name in your Java object. This hurts reusability, because you couldn't reuse that Java object with other destinations. If you get the destination information from a disk (such as with property files), this is a bit clunky.

• Reuse an existing type of EJB component somehow to receive JMS messages. Another option could have been to shoehorn session beans or entity beans into receiving JMS messages. Problems with this approach include:

  • Threading. If a message arrives for a bean while it's processing other requests, how can it take that message, given that EJB does not allow components to be multithreaded?

  • Life cycle management. If a JMS message arrives and there are no beans, how does the container know to create a bean

courtesy: Mastering EJB, Third Edition, Ed Roman