Should Message Driven Bean Business Logic be delegated to EJB session bean

Question

I have been asked to investigate some of our MDBs and where applicable move logic to an EJB. My question is does it matter if all the logic is in the OnMessage method or should this call an EJB method. The current logic does not need to be called directly so there is no need to make it accessible via an EJB. Would the MDB calling the EJB have any benefits?

Answer 1

An MDB can contain references to another EJB, JMS connection resources and any other datasource or database connection resources. Other than that it should not hold any state (like a stateless bean not holding client state). MDBs are not accessed directly by clients, and no interface gets exposed, mdbs listen for messages asynchronously from clients.

So, check if the MDB instances retain any data or conversational state for a specific client. Generally container should be able to assign a message to any one of the mdbs and also pool the instances, such that streams of messages from multiple clients can be processed concurrently. So separating concerns, as for any other class will have its benefit here as well, MDB should do what it is intended to do, move the business logic related to message handling to another EJB instance (if the contianer services are required).

The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

see wiki Separation of concerns. Separate class need be an ejb if u require the container services like transaction.

Answer 2

The primary benefit of moving your logic to an EJB is that this will give you additional control over transaction boundaries.

As MDBs are inherently transactional, failures can result in a rollback followed by the message being re-delivered. Sometimes this is exactly the behaviour you want, but not often.

If you configure the service method on your EJB so that it starts a new transaction (REQUIRES_NEW) then any errors will result in a rollback of the EJB's transaction, but not that of the MDB.

The onMessage method can then take whatever action is required to recover (or not) within it's still intact transaction.

Answer 3

There is a difference between MDB and and EJB bean. MDB is basically used for asynchronous processing where some system puts a message on the Queue and then Application server picks up an instance of MDB from the pool and process that message. In case of EJB, its a synchronous call where client has to wait for the Application Server to respond.

So if you want to move your login into MDBs then check if the Asynhronous work which that MDB was doing is needed or not at all.

And instead of moving logic to EJB and calling that EJB , you can create an internal service class which will have the business logic and use this service from both the MDB and EJB implementation method. So whichever way client wants it (asynchronous/synchronous), you can serve the same business logic.