Basically,you should not ask what's the difference, but what's the similarity ;). From 10000 feet high, the similarity is
that with both you can persist a class in a DB; but it ends there. Period.
EJBs are supposed to be components, in the sense that they're not just one class, but a set of classes, descriptors (thats an
XML and/or annotations in EJB 3) and usage and management contracts. All of this in order to allow a container (JBoss,
Weblogic, etc.) to provide services to those components, and to be able to reuse and distribute this components. This
services are, among others, transactions, concurrent access control, security, instance pooling, etcetera.
Hibernat is "just" an ORM (Object/Relational Mapping) tool. Quick and dirty, this means you can store an object tree
belonging to an class hierarchy in a relational DB without writing a single SQL query. Quite cool, IMO. But no transaction
control, no instance pooling, no concurrency control, and certainly no security.
On the other hand, inheritance and polimorphism (did i spell it right? sigh...) are IMPOSSIBLE out of the box with EJB. A
quite big drawback, i think.
The big issue seems to be this days that there's no intersection between Hibernate and EJB's funcionality... what you can
with one you can barely do with the other. So EJB 3 is on its way to fill this gap and solve all of our problems. The spec is
a draft for the time being, but there are some implementations, already.
That's the difference between Hibernate and EJB, in a nutshell. Still, you should expand this concepts with more research,
but don't expect to get all of it posting in ANY forum... It's just not polite to ask without having invested some time
It states that the EJB expert group has decided to use Hibernate as the persistence mechanism in EJB 3.0. That’s not how i
understood it. EJB 3.0 will provide a POJO object relational mapping much like Hibernate, but i don’t think it will be
exactly like Hibernate.