EIG:Remote Services Admin
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. ECF's RSA implementation is complete and fully compliant with the specfication. We are in the process of getting access to the OSGi Test Compatibility Kit (TCK), and will verify full compliance with the specification through use of that TCK as soon as possible.
Unique ECF-provided Features
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
- Service Locator Protocol/SLP
- DNS-SD (DNS Service Discovery)
and the following distribution providers
- ECF Generic
- REST-based protocols
- SOAP-based protocols
- JMS-based protocols
Discovery and distribution providers...implemented as OSGi modules...may be mixed and matched in order to satisfy development-time and/or deployment-time requirements...for remote service security, for scalability, and/or for interoperability and integration with existing systems.
As well, 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 programmatic API. This is possible because of ECF's transport-independent, open, community-tested APIs (discovery and remote services).
Further, ECF's transport independence makes it extremely convenient to develop and test remote services using one discovery provider (e.g. Bonjour/Zeroconf) and deploy with another (e.g. Zookeeper).
Asynchronous Remote Services
In addition to fully supporting the OSGi-specified synchronous remote services, ECF provides the means to easily define and use asynchronous remote services. This capability is described with code examples here.
ECF's RSA implementation is written to OSGi specifications, and so can/does run on multiple OSGi frameworks. We have some (small) amount of cross-framework testing, but are looking to do much more. Equinox is currently our primary framework (for development and testing), and Felix has been minimally tested. We would be very interested in working with anyone willing to help us test more thoroughly on Felix or other OSGi frameworks.
ECF has moved to git for source code control, and the ECF repo can be found here.
The main bundles for the RSA are in osgi/bundles in the following projects:
- org.eclipse.ecf.osgi.remoteserviceadmin: OSGi-provided specified API classes
- org.eclipse.ecf.osgi.services.remoteserviceadmin: The ECF RSA implementation
Bug Reporting and Support
For support in use of ECF's RSA implementation, see the ecf-dev mailing list.
To report bugs for the ECF RSA implementation open a bug with the component=ecf.remoteservices and subject line containing [remoteserviceadmin] here.
From the RSA specification, here is a high-level diagram of the RSA Architecture
There are two roles that use these system entities:
- Service Host. This is the OSGi framework that exports an OSGi service, making it available for remote access and optionally publishing it for network discovery. The entities from the architecture diagram involved in host export are the Topology Manager Impl (for deciding when/what services to export), the Remote Service Admin impl (for actually performing the export), and the Discovery Impl (for publishing the remote service for automatic discovery.
- Service Consumer. This is the OSGi framework that imports an OSGi service, creating a proxy for the remote service, and then registering the proxy in the local OSGi service registry. The entities from the architecture diagram involved in consumer import are the Topology Manager Impl (for deciding when/what services to import), the Remote Service Admin impl (for actually performing the import), and the Discovery Impl (for discovering the remote service via some discovery mechanism).
On the service host (the framework that exports an OSGi remote service, for access over a network), the main entities