Sunday, January 03, 2010

OSGi Remote Services from ECF

The ECF project has just finished our initial implementation of the OSGi 4.2 Remote Service specification (chapter 13 in compendium section).

I want to highlight a few distinctive features of ECF's implementation. I'll be doing other/more blog posts to go into details about some of these.

Transport Independence

ECF's implementation currently works with the following distribution transports: JMS (ActiveMQ), r-OSGi, JavaGroups, XMPP, Skype, ECF generic, and with the following discovery protocols: SLP, zeroconf, static xml file-based discovery. The ECF implementation is immediately usable with any...or all...of these providers...even within a single application if desired. Further, ECF's remote services and discovery APIs allow other distribution and/or discovery systems to be plugged in underneath our implementation...meaning that other distribution systems (e.g. open source distribution systems such as Riena, Apache CXF, and/or proprietary distribution systems) can reuse/leverage our implementation...and avoid the work otherwise necessary to implement the OSGi specification themselves. ECF's implementation can also run alongside other remote services implementations without conflict.

Asynchronous and Synchronous

Distributed applications and services frequently need to use asynchronous/non-blocking remote invocation addition to synchronous, proxy-based remote method call. Right now, ECF has built-in support for both asynchronous invocation (e.g. asynchronous listeners, futures, one-ways), as well as proxy/synchronous the services and application programmer a transport-independent choice of which to use. Currently, the OSGi 4.2 spec does not yet specify asynchronous invocation patterns for remote services, but ECF's implementation does have it.


The entire ECF implementation of the spec...along with ECF's remote services < 150k of code. Further, the OSGi execution environment requirements are minimal (CDC 1.1/Foundation 1.1). Combined with a small provider (like r-OSGi), and this allows even small devices to both expose/host and consume standardized remote services.

Standard, Open Source, Open Team, Open Process

The ECF implementation is fully compliant with the OSGi 4.2 remote services specification...for any and all current and future ECF remote services providers. Further, as mentioned above, other providers can now get this compliance for free. Of course, ECF's implementation is open source, but it is also produced by a vendor-neutral project team, and fully open community-driven process. In addition, we have support for a distributed version of the OSGi EventAdmin service, for doing publish-and-subscribe-based applications using a standard event bus API/service.


ECF's implementation is deeply extensible, allowing control or customization of every aspect of the distribution of an OSGi service (e.g. custom discovery, custom marshalling/serialization, custom transport/wire protocol, etc) for those that need it. This is enabled by the open APIs that ECF exposes, and allows a wide variety of deployment requirements and application-level use cases to be easily supported.


It's All About Modules. ECF's modular structure is indeed enabled by OSGi's modularity, but we have also applied modular design to every level of APIs and implementations. For example, lightweightness, extensibility, and transport independence all are enabled by our modular separate API from implementation, and to separate distinct subsystems (e.g. discovery and remote services APIs).

We are preparing a release that includes this to immediately download/use ECF's implementation, or engage the community...for requesting enhancements, reporting bugs, contributing (e.g. examples, providers, customizations), helping with testing, or getting support please consider joining the ecf dev mailing list or see the ecf dev resources page.


Jeff McAffer said...

This is awesome! Well done Scott and the whole ECF team!

remain said...

Hooray!! Great Job!

Peter said...

Is it possible to use this implementation of OSGi remote services on other frameworks than Equinox? If yes, which bundles do I need to deploy OSGi Remote Services functionality using R-OSGi or ECF Generic providers?

Scott Lewis said...

@Peter: the answer to your first question (whether this impl can be used on frameworks other than Equinox) is 'yes'. WRT which bundles...the answer is org.eclipse.equinox.common and org.eclipse.equinox.registry (and their deps...but those deps are minimal is my understanding). Unfortunately/regrettably we/ECF currently do not have the resources to test this, however.

Fabian said...

Hi, I'm trying to get ecf r-osgi running on apache felix. My dependencies are:


