Python for OSGi Remote Services

The iPOPO project is a Python implementation of key parts of a standard OSGi framework...e.g. bundles, the service registry and servicereference api, and a dynamic service injection framework similar to the Apache iPOJO project...thus the name iPOPO.

With the 0.8.0 release of iPOPO, there is now a Python implementation of the OSGi Remote Services and Remote Service Admin (RSA) specifications.   To distinguish from the previously-provided remote services in iPOPO, this is known as RSA Remote Services.

iPOPO's RSA Remote Services has many of the same advantages as Java-based Remote Services/RSA.  Some of these advantages:

Decoupling - name/service contract is decoupled from the implementation (and distribution)

Dynamics - The service registry dynamics behavior, along with all notifications, etc is available in Python

Injection and Service Dependency Management - iPOPO provides service injection and dependency management, built upon the Python API

Standard RemoteServiceAdmin Management Agent, RSA Console Commands

API for Distribution and Discovery Providers - There are documented APIs for creating new distribution and discovery providers, making it easy to support other transports and implementations for distribution (e.g. REST/JaxRS, Jsonrpc, MQTT, Zeroconf Discovery, etc).

Other advantages of Java-based OSGi services are described here.   All of these advantages apply to Python/iPOPO-based services, but Python can be used to implement and/or consume services.

Currently, there are two distribution providers included with iPOPO 0.8.0:  XmlRpc, Python-Java and one discovery provider: etcd.   See here for tutorials showing their usage with included sample remote services. 

Other distribution and discovery providers are being considered or worked on.  If you are interested in seeing a particular transport supported for distribution or discovery please open an issue on the iPOPO project.

Remote Services between Python and Java

The Python-Java distribution provider makes it possible to use OSGi Remote Services between Python and Java...on both sides.    This allows Remote Services to be exported from Python, and discovered/imported and consumed in Java, or exported from Java and discovered/imported/consumed from Python.  See here for a sample and tutorial.   These capabilities and the underlying distribution provider will be described in more detail in a subsequent posting.

Rest Remote Services with CXF or Jersey

ECF's Photon Release now includes an example of using Karaf with the JaxRS distribution provider.

This distribution provider now fully supports OSGi R7 remote services, including async remote services, using either the Jersey or CXF JaxRS implementations.

This allows service developers to easily use only JAX-RS annotations to define and implement OSGi R7 remote services.

ECF Photon supports OSGi R7 Async Services - part 2

In a previous post, I described a usage of OSGi R7's Async Remote Services. This specification makes it easy to define, implement and use non-blocking remote services. ECF's implementation allows the use of pluggable transports...known as distribution providers.

Here's a partial list of distribution providers:

R-OSGi
ECF generic
JMS/ActiveMQ
XML-RPC
Hazelcast
MQTT
Jax-RS Jersey
Jax-RS CXF
JavaGroups
Python.Java (Supports async remote services between Java and Python with protocol buffers serialization)

 It's also straightforward to creation your own distribution provider, using private or legacy transport and/or serialization. This can be done by extending one of the distribution providers above or creating a new one.

Most of these distribution providers have updated examples and/or tutorials, and many of them now have templates included in the Bndtools (4.0+) Support added for Photon.

Separating the remote service contract from the underlying distribution provider via OSGi remote services allows implementers and consumers to create, debug, and test remote services without being bound to a single transport, while still allowing consistent (specified) runtime behavior.

For more info and links, please see the New and Noteworthy.

ECF Photon supports OSGi Async Remote Services

In a previous post, I indicated that ECF Photon/3.14.0 will support the recently-approved OSGi R7 specification.   What does this support provide for  developers?

Support osgi.async remote service intent

The OSGi R7 Remote Services specification has been enhanced with remote service intents.  Remote Service Intents allow service authors to specify requirements on the underlying distribution system in a standardized way.   Standardization of service behavior guarantees the same runtime behavior across distribution providers and implementations.

