Another contract, another technology set. Having successfully avoided working in EJB2 after getting certified in it by Sun (only to work out just how badly it smelt 😉 ), my initial foray into its successor has been much nicer. The job in question specified Spring and EJB3 as technology requirements, so having Sprung in anger, I approached it from that angle as well as getting myself up to speed on the EJB3 changes.
Firstly, while they may be viewed competing technologies they can be complementary ones. Spring is a framework which aside from dependency injection gives you a bunch of goodies for the various tiers in your application that make your life easy and cut down on boiler-plate code. EJB3 is a model for building server-side components that gives you services such as concurrency, transaction management, persistence, object distribution, naming, and security. And it’s finally getting to be the technology that it should have been.
The changes in EJB since version 2:
- All EJBs are now POJOs. Woohoo! Nothing to subclass. Easy to test!
- You don’t have to implement a whole bunch of container callback methods – write up the ones you want (if you want them) and annotate with the event that triggers. I am finally seeing the power of the annotation here. Think optional mini-interface.
- Remote interfaces don’t have to differ from local interfaces only by a RemoteException that needs to be handled around each invocation.
- Persistence via entity beans has been reworked into it’s own API (JPA) which means it can be used outside a container. Stuff that implements it? Hibernate, Toplink… all the stuff you already know.
In fact… a stateless session bean does not look that far removed from a stateless class your existing Spring application used in its service layer. A smattering of annotations, a hook for Spring to weave its DI magic and a change of config is all it takes for your Spring app to use all of the goodies that EJB gives you via local session beans. You still have to understand the EJB life cycle but you don’t get something for nothing.
EJB3 supports dependency injection out of the box, but it’s kind of limited. The only things that are injected are other EJBs, and an EntityManager object (used to access the ORM – kind of naff since we have all been happily DAOing for ages and like to separate our data access from our business logic). If you wanted to use DI to inject stuff at a finer level (such as DAOs, JavaMail sessions etc.), you still have to use an actual DI container – hence Spring. The hook feels a bit clumsy, in that your EJBs have to subclass a Spring class and implement a callback, but it makes sense when you understand the bean life cycle. Not quite painless but pretty good nevertheless.
Spring strikes again in the DAO/EAO layer (E for Entity, get it?) with it’s superb template approach via the JpaDaoSupport class, cutting boiler-plate code in that layer to nothing. Mmm… warm fuzzy feeling ahead:
public class UserDao extends JpaDaoSupport {
public List getAdminUsers() {
return getJpaTemplate().find("select u from User u where type=?1", "admin");
}
}
EJB 3 in Action is worth the money just for the chapter covering the Spring integration. The rest of the book is also quite good both from the point of view of a new developer and people like me who are getting up to speed on the changes from earlier versions. The latest edition of the definitive guide, Enterprise JavaBeans 3.0 by Burke and Monson-Haefel (who retired from writing before this edition) is also exceptional, but you should check out the relevant Spring documentation to supplement it.
My take on this is that Spring gives you good stuff, and EJB gives you good stuff as well – and now without the pain. Use one, or the other, or feel free to mix and match. It’s nice to know that you don’t have to trade one for the other.