[ecf-dev] Re: [osgi-dev] Best practice to decouple remote technology fro

[Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>]

Hi Eugen,

I think this discussion should be moved over to ecf-dev at eclipse.org 
so I'm going to repost it there and respond in that forum with comments 
WRT ECF.

Scott


Eugen Reiswich wrote:
> Hey folks,
>
> as I understand ECF is a layer above a specific remote communication 
> technology (like RMI) and it's various APIs can be used without the 
> knowledge of the underlying remote technology. But as far as I 
> understand there has to be an ECF specific implementation for a remote 
> communication technology which acts as a communication bridge between 
> the ECF API and the underlying technology. If this is the case I would:
>
> 1. need to wait for a new ECF implementation for RCF 119
> 2. hope that the ECF implementation is as reliable as the underlying 
> technology
>
> If this is correct I would on the one hand decrease the dependency to 
> a specific communication technology in my code but I would on the 
> other hand create a new one to ECF.  What if the ECF implementations 
> are too buggy for business applications? 
> How much effort do I have to spent to switch to pure RMI/Riena etc. 
> without ECF?
>
> I would like to decouple my application completely from a specific 
> technology and use the plug-in concepts of OSGi to add e.g. an RMI 
> bundle for RMI communication, ECF bundle to switch to RMI over ECF or 
> something else but without code changes in my main application.
>
> Regards,
> Eugen
>
>
> Am May 23, 2009 um 3:33  schrieb Jeff McAffer:
>
> > Eugen,
> >
> > Just FYI, you don't actually have to wait.  As Peter aluded, there 
> > are several implementations available now.  The spec appears to be 
> > undergoing change but if you want to get started and are willing to 
> > adapt when the spec settles knock yourself out.  I have used the ECF 
> > remote messaging to great success in a few cases.  You can do the 
> > current distributed services draft spec style or the native ECF 
> > style.  Plug in different transports, ...
> >
> > Jeff
> >
> > Eugen Reiswich wrote:
> > > Thanks Peter,
> > >
> > > this is exactly what I wanted to know! I will wait for RFC 119...
> > >
> > > Kind regards
> > > Eugen
> > >
> > > Am May 20, 2009 um 17:02  schrieb Peter Kriens:
> > >
> > > > The upcoming R4.2 will provide a Remote Services section that 
> > > > allows you to decouple bundles from the underlying distribution 
> > > > provider. This means that the only dependency in your code you have 
> > > > on the distribution provider is a number of properties + the OSGi 
> > > > service API. These properties should be settable by configuration 
> > > > management. The intention is that you can switch distribution 
> > > > provider without changing your app bundles, only have to change the 
> > > > properties. We are currently working very hard to create the spec 
> > > > based on the RFC 119 for this area and things are still a bit in 
> > > > flux so the RFC 119 is currently unfortunately a bit stale.
> > > >
> > > > ECF, CXF, and others are implementing this specification as 
> > > > distribution providers.
> > > >
> > > > Kind regards,
> > > >
> > > >    Peter Kriens
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 19 mei 2009, at 20:05, Eugen Reiswich wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > we are developing a client/server application with osgi. Say I 
> > > > > have three bundles:
> > > > >
> > > > > 1. client
> > > > > 2. common (includes the service interface and domain value objects)
> > > > > 3. server (includes the service implementation)
> > > > >
> > > > > We've started to develop our application with the remote 
> > > > > technology RMI but switched now to Riena. As it was really a pain 
> > > > > to remove all RMI dependencies from our code (e.g. all 
> > > > > RemoteExceptions)  I wonder if there is a best practise approach 
> > > > > how to achieve a loose coupling of a specific remote technology in 
> > > > > our osgi bundles without using tons of wrappers.
> > > > >
> > > > > Regards,
> > > > > Eugen
> > > > > _______________________________________________
> > > > > OSGi Developer Mail List
> > > > > osgi-dev@xxxxxxxxxxxxx
> > > > > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > > >
> > > > _______________________________________________
> > > > OSGi Developer Mail List
> > > > osgi-dev@xxxxxxxxxxxxx
> > > > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > >
> > > _______________________________________________
> > > OSGi Developer Mail List
> > > osgi-dev@xxxxxxxxxxxxx
> > > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@xxxxxxxxxxxxx
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@xxxxxxxxxxxxx
> https://mail.osgi.org/mailman/listinfo/osgi-dev