ECF 3.14.4 released

ECF 3.14.4 was recently released.  This was a bug-fix release.  There are notes on some of the recent additions here.

ECF 3.14.3 released

ECF 3.14.3 has been released.  This is a bug fix release, but in addition to the fixes a number of usage examples have been created:

Remote Services Between Java and Python and Python for OSGi Remote Services

RESTful Remote Services Using either CXF or Jersey

Using OSGi R7 Async Remote Services

Using Gogo Commands and RSA for Controlling Remote Services

Using BndTools 4 for Developing OSGi Remote Services

OSGi Remote Services Between Python and Java

In a previous post, I described the support for OSGi Remote Services and Remote Service Admin in iPOPO 0.8.0 release.   The previous post refers to a tutorial showing a Python service impl and Python consumer.

Python<->Java Distribution Provider

Included with iPOPO 0.8.0 is a distribution provider that allows remote services between Java and Python frameworks.   For example, this is a tutorial, that uses Karaf on the Java side as the remote service implementation, and has a Python consumer that calls the Java-implemented remote service.

Python Service Implementation with Java Consumers

This distribution provider also supports Python-implemented remote services, with Java/OSGi consumers.   With iPOPO for dynamic service injection in Python, and Declarative Services for Java/OSGi, this allows very easy Python<->Java service-level interaction, with support for all dynamics, RSA management agent, extensible/customizable topology management, management of complicated service dependencies, pluggable local and network discovery, and other RS/RSA features handled consistently in both Java and Python.  As well, the use of OSGi-specified EndpointDescription service metadata allows service-level interoperability across languages.

Python<->Java with Protocol Buffers Serialization

Also included with this distribution provider is serialization using Google's protocol buffers.  This allows open, extensible, and efficient rpc between Python and Java.

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.