Hi Mirko,
Mirko Jahn wrote:
Hi Eugen,
I have to admit, that I am not familiar with ECF and I don't know how
tight it is coupled to Equinox/Eclipse, but as long as you rely on RFP
119 of the upcoming OSGi R4.2 specification, it doesn't really matter
if the implementation is young or not.
This is correct...i.e. relying on RFP 119 would/will/does allow you to
use multiple distribution providers.
A couple of points about this from our perspective:
a) ECF's implementation of RFC119 is layered on top of the ECF remote
services API.
b) The 4.2 spec is unfortunately not finalized wrt RFC119, and will be
going through some changes over the next few months.
c) RFC119 doesn't specify anything wrt asynchronous messaging patterns
(e.g. one-way, etc)...and ECF remote services does provide this for
those that need it. Asynchronous messaging support is specifically
accomodated in RFC119 as external to the current spec (i.e. not
specified in spec, but providers/implementers are not prevented from
implementing).
But in general you are right...within the completed spec, using RFC119
can/could accomplish these same goals of using alternative distribution
providers for plain 'ol RPC. In any event, I request that we move any
more detailed discussion about ECF specifically over to ecf-dev at
eclipse.org.
Scott
You should be able to switch
the remoting implementation without affecting your clients. At least
this was the idea behind the spec. Just my 2 cents. Maybe Scott can
elaborate on this further...
Cheers,
Mirko
On Wed, May 20, 2009 at 2:30 PM, Eugen Reiswich
<reisw...@informatik.uni-hamburg.de> wrote:
Hi Scott,
thanks for the clarification, I indeed misunderstood some concepts behind
ECF. I will consider your statement for our next project although I fear to
run into truble with our project lead if I try to convince him to use the
young ECF technology rather than matured RMI or something similar.
Regards,
Eugen
Am May 19, 2009 um 23:18 schrieb Scott Lewis:
Hi Eugen,
Eugen Reiswich wrote:
Hi Scott,
ECF is definitely one approach (and it does it really good) but since it
is not the only one remote framework I'm looking for a way to decouple my
bundles from any technology as much as possible. The goal is to be able to
switch from ECF to Riena or RMI or some other technology with a minimal
effort.
Yes, I understand this desire.
But one thing to clarify: I think it's a common misconception that ECF's
remote services API is actually a peer technology to Riena, RMI, r-OSGi,
CXF, SOAP-based web services, etc. It is *not* this. The remote services
API is just an abstract remoting/distribution API *separate* from any/every
implementation. Of course, ECF also has provider/implementation bundles
that implement the rs API, and we have several of these ...e.g. based
upon/using r-OSGI, RMI, JMS, XMPP, and we expect soon Riena and others.
So, clients that use the remote services API (and/or our RFC 119
implementation...which is layed on top of the ECF remote service API) have
no effort to move to some other technology for distribution. I see that as
one of the main advantages of separating out API from implementation
technology for remoting/distribution...and given the frequency and the
traditional difficulty of what you are doing (moving to some other
distribution technology) we think this advantage is significant.
In any case, sorry to all for the long-windedness on this point...but
we've been what I consider mischaracterized before as being a
peer/competitor with other distribution technologies...and so I wanted to
clarify this point.
Scott
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
