ECF's Architecture for Distributed OSGi

From Eclipsepedia

Jump to: navigation, search

Contents

Introduction

Rather than expose a single API for supporting distributed OSGi services, ECF is structured as a layered set of APIs, so as to support as many use cases for distributed systems as possible. So, rather than require that all applications use a single API for all their remoting needs, we allow applications to decide what mechanisms they need for their particular use case.

Here is a diagram to show the relationship between the various components within ECF's implementation of distributed OSGi

Distributedosgi.png

At the Top: RFC119

At the top of the stack shown above is the implementation of the two major components of RFC119, discovery and distribution. We have a Getting Started with ECF's RFC119 Implementation that has sample code and shows how to setup, register, and publish a remote service, and how to write a consumer of that remote service using the standard ServiceTracker.

For reference, this top-level is implemented via three small bundles:

org.eclipse.ecf.osgi.services: Implementation of RFC119-defined interface classes (11k).

org.eclipse.ecf.services.osgi.discovery: Implementation of RFC119 discovery based upon the ECF Discovery API. Also includes provisional API to extend and/or customize the behavior of the implementation. See here for the package javadocs (32k).

org.eclipse.ecf.services.osgi.distribution: Implementation of RFC119 distribution based upon the ECF Remote Services API. Also includes provisional API to extend and/or customize the runtime behavior of the implementation. See here for the package javadocs (53k).

One Level Down: ECF Discovery and Remote Services APIs

The ECF implementation of RFC119 is based upon/uses two pre-existing ECF APIs: Discovery and Remote Services. Both the discovery API, and the remote services API are abstract, transport-independent APIs for doing network discovery and calling remote services (both synchronously and asynchronously).

The discovery API is defined in the bundle

org.eclipse.ecf.discovery (38k). See the ECF API Docs for package-level documentation.

and the remote services API is defined in the bundle

org.eclipse.ecf.remoteservice (40k). See the ECF API Docs for package-level documentation.

Here is a page for Getting Started with Using the ECF Remote Services API.

Two levels down: ECF providers

ECF has a provider architecture, such that any API exposed via ECF can be implemented via multiple transport protocols.

Discovery Providers

Service Locator Protocol: An emerging standard service discovery protocol implemented via the bundles org.eclipse.ecf.provider.jslp (40k) and ch.ethz.iks.slp (115k).

Bonjour/Zeroconf: Discovery protocol originally created by Apple and implemented via the bundle org.eclipse.ecf.provider.jmdns (109k).

Remote Services Providers

r-OSGi

ECF Generic

XMPP

JMS/ActiveMQ

Skype

JavaGroups

Of course, as with any ECF APIs, those that wish to create a new provider are strongly encouraged to do so. The provider can/may be proprietary, or based upon proprietary technology, or it may be done in open source. If done in open source, with a license compatible with the EPL, some may wish to contribute their providers to the wider ECF community. If you are interested in doing this, please post your intention to the ecf-dev at eclipse.org mailing list.