As a side note, if the deployment target will be Weblogic 10+ then reading the Pitchfork Project documentation is advisable as some nice tricks can be performed.
First of all let's describe how a SLSB EJB3 likes to manage persistence. As you can imagine the entity classes stay the same and the bean will serve as a facade. Everything is then packed in an EAR file that usually contains a WAR file (for the screens), a JAR file for the EJBs and another JAR file inside the lib directory (for common libraries) with the entities. A simple code example of the implementation class:
|Extremely easy to code||Forces an EAR deployment|
|Extensive use of annotations||DI just for container managed classes|
|Declarative transactions and security||Several business layers|
|Optional deployment descriptors||Looses lazy loading when accessed remotely|
|Local or remote deployments|
Spring approach is different. As always they enforce a lightweight, POJO based, solution (EJBs now are as similar to a POJO as possible). They offer three distinct possibilities (and the best of all is that they're easily intechangeable by configuration):
- The JPATemplate: Specialy useful when upgrading from other templates (ie Hibernate). Here's an use explanation by Inteface 21 themselves. It has two downsides IMHO, it's Spring dependent (invasive) and it uses inline functions (which I tend to dislike)
- The LocalContainerEntiyManagerFactoryBean: Or converting the Spring context in a JPA container (!). As in the first case it allows declarative transactions and it adds the capability to parse @PersistenceContext for EntityManager injection. Here's another explanation
- Leveraging the JTA (container) EntityManager. Spring will integrate with the AS and use the containers facilities.
Now we are in disposition to answer the initial question. Which technology fits better? And I'm going to give a response. Both! Just use both! Leverage the fact that the same implementation works for both cases and create two facades, use the EJB3 facade for container managed classes (like filters or servlets) and Spring for your beans. Both parts work well together and Spring can join a transaction created by an EJB3 and viceversa. Nice, isn't it?