This post on the OSGi.org blog is relevant to this discussion:
-Ken
On Sep 12, 2006, at 9:30 PM, Jeff McAffer wrote: Sounds like fun! I have not been following the ins and outs of ECF much so please excuse any ignorant questions... - do you see a path to this being integrated with declarative services and/or Spring and whatever Spring does for remoting? - do you see integrating with/using concurrency constructs like Futures whith remove services? - can I assume that under the covers you can use any transport to contact the remote service? - do you know where I can find some spare time to play with all the great things people are creating these days? ;-) Jeff Hi Folks, Although not completed, a 'signs of life' ECF remote service API is now functioning with test code. The intention of this API is to provide access to remote services similar to the manner in which OSGI provides access to local services via OSGi service registry. The remoteservice API, however, is *not* the same as the OSGi service API, in recognition/acknowledgment of the problems introduced by approaches that attempt network transparency. The remoteservice API exposes a distinct API and underlying service registry, similar in structure to the OSGi services API, but with modifications to account for 1) the use of asynchronous messaging; 2) partial failure. The three plugins in CVS are: plugins/org.eclipse.ecf.remoteservice (API) plugins/org.eclipse.ecf.provider.remoteservice (exampleprovider) plugins/org.eclipse.ecf.test.remoteservice (JUnit Plugin test code) As a brief example, here's how a remote service is registered/made available for remotes to access. This is done on the client that is the server for this particular service // First get IRemoteServiceContainer adapter IRemoteServiceContainer rsc = (IRemoteServiceContainer) container.getAdapter(IRemoteServiceContainer); // Then register remote service rsc.registerRemoteService(new String [] { IMyService.class.getName() }, service, null); Note that the 'service' object must implement the IMyService. Assume that IMyService has a single method "exec()". For those familiar with the OSGI service interface, this looks very much like the BundleContext.registerService method. Then, on the client that wishes to use the service: IRemoteServiceReference [] refs = rsc.getRemoteServiceReferences(null, IMyService.class.getName(),null); // Assume we want the first one IRemoteService remoteService = rsc.getRemoteService(refs[0]); // Now call service with one of methods on IRemoteService: callSynch, callAsynch, fireAsynch, getProxy() Note the getRemoteServiceReferences(...) and getRemoteService(...) are similar to the OSGI BundleContext.getServiceReferences(...) and getService(...) methods. The methods on IRemoteService allow the client to invoke the service in several different ways...i.e. synchronously (callSynch) or asynchronously (callAsynch...with a listener callback for results, and fireAsynch which fires a remote method asynchronously with no return value). Note also the 'getProxy()' call, which will return an Object *that is guaranteed to implement the IMyService interface*. Meaning that one can do this: IMyService proxy = (IMyService) remoteService.getProxy(); proxy.exec(); And the remote 'exec()' method will be remotely invoked. So the point of the IRemoteService interface is to allow the client to control how the remote service invocation is done...synchronously with return value, synchronously via proxy, or asynchronously with (callAsynch)/without (fireAsynch) return value. There's test code in the org.eclipse.ecf.test.remoteservice test plugin that uses these methods on IRemoteService interface. I've made put project set files for committer and anonymous cvs access here: http://wiki.eclipse.org/index.php/Remote_OSGI_Services Any comments/criticisms/flames welcome. This is just an initial "signs of life" attempt, and the API and implementation will likely go through many changes. Thanks, Scott _______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________ ecf-dev mailing list
|