Even that EJB 3.0 (which was given a huge trim – mainly because of EJB 2.x complexity and introduction of Spring 1.x) was introduced in 2006 I can still hear “rumours” that EJB is heavy, hard to work with and unnecessarily bloated. I believe that’s mainly due to the fact that it’s hard to clear the bad reputation of EJB 2.x.
Back then, in pre 2006, Spring Framework was introduced as a lighter and definitely easier to work with alternative to EJB. Since then – both alternatives have grown up, learning from each other in the process. EJB, with its current 3.2 (May 2013) version, is quite easy to use, still providing rich feature set which is expected to be implemented on application servers. On the other hand, Spring Framework doesn’t require huge amount of xml anymore, yet it’s keeping its modularity.
One another conclusion I’ve recently heard is that EJB should be used for big customers and Spring can be used for smaller ones – because it’s not a corporate solution. Despite the fact that EJB is a JEE standard, and it may be hard to overcome in some corporate organizations, I cannot imagine that we – professional developers – choose one solution over another based on our clients’ company size.
That has led me to the conclusion that we (still referring to software engineers) don’t know or understand both solutions well enough to make a reasonable judgement. My opinion is that we should choose the technology stack for our new/existing software not of the basis of myths or broscience, but rather on factors such as:
- offered feature set compared with clients’ functional requirements
- non-functional requirements
- competences of the team
And last, but not least, as professional developers we should understand and be aware of consequences of our choices and choose the technology stack thoughtfully.
That’s why I wanted to provide some brief overview and comparison of aforementioned approaches to software development.
I’d like to discuss the basics of both solutions without getting too far into details.
The Spring Framework is an application framework and IoC container for the Java platform. The framework was initially created as an alternative to EJB. Spring offers modular approach to adding new functionalities, which means that developers can use only parts they’re interested in. It’s quite easy to learn how to use Spring, hence many beginner developers start with it. Also one of the greatest benefits of Spring is that it doesn’t require an application server to run.
Enterprise JavaBeans 3.x
EJB is a specification, which is a part of JEE technology stack. Many say that EJB being a standard will stay in the development environment long enough, so building applications with that technology is secure as it comes to maintenance and updates. What’s important in this programming model is that a developer doesn’t need to know the details of EJB implementation and can move his application between application servers (JEE compliant), but only if one doesn’t bind himself to a vendor-specific feature or implementation. Ten years ago it was hard to get into using EJB. Nowadays, it looks rather easy to follow. It’s worth mentioning that JEE standard defines others specifications for enterprise application development in Java as well: eg. JSF, JAX-RS, JAX-WS, which of course are compatible with EJB.
Enterprise JavaBeans had an important milestone release with 3.0 (eg.lot of functions inspired by Spring; elimination of component, home and remote interfaces) version of the specification, bringing it further with 3.1 (eg. schedules; EJB Lite; interceptors; asynchronous calls). Although the 3.2 release doesn’t introduce many changes (eg. file access support), it still shows that EJB is not forsaken.
Since 3.1 there’s also an EJB 3.1 Lite specification provided. So far I haven’t found any application server which makes use of that subset of EJB 3.1.
|Feature||EJB 3.x||Spring Framework|
|Aspect Oriented Programming||
When to use which?
This is indeed hard question to answer. Since currently both solutions actually provide means to achieve the same goal it’ll all boil down into following factors:
- environment of application (standalone, distributed)
- functional customer requirements
- non-functional customer requirements (scalability, fail-over)
- the general knowledge of programming models for both solutions
- the development team skills
I hope that in this short article I’ve shown you that EJB isn’t that big fat monster any more, as it was in 2004. As well as that, on the other hand, Spring-based application can result in a one-hundred megabyte application, when one incorporates all of Spring modules (sounds already like an application server to me). So next time, when you have to decide what technology stack to choose, do it wisely, do it based on knowledge, do it thoughtfully.
So, based on what information are you choosing your technology stack?
- Enterprise JavaBeans 3.2 Specification – https://jcp.org/en/jsr/detail?id=345
- Spring Framework – http://docs.spring.io/spring/docs/4.0.2.RELEASE/spring-framework-reference/htmlsingle/
- Apache Tomee – http://tomee.apache.org/apache-tomee.html
- Java EE 7 Technology Stack – http://www.oracle.com/technetwork/java/javaee/tech/index.html
- Arquilian – http://arquillian.org/