[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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 [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
