Why EJB 3, vs Hibernate, etc.

The EJB 2.x have drawn some negative remarks. Some opted to Hibernate, etc.

What are the reasons why a decision will be made to use EJB 3, instead of those other technologies like Hibernate?

EJB is much more than just persistence. A similar question was answered here

I just read chapter one of this book and it says:

"Although many people think EJBs are overkill for developing relatively simple web applications of moderate size, nothing could be further from the truth. When you build a house, you don�t build everything from scratch. Instead, you buy materials or even the services of a contractor as you need it. It isn�t too practical to build an enterprise application from scratch either. Most server-side applications have a lot in common, including churning business logic, managing application state, storing and retrieving information from a relational database, managing transactions, implementing security, performing asynchronous processing, integrating systems, and so on.
As a framework, the EJB container provides these kinds of common functionality as out-of-the-box services so that your EJB components can use them in your applications without reinventing the wheel..."

EJB provides more than just the functions that Hibernate or Spring provides

"Although many people think EJBs are overkill for developing relatively simple web applications of moderate size, nothing could be further from the truth. When you build a house, you don�t build everything from scratch. Instead, you buy materials or even the services of a contractor as you need it. It isn�t too practical to build an enterprise application from scratch either. Most server-side applications have a lot in common, including churning business logic, managing application state, storing and retrieving information from a relational database, managing transactions, implementing security, performing asynchronous processing, integrating systems, and so on.
As a framework, the EJB container provides these kinds of common functionality as out-of-the-box services so that your EJB components can use them in your applications without reinventing the wheel..."

That's a really good explanation to one of the most frequently asked questions. Speaks volumes about the quality of the book

Does that mean that EJB 2.x also is better than Hibernate or other solutions?
[ March 14, 2007: Message edited by: Jesus Angeles ]

Each technology has its court, choose what your application needs.

Does that mean that EJB 2.x also is better than Hibernate or other solutions?

EJB2.x has a different set of features than Hibernate. Though EJB2.x had its flaws, comparing it with Hibernate will not be correct because Hibernate never catered to the set of features which EJB did.

To be more specific, Hibernate caters to a subset of features that EJB has.

Many people use Tomcat as the application server and Tomcat does not support EJB. They have no choice but using Spring etc.

Bruce:

You may add EJB 3 support to Tomcat either through the JBoss embeddable container or OpenEJB.

Reza
[ March 14, 2007: Message edited by: Reza Rahman ]

Redirecting to EJB topic, is there any solution out there that competes with EJB? Lets say, we are an architect and we are looking at which technology to propose to our company.

Jesus:

I hope the responses from the kind folks on this forum were helpful. If not, let me attempt to sumarize:

1. Why choose EJB 3 over Hibernate?:
* As mentioned, EJB 3 provides more than Hibernate (or Spring for that
matter) alone do since it is a "complete" platform.
* JPA (part of EJB 3) is a standard "facade" over Hibernate. Put another
way, Hibernate implements JPA and is the default JPA persistence
provider for JBoss AS. This means that if you develop in against JPA
interfaces instead of against native Hibernate, you can switch
persistece providers (such as TopoLink or Kodo) if you need to. To be
honest, I have heard more than one person say JPA interfaces are more
intuitive since they "learn from" Hibernate, TopLink, etc.
2. What are the alternatives to EJB?:
If standardization is not a concern for you and you need the services
offered by EJB, you can build your own custom stack to provide
equivalent functionality. A stack could look like:
* Spring: depenency injection, "service registry", life-cycle
management, remoting, declarative transcations,
messaging, state management (not fully existant in Spring
yet), etc.
* Acegi: declarative security.
* AspectJ: AOP.
* Hibernate/JDBCTemplate/iBATIS/TopLink: persistence.
* XFire/Axis: web services support.

Does this answer your question?

Reza
[ March 15, 2007: Message edited by: Reza Rahman ]

Jaikiran/Bruce:

Thanks for the kind words. We tried our best to make a faithful presentation of what EJB really is...

Reza

Thanks. Ill grab a book asap on all these technologies.

You are welcome.