|Re: [ecf-dev] Remote OSGi services|
Eugen Reiswich wrote:
Now I've found the ECF discovery service (http://wiki.eclipse.org/Discovery_of_Remote_Services) and wonder if this might be the right approach for me. Although I tried to get familiar with the code I didn't get the important steps.Could please anybody tell me if the discovery service is the right approach in order to find dynamically remote services. And if possible post some code snippet of the important stepts to do (client and server side).
(copied from another mail) Hi,the remote service examples  already use Zeroconf and SLP simultaneously via the CompositeDiscoveryContainer  which showcases how discovery is to be used. It's merely configuration done via an OSGi filter on the ServiceTracker . Also the unit tests are a good source for documentation . The unit tests also show the alternative usage pattern where the discovery service is obtained via the ECF provider fw.
Basically all discovery providers register as org.eclipse.ecf.discovery.service.IDiscoveryService with the OSGi framework. The consumer either handles all providers manually which are identifiable by a service property , or chooses to use the CompositeDiscoveryContainer.
CDC, as the name implies, is simply a container for discovery providers and delegates each call to every registered provider. The code is not perfect yet  but it pretty much does what it is supposed to do.
Also keep in mind that jSLP currently suffers from a RFC limitation  which might cause problems if used with non-default scopes (!= "default") which is e.g. used with Zeroconf ("local"). Jan and me are working on it. Another inconvenience is port 427. A DA as well as a SA  require to bind to that port. If you only want to discover services (UA) setting net.slp.uaonly=true turns jSLP into UA only mode though. Alternatively the port can be changed to some high port (net.slp.port=10427). Obviously this doesn't integrate well with existing infrastructure.
If update sites are modelled as OSGi services, a totally different approach can be taken by using the ServiceRegistry discovery listener which transparently announces all services of a given type . That way the server side wouldn't need to actively announce update sites (getting the discovery server, announcing the service), but would simply register the update site service with the OSGi framework. The discovery listener takes care of the rest.
All this is HEAD, not Release_2_0! Markus  org.eclipse.ecf.discovery.ui.views.DiscoveryView.getDiscovery()  org.eclipse.ecf.internal.discovery.ui.Activator.getFilter()  org.eclipse.ecf.discovery.service.IDiscoveryService.CONTAINER_NAME  org.eclipse.ecf.provider.discovery.CompositeDiscoveryContainer  https://bugs.eclipse.org/236828  org.eclipse.ecf.tests.discovery  https://bugs.eclipse.org/218308  http://en.wikipedia.org/wiki/Service_Location_Protocol#SLP_roles  https://bugs.eclipse.org/235604  org.eclipse.ecf.examples.remoteservices.server
Back to the top