ECF 3.14.19 released - simplify remote service discovery via properties

 ECF 3.14.19 has been released.

Along with the usual bug fixes, this release includes new documentation on the use of properties for discovering and importing remote services.   The docs describe the use of properties files for simplifying the import of remote services.   

This capability is especially useful for Eclipse RCP clients accessing Jax-RS/REST remote services.

Patrick Paulin describes a production usage his blog posting here.

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.

Remote Services over (Unreliable) Networks

In a previous post, I described how ECF Remote Services provided a way to create, implement, test, deploy and upgrade transport-independent remote services.

Note that 'transport-independent' does not mean 'transparent'.

For example, with network services it's always going to relatively likely that a remote service (whether an OSGi Remote Service or any other kind of service) could fail at runtime.   The truth of this is encapsulated in the first fallacy of distributed computing:  The network is reliable.

A 'transparent' remote services distribution system would attempt to hide this fact from the service designer and implementer.   Alternatively, the ECF Remote Services approach allows one to choose a distribution provider(s) to meet the reliability and availability requirements for that remote service, and/or potentially change that selection in the future if requirements change.  

Also, the dynamics of OSGi services (inherited by Remote Services), allows network failure to be mapped by the distribution system to dynamic service departure.   For example, using Declarative Services, responding at the application level to a network failure can be as simple as implementing a method:

void unbindStudentService(StudentService service) throws Exception {
        // Make service unavailable to application
	this.studentService = null;
        // Also could respond by using/binding to a backup service, removing
        // service from UI, etc
}

This is only possible if

1. The distribution system detects the failure
2. The distribution system maps the detected failure to a service unregistration of the proxy

If those two things happen, then using DS the proxy unregistration will result in the unbind method above being called by DS.
But the two requirements on the distribution system above may not be satisfied by all distribution providers. For example, for a typical REST/http-based service, there may be no way for the distribution system to detect network failure, and so no unbinding of the service can/will occur.

The use of transport-independent remote services, along with the ability to choose/use/create custom distribution providers as appropriate allows micro service developers to easily deal with the realities of distributed computing, as well as changing service requirements.

IoT Standards and Remote Services

In a recent posting, Ian Skerrit asks:   Can open source solve the too-many standards problem?

Even though it's clear that IoT developers want interoperability (the putative reason for many communications standards), there are other reasons that lead to multiple competing standards efforts (e.g. technical NIH, desire for emerging market dominance, different layering, etc).

I agree with Ian that open source provides one way out of this problem, as open implementations can provide interoperability much more quickly than formal standardization efforts.   One doesn't have to look very far to see that's been the case for previous communication and software standards efforts.

One complication for the IoT developer, however, is that they frequently need to make a choice...so that they can build their applications.   This choice has risks, however, because if the communications protocol one chooses doesn't end up being widely adopted/popular, does not provide interoperability with the necessary systems, or is a poor fit to the application-level or non-functional needs for your app (e.g. performance/bw requirements, round-trips, etc), then it could mean a very costly re-architecture and/or re-implementation of one's app or service.  

One way to hedge this risk is provided by ECF's implementation of Remote Services.   OSGi Remote Services is a simple specification for exposing an arbitrary service for remote access,   The spec says nothing about how the communication is done (protocol, messaging pattern, serialization), but rather identifies a pluggable distribution provider role that must be present for a remote service to be exported.   Each service can be exported with a distinct distribution provider, and the decision about what provider is to be used is done at service registration time.

One effect of this is that the remote service can be declared, implemented, tested, deployed, used, and versioned without ever binding to a distribution system.   In fact, it's possible to use one distribution provider to develop and test a remote service, and deploy with a completely different distribution provider simply by changing the values of some service properties.   With ECF's implementation, it's easy to either use an existing distribution provider, or create your own (open source or not), using your favorite communications framework.

ECF Remote Services allows IoT developers maximum flexibility to meet their application's technical needs, now and in the future, without having to commit permanently to a single communication framework, transport, or standard.

Transport-Independent Remote Services

ECF recently released version 3.13.1 of it's implementation of the OSGi Remote Services and Remote Service Admin specifications.

Over the past year, we have made it easier for us and others to create custom distribution providers.   This has made it possible to quickly create a variety of open source distribution providers...for example, HTTP/HTTP/REST/Jax-RS implementations, TCP, Hazelcast, JMS, AMQP, MQTT and JavaGroups) as well as others.

Why is this useful and important?   In my view, it's important because it allows service developers to define, implement, deploy and maintain transport-independent Remote Services.   Transport-independence gives the flexibility to address changing requirements without the need to alter the service or it's implementation.

For example, consider a small remote service for accessing a simple data set.   Ideally, the service interface, implementation, and client would use one distribution system/transport for all time for the life of the service.   In practice, however, it's often necessary to respond to changing funtional and non-functional transport-related requirements...for example requirements for interoperability/integration, changing security requirements, network performance requirements, bandwidth, service availability requirements, the need to take advantage of new protocols (e.g. MQTT, COAP, Iot.), etc.

This new tutorial shows how Remote Services can be declared, implemented, deployed, and versioned without any dependencies on the underlying distribution system or transport.   Pluggable distribution providers may be substituted with no service or application-level code changes.   This is accomplished by adherence to standards (OSGi Services/Remote Services and Jax-RS) as well as ECF's pluggable distribution provider approach.

ECF 3.13.1 released

ECF 3.13.1 is released.   This is a maintenance release to correct a few small issues identified in 3.13.

See the New and Noteworthy. For tutorials and other docs see here.

ECF provides a CT-tested implementation of the OSGi R6 Remote Services and Remote Service Admin specifications.  We also expose an API for easily creating custom distribution providers and provide a number of open distribution providers based upon a variety of transports.

ECF Remote Services: Distribution Providers

ECF's modular implementation of OSGi Remote Services supports the runtime selection of a distribution provider.  Distribution providers are responsible for the underlying communication when a remote method call is made.

ECF commiters and contributors have been adding distribution providers, and we are now up to 9 publicly available providers:  ECF generic, r-OSGi, websocket r-OSGi, JMS/ActiveMQ, MQTT/Paho, Jax-RS Jersey, Jax-RS CXF, Hazelcast, and REST-API-based providers,

We've documented these distribution providers, so that consumers may compare and contrast them, understand dependencies, and have working examples in case they choose to create their own distribution provider.

ECF 3.11.0 - Custom Remote Services Distribution Providers

ECF 3.11.0 is released.

What's New:  A new distribution provider api to simplify the creation of Remote Services distribution providers.    We've used this new API to recently create distribution providers based upon Jax Rest Services standard (with CXF, Jersey, and RestEasy implementations) and Hazelcast.

Exposing an OSGi Service as a REST Service

In a previous tutorial I showed how to use ECF Remote Services and Jax-RS client technology to import and consume/use a REST service.

In more recent companion tutorial, I show how to use ECF Remote Services and Jax-RS server technology to export an OSGi service as a REST service.

Together, these tutorials show the use of ECF Remote Services and Jax-RS standards to easily but flexibly create, export, import, understand, and consume REST-based services.