I’ve blogged previously about what we (ECF) are doing WRT to RFC 119 (Distributed OSGi Services): RFC 119 and ECF – part 2
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
- r-OSGi (http)
- ECF Generic
- Java Messaging Service (JMS)
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.