Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Remote OSGi services

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



Back to the top