The osgi.async intent allows the service interface to use return types such as Java8's CompletableFuture or OSGi's Promise.   With a supporting distribution provider, the proxy will automatically implement the asynchronous/non-blocking behavior for the service consumer.

For example, consider a service interface:

public interface Hello {
    CompletableFuture<String> hello(String greetingMessage);
}

When an implementation of this service is registered and exported as a remote service with the osgi.async intent:

@Component(property = { "service.exported.interfaces=*", "service.intents=osgi.async" })
public class HelloImpl implements Hello {
    public CompletableFuture<String> hello(String greetingMessage) {
          CompletableFuture<String> future = new CompletableFuture<String>();
          future.complete("Hi.  This a response to the greeting: "+greetingMessage);
          return future;
    }
}

Then when a Hello service consumer (on same or other process) discovers, imports and then remote service is injected by DS:

@Component(immediate=true)
public class HelloConsumer {

    @Reference
    private Hello helloService;

    @Activate
    void activate() throws Exception {
        // Call helloService.hello remote service without blocking
        helloService.hello("hi there").whenComplete((result,exception) -> {
            if (exception != null)
                exception.printStackTrace(exception);
            else
                System.out.println("hello service responds: " + result);
        });
    }
}

The injected helloService instance (a distribution-provider-constructed proxy) will automatically implement the asynchronous remote call.   Since the proxy is constructed by the distribution provider, there is no need for the consumer to implement anything other than calling the 'hello' method and handling the response via the Java8-provided whenComplete method.   Java8's CompletionStage, Future, and OSGi's Promise are also supported return types.  (Only the return type is used to identify asynchronous remote methods, any method name can be used).  For example: the following signature is also supported as an async remote service:

public interface Hello {
    org.osgi.util.promise.Promise<String> hello(String greetingMessage);
}

Further, OSGi R7 Remote Services supports a timeout property:

@Component(property = { "service.exported.interfaces=*", "service.intents=osgi.async", "osgi.basic.timeout=20000" })
public class HelloImpl implements Hello {
    public CompletableFuture<String> hello(String greetingMessage) {
          CompletableFuture<String> future = new CompletableFuture<String>();
          future.complete("Hi.  This a response to the greeting: "+greetingMessage);
          return future;
    }
}

With ECF's RSA implementation and distribution providers, this timeout will be honored by the underlying distribution system. That is, if the remote implementation does not return within 20000ms, then the returned CompletableFuture will complete with a TimeoutException.

Async Remote Services make it very easy for service developers to define, implement, and consume loosely-coupled and dynamic asynchronous remote services.   It also makes asynchronous remote service contracts transport independent, allowing the swapping of distribution providers or creating/using custom providers without changes to the service contract.

For the documented example code, see here

ECF Photon adds Gogo Commands

A third major enhancement for ECF's implementation of OSGi Remote Services is the addition of Apache Gogo console commands for examining the existing state of remote services, and the ability to export a service and import an endpoint from the OSGi console.

See this wiki page describing the new commands and their usage.

ECF Photon supports Bndtools

A second major enhancement for ECF Photon is adding support for using Bndtools to develop and test OSGi Remote Services.   Bndtools is increasingly popular for developing OSGi-based applications and frameworks, and we've added support for Bndtools Workspace, Project, and Run Descriptor templates for developing and testing remote services.

Initial documentation is available at Bndtools Support for Remote Services Development.

Note that these templates and the RSA impl may change slightly before ECF Photon, and new/additional templates will be added to (e.g.) support other distribution and discovery providers.

ECF Photon supports OSGI R7

ECF Photon has several major enhancements.   I'll blog about these enhancements individually over the coming weeks, starting with

Support for OSGI R7 Remote Services

In the R7 final draft specification (chapter 100) detail was added about the use of Remote Service Intents.   RS Intents describe a distribution provider's abstract capabilities.    By way of example, several new standard intents have been defined, including osgi.basic and osgi.async.   

