RSA (Remote Service Admin)
The Aries Remote Service Admin (RSA) project allows to transparently use OSGi services for remote communication.
OSGi services can be marked for export by adding a service property
service.exported.interfaces=*. Various other properties
can be used to customize how the service is to be exposed.
For more information, check out section "122 JPA Service Specification
Version 1.0" in the "OSGi Service Platform Enterprise Specification,
Release 4, Version 4.2" available for public download from the OSGi Alliance.
The Aries RSA source is in a separate git repository aries-rsa there is also a mirror on github.
- EndpointDescription Describes a remote service using service interfaces, remote url and all other properties to import the remote service.
- EndpointListener a service that is to be notified when remote Endpoints described by OSGi filters appear or disappear.
- Listens to local services and decides which to expose. It can also add properties to change the way services are exposed.
For the services to be exported it calls RemoteServiceAdmin.exportService to do the actual export. Then notifies EndpointListeners
about the new Endpoint.
- Listens for service requests from consumers and creates EndpointListeners for these interests.
The TopologyManager by default exposes all suitably marked local services for export and imports all service interests with matching
It is the best place to implement system wide governance rules. Some examples what can be done:
- Enhancing all exposed remote endpoints with SSL, basic auth, logging
- Exporting OSGi services with annotations for JAX-WS or JAX-RS even when not specially marked for export
According to its role the TopologyManager of course does not directly implement the enhancements above. It simply creates the necessary
calls to a suitable RemoteServiceAdmin.
Is called by the Topology Manager to expose local services as remote endpoints and create local proxy services as clients for
Aries RSA has a custom SPI DistributionProvider that allows to easily create new transports and serializations.
Existing providers are:
- uses Apache CXF for transport
- service endpoints consumable with non-java software (XML/JSON)
- Java serialization over TCP (one port per service)
- very few dependencies
- easy to comprehend blueprint for own transport implementations
- tuned Java serialization (or Protobuf) over TCP using NIO
- multiplexing over a single port
- transparently handles InputSteams and OutputStreams in remote services
- synchronous and asnychronous calls supported
A discovery implementation uses EndpointListeners to listen for local Endpoints and publishs them for other containers.
It also listens to remote Endpoints and notifies EndpointListeners about their presence.
A simple example using Apache Karaf
See EchoTCP example. Follow the Readme to install the example in Apache Karaf.
The EchoTCP example implements a simple echo service that can be called remotely.
The example uses declarative services to publish and bind services.
- api : EchoService interface
- service : EchoService implementation
- consumer : Small consumer that uses the EchoService
The example installation uses the tcp transport to do the remoting but the example code is not tied to any transport.
Example using fastbin transport
A similar example exists for the fastbin transport . Follow the Readme to install the example in Apache Karaf.
The example implements an echo service that showcases synchronous calls, asnychronous calls and InputStream as parameter and return value.