Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Planned Discovery UI contribution

Scott Lewis wrote:
> One other thought...with the enhancements to ECF discovery API by
> Markus, and the use of jSLP (an standard service locator protocol) to
> implement an ECF discovery provider (which Markus has graciously already
> offered to contribute) and the work on the remote services API, one
> architectural issue that I've been recently wrestling with is the
> following:  we *could* very easily add a dependency on the ECF discovery
> API to the ECF remote services API.  In that case, the discovery API
> could/would be used to asynchronously discover ECF remote services...and
> then either explicitly use the ECF remote services API, or transparently
> use it with services registered with the OSGi services registry as
> remote (like r-OSGi does now).
> Of course this would mean creating a compile-time dependency of
> org.eclipse.ecf.remoteservices (the RS API bundle) on
> org.eclipse.ecf.discovery (the discovery API bundle).   This isn't a
> major 'loss' in any sense, however, since the org.eclipse.ecf.discovery
> bundle has a OSGi 1.0 ee minimum (and so does the remote services
> API) it would not increase the runtime requirements for remote
> services.  It would, however, increase the runtime size of remote services.
> In any event, please let all know what you think...about such a
> dependency...I'm just floating a trial balloon at this point.
> Scott


do we really need the compile time dependency? With a slightly different
architecture I think we might get around it. With the
CompositeDiscoveryContainer CDC in place
(, we could build
it in a way that we use the SLP/ZeroConf/... containers for the
discovery of the remote OSGi runtimes. The newly written
RemoteServiceRegistryContainer would then listen for discovery events at
the CDC of the OSGi type and then query the remote runtime for services
and announce them via the CDC itself. For the discovery consumer this
would be totally transparent and even configurable. If the consumer
doesn't need OSGi remote service discovery, he simply doesn't register
the container.


Back to the top