RFC 119 and ECF – part 2

RFC 119 and ECF – part 2

Some time ago, I blogged about RFC 119 and ECF part 1, so now it’s time for part 2…

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
  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.

No Comments

Sorry, the comment form is closed at this time.