Simple but good pattern for EJB

Question

What would you suggest as a good and practical but simple pattern for a solution with:

• HTML + JSP (as a view/presentation)
• Servlets (controller, request, session-handling)
• EJB (persistence, businesslogic)
• MySQL DB

And is it necessary to use an own layer of DAO for persistence? I use JPA to persist objects to my DB.

Should I withdraw business logic from my EJB? All online sources tell me different things and confuses me...

Answer 1

I would definitely put the business logic in Stateless Session Beans. Stateless session beans are nice as they nicely capture the transaction boundaries. And it decouples the View layer from the persistence layer.

Take care that the methods of the SSB correspond to small business goals the user wants to achieve.

Another point is that you must be sure that the data you return has all data in the object tree and that you do not rely on lazy loading to get the rest, because this causes all kind of problems.

Stay as far away as possible from Stateful Session Beans : they are bad news and are a broken concept in the context of a web application.

For long running things, consider using Message Driven Beans which you trigger by sending a JMS message. These are a nice way to do background processing which frees the business logic faster, keeps transactions shorter and returns control to the end user faster.

Answer 2

What would you suggest as a good and practical but simple pattern for a solution with JSP/Servlets + EJB + MySQL

Use the MVC framework of your choice, Stateless Session Beans for the business logic and transaction management (prefer local interfaces if you don't need remoting), Entities for persistence.

Inject your EJBs wherever possible (if you are using Java EE 6, this means anywhere and you can also skip the interface).

And is it necessary to use an own layer of DAO for persistence? I use JPA to persist objects to my DB.

Some might say yes, I say no in most cases. The EntityManager already implements the Domain Store pattern, there is no need to shield it behind a DAO for simple needs.

You might want to read the following resources for more opinions on this:

• Has JPA Killed the DAO?,
• JPA/EJB3 killed the DAO,
• and the more recent DAOs Aren't Dead - But They Either Collapsed Or Disappeared

Should I withdraw business logic from my EJB?

I wouldn't. Put your business logic in your (Stateless) Session Beans. EJB3 are POJOs, they are easily testable, there is no need to delegate the business logic to another layer.