The problem that I have is that containerManager.getContainerFactory().createContainer("ecf.r_osgi.peer"); throws a "Container type description with name=ecf.r_osgi.peer not found. This may indicate that the desired provider is not available or not startable within runtime." exception.

Bundle states:

id State Bundle
0 ACTIVE org.eclipse.osgi_3.6.0.qualifier
1 ACTIVE org.eclipse.ecf.remoteservice_3.3.0.qualifier
2 ACTIVE org.eclipse.equinox.common_3.6.0.qualifier
3 ACTIVE org.eclipse.ecf.examples.remoteservices.hello_1.0.0.qualifier
4 ACTIVE org.eclipse.ecf_3.1.0.qualifier
8 ACTIVE org.eclipse.ecf.discovery_3.0.0.qualifier
9 ACTIVE org.eclipse.equinox.registry_3.5.0.qualifier
10 ACTIVE org.eclipse.equinox.concurrent_1.0.0.qualifier
11 ACTIVE org.eclipse.ecf.identity_3.1.0.qualifier
12 ACTIVE org.eclipse.osgi.services_3.2.100.qualifier
14 ACTIVE org.eclipse.core.jobs_3.4.100.v20090429-1800

Scott Lewis said...

@Fabian: Hi Fabian.

First, thanks for working on this (running on Felix). Second, I suspect that the main problem is that you haven't included the r-OSGi provider (the bundles that expose the "ecf.r-osgi.peer" container type).

The r-OSGi provider requires the following bundles:

org.eclipse.ecf.provider.r_osgi (the ecf r-osgi provider).

ch.ethz.iks.r_osgi.remote (r-osgi impl)

org.objectweb.asm (r_osgi impl dependency for proxy creation)

Note: If you want to use the dynamic service discovery, it's also necessary to use a discovery provider as well...and the available discovery providers being jmdns/zeroconf, slp, and xml-file-based discovery). So the desired providers for discovery will also be needed.

Third, would you consent to joining the ECF mailing list and asking questions there? that the entire community can/could engage in this? Thanks again!

To join ECF mailing list:

AlBlue said...


Is there an update site for the ECF which contains a working snapshot of the remote services APIs, or is it just check-out-from-source? The Update site listed on the main ECF page is for 3.1 I believe, which was released a while before you wrote this post.


Scott Lewis said...

@AlBlue: There is not yet an update site for the new remote services work. We have to figure out the resources to prepare for/have a release review, and then produce a 3.2 release...hopefully before EclipseCon/March 2010. You can get the nightly builds, however, from if you like...or from source.

horzsolt said...

Hi Fabian!

Can you give me your directory list which displays the full names of your bundles under Felix? If I use your dependency list I'm unable to start Felix. I'm afraid I have some kind of version incompatibility.

Thx: Zsolt

Anonymous said...

I could use that list too, because ECF seems to refer things in the Equinox framework bundle (specifically org.eclipse.osgi.util and org.eclipse.osgi.framewor.log) and don't know how to resolve these without copying the entire framework JAR (which I tried and the duplicate classes killed the entire boot process).

Unfortunately, this is not the first time we meet bundles that are not portable, their configuration admin implementation also did not work in Felix. :-(

Scott Lewis said...


Since the ECF project participates in the yearly simultaneous release, we are required to refer to (at least) the NLS class for internationalization.

WRT the config admin impl...afaik ECF isn't using config admin at all (yet).

But even given the above, I would like to initiate an effort to make any necessary dependency changes to get ECF bundles running on other frameworks. Due to resource constraints, however, we are going to need some help with doing this from the community...and for testing. I've created this bug

Please join the bug and offer some assistance with the effort.

Anonymous said...


Thanks for your bug report, hope this get fixed in the near future.

Sorry that my note about config admin is misleading. What I wanted to say is that while the Apache community is committed to create portable bundles, the Eclipse community seems to care less. I used config admin as an example because it does not work under Felix and the same is true with ECF as your bug report says.