|
| Re: api for advertising services over (zeroconf) Discovery [message #624855 is a reply to message #624853] |
Thu, 23 April 2009 18:20  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Roland,
Roland Tepp wrote:
> Hey,
>
> Some time ago I asked if latest official ECF build (2.1) could be used
> in the context of Eclispe 3.2.2 environment and after looking at the
> possibility discarded it as too risky (unknown subtleties of running
> code that was written to run in newr osgi environment).
>
> I found myself the JmDNS library (the same that is used by ECF discovery
> provider). And wrote my own api (sort of) on top of it.
>
> Since I was not really all too happy with providing the low level manual
> API to the team for advertising their services over Zeroconf SD, I
> decided to "simplify" the process.
>
> Basically I assumed (and I know that this assumption may not hold in all
> cases, in which case the manual process is still available), that the
> osgi service that wants to be advertise itself over Zeroconf would most
> likely want to do that over the entire lifetime of it's existence.
>
> So what I did was to register a service tracker with a custom filter to
> watch for osgi services that contain certain service properties and
> advertise them via Zeroconf when they come up and unregister them as
> soon as the osgi service goes away.
>
> As I was doing that, it struck me that this kind of capability of
> seamless and near effortless pairing of osgi service with autodiscovery
> would be quite welcome as well to the more general audience of the ECF
> users.
>
> Does ECF already have this kind of capability?
Yes. It's in our implementation of OSGi RFC 119 (in these bundles:
org.eclipse.ecf.osgi.services, o.e.e.osgi.services.discovery, and
o.e.e.osgi.services.distribution).
What you describe in terms of pairing osgi service registration with
discovery is very close in concept to what RFC 119 specifies.
The ECF implementation of RFC 119 is unique (as far as I know) in
separating the discovery and distribution protocols from the RFC 119
specified logic for publishing osgi services and creating/using proxies
for them. That is, the RFC 119 discovery implementation (in
o.e.e.osgi.services.discovery) is not tied to either JmDNS, JSLP,
file-based discovery or any other specific discovery approach, but
rather is abstract (i.e. as defined in o.e.e.discovery)...and so can/is
currently implemented by JmDNS/zeroconf, JSLP, and file-based
discovery...and supports any other implementation of the discovery API.
This makes things very pluggable, as if you (for example) wish to use
the RFC119-specified approach for remote OSGi services, but also wish to
use your own custom discovery implementation (with/for example, the
security and/or wide area discovery capabilities you wish), you may do
so...simply by implementing the ECF discovery API. The ECF RFC119
implementation will then use your mechanism for publishing and
discovering the published service.
The same is true for the distribution part of RFC 119...it is supported
via the ECF remote services API...rather than any particular
distribution mechanism...so, it can/does support multiple distribution
providers: r-OSGi, ECF generic, JMS, Riena (hopefully soon) others/your
custom/commercial/whatever provider.
My intention and desire is to blog about this aspect of ECF's
implementation of RFC 119 and the choice/advantages it presents as much
as I can, given time before Galileo.
Thanks,
Scott
|
|
|
Powered by
FUDForum. Page generated in 0.03207 seconds
] 
Search
Help
Register
Login
Home
