ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  POJO Application Frameworks: Spring Vs. EJB 3.0
Subject:   Spring and EJB3.0. share commonality but they are not the same thing.
Date:   2005-08-17 10:56:07
From:   pankajtandon
Response to: Spring and EJB3.0. share commonality but they are not the same thing.

I agree with the above statment.
Altho it is interesting to read about the implementaion differences between EJB30 and Spring, to me, whether I will use EJB or Spring will depend on if my usecase needs EntityBean caching and remoting or not. As far as I can see, bean caching and remoting are the only things that Spring does not provide.


  • Transactions in EJB30 are via a SessionBean deployment descriptor(via an annotation on a POJO). In Spring, the transaction service is injected via an app context (in an XML config file). And we have the liberty to choose any transaction manager (maybe a jta impl, if we like)


  • Persistence is provided via a PersistenceManager of your choice (EJB30's is Hibernate, altho I think EntityManager is another one?) and in Spring you can choose any you like (iBatis, Hibernate, TopLink).


  • EJB30 EntityBeans will provide Bean caching in the EJB container which is absent in the case of Spring. So IF my usecase requires it, I will feel comfortable to implement some of my POJOs as EJB30 EntityBeans and others (where no caching is needed) as POJOs that accept a service context object via IOC using the Spring Framework.


  • Again if my usecase needs remoting where I see that I am placing my business objects on a different machine than my webapp, then surely, I will consider building a component as an EJB30 session bean (mostlikely) or an EnityBean


    So if these 2 'sevices' are needed, then the Spring vs EJB debate in my mind will clearly move in favor of EJB. However , in other cases where caching and remoting are not an issue, I see clear benefits with Spring becasue I am not interjecting a heavy container for something I don't need.


    And as far as complexity is concerned, sure, the developer will have to know more in Springland.. afterall, you are picking and choosing what you need. In EJBLand tho' you get the whole enchilada.. easier to develop.. debugging tho (when you have to step thru remote stub and generated code) is another story.


    My 2c


    Pankaj



    be clearin the I think Spring and EJB30 can peacefully co-exist in the same environment without stepping on each other.