Re: [ecf-dev] Remote OSGi services

[Eugen Reiswich <reiswich@xxxxxx>]

Thanks Scott, thanks Markus for your help! I will have a look at the  
described sources.

Regards,
Eugen


Am 24.06.2008 um 10:11 schrieb Markus Alexande Kuppe:

> 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 [10] already use Zeroconf and SLP  
> simultaneously via the CompositeDiscoveryContainer [4] which  
> showcases how discovery is to be used. It's merely configuration  
> done via an OSGi filter on the ServiceTracker [1][2]. Also the unit  
> tests are a good source for documentation [6]. 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 [3], 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 [5] but it pretty much does what it is  
> supposed to do.
>
> Also keep in mind that jSLP currently suffers from a RFC limitation  
> [7] 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 [8] 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  
> [9]. 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
>
> [1] org.eclipse.ecf.discovery.ui.views.DiscoveryView.getDiscovery()
> [2] org.eclipse.ecf.internal.discovery.ui.Activator.getFilter()
> [3] org.eclipse.ecf.discovery.service.IDiscoveryService.CONTAINER_NAME
> [4] org.eclipse.ecf.provider.discovery.CompositeDiscoveryContainer
> [5] https://bugs.eclipse.org/236828
> [6] org.eclipse.ecf.tests.discovery
> [7] https://bugs.eclipse.org/218308
> [8] http://en.wikipedia.org/wiki/Service_Location_Protocol#SLP_roles
> [9] https://bugs.eclipse.org/235604
> [10] org.eclipse.ecf.examples.remoteservices.server
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev