View source for ECF's Architecture for Distributed OSGi

==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

[[Image: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_API_Docs | ECF Discovery API]].  Also includes provisional API to extend and/or customize the behavior of the implementation.  See [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/discovery/package-frame.html here for the package javadocs] (32k).

'''org.eclipse.ecf.services.osgi.distribution''':  Implementation of RFC119 distribution based upon the [[ECF_API_Docs | ECF Remote Services API]].  Also includes provisional API to extend and/or customize the
runtime behavior of the implementation.  See [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/distribution/package-frame.html 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:  [[ECF_API_Docs | 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===

'''[http://en.wikipedia.org/wiki/Service_Location_Protocol 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).

'''[http://en.wikipedia.org/wiki/Bonjour_(software) 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 [mailto:ecf-dev@eclipse.org ecf-dev at eclipse.org] mailing list.