[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