Re: [Springframework-developer] EJBs vs POJOs

[Dmitriy K. <dko...@ru...>]

To put simply - if you absolutely require to physically distribute your=20
application, EJB (SLSB facade) would probably be the good choice here.=20
Please note that you still would want to use Spring-EJB support as it=20
transparently exposes your POJO business interfaces as EJB=20
implementations (via proxies) and also frees the application code from=20
low level plumbing code related to EJB programming model e.g. JNDI=20
lookups, etc. Coupled with IoC container (for DI) you get easy testable=20
code with minimal dependence on EJB container.

Regards,
Dmitriy.

Garvey, Paul M (GE Commercial Finance) wrote:

>James,
>      Your response was insightful and you did partially answered my que=
stion.
>Let me try to be a bit clearer, If I had to create an application that n=
eeded to
>be distributed across multiple machines I would normally use EJBs (state=
less 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=20
>in my mind of when to use Spring on a project and when to use EJBs. In o=
ther words,=20
>when does it make most sense to use EJBs instead of Spring and vice vers=
a?
>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=E7ade 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, m=
aybe
>others)
>
>
>
>
> =20
>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On=20
>>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=20
>>on it. I have bought into the concept of the lightweight feature of=20
>>Spring. I do have a quick question, Springs seems to handle every=20
>>scenario that I would
>>use EJBs, is there a few cases where EJBs are unavoidable to use? In ot=
her
>>words
>>are there any scenarios where Spring is just not the best tool to use a=
nd
>>EJBs is
>>the more suited? Any thoughts?
>>
>>Paul
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real=20
>>users. Discover which products truly live up to the hype. Start=20
>>reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
>>_______________________________________________
>>Springframework-developer mailing list=20
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>   =20
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>