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: