| Re: [ecf-dev] Problem using multiple services from single server |
|
Hi Tim and Peter,
I don't mean to circumvent Tim's request of Peter...i.e. I think it would be great if Peter shared a description and/or sample of how he solved his needs to control the import. I wanted to supplement this discussion with a bit of description of 'how ECF RSA works'. For those that want more and/or all the gory technical and specification details, I refer people to this page [1]. But here's a 'short' version, that will hopefully give some useful context without having to read and understand the RSA specfication. According to the RSA spec, there is a standard service: org.osgi.service.remoteserviceadmin.RemoteServiceAdmin that is responsible for exporting a remote service (i.e. on host) via exportService method call, and importing a remote service (on consumer) via call to importService. The question of *when* these methods are called is determined (again by spec) by an entity in a role called a TopologyManager. On a remote service consumer/client the topology manager defines the connection between RSA discovery (i.e. of EndpointDescriptions) and calling importService. The RSA spec...and ECF's implementation of course...allows whatever connection between EndpointDescription discovery and importService that is needed/desired. By default, ECF provides a 'BasicTopologyManager' [2]. That implements the following policy: Whenever a EndpointDescription is discovered (i.e. via *either* edef bundle start/BundleTracker *or* network discovery), the RSA importService method is called. You can see this in the impl at [2] if you want...the method 'handleEndpointAdded' is called an it turns around and calls AbstractTopologyManager.handleECFEndpointAdded, which is implemented like this: // Import service getRemoteServiceAdmin().importService(endpointDescription); I believe that what Peter is probably doing (he can confirm or deny this of course) is probably calling the RSA.importService method *via his own code*, rather than having it called via the BasicTopologyManager. Then he can control precisely *when* the importService call is made, as well as the remote service unregistration if he wants to. There is absolutely nothing wrong about this. It's just a more direct programmatic control over the call to RSA.importService. Note that you can do this in addition to the BasicTopologyManager's behavior, or you can could completely *replace* the BasicTopologyManager if you want to. There's absolutely nothing wrong with replacing the BasicTopologyManager, it's allowed by spec, and it's allowed/encouraged/supported explicitly by ECF' s implementation. For example, o.e.e.osgi.services.remoteserviceadmin.AbstractTopologyManager has been written and designed specifically to ease the implementation of other TMs. I've also been contemplating implementing other TMs for other use cases (e.g. a *remote* TM), that's the reason for this repo at github [3]. Nothing there yet, mostly because of time/resources as well as deciding on community-desired use cases. What I potentially envision here is a palette of TMs, with different capabilities and policies, all available for selection and/or extension/customization. As an aside, ECF's impl of RSA also provides a number of services internally, that allow the customization of ECF's RSA impl in various ways. For example, it's possible to substitute other ways of creating the proxy on the remote service consumer, either for each container type separately, or for all containers. And it's possible to replace the container selection approach with one's own, or just extend/customize what's there. Hope this helps provide some technical context. Scott [1] https://wiki.eclipse.org/Remote_Services_Admin [2] org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl file located in git here: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/compendium/bundles/org.eclipse.ecf.osgi.services.distribution/src/org/eclipse/ecf/internal/osgi/services/distribution/BasicTopologyManagerImpl.java [3] https://github.com/ECF/OSGIRemoteServiceAdmin On 3/20/2015 7:21 AM, Timothy Vogel wrote:
|