Jakub Korab

A few weeks ago I blogged about Spring and EJB integration, but something just did not sit well with me. Why would you want to do this at all?

I like Spring. Its myriad components make my life simpler. I can write the business code I need to faster without worrying as much about the plumbing aspects. The Spring contributors have put a lot of thought into reducing the lines of code that I as an application developer need to write. Brilliant! My stuff can be easily tested by applying DI principles and this makes me happy as it takes less effort to make the end client happy.

I have access to all of the services on the JEE platform, including transactions, naming and management and can use it as is appropriate to the task at hand. EJB is also a way of doing the same thing. If two things do the same thing, then why would you want to use them both?

I have read a lot of opinions on this question (actually, most have been on which is better, which is meaningless in this context), and have come to the conclusion that I don’t. The problem space is such that you get no additional benefits in tying the two together.

Spring is a platform, an over-arching container, a way of structuring applications and a tool set. EJB is a component model for developing the business tier that ties in directly into your JEE server. Where they cross over is that they allow your application to access the underlying services in such a way that you don’t deal with them when you write your business code.

You would use Spring to manage your business tier when you want to write a Spring application - ORM templates, Webflow, Web services, Remoting API. You would use EJB when you want to write something like a Seam application - JSF, tying in directly to a business tier that manages your persistence, jBPM for process management etc.

The question is what Style of application are you building - is it multi-tier with clear delineation of function (web tier, business tier, data access tier, anemic model), which is what Spring excels at, or do you want a tighter relationship between your tiers with a framework that manages everything in a much more integrated way (not saying that you can’t achieve this with Spring).
This is what I would term a soft decision - it’s less about technical merit and more about the vibe. Where software design meets gut feel.

Sticking EJB into a Spring app is clunky. It does not sit well. Even the stuff that you may have considered EJB for in that past have equivalents in this new world. Remoting (largely out of favour in preference to WS), listening on the end of JMS queues (which I like MDBs for) have nicer corresponding elements that sit better in Spring.

The application style is up to you at the end of the day. Whether you like the full prescribed JEE stack using EJB, or mix and matching the frameworks that you are productive in with Spring, run with it. Just keep in mind the problems that each piece of your application is trying to solve, and don’t double up. It will only make your applications unnecessarily complex.

As a side note, my current project has dropped EJB3 from the rest of the (Spring) stack.

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.