[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] Re: More interfaces on remote OSGI services page
|
These two documents shine brightly for me in regards to distributed
OSGi:
flowSGi - Collaborative middleware for mobile devices
http://www.iks.inf.ethz.ch/publications/files/flowSGI.pdf (Jan would
make an ideal ECFer...)
A Note on Distributed Computing
http://research.sun.com/techrep/1994/smli_tr-94-29.pdf
Regarding this topic as a whole, an implicit transition has been made
from "Eclipse" to "OSGi". They are different worlds with different
problem domains, and I have been pondering the pluses and minuses of
ECF in a pure OSGi context. The value of ECF in the Eclipse context
is clear, but it's value (in relation to other solutions) at the OSGi
level is ambiguous to me. It's tricky because OSGi has some very
compelling native services that seem ripe for utilizing in a
distributed manner (Event Admin, Device Service). Again from
yesterday's phone conversation it really depends on your
application. But given "A Note on Distributed Computing", does it
make sense to represent a remote service transparently in an OSGi
runtime? Is there merit in distinguishing Eclipse-ECF and OSGi-ECF?
-Ken
On Jul 10, 2006, at 5:46 PM, Scott Lewis wrote:
Hi Bob, Ken, and all,
This afternoon I put some more of the ideas for OSGI remote service
API that I've been playing around with here:
http://wiki.eclipse.org/index.php/Remote_OSGI_Services
Note as usual for ECF :-) this says exactly nothing about how these
APIs would be implemented...e.g. they could be implemented with
some existing RPC mechanism, or via RPC built on asych messaging
(e.g. ecf generic). Clearly I think of missing functionality as a
feature :). Also, as discussed during the conf call today the
actual implementation bundles (e.g. whether they are dynamically
loaded/installed or rather must be there to begin with) is left
unspecified...meaning that (for example) a call to
getRemoteServiceReferences could actually retrieve the bundles
holding the proxies associated with the given remote service. I
think that's a pretty exciting idea, actually.
Also note that the intention here was to present to remote clients
an OSGI service interface that 'looks' a fair amount like the OSGI
'local' service interface (e.g. BundleContext.registerService,
BundleContext.getServiceReferences, BundleContext.getService,
etc). This may/may not be a good idea...as Ken hinted at during
the call...that is, it's not clear whether a remote service
interface is best...or some way to access remote bundle code, or
certain packages, within bundle, etc. The process-local OSGI
service concept, though, is at least one that is standardized by
OSGI itself...and used in Eclipse and other RCP apps.
Any thoughts/comments/criticisms/'you are crazy's appreciated.
Scott
