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.
Regards,
Jon