OSGi Remote Services from ECF - Discovery
Join the DZone community and get the full member experience.
Join For FreeReleased in Feb, ECF 3.2 has full support for the OSGi 4.2 remote services specification.
As
with any general technology, there are potentially many use cases for
remoting OSGi services, and any given implementation won't support all
those use cases. It's therefore very important that any technology be
extensible to support use cases that were not envisioned originally.
OSGi Remote Services: A tale of discovery and distribution
In
providing access to a remote service there are at least two
network-created issues that must be addressed for any remoting
technology to work. In this post I'll discuss discovery, and in subsequent posts talk about distribution.
Modularity for Network Discovery
When
a new service is made available...via a server, or a peer, or a device,
etc...any consumers/clients of that service must somehow be made aware
of that service, and given sufficient information to be able to access
that service. A very common example of being made 'aware' of a web
service is receiving (via email, or a web page, or twitter, or
whatever) the URL for that service...e.g. the twitter user status
service URL is http://twitter.com/statuses/user_timeline.json.
With OSGi remote services the notion of a URL is generalized to an endpoint.
As with all OSGi services, service properties provide metadata about
the remote service (including but not limited to the endpoint)...and
this metadata is sufficient for a consumer to actually access/use the
service.
There are potentially many ways to discover a remote service. There are network discovery protocols (e.g. zeroconf/bonjour, Service Location Protocol (SLP), Apache Zookeeper), as well as static xml or other formatted files, custom http-based service registries, etc., etc.
To deal with the required flexibility, ECF has an abstract discovery API (org.eclipse.ecf.discovery). This is a network-protocol-independent
API for discovering things over the network. I use 'things' because the
discovery API isn't only for discovering remote OSGi services, and it
can also be used to discover devices, other applications (an example of
this is that since Apple's iTunes uses zeroconf to publish itself, it's
possible to interoperate with iTunes and/or other iMac and iPhone
applications from within an OSGi runtime).
The providers/protocols that we ship with ECF now are zeroconf/bonjour, SLP, and we have a pending contribution for Apache Zookeeper. We also currently have support for static xml-file-based discovery of remote services and are working on support for use of DNS-SD for wide-area dns-based discovery.
The ECF discovery API effectively separates network discovery into a distinct module,
and allows the reuse of existing network protocol implementations, OR
substitution of one's own approach to discovery to meet custom use
cases (such as discovering remote services only behind a firewall, etc).
This
modularization enables reuse, since all the other parts of ECF's remote
services implementation (e.g. the distribution...i.e. remote method
marshalling/unmarshalling, etc) can be reused without modification.
This is so because ECF's OSGi remote services implementation simply
uses any/all discovery API providers at runtime to publish the remote
service. This makes any new discovery API provider automatically and
immediately compliant with the OSGi remote services specification.
The
reuse and extensibility is a positive side effect of the modularity
provided inherently by OSGi, along with the separation of concerns
built into ECF's implementation of OSGi remote services. In a future
posting(s) I'll discuss the distribution module of ECF's remote
services implementation...referred to as the ECF remote services API.
Reference:
OSGi 4.2 Remote Services
ecf-dev mailing list
From http://eclipseecf.blogspot.com/2010/04/osgi-remote-services-from-ecf-discovery.html
Opinions expressed by DZone contributors are their own.
Comments