[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Re: [osgi-dev] Best practice to decouple remote technology from bundles
|
Hi Scott,
Thanks for your detailed answer. As I have already used ECF now for
about one year I see the advantages of this technology. But I do also
have to convince my project lead and other colleagues of the
reliability and sustainability of ECF. Thanks to your mail I can now
bring forward some arguments that might be helpful for a decision.
Regards,
Eugen
Am May 25, 2009 um 2:28 schrieb Scott Lewis:
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
