Jump to: navigation, search

Difference between revisions of "EIG:Remote Services Admin"

(ECF's RSA Implementation)
(ECF's RSA Implementation)
Line 15: Line 15:
 
*Service Locator Protocol/SLP
 
*Service Locator Protocol/SLP
 
*DNS-SD (DNS Service Discovery)
 
*DNS-SD (DNS Service Discovery)
 +
*Others
  
 
and the following distribution providers
 
and the following distribution providers
Line 24: Line 25:
 
*XMPP
 
*XMPP
 
*JavaGroups
 
*JavaGroups
 +
*Others
  
 
Further, new (proprietary or open) discovery providers and/or distribution providers can be easily created and used as specification-compliant implementations of both RS and RSA...without any changes to the applications that export remote services or use RSA specification-defined API.  This is possible because of ECF's transport-independent, open, community-tested APIs (discovery and remote services).
 
Further, new (proprietary or open) discovery providers and/or distribution providers can be easily created and used as specification-compliant implementations of both RS and RSA...without any changes to the applications that export remote services or use RSA specification-defined API.  This is possible because of ECF's transport-independent, open, community-tested APIs (discovery and remote services).

Revision as of 16:29, 4 March 2011

Since ECF 3.3/Helios release in June 2010, ECF has provided a full implementation of the OSGi Remote Services specification. This specification is in the OSGi 4.2 compendium, chapter 13. You can download the compendium specification here.

As of our 3.5 release (March 2011), we now also support the Remote Services Admin specification. This is chapter 122 from the OSGi enterprise specification, and you can download this specification here.

What's Remote Services Admin?

Remote Services Admin (RSA) is the specification of a management agent for remote services. The Remote Services spec (chapter 13), defines the programmer-specified service properties for exporting an OSGi service as a remote service, but does not say anything about the mechanism or implementation of the two major subsystems involved: discovery (for knowing that a remote service is available on some network), and distribution (for accessing and using that remote service). For those that need to control and/or customize the actual discovery and distribution of an OSGi service over a network, the management agent specified by RSA allows them to have a much greater degree of control...i.e. to allow them to more easily secure remote services, to optionally use multiple/alternative communications protocols for both discovery and distribution, to customize and extend the behavior of both discovery and distribution as needed for more complex/enterprise use cases. The RSA specification defines the API for this remote services management agent, and ECF 3.5 provides a complete/spec-compliant, small, easily customizable and extensible, cross-framework implementation.

ECF's RSA Implementation

The RSA implementation uses ECF's discovery API and ECF's Remote Service API to implement the management agent's discovery and distribution subsystems. Since both the discovery and remote services apis are transport independent, and the ECF RSA implementation only uses these APIs themselves, the ECF RSA impl is also transport independent, allowing remote services to 'mix and match' discovery and distribution systems. For example, ECF currently has discovery providers based upon the following network discovery protocols:

  • Apache Zookeeper
  • Bonjour/Zeroconf
  • Service Locator Protocol/SLP
  • DNS-SD (DNS Service Discovery)
  • Others

and the following distribution providers

  • r-osgi (remote osgi)
  • ECF 'generic'
  • REST-based protocols
  • JMS-based protocols
  • XMPP
  • JavaGroups
  • Others

Further, new (proprietary or open) discovery providers and/or distribution providers can be easily created and used as specification-compliant implementations of both RS and RSA...without any changes to the applications that export remote services or use RSA specification-defined API. This is possible because of ECF's transport-independent, open, community-tested APIs (discovery and remote services).