RFC 119 and ECF – Part 1

There seems to be a lot of interest in doing distributed services with OSGi/Equinox, and so I wanted to begin a series of postings about what the ECF project is doing in this area (short story: a lot), and what we are planning for supporting standardization via RFC 119.

What is RFC 119?

First, here is the OSGi 4.2 early draft, which includes a draft of RFC 119 (toward end of PDF).  RFC 119 is an effort to standardize some aspects of creating, publishing, discovering, and accessing out-of-process OSGi services.  It is not yet complete, but is quickly moving toward standardization.

What is ECF Doing with Discovery and Remote OSGi Services?

For some time, ECF has had both a discovery API, and a remote services API.

These APIs have two interesting characteristics (relevant to this post, anyway):

  1. They are transport independent
  2. They expose both transparent and non-transparent remote method access

Why is Transport Independence Useful?

Transport independence means that multiple implementations can and do exist, for both the discovery and remote services APIs.  So, for example, for discovery ECF currently has two implementation…also known as ‘providers’:  the Service Locator Protocol (RFC 2608), and Zeroconf/Bonjour.

Transport independence also exists for the remote services API, and we already have implementations based upon r-OSGi, XMPP, a simple tcp-based protocol, and JMS.

In general, transport independence is helpful because provider implementations can be replaced/changed without affecting clients (i.e. code that uses remote services).

Among other things, this is important for interoperability and cross-vendor openness, as it allows multiple servers/services to be used without rewriting the clients of those services.

Exposing both transparent and non-transparent remote method access

There is a long (and sometimes bitter) dialog in the distributed systems literature about whether transparency in networked services is a ‘good idea’.   ECF has attempted to skirt this entire large and complicated philosophical issue by providing both transparent access to remote services (i.e. through the normal OSGi services registry), and non-transparent access (via IRemoteService interface…see javadocs here) and leaving the decision about which is appropriate to the service creator and service client.

For non-transparent access to remote service, ECF provides the IRemoteService interface.  It exposes methods to remotely invoke methods via non-blocking techniques (e.g. with listeners for receiving callbacks or with a ‘future’).  This gives clients the flexibility and the tools to use transparent invocation (via proxy) if desired/appropriate, or use the asynchronous, non-blocking mechanisms present on IRemoteService.

What about ECF and RFC 119?

The short story is that we have plans to implement RFC 119 with the ECF discovery and remote services APIs.  Specifically, see bug 249240.   Given the existing drafts of RFC 119, we believe that we can implement it by writing code above the ECF discovery and remote services APIs, without significant changes to the APIs themselves.   This would mean that all ECF providers would then implement RFC 119, without having to do any additional work.

More on this and other issues in subsequent posts.

You may also like...

Share this Post

Twitter0
Google+0
LinkedIn
Facebook

Tags

2 Responses to “RFC 119 and ECF – Part 1”

  1. [...] Everything in the demo is based on Toast, the telematics example application we are using in the upcoming Equinox and OSGi book. The core of this is a car infotainment unit and a back end server that interact. From that humble beginning the demo shows how to add in all manner of things from VOIP, AJAX, reporting, scalable databases, Equinox server side, p2 provisioning and of course, RFC 119 distributed services. [...]

  2. [...] time ago, I blogged about RFC 119 and ECF part 1, so now it’s time for part [...]

2 responses so far

Written by . Published in Categories: EclipseSource News, Planet Eclipse