Released 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