Remote Service Admin
Pelix/iPOPO now includes an implementation of the Remote Service Admin OSGi specification. It has been contributed by Scott Lewis, leader of the Eclipse Communication Framework project.
This feature can be use to let multiple iPOPO and OSGi frameworks share their services. Note that Java is not mandatory when used only between iPOPO frameworks.
Links to ECF
The Remote Service Admin implementation in iPOPO is based an architecture similar to the Eclipse Communication Framework (implemented in Java). Most of the concepts have been kept in the Python implementation, it is therefore useful to check the documentation of this Eclipse project.
ECF project page, the formal project page
ECF wiki, where most of the documentation can be found
ECF blog, providing news and description of new features
Some pages of the wiki are related to the links between Java and Python worlds:
OSGi R7 Remote Services between Python and Java describes how to share remote services between an iPOPO Framework and an OSGi Framework.
Package description
The implementation of Remote Service Admin is provided by the pelix.rsa
package, which is organized as follows (all names must be prefixed by
pelix.rsa
):
Module / Package |
Description |
---|---|
|
Definition of the EDEF XML endpoint description format |
|
|
|
Core implementation of RSA |
|
Shell commands to control/debug RSA |
|
Package of discovery providers |
|
Package of transport providers |
|
Basic implementation of a Topology Manager |
Providers included with Pelix/iPOPO
iPOPO includes some discovery and transport providers. More of them will be added in future releases.
etcd Discovery
- Bundle:
pelix.rsa.providers.discovery.discovery_etcd
- Requires:
none
- Libraries:
This discovery provider uses etcd as a store of descriptions of endpoints. It depends on the python-etcd third-party package.
This discovery provider is instantiated immediately as the bundle is
started. The instance configuration must therefore be given as Framework
properties. Another solution is to kill the etcd-endpoint-discovery
component and restart it with custom properties.
This provider can be configured with the following properties:
Property |
Default value |
Description |
---|---|---|
|
localhost |
Address of the etcd server |
|
2379 |
Port of the etcd server |
|
/org.eclipse.ecf.provider.etcd.EtcdDiscoveryContainer |
Path in etcd where to store endpoints |
|
30 |
Session Time To Live |
etcd3 Discovery
- Bundle:
pelix.rsa.providers.discovery.discovery_etcd3
- Requires:
none
- Libraries:
This discovery provider uses etcd3 as a store of descriptions of endpoints. It depends on the etcd3 third-party package.
This discovery provider is instantiated immediately as the bundle is
started. The instance configuration must therefore be given as Framework
properties. Another solution is to kill the etcd-endpoint-discovery
component and restart it with custom properties.
This provider can be configured with the following properties:
Property |
Default value |
Description |
---|---|---|
|
localhost |
Address of the etcd server |
|
2379 |
Port of the etcd server |
|
org.eclipse.ecf.provider.etcd3.Etcd3DiscoveryContainer |
Path in etcd where to store endpoints |
|
30 |
Session Time To Live |
XML-RPC Distribution
- Bundle:
pelix.rsa.providers.transport.xmlrpc
- Requires:
HTTP Service
- Libraries:
nothing (based on the Python Standard Library)
The XML-RPC distribution is the recommended provider for inter-Python communications. Note that it also supports communications between Python and Java applications. Its main advantage is that is doesn’t depend on an external library, XML-RPC being supported by the Python Standard Library.
All components of this provider are automatically instantiated when the bundle starts. They can be configured using framework properties or by killing and restarting its components with custom properties.
Property |
Default value |
Description |
---|---|---|
|
localhost |
Hostname of the HTTP server ( |
|
/xml-rpc |
Path to use in the HTTP server |
|
30 |
XML-RPC requests timeout |
Other properties are available but not presented here as they describe constants used to mimic the Java side configuration.
A sample usage of this provider can be found in the tutorial RSA Remote Services using XmlRpc transport.
Py4J Distribution
- Bundle:
pelix.rsa.providers.transport.py4j
- Requires:
HTTP Service
- Libraries:
This provider allows to discover and share a Python service with its Py4J gateway and vice versa.
It can be configured with the following properties:
Property |
Default value |
Description |
---|---|---|
|
25333 |
Port of the Java proxy |
|
25334 |
Port of the Python proxy |
|
30 |
Timeout before gateway timeout |
A sample usage of this provider can be found in the tutorial RSA Remote Services between Python and Java.