J2EE design strategies recommend that all business logic exposed to EJB clients should be placed in Stateless Session Beans. See Wrap Entity Beans with Session Beans (http://www.theserverside.com/patterns/thread.jsp?thread_id=625) pattern for more information.
Message Driven Beans can be considered a variety of Stateless Session Beans and thus perform similar tasks. The difference can be argued lies in the Bean invocation. However, Object Oriented and J2EE design principles call for a clear separation of responsibilities between Message Driven and Stateless Session Beans. MDBs should serve as asynchronous message consumers. They should receive, process and parse the messages but should not perform any actual work. As discussed above, all the business logic should be located in Stateless Session Beans. MDBs should interact with specific methods from these Beans instead of implementing the functionality themselves. Note that MDBs should not interact directly with Entity Beans but rather allow Stateless Session Beans to do this as a part of a business logic method.
This technique strengthens and supports previously defined J2EE design patterns by containing business logic in one logical location. It also allows MDBs to become easier to implement and more lightweight and efficient by separating message parsing from business logic implementation.
2 replies in this thread
Reply
Message Driven Bean Strategy
Posted By: Gal Binyamini on December 8, 2001 in response to this message.
I think this pattern is very useful in certain situations, which are fairly easy to spot. However, I disagree with Leo about the scope of this pattern. Here is why:
"J2EE design strategies recommend that all business logic exposed to EJB clients should be placed in Stateless Session Beans. See Wrap Entity Beans with Session Beans".
First of all, the meaning of the term "business logic" depends on the context in which it is used. In the context of the pattern mentioned, it means logic that is called directly as a result of a client request (this is the only model in EJB1.1, for which the pattern was designed). This kind of business logic may be different from the "backend service logic" you might put in MDBs.
Second, this pattern was designed for EJB1.1, and MDBs were not an option. I don't think the pattern completely covers the new possibilities in EJB2.0 (e.g, MDBs).
I do not think MDBs and SLSBs perform logically equivalent tasks. IMO, The a fundanmental difference is in the context of the executed task. MDBs perform tasks in an independent context, while SLSBs perform the task in the same context (context meaning TX, security, etc).
The idea of seperating message consumption from logic is good OO thinking. However, I can't see any reason why this seperation should divide the two tasks into different phisycal layers (i.e, different containers). There are many design pattern that facilitate this seperation without this division (i.e, event-dispatch, command).
"This technique strengthens and supports previously defined J2EE design patterns by containing business logic in one logical location."
