The news for today…I’m rather excited to report…is that we now have a working implementation of RFC 119, with support for both discovery and distribution parts of the specification.  This will be part of the ECF 3.0/Galileo release, and of course we will be talking about it in Markus’ and my tutorial, as well as some other talks.

What’s So Cool About Yet Another Spec Implementation?

In my view, what makes this implementation interesting and useful is that we’ve used the abstract ECF discovery and remote services APIs to implement this spec, meaning that without doing any other work, RFC compliant distributed OSGi services are supported using the following transports

Distribution

• r-OSGi (http)
• XMPP
• ECF Generic
• Skype
• Java Messaging Service (JMS)
• JavaGroups

Discovery

• Service Location Protocol (RFC 2608)
• Bonjour/Zeroconf/DNS-SD

And, of course any other transports that people are willing to create, as the ECF remote services API is completely open.

Our desire/hope is that others will implement ECF providers built from other protocols/transports of their choosing (both commercial and open source)…with the payoff to them being that they will then automagically have a RFC 119-compliant implementation…since all ECF providers are now RFC 119 compliant (and will remain so, as we will update the impl as the spec changes).  All the existing implementations done by the ECF team (e.g. r-OSGi, ECF generic, etc) are open source and so may be used/reused to create new providers as desired.

Another thing that I think is cool is that even though RFC 119 specifies using transparent proxies for accessing remote OSGi services, it allows (and even encourages) implementations to support non-transparent/asynchronous remoting (i.e. using one-ways, asynchronous rpc, and futures).  ECF’s remote services API already has support for futures, and asynchronous/non-blocking remote invocation via its IRemoteService interface.

With our current impl of RFC 119, clients can access the IRemoteService instance (in addition to or instead of the proxy), via a standard service property on the ServiceReference.  This gives clients a runtime choice of whether to access a remoted service via a proxy…or via asynchronous/non-blocking techniques like futures and one-ways.

One final thing…the size cost for the ECF remote services API is fairly small (<60k of code) next to the size of the implementations…making it possible to use in smaller (as well as larger) execution environments.

ECF now has a set of plugins that serve as a bridge between the RFC 119 spec (see part 1) and ECF’s discovery and remote services API (note:  all the following plugins begin with ‘org.eclipse.ecf’ and can be found in /cvsroot/rt/org.eclipse.ecf/framework/bundles at dev.eclipse.org):

1. osgi.services
2. osgi.services.discovery
3. osgi.services.distribution

The osgi.service bundle only contains the classes that are included in the OSGi 4.2 compendium, i.e. interfaces such as DiscoveryProvider, DiscoveredServiceTracker, and DistributionProvider.  These interfaces are defined by the OSGi Enterprise Experts group, and are part of the RFC 119 specification.  The implementation is from the OSGi Alliance, as are other parts of OSGi that are implemented in Equinox.

RFC 119 is divided into two parts:  1) service discovery; 2) service distribution.  Service discovery is optional, and service distribution is required.

The osgi.services.discovery bundle implements the RFC 119 discovery and uses ECF’s discovery API to implement protocol independent network service discovery.   There are two existing provider implementations of the ECF discovery API right now:  zeroconf/bonjour and SLP…so users will be able to publish their services automatically over both SLP and zeroconf discovery mechanisms with a single service publication.

Similarly the osgi.services.distribution bundle implements RFC 119 distribution using ECF’s remote services API.   When this is complete, it will mean that without any additional coding, remote services will run immediately on the following transports:

1. r-OSGi/http
2. TCP/ECF generic
3. XMPP/XMPPS
4. Skype
5. JMS – ActiveMQ, Weblogic JMS
6. Others under active development:  EMF/CDO, http-with-rest

Further,  the ECF remote services API also allows non-transparent access to remote services, in order to support asynchronous remote method invocation, one-ways, futures, explicit failure handling, and other features not part of RFC 119 at this point.

Note also that other providers that implement the ECF remote services API will automatically be RFC 119 compliant…i.e. they have to do no work to be compliant with RFC 119 for transparent remote procedure call.  Further, with ECF remote services, if clients wish to use non-transparent remoting…in combination with or in exclusion to transparent remoting…that is also available.

We’re closing in as rapidly as we can on having this all ready and working…and EclipseCon 2009 is coming up fast…so stay tuned.