Spring and EJB 3 Compared

Posted by Floyd Marinescu on Sep 01, 2006

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

JCP Standards ,

Data Access ,

Java

Tags

JPA ,

EJB ,

Spring

devx is hosting an article comparing Spring 2 and EJB 3 focusing on support for persistence, transaction management, and statefulness. For each it examines code samples and also makes nonfunctional comparisons. 

On persistence and transaction management, the article shows the two as nearly equivalent, with EJB being simpler for simple cases and Spring allowing more options over all due to wider third party framework/product support and more configuration options.  The article compares Spring+Hibernate with EJB JPA.  As reported by InfoQ in Spring+JPA to be the next popular stack?, Spring 2.0 now provides the complete EJB container contract for JPA, allowing JPA to be used under a Spring managed services layer (with all the AOP and DI richness of Spring) in any environment.   Debates are already beginning about whether the next defacto stack will be EJB, Spring+Hibernate, or Spring + JPA.  By implementing the ejb container contract, Spring allows the injection of the persistence context across components in the same transaction, as well as the ability to have components join transactions and also support for extended persistence context (which the article didn't mention - instead suggesting that only open session in view is supported).   Spring 2 thus allows the use of JPA with all the features supported within a container.

The main difference the article found was in approaches to state management - both support it (EJB 3 via stateful session beans, Spring via prototype beans and also request, session, and global session scoping), but concluded that a bit more work needs to be done in the Spring case to replicate the capabilities of SFSB's, possibly making EJB a better choice.

Missing from the article was a comparison of dependency injection and aspect oriented features. EJB 3 supports injection of primitive types (see resource injection in the Java EE platform) and Spring supporting injection of anything. EJB allows injecting EJB's, whereas Spring 2 allows injection of any domain objects using the features of AspectJ. On the Aspects front - EJB 3 supports interceptors, while Spring is tightly integrated with AspectJ with all of it's features.

As InfoQ will report on this coming monday, Spring 2 final has been delayed to Sept 26th to work on additional features, including final support for JPA. When comparing Spring to EJB 3, JPA can almost be factored out due to the strong support inherent in both, the remaining feature to compare then is the programming model surrounding session beans (the services layer) an area in which EJB 3 itself has been catching up to Spring on.  On a similar note,  Corby Page made an interesting anecdote in a TSS thread covering this same subject:

Two years ago, EJB2 was the complex, overfeatured monster, and Spring brought elegance and simplicity to the development process.  Now, EJB3 brings a basic, 'good-enough-for-most-jobs' implementation of component management. Spring 2.0 offers a lot more power and customization, but the use of AspectJ actually makes the learning curve steeper.

In some ways Spring and EJB 3 are being seen in the community as competing standards for the enterprise programming model of choice, with JBoss SEAM (see Seam, re-thinking web application architecture) as another stack with the closely related Web Beans standard approved for development in the JCP as well.  Spring and EJB 3 comparisons are likely to be made many more times as Spring 2 finalizes and EJB 3 implementations become available.

1. Back to top

   mostly true

   by Mike Keith

   Not a bad article, and although not far off, this article did contain parts that were incorrect. The most prominent untruth, that he even spent a bit of text on and reached the summary section, was the comment that EJB 3.0 only supports JTA transactions. EJB 3.0 does also support JDBC-level transactions.
   
   On one hand the fact that I have to keep correcting articles that people are writing about EJB 3.0 might mean that we didn't do as good a job as we could have writing the spec. On the other hand, the part that describes this is actually pretty clear, so in this case I think it was just a matter of the guy not knowing the spec well enough before writing the article.

   Reply

• Older >