The osgi.basic intent requires that a distribution provider support a remote service-specific timeout, as well as serialization of remote service arguments and return values include DTOs (Data Type Objects), java primitives, maps, collections, lists, OSGI Version, etc.   

The osgi.async intent requires that remote service method signatures using CompletableFuture, Future, and OSGI's Promise be supported directly by the distribution provider.   This allows non-blocking asynchronous remote services to be easily declared in the service interface, and implemented by the distribution provider.  Here is an example remote service declaration that demonstrates how the osgi.async intent can be used.   In a forthcoming tutorial, I'll show how such a small service can be easily defined, implemented, and remoted using ECF Remote Services.

ECF's remote services impl has multiple distribution providers, and open APIs for creating custom or extension providers.   Most of the existing ECF distribution providers already available have been updated to implement the R7-standardized intents.   Others will be updated prior to and after Photon release.

Python 3 and Import Hooks for OSGi Services

In a previous post I described using Python for implementing OSGi Services.   This Python<->Java service bridge allows Python-provided/implemented OSGi services called from Java, and Java-provided/implemented OSGi Services called from Python.   OSGi Remote Services provides a standardized way of communicating service meta-data (e.g. service contracts, endpoint meta-data) between Java and Python processes.

As this Java<->Python communication conforms to the OSGi Remote Services specification, everything is completely inter-operable with Declarative Services and/or other frameworks based upon OSGi Services.  It will also run in any OSGi R5+ environment, including Eclipse, Karaf, OSGi-based web servers, or other OSGi-based environments.

Recently, Python 3 has introduced the concept of an Import Hook.   An import hook allows the python path and the behavior of the python import statement to be dynamically or extended. 

In the most recent version (2.7) of the ECF Py4j Distribution Provider, we use import hooks so that Python module import is resolved by a Java-side OSGi ModuleResolver service.   For example, as described in this tutorial, this Python statement

from hello import HelloServiceImpl

imports the hello.py module as a string loaded from within an OSGi bundle.  Among other things, this allows OSGi dynamics to be used to add and remove modules from the python path without stopping and restarting either the Java or the Python processes.

Remote Services without OSGi bundles

Remote Services provides a dynamic, transport-independent, simple, modular way to expose micro services.   ECF has created a spec-compliant implementation along with a large and growing number of open and extensible distribution providers.   

Remote services are frequently useful for fog/edge use cases, where the communication transports (e.g. MQTT) may be different than those typically used in the cloud (e.g. http/https, jaxrs, enterprise messaging, etc).   

Typically, remote services are run on OSGi-based frameworks and apps such as Equinox, Felix, Karaf, Eclipse, and others, and indeed ECF's RSA implementation works very well in any of these environments.   

Perhaps less well known, however, is that remote services can be used in other inter-process environments...for example between Java and Python.  

It's also possible to use ECF remote services without an OSGi framework, i.e. running only as Java applications.   This repository has an example of using ECF remote services without an OSGi framework.   The projects are Java applications (no OSGi framework assumed), on both the remote service provider side, as well as the remote service consumer side.   The examples may be run within Eclipse by using the launch configs in the example projects.

Most of the benefits of OSGi Remote Services are still available...for example the ability to use multiple distribution providers for a service, the ability to remotely discover services and dynamically respond to network failure, and the ability to use the OSGi service registry for service dynamics, and service injection.   Also, the service definition, implementation, registration and lookup are exactly the same whether via an OSGi bundle or a Java application.   This allows services to be defined consistently across runtime environments in addition to cross-distribution mechanisms.

Please clone the ServiceRegistry github repository and give things a try!

Remote Services between Python and Java

ECF's implementation of OSGi Remote Services allows multiple distribution providers, which are responsible for the actual rpc communication required by remote services.   Here is a list of ECF distribution providers we've created.

