Last night I attended a New England Java User Group (NEJUG) meeting where Reza Rahman presented a "comparative analysis" of EJB 3 and Spring. Reza is one of the authors of EJB 3 in Action. I enjoyed meeting Reza and respect him for presenting what may be considered a controversial topic. Also I appreciate that he did attempt to address pros and cons for both EJB 3 and Spring. Nevertheless, I feel compelled to clarify a few points that were not wholly accurate in his coverage of Spring and which led me (and other attendees) to believe the presentation was motivated by a bias toward EJB 3. To be fair, unlike a fixed specification version, Spring is constantly evolving and some of the things that I will point out here are new features. On the other hand, some are Spring 2.0 features that have been available for more than a year. I personally believe that a "comparative analysis" must account for the up-to-date feature set of the latest stable version of the products being compared. I think it goes without saying that I might be a bit biased as well, but my motivation here is to provide a wholly objective response so that the presentation could perhaps be revised to reflect a more 'apples-to-apples' comparison. I will provide brief responses to 10 "themes" of the presentation.
1. EJB uses annotations for metadata. Spring uses XML.
It was mentioned that Spring is beginning to support more annotations but that it is "going to take them a while". However, the Spring 2.0 release provided full JPA integration with @PersistenceContext for injecting the EntityManager and annotation-driven transaction management with Spring's @Transactional annotation (supporting the same semantics as a @Stateless EJB with the default propagation of REQUIRED). I was particularly discouraged that the comparison did not include JPA on both sides (see point #3 below). Spring 2.0 also introduced full annotation-based AspectJ support (@Aspect, @Before, @After, @Around) and the concept of "stereotype" annotations. For example, the @Repository annotation enables non-invasive Exception translation for data-access code that uses JPA or Hibernate APIs directly (without Spring's templates). Spring even provided annotation support as early as version 1.2, such as @ManagedResource for transparently exporting any Spring-managed object as a JMX MBean.
Now the main reason this issue is #1 for me, is the comment that it is "going to take them a while". As one of the main developers of Spring 2.5's annotation-driven configuration support, I must say that the Spring metadata model is extremely flexible and therefore we have been able to provide a comprehensive annotation-based model more quickly than one might expect. In fact, Spring 2.5 provides support for JSR-250 annotations: @Resource, @PostConstruct, and @PreDestroy - as well as @WebServiceRef and @EJB. Of particular interest is @Resource since it is the primary annotation used for dependency injection in EJB 3. With Spring, the @Resource annotation supports not only JNDI lookups (as with EJB 3) but also injection of any Spring-managed object. This effectively combines the main Spring advantage that was mentioned in this presentation (Spring supports DI of any type of object) with the main EJB 3 advantage (use of annotations instead of XML). Spring 2.5 also introduces an even more fine-grained annotation-driven dependency injection model based on @Autowired and the (extensible) @Qualifier annotation. Spring 2.5 also extends the "stereotype" annotations to include @Service and @Controller. Each of the stereotype annotations extends the generic @Component annotation by applying it as a meta-annotation. By applying the same technique, the @Component annotation provides an extension point for user-defined stereotypes. Spring can even auto-detect these annotated components as an alternative to XML configuration. For example, this excerpt is taken from the 2.5 version of the PetClinic sample application:
<context:component-scan base-package="org.springframework.samples.petclinic.web" />
No additional XML is required for the web controllers since they use annotation-driven dependency injection and annotations for request mapping. I point this out, because the presentation specifically emphasized the verbosity of configuration for the web-tier:
@Controller
public class ClinicController {
private final Clinic clinic;
@Autowired
public ClinicController(Clinic clinic) {
this.clinic = clinic;
}
...
For up-to-date coverage of Spring's annotation support, see: Introduction to Spring 2.5 on The Server Side, or the latest version of Spring's reference manual - specifically the Annotation-based configuration section. Also, stay tuned to this blog and the Spring Framework home for some soon-to-be-released articles and blogs covering version 2.5.
2. Spring allows you to support multiple deployment environments but requires more configuration.
This one was actually presented as a Spring advantage but with an emphasis on the configuration overhead. The truth is any project where testing and agile development are taken seriously is going to require supporting "multiple deployment environments". In other words, this particular topic often gets distorted as if it applies only to multiple production environments. In reality, having to deploy to an Application Server during each development and testing cycle is a major obstacle to agility. Typically Spring users will modularize their configuration such that "infrastructure" configuration (e.g. DataSource, TransactionManager, JMS ConnectionFactory) is separate and dynamic properties are externalized. Since Spring provides support for replacing '${placeholders}' based on the externalized properties, the inclusion of different properties files typically becomes a transparent concern.
3. EJB with JPA, Spring with Hibernate
I must admit this one bothered me the most. In the comparison slides, the EJB 3 examples showed JPA with data-access via entityManager and the entityManager instance being provided with the @PersistenceContext annotation. On the other hand, the Spring examples used Hibernate and showed setter injection of the Hibernate SessionFactory. In my mind, this violates the first rule of a bona-fide "comparative analysis": use the most similar feature available on both sides of the comparison. In this particular case, Spring does provide support for using the JPA API directly (i.e. JpaTemplate is completely optional; direct usage of the 'entityManager' still participates in Spring transactions, etc), and Spring also recognizes the @PersistenceContext annotation. This support has been available since Spring 2.0 (final release was more than a year ago), so I don't understand why the comparison does not use JPA on the Spring side as well. Other parts of the comparison were clearly based on Spring 2.0, so this leaves the impression of being selectively out-of-date and revealing a bias. If this particular example were modified to be 'apples-to-apples', it would have undermined one of the main overall themes: that Spring requires more configuration whereas EJB 3 relies on standard annotations.
Now, even though I believe the usage of Hibernate rather than JPA on the Spring side distorted the comparison, it does simultaneously reveal a strength of Spring. If you do want to use the Hibernate API directly instead of relying on the JPA API, Spring enables that, and it does so in a consistent way with regard to Spring transaction management and Exception translation. This then opens up the opportunity to use Hibernate features that extend beyond the limitations of JPA, such as Hibernate's "criteria" query API. By the same token, if you would like to add some direct JDBC for data-access where ORM is overkill, that is also supported in Spring - even when invoked within the same transaction as Hibernate or JPA data-access.
4. Spring makes no assumptions, you have to provide configuration.
One specific example was the definition of a transaction manager. It was stated that you have to understand things at the container-vendor level to configure Spring integration. This is incorrect. For example, the following bean definition does not contain any container-specific information, yet Spring will auto-detect the transaction manager in all Java EE Application Servers:
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>
If you do want to leverage container-specific features such as per-transaction isolation levels, then Spring also provides a few specialized implementations: WebLogicJtaTransactionManager WebSphereUowTransactionManager, and OC4JJtaTransactionManager. Switching between these implementations is only a matter of changing this single definition.
In addition to this, the Spring configuration slides were unnecessarily verbose. I'm afraid this may also have been motivated by the goal of emphasizing that EJB unlike Spring relies on intelligent defaulting. For example, the slide showed:
<tx:annotation-driven transaction-manager="transactionManager"/>
Actually, if there is a single 'transactionManager' defined within a Spring context, then that attribute does not need to be provided explicitly on the 'annotation-driven' element. That attribute is available solely for enabling the usage of multiple transaction managers within one application if necessary. These techniques of "auto-detection" and "intelligent defaulting" apply throughout Spring, such as the JMS 'connectionFactory' for a message-listener (which is implicit in the example of #6 below) and the automatic location of an existing MBean server or RMI registry.
On a positive note, it was actually mentioned as an advantage that Spring allows for "local" transaction management. While EJB requires JTA for transaction management, many applications do not need distributed transactions across two-phase commit capable resources. In such cases, Spring allows for simpler transaction managers with less-overhead: DataSourceTransactionManager (for JDBC), HibernateTransactionManager, or JpaTransactionManager. I would have expected to hear a bit more detail on that particular Spring strength if the goal was to accurately describe the pros and cons. For example, this is a huge benefit for testing outside of the container or developing within a lightweight IDE environment such as Eclipse or IDEA.
Furthermore, if you do require JTA for distributed transactions but want to run in a lightweight container like Tomcat or Jetty, Spring easily supports standalone JTA providers like Atomikos and JOTM. Sure Spring's transaction manager setup requires configuration of a single bean definition, but it really is a one-time cost - and well worth the benefit.
5. Spring does not have a stateful application paradigm.
The benefits of a stateless service layer are fairly well-established as a best practice, and Spring embraces that. Spring does provide scopes other than singleton however. Spring's "prototype" scope enables a distinct instance for each injection or lookup, and Spring 2.0 introduced web scopes: "request" and "session". The scoping mechanism itself is even extensible; it's possible to define and map a custom scope to the notion of a conversation. Spring also supports simple object pooling with the CommonsPoolTargetSource, but object pooling is rarely the best solution for state management.
More importantly, Spring does provide very robust, highly configurable state-management for web applications via Spring Web Flow. There the conversational state is managed transparently, contrary to the claim of this presentation that developers have to interact directly with the HTTP Session to manage state in Spring applications. Furthermore, the repository configuration is pluggable so that various strategies may be used for physical storage of the state (session, client, backend cache, etc.). Finally, the latest developments in Spring Web Flow include support for extended persistence context and fully integrated support for JSF.
6. Spring requires configuration of a container per MessageListener.
Spring 2.5 provides a new 'jms' namespace to greatly simplify the configuration of message-listeners. Notice that there is no separate configuration for a container per-listener. Multiple listeners share the configuration, and intelligent defaulting is used extensively:
<jms:listener-container>
<jms:listener destination="queue.confirm" ref="logger" method="log"/>
<jms:listener destination="queue.order…
