EJB is a Dinosaur, Spring Framework is the Small Furry Mammal
- By Matt Stephens
- April 23, 2005
One of the worst-kept secrets surrounding J2EE is the sheer ineffectiveness of Enterprise JavaBeans (EJB) as an enterprise business-object framework. Bloated, over-designed, difficult to test, slow to develop with, plagued over the years by buggy "first-to-market" implementations, EJB is the Achilles heel of server-side Java development. Which is bad, because the server-side is meant to be Java's greatest strength.
An old but mostly-still-relevant list of problems with EJB can be found in this article from 2002.
Take EJB out of J2EE, and what do you have left? Actually quite a lot. JMS (for asynchronous messaging and queuing), JSP (the trusty web presentation layer), JTA for transactions, JNDI for naming and directory services and so on. Certainly there are gaps which leave room for all sorts of creative open-source solutions.
The biggest gap is the lack of a decent Model-View-Controller (MVC) framework built on top of JSP. JSP is good for what it does, but as soon as you want to do a complex app bigger than 5-10 pages, things start to get fiddly. JSP doesn't provide its own MVC framework; so mapping web requests to server-side actions (or "controllers") tends to involve imaginative solutions, reinvented for each project.
This is where the myriad of third-party Java web frameworks come in. One of the latecomers to the party was Sun's "official" MVC implementation, JavaServer Faces (JSF). However, JSF - though maturing slowly like Swiss cheese left in the sun - isn't without its holes. This leaves us with a bunch of (actually very popular) open-source alternatives. Struts is the most popular, but is also arguably the ugliest with its "endless layers of XML" approach. (Struts reminds me of a bureaucratic Government department: want to make a small change to your webapp? Please fill out this pile of XML forms first, in triplicate…)
In fact, none of these approaches quite "hits the spot" as a simple yet powerful MVC framework for Java.
So, what are we left with? Some powerful stuff for transactions and directory lookups, a decent web presentation layer with nasty/non-existent MVC support, and an abortive business-object framework.
Enter Spring Framework. It's based on the radical notion that simplicity is better. Funnily enough, it builds on J2EE's strengths, and plugs the gaps where J2EE falls short. Spring is one of a new breed of "lightweight frameworks", using all manner of "simplicity-inducing" modern design patterns and technologies (e.g. Inversion of Control, and AOP). It can be thought of as a J2EE framework because it builds on J2EE; so as a replacement for EJB it's perfectly viable, and MUCH easier to program with.
Spring doesn't replace JSP. Instead it provides an MVC framework (appropriately named "Spring Web MVC") which allows you to use JSP as the templating mechanism for building the presentation tier to your MVC webapp. If you're so inclined, you can alternatively "plug in" the presentation tier of your choice (Struts, Velocity, Tiles etc).
For database access, Spring is "persistence layer agnostic". That is, it leaves the decision of which O-R mapping solution to use up to the developers. It provides built-in support for Hibernate, "vanilla" JDBC etc, but allowing developers to use a consistent approach to domain objects and exception handling, regardless of which persistence solution happens to be "under the covers". Aside from reducing the learning curve, this also makes it potentially a simple matter to switch to a different persistence framework should you want to, without having to rewrite all of your domain classes and DAO interfaces.
Spring makes heavy use of the "Inversion of Control" (IoC) design pattern, meaning simply that individual JavaBeans don't go looking for data, the data is handed to them by the framework. This reduces interdependencies between classes (always a good thing in software design), and surprisingly also reduces your JavaBeans' dependence on the framework itself. It means that your classes can extend whatever business-oriented classes you want them to extend, not some class or other dictated by your application server.
This approach makes Spring-based applications much easier to test, because JavaBeans can be tested in isolation from the rest of the system.
One of Spring's greatest strengths, however, is the quality of the documentation (a rare but commendable thing in the open source world). Their website provides a 220-page PDF, a book in itself, covering all aspects of developing with Spring Framework and including lots of up-to-date examples.
On top of this, there are several books available on Spring (see their website for an up-to-date list - the best book so far is Pro Spring by Rob Harrop and Jan Machacek). I'm also working on a new book (on use case driven analysis and design) which happens to use Spring Web MVC for its central example.
Spring Framework isn't the only lightweight Java framework out there (e.g. there's also Pico Container and Keel Framework), but at the moment Spring certainly seems to be the strongest contender. With luck, in the next 12 months we'll see an upsurge of real-world Spring usage.