Using Py4j and Google Protocol Buffers, we've recently enhanced an ECF distribution provider that allows the use of remote services (and Remote Service Admin) between OSGi and Python.   Service impls can be in either Java or Python, and consumers can be either Java or Python.     Protocol Buffers can be used to efficiently serialize arguments and return values.

The only dependencies are on OSGi, Py4j, and Google Protocol buffers, so this distribution provider can be used in Eclipse or other OSGi environments like Karaf.

Get the most recent release, with examples and source code at this github repository.

ECF 3.13.8 and etcd discovery for remote services

ECF 3.13.8 has been available since September, but there are some new things available:

ECF 3.13.8 changes have distributed to maven central

There is a new release (1.3.0) of the etcd discovery provider.    This provider uses an ectd cluster to publish and discover remote services allow complete integration with systems like Kubernetes, which also use etcd for service discovery.

ECF 3.13.7 Oxygen: Maven and Python OSGi Services

ECF 3.13.7 has been released as part of the Oxygen Simultaneous Release.  ECF's work recently has emphasized it's implementation of OSGi Remote Services, and the 3.13.7 continues this emphasis.

Highlights:

1. ECF has multiple distribution providers, and most have been moved to Maven-based builds
2. Remote Services/RSA is now available via Maven Central, and the Karaf Feature Install uses Maven install.
3. A new distribution provider that allows Python code as OSGi Services.   See this tutorial for a description.
4. Many bug fixes and small improvements

ECF 3.13.4 now available

ECF 3.13.4 is now available.  This was a maintenance release, with bug fixes for the Eclipse tooling for OSGi Remote Services and an update of the Apache Httpclient filetransfer provider contributed to Eclipse.

ECF 3.13.3 Available

ECF 3.13.3 is now available.

3.13.3 is a maintenance release, focused on fixes for ECF's implementation of OSGi Remote Services and Remote Service Admin.   Among other things, the tutorial that uses Karaf as the remote service host and Eclipse as the remote service consumer has been simplified and updated to use take maximum advantage of Java8 and Eclipse Neon.

ECF 3.13.2

ECF 3.13.2 is now available.

This is a maintenance/bug fix release, but includes new documentation on growing set of ECF distribution providers to support our implementation of OSGi Remote Services.

New and Noteworthy here.

Avoiding Tragedy of the Commons

Open source communities frequently struggle with the famous Tragedy of the Commons problem.   See the link for a description of the history and links to work.

There are, however, some recent ideas and associated research that have shown promise:

Commons-based peer production

Altruistic Punishment

Polyglot Remote Services

ECF has a growing number of distribution providers that implement the OSGi Remote Service Admin (RSA) specification.   Recently, a provider based upon Google RPC was introduced, and now a provider based upon XML-RPC is available.   It's also now much easier to create custom distribution providers using any desired transport.   All ECF distribution providers fully and automatically implement the OSGi RSA specification.

Several of these new distribution providers also support non-OSGi and even non-Java servers and/or clients...i.e. written in JavaScript, Python, C++ and other languages.   This has a number of use cases allowing cross-language interoperability and backward compatibility.  Some examples:

It's possible to take an existing/deployed service (written in any language) and easily create an RSA client for it.   This allows RSA/OSGi to be used for discovery, deal with remote service dynamics, use of DS or Spring, and service versioning on the consumer/client.

It's possible to export an OSGi Remote Service and use any/all clients (written in any language  supported by the exporting distribution provider).

It's possible to take an existing web server implementation, and move/refactor it to OSGi RSA without breaking backward compatibility for existing clients (written in any language).

Microservices Granularity for the Internet of Things

In a 2014 blog posting, Martin Fowler discussed issues around creating networked services in Microservices and the First Law of Distributed Objects.   One of his points is that networked services should generally be more coarse-grained than local (in-process) services. The reason for this is that distribution always has costs (bandwidth, performance), and these costs easily can become large with fine-grained remote calls.

