Business Logic in EJB3 SessionBean?

[Srikanth Nittala]

Hi,
Mine is a classic JEE application with this flow ( JSF + EJB + Oracle) on OC4J.

In the EJB3 books and Sun's JEE5 tutorial i ve read so far, they always have an EJB ( Session bean) thats filled with business logic and calls to DB via Entity Manager(injecting it) .
But is it a good practice to have business logic and DB calls in EJB that way? Now if you add service class(using Spring) or an DAO ( that does DB calls for each entity) you lose the power of injections and container-managed Entity managers. And I dont see the use of Spring services here as i think it is an overhead code for a simple flows like CRUD.
So in short i guess my question is " Is it ok to have all the business logic in session facade EJB itself? Isnt the facade EJB supposed to be neat and clean just doing security and transactions? What are the best practices for JEE architecture?

Opinions please.

Thanks.

[Amit M Tank]

I were to use EJB3 Session Bean, I will not use Spring. I will rather have a session facade which calls other Session EJBs(or Service Class) which inturn calls EntityBeans/DAO.

[Aurelio Calegari]

Originally posted by Srikanth Nittala:
Mine is a classic JEE application with this flow ( JSF + EJB + Oracle) on OC4J.

That's a robust environment. Also consider using JPA over Toplink. Is it OC4J 10g 10.1.3.3? Be aware there are a few bugs on OC4J in regard of EJB3, but nothing that would compromise the application.

Originally posted by Srikanth Nittala:
In the EJB3 books and Sun's JEE5 tutorial i ve read so far, they always have an EJB ( Session bean) thats filled with business logic and calls to DB via Entity Manager(injecting it) .
But is it a good practice to have business logic and DB calls in EJB that way? Now if you add service class(using Spring) or an DAO ( that does DB calls for each entity) you lose the power of injections and container-managed Entity managers. And I dont see the use of Spring services here as i think it is an overhead code for a simple flows like CRUD.
So in short i guess my question is " Is it ok to have all the business logic in session facade EJB itself? Isnt the facade EJB supposed to be neat and clean just doing security and transactions? What are the best practices for JEE architecture?

It's not good practice to keep business logic withing EJB. Regarding where to place the business logic, I would recommend you to place them in POJOs realizing, thus, the Application Service J2EE pattern. EJB is a thin application layer. EJB is rather a way to expose services to the outside world. You may inject the EntityManager within EJB and pass it as an argument of the Application Service POJO. Take a look at the J2EE Core Patterns 2nd Ed. Study the Application Service Pattern.

You don't need DAOs if you're using App Service + JPA, because JPA is itself a domain store. You may want to use DAOs when you're encapsulating access to legacy systems either through using raw JDBC directly or emulating a screen scraper. You may want to combine App Service + JPA for trivial stuff and App Service + DAO to run stored procedures, for example.

Don't forget to set up TWO connection pools. One for the JPA other for the DAOs itself.

Regards

[Srikanth Nittala]

Thanks for the inputs. I like your suggestion of injecting Entity Manger into the EJB session bean and passing it into the service class. That way i would get to use the container managed EM. A slight modification of this design is that I read in the book 'EJB3 in Action' that have a DAO as Session beans and inject entity beans into them. So then we have EJB3(Facade) + Service(Business logic) + DAO(Stateless Session bean with entity manager injected). This has also the separation of layers plus does not take away the EM injection facility.

[Brick Riccardi]

Originally posted by Aurelio Calegari:


You don't need DAOs if you're using App Service + JPA, because JPA is itself a domain store. You may want to use DAOs when you're encapsulating access to legacy systems either through using raw JDBC directly or emulating a screen scraper. You may want to combine App Service + JPA for trivial stuff and App Service + DAO to run stored procedures, for example.

I'm confused what you mean by this. Why wouldn't one also want a service class and a dao to abstract away all the jpa query stuff?

For example, if returning an employee doesn't it make sense to have:

EmployeeService  {
    public Employee getEmployee(int id) {
        return employeeDAO.getEmployee():
    }
}
 
EmployeeDAO { 
    @PersistenceContext 
    protected EntityManager em;  
 
    public Employee getEmployee(int id) {
        Query query = em.createNamedQuery("Employee.findByEmployeeID");
        query.setParameter("id", id); 
        return (Employee)query.getSingleResult();
    }
}

(above shortened and not real code, but you get the idea)

This way you can do other stuff in your Employee service class, like maybe you want to do some transformation of the Employee to XML. Why would you want to tie up all the JPA specific logic inside of a service class? If the dao that gets an Employee is separate you can use it in other places as well. Although maybe my use of the DAO is the same idea as your use of a Service class? (where my Service class would be a different type of service class in your scenario?)

[Reza Rahman]

Srikanth,

The answer to this question really depends on you. EJB 3 (unlike EJB 2) will not force an architecture on you.

Indeed, according to many prominent Java EE luminaries like Gavin King and Adam Bien, the simple EJB 3 session bean/JPA architecture is perfectly acceptable. Take a look here: http://www.infoq.com/news/2007/09/jpa-dao.

As we mention in the book, it is not a great sin and a shame to put business logic in session beans since they are merely POJOs and are perfectly suitable as service objects. EJB 3 POJOs are equally suitable as DAOs. As we also discuss in the book, it is perfectly acceptable to put business logic in JPA entities, as per Domain-Driven Design: http://domaindrivendesign.org. As I mentioned in a recent presentation, there is also nothing wrong with using EJB 3 with Spring if that's what you see as useful: http://www.ctjava.org/camp2008/sessionB.jsf?cid=465. It is *very easy* to integrate EJB 3 with Spring.

The bottom line is that there is no reason to confine yourself to the outdated "J2EE Design Patterns" mentality. EJB 3 certainly does not encourage or discourage any particular architecture.

I personally prefer the simple EJB 3 session bean and JPA based model without any more "code bloat", much like Adam Bien and Gavin advocate. Clean, lean and agile, just like Ruby on Rails :-).

Cheers,
Reza
[ November 01, 2008: Message edited by: Reza Rahman ]

[frank meng]

I personally prefer to have an application service layer (pojo) aggregating most of business logic, if the business logic is not trivial.

However, the EntityManager cannot simply be injected to the pojo classes in EJB3, and I don't think passing an instance of EntityManager is an elegant idea either, because that way pojos are tied to the container.

Is there any other options?

[Reza Rahman]

Frank,

You can use Seam to inject an entity manager into a Seam POJO component that's not an EJB (does not have transactions, thread-safety, pooling, etc).

Regards,
Reza

[frank meng]

Reza,

Good to know.

Thanks,
Frank