EJB3 vs Spring

EJB3 vs Spring

After many years happily spent using the Spring framework, I got involved into an EJB-based project, and luckily it was EJB3 based :)
Let's see what are the advantages EJB estimators usually come up with and let's compare them with their Spring equivalent: 

• Bean life cycle management. Spring's core is all about this
• Dependency Injection: in an EJB3 you can only inject other EJB's or objects registered in JNDI with relative lookup overhead. With Spring you can inject anything you want, including values coming from properties file, which is very nice
• Transaction management: really great but Spring fully supports JTA as well
• Distributed transaction: it can be very handy, but it is also true that a simple design presumes a single database, if you have multiple ones you are probably working on some legacy system
• Security: it would have been great if it would not depend on the application server vendor and it would not be web dependent (since you have to first authenticate on that layer most of the time). Anyway Spring support the same feature
• Stateful session bean: I don't plan to use them any time soon :)
• Thread safe abstraction model: it is nice that as a developer I do not have to care about concurrent access to my bean. However this goal is achieved by maintaining a pool of beans you have to be aware of when you want to tune. Personally I prefer to use not thread safe Spring beans and having total control of what is going on, but this is just my opinion
• Aspect Oriented Programming: in this case support is quite limited since it is runtime only (Interceptors will contain the aspect's logic). This means you cannot use AspectJ, which is very bad :(
• Timer: also in this case the support is quite limited, if you want to use any cron-like expression to schedule jobs you would better make use of the Quartz library
• EJB3 are POJO so they are easy to test, I would say they are easier but not easy to test. Since, as I said before, Dependency Injection support is quite limited, mocking becomes not easy as well. For example, mocking and injecting an EntityManager is not something trivial
• JMS integration: Message Driven Bean are really great, you can setup something similar with Spring as well, but in this case I would go for EJB
• JPA: well this is really great but in this case credits go to Hibernate since Entity Beans,JPQL are just clones of Hibernate domain object, HQL and so on
• Annotation based vs Xml configuration: I prefer EJB in this case too. Anyway the Spring Java Config provides no-xml configuration as well
• Clustering, load balancing, fail-over: really great but still it's the developer's responsibility to setup a mechanism to allow beans running on different nodes to share their data (Database and Terracottaare the best options for this)
• Integrated solution stack: this is one of the biggest advantages. In one package you get so many features you would need to refer to many different library(s) to get the same result. Still when you need something more specific (like cron expression for scheduling) you would still need to recur to an external library
• It is a standard: this can be a pro but a cons at the same time, since being a standard its evolution is quite slow