Re: [Springframework-developer] EJBs vs POJOs

[Eugene K. <eu...@ja...>]

Paul,

   There is nothing wrong with using EJB as a remore facade. That will 
give you standard access to J2EE services (JTA, remoting, failover, 
clustering). In my current project we are using the following pattern:

   EJB Layer (Stateless and MDB without any business logic)
   Spring managed POJO's (IoC + AOP + componentization)
   Persistance (DAO, CMP beans)

   This way EJB layer is used as a remote facade and all business logic 
is easily testable outside of J2EE container and allow to hook up 
aspects and nicely manage dependencies. We also found that CMP layer 
with caching provided by J2EE container perform quite well in some cases 
(especially when cluster-wide cache between transactions is turned on), 
but in some cases caching aspects allow additional performance improvment.

   regards,
   Eugene


Garvey, Paul M (GE Commercial Finance) wrote:
> James,
>       Your response was insightful and you did partially answered my question.
> Let me try to be a bit clearer, If I had to create an application that needed to
> be distributed across multiple machines I would normally use EJBs (stateless Bean + Entity Beans)
> or (stateless beans + DAOs) or (stateless beans + hibernate) etc. Could I use Spring
> in this senario? Would it make more sense to stick with the EJB paradigm? I want to have a clear picture 
> in my mind of when to use Spring on a project and when to use EJBs. In other words, 
> when does it make most sense to use EJBs instead of Spring and vice versa?
> Are there times when Spring is just not the solution to the problem and EBJ is?
> 
> Paul
> 
> 
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of James Cook
> Sent: Thursday, April 21, 2005 5:25 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] EJBs vs POJOs
> 
> 
> Spring simply provides a convenient façade to other persistence
> implementations, including EJB!
> 
> You may have meant Entity Beans when you stated EJB. If so, another
> way of wording your question is, "Are there cases when EJB is
> preferred as a persistence mechanism over a POJO persistence
> (Hibernate, TopLink, iBatis, JDO, EJB3, and dozens of others)
> mechanism?"
> 
> Take these with a grain of salt, since I don't have hands-on
> experience with all of the POJO persistence mechanisms. A few benefits
> don't come easily to the world of POJO persistence.
> 
> a) POJO-based approaches (AFAIK) with the exception of EJB3, do not
> support distributed security contexts. Even if you were writing an EJB
> implementation, you would want to limit the number of network calls
> your app has to make. But if you really have part of your application
> on one machine, and part on another, you can invoke EJB's on the
> various machines and remain within the same security context.
> 
> b) Clustered sessions are still the realm of the J2EE container.
> Distributed caching of persistent object between machines is difficult
> to achieve using POJO persistence.
> 
> c) Support for CORBA clients is a standard feature of J2EE.
> 
> There may be more. Of course, EJB3 will probably turn this discussion
> on its ear.
> 
> If I totally missed your point, and you just wanted to know if Spring
> provided lightweight (sorry Hani) alternatives for the specification
> components that make up Enterprise Java Beans (EJB), namely:
> 
> - Stateless Session Bean (yes, via service interfaces, pojos you write)
> - Stateful Session Bean (no)
> - Entity Bean (yes, via Hibernate, TopLink, iBatis, JDO passthrus)
> - Message Driven Bean (No, AFAIK)
> - Timer Bean (yes, via quartz)
> - Web Service Endpoints (yes, via http invoker, hessian, burlap, axis, maybe
> others)
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On 
>>Behalf Of Garvey, Paul M (GE Commercial Finance)
>>Sent: Thursday, April 21, 2005 3:53 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] EJBs vs POJOs
>>
>>All,
>>
>>I fairly new to Spring and I am currently reading some documentation 
>>on it. I have bought into the concept of the lightweight feature of 
>>Spring. I do have a quick question, Springs seems to handle every 
>>scenario that I would
>>use EJBs, is there a few cases where EJBs are unavoidable to use? In other
>>words
>>are there any scenarios where Spring is just not the best tool to use and
>>EJBs is
>>the more suited? Any thoughts?
>>
>>Paul
>>