Another one on… Spring Framework and Enterprise JavaBeans

data: 3 marca, 2014

czas czytania: 8 min

autor: Grzegorz Masłowski

Categories

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.

Spring Framework

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.

Comparison

Feature	EJB 3.x	Spring Framework
Distributed Computing	allows remote invocation with RMI, beans accessed via @Remote interfaces possibility to perform a remote JNDI lookup access through web services: JAX-WS, JAX-RS (not EJB part, but EJBs can be accessed through them)	Remoting with RMI, JAX-RPC, JAX-WS, JAX-RS modules: spring-ws, spring-webmvc
Beans	@Stateless – provides business logic @Singleton – exists only one per application @Statefull – provides business logic and additionally can hold client state @MessageDriven – handles messages sent to message destination	Singleton – only one per IoC container; created at application start Prototype – created every time injected Request – created for one single request Session – can hold client state; scopes a single bean to the lifecycle of an HTTP session Global Session – scopes a single bean to the lifecycle of an HTTP global session
Dependency Management	JNDI registry allows obtaining beans using their local, remote or no-interface views @EJB annotation handles automatic dependency injection @Resource allows to inject resource managers eg. EJBContext, TimerService, SecurityContext possibility to manage dependencies also on deployment descriptor level (overwrites annotations)	allows injecting through setter, constructor, interface dependency injection done through @Autowired, @Resource, @Inject annotations application context descriptor overwrites annotations allows lookup JNDI registry
Concurrency Management	for stateless, stateful session beans the container manages the concurrency container keeps a pool of accessible beans – not possible to tune in runtime by developer singleton beans (since 3.1) support for bean managed concurrency for singleton beans container managed concurrency allows for customizing method locking asynchronous invocations in new thread via @Asynchronous no direct access to message driven beans	all beans act as singletons; beans with session scope created for every client concurrency is always bean managed for synchronizing threads Java mechanism has to be used asynchronous invocation using @Async
Transaction Management	container managed transaction using JTA container managed transaction demarcation – allows tuning on annotation and descriptor level; container starts, commits or rollback the transaction bean managed transaction demarcation – manual start, commit and rollback of transaction in @Statefull bean managed transaction doesn’t have to commit or rollback in one method	consistent programming model across different transaction APIs such as JTA, JDBC, Hibernate, JPA, JDO Support for declarative transaction management Simpler API for programmatic transaction management than complex transaction APIs such as JTA.
Messaging	message driven beans act as message listeners queue (point2point) and topic (publish-subscribe) support concurrency handled by container – pool with available beans	with spring-jms it’s possible to create message receiver and message producer requires external MQ eg. ActiveMQ
Aspect Oriented Programming	Interceptors 1.1 (since 3.1) – rather stiff solution and not that flexible solution	spring-aop with AspectJ, CGLIB
Scheduling	scheduling jobs using TimerService business methods creating timers @Scheduled (cron-alike) method invocation	Spring TaskScheduler (since 3.0.0) Quartz can be added to spring for more sophisticated timer support
Security Management	Integrated support for declarative and programmatic security through JAAS	spring-security with default or custom AuthenticationProviders
Integration Testing	integration testing with Arquilian integration testing with embedded container	great support in spring-test starting application context with SpringTestRunner
Deployment	enterprise archive .ear – may consist of many web and ejb modules single web module packaged in .war configuration in application.xml (.ear) and ejb-jar.xml (.jar, *.war) requires EJB compliant application server eg. JBoss, WebLogic, Apache Tomee/+	packaged in .jar or .war files configuration in *.xml files overriding annotations can be deployed on lightweight containers eg. Tomcat, Jetty

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
etc.

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?