But as Fowler points out, there are good reasons (e.g. complexity) to make a networked API as fine-grained as possible.   How granular/coarse should IoT microservices be?  In his blog posting, Fowler suggested that granularity was an open question, and that experience with different systems with different levels of microservices granularity would provide eventual insight.

I agree with Fowler's view that experience is necessary to decide on 'appropriate' granularity.   I think it's particularly true for the Internet of Things, where multiple people and organizations are attempting attempting to create consistent abstractions for the relatively-limited input and output capabilities exposed by newly networked devices...aka 'things'.

But when actually defining remote services, often the first thing done is to bind the service to a particular transport+protocol+impl framework (e.g. https+json+jersey).   Once bound to a transport, the service API may become very difficult to refactor and version.  This is especially true once a service has been deployed, but frequently deployment is the only way to get enough real experience to be more (or less) granular!

One way to provide flexibility...and allow future change to a service is to remain as transport-independent as possible.   As described by this article, new standards such as OSGi Remote Services/RSA and ECF's modular implementation makes it possible to design and refactor services independent of the transport.  Such independence will make it easier to update the granularity of a microservice when necessary.

Network Dynamics and Micro Services

One of the most challenging aspects of building networked applications is dealing with network dynamics. Networks and endpoints go down, sometimes come back up, and this implies that consumers accessing these services have to respond as these changes occur.

This will be even more true for the Internet of Things (IoT), where a wide variety of devices and a wide variety of networks will be involved to support the use of a micro service. Through no design or programming fault, IoT services and the applications that depend upon them will be less reliable.

How should micro-service consumers respond to failure? That's a good question, as the answer clearly depends upon the application-level needs and requirements.

For example, once loaded an html web page does not need to know/respond to the failure of the web server or the dropping (or changing due to mobility) of the network connecting the browser to the web server. If the user clicks on a link to present another page the load of the page will fail, but for browsing web pages that's a completely acceptable strategy for handling network failure.

On the other hand, consider an IoT application where a real-time data stream is collected from a sensor device. In such a case it might make more sense to have strategy for responding to network and/or device failure such as switching to a backup, or perhaps presenting to a user or admin that the data stream is temporarily unavailable. The larger point is that consumers of a micro service will differ in their requirements for responding to network failures.

What does any of this have to do with micro services? Frequently it falls to the application to not only define a strategy for application-level failure handling, but also to implement the networking code to detect failure and to use this detection to allow an application to implement a failure-handling strategy. This networking code can be a very difficult thing to create, especially if it has to meet multiple service and application-level requirements.

There are now specifications allowing the excellent dynamics support in OSGi Services to be used for Remote Services. The OSGi Service Registry, was designed to support dynamic within-process services. This allows applications to respond to services that come and go dynamically without having to create all the software infrastructure to do so reliably. Further, there are now OSGi specifications for Remote Services, and these allow the same dynamics support to be used to respond to network dynamics. Since the OSGi service registry is standardized, applications can also use (rather than build) convenient frameworks like Declarative Services/SCR or Spring/Blueprint to respond to network-induced service changes.

In short, the OSGi service registry and Remote Services provide standardized support for micro services dynamics without being bound by implementation to a specific protocol/transport, or even language.

ECF Remote Services using Google RPC and Protocol Buffers

ECF's implementation of OSGi Remote Services/Remote Service Admin (RS/RSA) has a modular architecture, allowing the easy creation and use of new distribution providers. Having multiple distribution providers enables transport-independent remote services.

A new ECF distribution provider is now available, based upon Google RCP and Protocol Buffers 3. Protocol Buffers is a popular serialization approach for remote services, because it's high performance, open, lightweight, and supports usage across multiple languages.

This new tutorial shows an example of how grpc/protocol buffers and OSGI Remote Services can now be used together to define, implement, discover, and consume dynamic transport-independent remote services.