Re: [Springframework-developer] Are there scenarios where EJB is a better option than Spring?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I have almost zero knowlege in spring remoting and do not have
extensive experience in EJB remoting but would bean level clustering
be considered another differences between the two?   Can
spring-remoting provide failover/clustering solution the way EJB
(supposedly) does?

On 11/5/05, Juergen Hoeller <ju...@in...> wrote:
> Spring Remoting and Remote EJBs are quite different solutions to the same
> problem - actually, different in style more than different in capability.
>
> Spring Remoting follows the philosophy of taking existing POJO service
> instances and exporting them under a given protocol, at a given URL, with
> configurable protocol. Exporting the same service instance with different
> protocols *at the same time* is straightforward: simply define multiple
> exporters at different URLs, with each exporter pointing to the same serv=
ice
> but talking a different protocol. The target service instance can be any
> existing application service, as long as it's suitable for remoting (i.e.
> has serializable arguments etc).
>
> The supported protocols include Hessian, Burlap, HTTP invoker, traditiona=
l
> RMI and RMI invoker - both using any RMI protocol internally, be it JRMP,
> IIOP or WebLogic's T3. Furthermore, there's also support for Web Services
> via a JAX-RPC provider (such as Axis). The only environment required is a
> plain Servlet container, or even just a plain JVM in the case of RMI. No
> special class loaders get created; Spring's remoting seamlessly nestes in=
to
> an existing environment, exporting existing local application services wh=
ere
> needed.
>
> Remote EJBs on the other hand are based on the explicit notion of a remot=
e
> component that you have to implement based on a strict component model. S=
uch
> a component then gets deployed; binding it do a specific protocol and URL=
 is
> part of the (partly server-specific) deployment step. Binding to multiple
> protocols at the same time means deploying your Remote EJB multiple times=
,
> with different EJB instances representing each deployment.
>
> Of course, remote EJBs just work within an explicit EJB container, based =
on
> a specific deployment unit and running in their own class loader. EJBs ge=
t
> deployed separately; they are effectively not plain remote service facade=
s
> but rather fully self-contained application components that natively have=
 a
> remote service interface. EJBs are not made for exposing some existing
> application service but rather for building self-contained remote service=
s.
>
> So the main difference is essentially the configuration and deployment
> model. If all you want is export some remote services from an existing
> application, take Spring Remoting, in particular if the existing applicat=
ion
> is a WAR file or a standalone application (running outside of a J2EE
> server). If you want to build self-contained remote components that you c=
an
> deploy on their own and that are not an inherent part of an overall
> application, take remote EJBs.
>
> Remote EJBs also offer stateful remoting as a central part of the compone=
nt
> model, while Spring Remoting is primarily about stateless remoting - just
> like Web Services are stateless. So if you have a strong need for remote
> sessions, remote stateful session EJBs are a straightforward solution.
> However, double-check whether you actually need stateful remote sessions;
> stateless remoting is inherently much more scalable.
>
> A further advanced feature of remote EJBs is remote transaction propagati=
on,
> that is, a client-side transaction getting propagated to remote services.
> This is in most cases architecturally undesirable, though, and not genera=
lly
> supported by all J2EE servers. If you really need this feature, you could
> also consider using Spring's RMI support in conjunction with your J2EE
> server's RMI subsystem: for example, with WebLogic RMI, which offers
> seamless propagation of the transaction and security context.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> Garvey, Paul M (GE Commercial Finance)
> Sent: Friday, November 04, 2005 2:03 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Are there scenarios where EJB is=
 a
> better option than Spring?
>
>
>
> Yes, I was actually on page 9 :-) Anyway, thx
>
> On page 11 of "Expert One-On-One J2EE Development without EJB" it States
> that EJBs is the best solutions for application that need object
> distributed.
> Why is this a better solution than Spring Remoting? Is it the the EJB
> container provides Better support for distribution than Spring?
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> James Cook
> Sent: Thursday, November 03, 2005 2:51 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Are there scenarios where EJB is=
 a
> better option than Spring?
>
> You must be in the single digits of your reading! :-)
>
> Try Page 11, "Should We Ever Use EJB?"
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> Garvey, Paul M (GE Commercial Finance)
> Sent: Thursday, November 03, 2005 10:19 AM
> To: spr...@li...
> Subject: [Springframework-developer] Are there scenarios where EJB is a
> better option than Spring?
>
>
> All,
> I am fairly new to Spring and I have started reading "Expert One-On-One J=
2EE
> Development without EJB"
> 1. I am trying to find senarios where EJB is a better option
>  than Spring but so far I haven't found any in the book.
>  Just started reading BTW.
> 2. What are some of the weaknesses of Spring? The weasknesses
>  of EJB is well documented by the book.
> BTW, very good book, I intend to read it in its entirety.
>
> - Paul
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>