Since Spring is able to use transactions just like EJB. For me, Spring is able to replace the requirement of using EJB. Can anyone tell me what are the extra advantages of using EJB?
+3
A:
First, let me say it clearly, I'm not saying you shouldn't use Spring but, because you are asking for some advantages, here are at least two of them:
EJB 3 is a standard while Spring is not (it's a de facto standard but that's not the same thing) and this won't change in the foreseeable future. Although you can use the Spring framework with any application server, Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring.
The Spring framework sits on top of the application servers and service libraries. Service integration code (e.g. data access templates) resides in the framework and is exposed to the application developers. In contrast, the EJB 3 framework is integrated into the application server and the service integration code is encapsulated behind an interface. EJB 3 vendors can thus optimize the performance and developer experience by working at the application server level. For example, they can tie the JPA engine closely to JTA transaction management. Another example is clustering support which is transparent to EJB 3 developers.
EJB 3 is not perfect though, it is still lacking some features (e.g. injection of non managed components like simple POJOs).
Pascal Thivent
2009-11-22 16:40:43
+3
A:
Pascal's points are valid. There are, however, the following in favour of Spring.
EJB specification is actually a bit loose, and therefore different behaviours can be observed with different application servers. This will not be true for the most cases, of course, but I've had such a problem for some "dark corners".
Spring has a lot of extra goodies, like spring-test, AOP, MVC, JSF integration, etc. EJB has some of those (interceptors, for example), but in my opinion they are not that much developed.
In conclusion, it depends mainly on your exact case.
Bozho
2009-11-22 16:51:04
Maybe something like *Spring only needs a servlet engine* would be more accurate (EJB can be used in any JEE container, servlet engine != JEE container).
Pascal Thivent
2009-11-22 17:40:17
Well, technically, Spring doesn't require a servlet engine either. For example spring-test uses an in-memory context.
Bozho
2009-11-22 17:55:21
Well, technically, EJBs don't require a standalone container neither if you go this way. Since EJB 3.1 there is the standard `EJBContainer.createEJBContainer()` API to use an embedded container. So, still, your statement is wrong.
Pascal Thivent
2009-11-22 18:37:51
ok, 3.1 is quite new and obviously I forgot about the additions. Removed that point from my answer.
Bozho
2009-11-22 19:45:59
+6
A:
Spring was developed as an alternative to EJB right from its inception, so the answer is of course you can use Spring in place of EJBs.
If there's an "advantage" to using EJBs, I'd say that it would depend on the skills of your team. If you have no Spring expertise, and lots of EJB experience, then maybe sticking with EJB 3.0 is a good move.
App servers written to support the EJB standard can, in theory, be ported from one compliant Java EE app server to another. But that means staying away from any and all vendor-specific extensions that lock you in to one vendor.
Spring ports easily between app servers (e.g., WebLogic, Tomcat, JBOSS, etc.) because it doesn't depend on them.
However, you are locked into Spring.
Spring encourages good OO design practices (e.g., interfaces, layers, separation of concerns) that benefit any problem they touch, even if you decide to switch to Guice or another DI framework.
duffymo
2009-11-22 17:13:33