Session Beans and EJB3 vs Spring

Question

I was curious about the capabilities of Sessions Beans in EJB 3 and whether they can be replaced in a typical mid-scale enterprise application with Spring.

I found this article: http://drag0sd0g.blogspot.com/2010/01/session-bean-alternative-spring.html that states the following: "Because of heavy use of annotations, you can pretty much avoid “XML Hell” using EJB 3; the same cannot be said of Spring. Moreover, because it is an integral part of the Java EE standard, the EJB container is natively integrated with components such as JSF, JSP, servlets, the JTA transaction manager, JMS providers, and JAAS security providers of your application server. With Spring, you have to worry whether your application server fully supports the framework with these native components and other high-performance features like clustering, load balancing, and failover. If you aren't worried about such things, then Spring is not a bad choice at all"

Do you agree with this statement? The Stateless Sessions Beans used to be considered a very powerful enterprise technology because of the pooling and management capabilities. My question is: when is it really necessary to use EJB 3 instead of or in addition to Spring (assuming a mission critical enterprise application in a large company)?

Answer 1

Looks like yet another Java EE vs. Spring post...

EJB/Java EE and Spring are now two mature, competitive Java-based technology stacks. Often there's no reason to complicate things and mix them up. EJB actually learned and used many ideas from Spring et al.

Neither of them drives you into the XML/configuration hell. Both are fairly easy to get started with, at least with the very basic stuff.

Spring is more than just IoC/SOA/transactions. It's more like a toolbox - it's ready to integrate with, or directly provides, frameworks for ORM and transactions, web/MVC, security, timers/scheduling etc. You can pick exactly the pieces you need. You're not forced to use a container (you can use it in your standalone "desktop" app).

EJB is part of Java EE stack. It is, well, the standard. It's not as broad, flexible as Spring, but it's by definition supported by all Java EE containers.

I prefer Spring for the freedom and being one step ahead.

Answer 2

I don't think there are many cases when the use of EJB 3 instead of Spring is absolutely necessary, but there are cases when using EJB 3 would be considerably easier. As the article states, the main advantages of EJB is the integration with the various other JEE technologies and, as of EJB 3, Enterprise Beans are much simpler to write than in they were in previous versions of the spec.

The classic reason for using EJB over POJOs or other middleware technologies is transactions. If your business logic needs to be transactional then EJB provides simple, declarative transnational demarcation and seamless integration with JTA via the container. While the article suggests that support for clustering, load balancing and performance management is an advantage, this is very much dependant on your choice of JEE application server.

I'd say the key factor in deciding whether to use Spring or EJB 3 is your container. If your target container is a fully JEE 5+ compliant application server and you need support for services such as transactions or messaging then EJB 3 is the obvious choice. If, however, you don't need to integrate with other JEE technologies or are deploying to a light-weight app server then using EJB would simply add unnecessary overhead.

Answer 3

How can anyone think EJB3's defining a data model using a series of java annotations spread out over several classes is superior to Hibernates simple model definition syntax is beyond me.

Its a maintainability nightmare. Why have you got an intersection table? It may be defined almost anywhere in the code base. Some junior programmer plays with the annotations and now your java classes are out of sync with the actual database.

Got a performance issues (and you will). Not only have you got the classic Hibernate "I don't know what SQL it's using" you also have the "I don't know why the table was built like that" problem.