Comparison of Discovery and Distribution Providers

As per this posting and thread followups on the ECF Mailing list, we are going to attempt to record and discuss the various technical (funcational and non-functional) characteristics of the ECF Discovery and Remote Service (distribution) providers.

Introduction

In the context of ECF's implementation of OSGi remote services, we are basically talking about discovery providers (to support remote service discovery), and distribution providers (to support the actual remote method calls). I would like to break things down broadly with discovery and distribution.

• Discovery
  • Zookeeper
  • Zeroconf (jmdns)
  • DNSSD
  • SLP (service locator protocol)
  • File-based discovery/EDEF
• Distribution
  • r-OSGi
  • ECF generic
  • REST-based providers
    • Restlet
    • Jaxr (under construction)
  • SOAP-based provider
    • Axis2
  • Generic-based providers
    • JMS
    • JavaGroups

The main thing to say as a starting point for this discussion is that these providers have different non-functional characteristics...i.e. they differ in how/what kinds of security, performance, reliability the provide under various runtime/deployment situations. For example, WRT discovery...it may be that for given application...because of app specific security requirements...that it's not possible or desirable to use multicast-based mechanisms (e.g. SLP or Zeroconf). OTOH, there are deployment scenarios (e.g. Internet with capital 'I') where using some discovery approaches will be practically difficult.

One other broad point to make about both discovery and remote services providers. ECF's architecture [2], supports the creation/use of arbitrary other providers (i.e. making/using your own custom provider). Combined with the fact that all the existing providers (for both discovery and remote services) are available in open source...and can be used as examples and/or extended to create actual implementations. This makes it quite easy to create custom providers (for both discovery and/or distribution), that are potentially proprietary (up to you), and can perhaps meet the specific requirements better than any of the existing providers. The question of 'what's right'? in those situations has to be based upon an examination of the specific requirements and runtime behaviors for the app.

As well, the providers can/will differ in how performant they are under different sorts of use situations. Further, because of our own resource limitations, some providers can/have gotten more technical and community attention than others. If work is needed..to functionally enhance a provider, to do performance work, or to fix bugs...we will do what we can to provide the necessary support. In some cases, however, we may need some help from the community...or won't be able to do the desired work.