[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[ecf-dev] Re: [osgi-dev] Best practice to decouple remote technology from bundles
|
See below for comments about Eugen's note to osgi-dev.
Scott Lewis wrote:
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
That depends upon what you are waiting for. Do you mean an RMI
implementation of the ECF remoteservices API?
2. hope that the ECF implementation is as reliable as the underlying
technology
If by ECF implementation you mean the ECF provider (i.e. that uses the
underlying technology)...yes, that's true of course. It's true of
others as well (i.e. all implementations)...so we're not unique in
this. The good news about this is:
1) We've created some modularization at the provider implementation
level, which allows provider implementers to reuse code to implement the
remote services API (if they wish, of course). This does have the added
side effect that testing/debugging/hardening the providers that use the
provider modularization improves the other providers that use it as well.
2) We've created a number of abstract test cases that are present so new
provider implementations can be tested (against the remote services API
and the RFC119 impl) without having to rewrite new tests.
But just to return to your original point...yes, the ECF implementation
does have to be as reliable as the underlying technology...yes, this is
true. But we're working toward making this as easy as possible for
provider implementers (i.e. may or may not be us/ECF team).
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.
Your new dependencies would be on the API, rather than on the
implementations.
What if the ECF implementations are too buggy for business applications?
It is always possible that implementation issues would create problems,
of course...although I'm not sure if I would use 'too buggy for business
applications' as the appropriate bar ;-). Further, with network
protocols it is possible that the choice of *approach* (i.e. not the
software, but rather the protocol) will affect things like reliability.
How much effort do I have to spent to switch to pure RMI/Riena etc.
without ECF?
It's hard to answer this in general...because each provider
implementation will differ in how it's structured. So, for example, it
is/would be trivial to switch from using ECF remote services to (say),
r-osgi...because r-osgi is implemented as a separate plugin, has an
existing API, has been well-designed for remoting osgi services (that
was it's original intention), etc. I expect the Riena provider (once
completed) to be similarly easy, as it also was originally designed for
doing osgi distribution/remoting as well.
OTOH, there's more to mapping RMI to OSGi remoting...because RMI has no
concept of a service registry, no concept of service references (local
or remote), and further RMI introduces/requires RemoteException (as you
know). So that one thing alone (RemoteException) can change the face of
the service interfaces themselves (i.e. your code) significantly. But
with ECF remote services you can use any service interface you wish
(i.e. with RemoteException too). So there really isn't any work
*required* to move between ECF and RMI remoting WRT the service
interface itself.
However, like I said above, in RMI there's no concept of services at
all...so all of those concepts will/are lost when moving to 'pure' RMI
only. So there *is* work in an RMI provider in implementing the
concepts around (e.g.) retrieving remote references
(getRemoteServiceReferences), registering remote services
(registerRemoteService) and some other things.
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.
I'm actually thinking that yours is not so much a question about RMI or
ECF, but rather one of differences between OSGi's model of services
(whether remoted or not), and RMI's notion of 'simple' remote objects.
It's the support of the OSGi service registry concepts that adds on the
work for remote services APi implementers...not the service interface
itself.
Hope this addresses some of your questions WRT to what's necessary to
create/use an ECF remote services API provider. If not please say so
and we'll discuss further.
Scott