ECF/Implementation of RFC119

Introduction

As part of the Galileo release (aka ECF 3.0), the ECF team has committed to implementing the current (DRAFT) state of OSGi EE RFC119. See the associated ECF enhancement request here.

ECF Team

The ECF team members working on RFC119 support are:

• Scott Lewis - slewis at eclipsesource.com, phone (cell): 503-756-8719, ECF project lead
• Markus Kuppe - markus.kuppe at lemmster.de, lead for ECF discovery API work
• Jan Rellermeyer - rellermeyer at inf.ethz.ch, ECF committer representative on OSGi Enterprise Experts Group, implementer of r-OSGi and jSLP.
• Marcelo Mayworm - mayworm at gmail.com, ECF committer

Ongoing Work Areas

Siemens Contribution for Service Discovery

Siemens has conveyed an interest in contributing work that they have done on implementing the service discovery part of RFC119. Here is a page for tracking this work and communication between Siemens and ECF team.

ECF Bundles

ECF now has three bundles to support the delivery of ECF-based remote services implementions. The CVS path for accessing these bundles on dev.eclipse.org is /cvsroot/rt/org.eclipse.ecf/compendium/bundles, and the bundles are as follows:

• org.eclipse.ecf.osgi.services -- Code from OSGi 4.2 compendium 20090123 version attached to cq: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795
• org.eclipse.ecf.osgi.services.discovery -- Code to implement discovery part of RFC 119 using ECF discovery API
• org.eclipse.ecf.osgi.services.distribution -- Code to implement distribution part of RFC119 using ECF remote services API

Notes 2.1.2009

1. The org.eclipse.ecf.osgi.services bundle is *only* to distribute the OSGi 4.2 compendium code (discovery and distribution packages only).
2. Code has recently been added to implement the use of the service registry hooks (RFC 126) to transparently register remote services.
3. Code has recently been added to begin to implement the RFC119-specified discovery, with support for RFC119 service publications resulting in IDiscoveryService.register(IServiceInfo)
4. We will introduce new tests plugin: org.eclipse.ecf.tests.osgi.services.distribution for testing. We can do that for discovery soon as well. These will be placed in /cvsroot/rt/org.eclipse.ecf/tests/bundles
5. We will add these three plugins to the ecf core set of bundles (core feature) for 3.5M6.

Notes 2.18.2009

Discovery (org.eclipse.ecf.osgi.services.discovery)

1. Responding to ServicePublication instance registration (using whiteboard to register services for discovery). This is implemented via ServicePublicationHandler class. The only missing piece...as compared to the spec version I have...is that RFC 119 discovery defines a 'filter' for DiscoveredServiceTracker instances, and currently this filter is unimplemented (i.e. ServicePublicationHandler.matchWithDiscoveredServiceInfo ...see org.osgi.service.discovery.DiscoveredServiceTracker.PROP_KEY_MATCH_CRITERIA_INTERFACES, and org.osgi.service.discovery.DiscoveredServiceTracker.PROP_KEY_MATCH_CRITERIA_FILTERS and explanation in spec).
2. Testing
3. Examples

Distribution (org.eclipse.ecf.osgi.services.distribution)

1. Responding to remote service registrations (e.g. bundleContext.registerService(...) is in place via the Service Registry Hooks...in class org.eclipse.ecf.internal.osgi.services.distribution.ECFEventHookImpl). This class responds to service registration and unregister by looking up ECF remote services providers, and calling IRemoteServiceContainerAdapter.registerRemoteService. Further, it publishes the remote service for discovery via registering a ServicePublication (i.e. see org.eclipse.ecf.internal.osgi.services.distribution.ECFEventHookImpl.publishRemoteService(ServiceReference, String[], Collection)). I believe that we need to assure that all ServicePublication properties (i.e. all constants in ServicePublication interface) are included.
2. The main thing that is yet missing from the distribution provider (as I understand it) is discovery of published services (via DiscoveredServiceTracker instance for ECF discovery published services), and the creation and registration of the remote service proxy in the local service registry for the remote service client process. I believe this will involve calling IRemoteServiceContainerAdapter.getRemoteServiceReferences(), calling IRemoteService.getProxy(), and then calling bundleContext.registerService(serviceintf, proxy). Does this square with what others are thinking about the client side processing?
3. Testing
4. Examples