In this article i;m trying to compare what EJB 3.1 and spring framework have in common, if at all? and whether Sun did a mistake by releasing EJB 3.0 spec? So the real question is if application are using EJb 2.1, should they migrate to EJb 3 or EJB 3.1? Or remove ejb's and use Spring framework to do everything...
well, 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 framework", 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. The DI model is just a tiny part of spring framework, and now REST support in Spring MVC and so n so forth..
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