Women in Technology

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-07-07 11:32:43
From:		TS133T
EJB3.0 is still meant for distibuted computing and transaction. Spring on other hand is an integration framework between different standards and programing environments. I believe this needs to be stressed otherwise you will see people tend to program non distributed services as EJB 3.0 and abuse them the same way as SessionBeans are abused.

Showing messages 1 through 1 of 1.

• Spring and EJB3.0. share commonality but they are not the same thing.
  2005-08-17 10:56:07  pankajtandon [View]
  
  
  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.