Hi Bill- First off, the JPA entity part of the EJB 3 spec was created largely in the image of POJO-based persistence frameworks like Hibernate and TopLink. Their similarities far outweigh their differences, and this POJO is a stark departure from EJB 2.x entity beans. In fact, the bulk of the TopLink source -- known as TopLink Essentials -- was donated by Oracle to become the JPA reference implementation for EJB 3. Both JBoss (Hibernate) and Oracle (TopLink) are promoting standardization on JPA entities, and compete on the strengths and weaknesses of their underlying implementations. The JPA spec took so much from these technologies that it left surprisingly little left over -- primarily, high-end configuration options -- that are not rolled into JPA. The JPA is designed to be extensible, so Hibernate and TopLink features that go beyond the JPA spec are entirely acceptable, though their use may limits the portability of the entities should the the application become reliant on these extension (this is rare). Because so much is in the JPA, however, many powerful JPA entities will exist that require no configuration extensions at all.
As for Spring, both EJB session and message driven beans, and JPA entities, have incorporated features of Spring, such as container injection and method interception (interceptors, for enterprise beans, and entity callbacks, for JPA entities). EJB 3 offers a standard programming API built around Java EE services, whereas Spring offers its own programming API. My impression is that whereas Spring is highly flexible and extensible, EJB 3 trades in some of that flexibility for clarity of its programming API.
JPA is the Java Persistence API, and defines the behavior of JPA entities which have replaced EJB 2.x entity beans. The Java Persistence API is one of three spec documents in JSR-220, which defines the EJB 3 spec. The JPA portion of the EJB 3 spec is pretty self-contained and holds no requirements on the EJB container. JPA entities can live and be instantiated outside the EJB container, since they are POJOs (plain old Java objects). EJB 2.x entity beans, like session beans, lived only in the EJB container and could only be accessed by remote clients through a remote interface. [BTW, other posts in this forum further describe the behavior of JPA entities.]
To my understanding Spring doesn't require any Application Server whereas EJB require a container in Application server.
In EJB 3, session and message driven beans execute inside the EJB container, and this requires an application server. The EJB container, and its supporting Java EE server, offer session beans and MDBs a number of standard enterprise services, including remotability, transaction management, shared resources, security services, and many others. JPA entities do not need to execute in an EJB container, or even in a Java EE server, and so they do not require an application server. They are supported by a persistence provider (a .jar file on the classpath) which, among other things, offers them persistence services to load/save their data to the database.
![[Logo]](https://coderanch.com/templates/default/mobile/images/mobile-moose.gif)
