Lean Java EE 6 Without Spring And Spring 3.0 In Java EE 6 World: Summary and Conclusion (eJug Session) 📎
It turned out, that both components models are surprisingly similar. You could migrate an EJB 3.1 based application, almost without any additional effort to Spring (search and replace for annotations). It is even possible to run an EJB 3.1 applications without ANY modification just tweaking Spring a bit.
Although both technologies are almost identical from the programming model perspective - the philosophy is totally different. Spring "is not just a glue-framework" (Juergen clarified that), rather than complete solution - the full stack. Spring was architected as a layer above the actual application server. The idea: you can upgrade your APIs updating Spring and not touching the application server. This is especially important if you have to use the "heavyweights" application servers (=they come with at least with one DVD to install and the installation takes several hours :-)) without having any control about the version. The Dependency Injection is only a small part of the framework. Spring offers you from DI, over Spring MVC with REST support (similar to JAX-RS) and even monitoring. It actually replaces the most parts of the application servers with own services.
What was also interesting - Spring is exactly NOT Convention Over Configuration. The idea is to configure everything is needed explicitly, without relying on conventions. But you don't have to configure everything over and over again - you can use "Stereotypes" for that purpose. Stereotypes are "Meta-Annotations". So you can introduce your own annotations, using "annotation inheritance". Then you only will have to use your own shortcuts (e.g. @Service, @ServiceFacade etc.).
The philosophy of EJB 3.1 is exactly the opposite. It is not a complete solution, rather than "only" a component model for transactional, serverside applications. It comes with a set of suitable conventions, so you don't have to configure anything an rely on the existing conventions. Neither annotations (except @Stateless), nor XML-configuration is needed. The EJB infrastructure has to be available at the application server - so you only have to deploy your application - without the EJB-"framework" (Glassfish EJB 3 container is about 700kB) bits. The DI are not as sophisticated as Spring's, JSR-299 or JSR-330, but actually absolutely sufficient for most projects (at least my projects :-)).
EJB 3.1 components are aimed to run directly on the server, without any indirections. This also means: you can only use EJB 3.1 in case your application server has support for it. But: I also saw some projects using openEJB container to run EJB 3.1 on tomcat :-). Whats also true: SAP, IBM Websphere, BEA Weblogic, Oracle OC4J, JBoss 4 and 5, openEJB / Geronimo and Glassfish v2 (+several others) comes already with EJB 3 support. In that case your components become vendor neutral. You can move them around, without changing any EJB 3.X setting (JPA is harder to port across different providers). You will, however, have to test them on different servers.
Spring will support parts of the Java EE 6 specification - except the @Stateless annotations :-). We (Juergen Hoeller, eJug audience and me) discussed a bit longer this issue. We have different opinions on this: If I were SpringSource, I would support @Stateless and few EJB 3.1 annotation to make the transition more easy. Juergen said it would be hard to support @Stateless in completely compliant way - and he would expect some criticism then. But: the differences could be documented - so there should be no problems as well at this point.
In the practice, however, the support issue may be important as well. It is more and more important to provide the support for the full stack from one company. I guess in future you will see SpringSource only (e.g. dm server), and Java EE 6 only solutions. These decisions will be not driven by technical, rather than political / strategic reasons. Imagine Spring will run on a commercial application server in production and something goes wrong. Such support issues could be really "exciting". Some of my involvements in the resolution of "multi-vendor J2EE-only" support cases were already funny enough in the past :-).
I hope this is a unbiased description of this event - otherwise please feel free to drop me an email or comment. The eJug meeting was well organized at a nice venue - the upcoming sessions are interesting as well. My (English) slides are based on some contents from my "Real World Java EE Patterns" book -the slides should be available for download from eJug. See the German (eJug) summary as well. Thanks Juergen Hoeller for the invitation!
Btw. I will cover some "extreme" EJB 3.1 / REST with Convention Over Configuration approaches in the upcoming Java Magazin (German only :-)).