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.

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 3.13 - Custom Distribution Providers

ECF 3.13 is now released

New and Noteworthy:

A Simplified API for Creating Custom Distribution Providers - This new API makes it easier to create custom distribution providers for ECF's implementation of OSGi Remote Service Admin.  Custom Distribution Providers may use any serialization format and any communication protocol to implement spec-compliant Remote Services
Remote Management APIs - APIs for remote interaction with OSGi frameworks:  e.g. wiring, bundles, services, framework.  Also for Eclipse p2, the extension registry and ECF components.

ECF 3.12.1 and Remote Management

ECF 3.12.1 is released.

Although this is a maintenance release, there are also some additions to announce at ECF's github site.

Specifically, there are now a set of remote services allowing  remote monitoring and management of an OSGi container.   Services for managing an OSGi framework...e.g. FrameworkManager, ServiceManager, SCR Manager, Wiring Manager, RSA Manager, etc.  There are also services for remotely managing P2 (Feature Install Manager, Repository Manager, Profile Manager, etc) and ECF.

Additionally, there is now Eclipse-based tooling/UI for exporting remote management services, and consuming/viewing in Eclipse.   See the New and Noteworthy for screenshots, links to builds and further explanation of the new remote management services.

ECF 3.12.0 Released

ECF 3.12.0 was released today.

The new work was primarily on improving the Remote Services/Remote Service Admin Tooling.

The new RSA Manager view, along with an enhanced Endpoint Discovery view, support easier OSGi Remote Services testing and debugging.

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.

Exposing a REST service as an OSGi Service

I've produced a tutorial describing an additional use case for Remote Services:  Exposing a Jax REST service as an OSGi Remote Service.

This describes how one can take an existing REST service and expose to consumers as an OSGi Remote Service.

ECF 3.10.1 released

ECF 3.10.1 has been released.

This is a maintenance/bug fix release since the 3.10.0/Mars release in late June.

One notable addition has been the simplification and refactoring of Karaf features, supporting the easy deployment of OSGi Remote Services in a variety of environments (e.g. Eclipse, RCP apps, Karaf servers, Equinox servers or clients, etc).

ECF 3.10/Mars Released

ECF 3.10 has been released as part of Mars.   Some highlights:

Remote Services Tooling - A new Remote Services perspective with views to help design, test, discover, and debug Remote Services

OSGi R6 - Full support for OSGi R6 Remote Services/Remote Service Admin specifications.   Full spec compliance via the OSGi compatibility test suite

New Providers - Support added for websockets and MQTT-based distribution providers, and etcd-based discovery

Apache Karaf - ECF Remote Services can now be easily installed into Apache Karaf

New Tutorials, Examples, and Documentation

More on the New and Noteworthy.  Download here or via repository included in Eclipse Mars.

ECF 3.9.3 release

ECF 3.9.3 was just released.   See here for download.

This was a maintenance/bug-fix release.  Even though a maintenance release, there have been several new non-EF code developments with ECF Remote Services since our previous release:

• Additional Remote Service tutorials
• OSGI Remote Services for OSGi Server Runtime Management
• A Websockets-based Distribution Provider for Remote Services over http/https websockets
• A MQTT-based Distribution Provider for Remote Services over MQTT

There is also work going on to create Eclipse-based Tooling for Remote Services for and after the Mars simultaneous release.  Since the design and implementation work is happening now, if you are interested in providing ideas, guidance, input, and/or contributions, please join the ecf-dev mailing list and contribute your ideas and/or expertise!

ECF 3.9.2 Released

ECF 3.9.2 was just released.  See here for download.

Along with 3.9.2 maintenance release, there is a new tutorial entitled ECF Remote Services for Accessing Existing REST Services.

Happy Holidays

ECF Remote Services for Accessing Existing REST Services

The ECF community has asked about the use of Remote Services for accessing existing web/REST-based services.   To address some of these questions, I've created a tutorial showing how ECF's open APIs can be used to easily expose an existing REST+JSON service as an OSGi Remote Service.

For this tutorial, the public Geonames Timezone service was used, but the techniques shown can be used for exposing any web-based service as an OSGi Remote Service.

ECF 3.9.1 Released

ECF 3.9.1 is now available.   See the New and Noteworthy.

Internet of Things and ECF Remote Services

Last week at EclipseCon Europe ECF committer Wim Jongman gave a talk where he cooked an egg using a hotplate, a Raspberry Pi, ECF Remote Services, and Eclipse Nebula.   Here's a screenshot of the RCP app he created to remotely control the Raspberry Pi and the connected hotplate:

Although I wasn't able to attend, I understand that after cooking, Wim consumed the egg onstage...and it went down pretty easy.  I'm looking forward to watching the video of the talk.  Congrats Wim.

Also, the Eclipse Newsletter has articles focused on Internet of Things, and we have an article about using ECF Remote Services with Raspberry Pi GPIO, which was also used to implement some of the behavior underneath Wim's egg cooker.

For other tutorials on using Remote Services with the Raspberry Pi as well as in other runtime contexts, see the ECF wiki documentation page.

ECF Remote Services Architecture

With the many updates, improvements in ECF's Remote Services releases, along with the tutorials and documentation added recently, it was time to update the Remote Services Architecture diagram.

Shellshock bug, open source maintenance and quality

Interesting NY Times article about shellshock bug, and it's relationship to open source maintenance and quality

ECF 3.9 Released

ECF 3.9.0 is released.   The release provides an update to our implementation of the OSGi Remote Services and Remote Service Admin specifications.   For RS/RSA the latest (R6) version of the specification included additions and changes, and this release supports them.

The implementation has been tested against and passed the OSGi RS RS/RSA compatibility test suite (CT).

To download and install go here.  

Note also that we now have a several tutorials focused on developing your own OSGi Remote Services.  A couple of these tutorials show how to use Remote Services with the Raspberry Pi.

Raspberry Pi GPIO using OSGi Services

I've created an API that abstracts individual GPIO Pins as OSGi services, and made it available via the ECF github repository.  This allows applications to easily use the Raspberry Pi's GPIO to send output to or receive input from peripherals.

I've also created a short tutorial on how to use these services to control a single LED.

This tutorial now has a short demonstration of how to use OSGi Remote Services to do remote control of a single GPIO Pin with Eclipse as the user interface.

ECF 3.8.1 Released

ECF's 3.8.1/Luna has been released.   Some of the highlights

• Fully compliant implementation of OSGi Remote Services and Remote Service Admin standards
• Support for Java8's CompleteableFuture for Asynchronous Remote Services
• Tutorials and documentation for OSGi Remote Services
• Support for creating and running standard remote services on MQTT protocol

A more complete list is provided by the New and Noteworthy

Congratulations to the ECF community

OSGi Remote Services on Raspberry Pi

ECF has created an example and tutorial showing the use of Java 8, OSGi, and OSGi Remote Services on the Raspberry Pi.   Any comments, suggestions, or other contributions are always welcome.

The costs of open source maintenance

Another very interesting story about Heartbleed/OpenSSL...wrt maintenance and support

• Who Should Pay to Keep the Internet's Locks Secure

Open Source In News

Two interesting articles about Heartbleed bug/OpenSSL and the Linux Foundation and OpenSSL Foundation in today's NYTimes:

• Heartbleed Highlights a Contradiction in the Web 
• OpenSSL and Linux: A Tale of Two Open-Source Projects

New tutorial on using Java8 and Asynchronous Remote Services

ECF has a new tutorial explaining how OSGi service designers may now use Java8 CompletableFuture for non-blocking remote services in ECF 3.8.1/Luna. Also present in the ECF wiki is page with additional examples and details on Asynchronous Remote Services.

CompletableFuture for OSGi Remote Services

As some of you may know, ECF's implementation of OSGi Remote Services has support for asynchronous proxies.   This allows consumers of remote services to easily use asynchronous/non-blocking invocation to access a remote service.  For example...here's a simple service interface that's used in our remote service tutorial:

public interface ITimeService {
    public Long getCurrentTime();
}

As with any OSGi Remote Service, any consumer that discovers this service will potentially block when they call getCurrentTime(). This is just the nature of call/return semantics applied to remoting...and so will be true for any implementation of OSGi remote services.

ECF's impl of OSGi Remote Service offers asynchronous proxies, meaning that iff a related service interface is defined...e.g.

public interface ITimeServiceAsync {
    public Future getCurrentTimeAsync();
}

then consumers will be able to use ITimeServiceAsync to access the service...e.g:

ITimeServiceAsync tsa = ... get ITimeServiceAsync reference

Future timeFuture = tsa.getCurrentTimeAsync();
...do work...
Long time = timeFuture.get();

With ECF 3.8.0 we further added [3]...i.e. the ability to have ITimeServiceAsync be registered as a service automatically on the consumer...so that (e.g.) the ITimeServiceAsync reference can be injected via declarative services...e.g.

...ds component impl...

void bindTimeServiceAsync(ITimeServiceAsync tsa) {
     ...use or store tsa...
}

This [3] is all available in ECF 3.8.0.   Note that the service interfaces have absolutely no reference to ECF classes, nor to OSGi classes.   None are needed now.

As many of you certainly know...java8 just came out, and a big part of java8 is improved support for concurrency, functional programming, and lambdas.    This support for concurrency in java8 is potentially very useful for users of OSGi Remote Services.

Consider CompletableFuture, which as the name implies is a type of java.util.concurrent.Future.    It has some very nice properties for API/service designers...the main one being that it's not at all necessary to call Future.get directly...but rather you can write nice, succinct and *guaranteed to be non-blocking but asynchronous* usage such as:

CompletableFuture cf = ...get CompletableFuture....

cf.thenAccept((time) -> System.out.println("time is: " + time));

This is nice...it's completely non-blocking...and very succinct.  Also you can do very interesting things with asynchronous/event-driven chaining/filtering, etc., etc. All guaranteed to be non-blocking...which is a key guarantee for remoting.

Yesterday I realized that with Java8, our asynchronous proxies could be easily generalized to allow this:

public interface ITimeServiceAsync {
    public CompletableFuture getCurrentTimeAsync();
}

I made some minor additions to the ECF remote service implementation of asynchronous proxies and now this is working. What I mean by this is that consumers of an arbitrary remote service can now do this

...service component impl...

void bindTimeServiceAsync(ITimeServiceAsync tsa) {
       // Get the CompletableFuture...no blocking here
       CompletableFuture cf = tsa.getCurrentTimeAsync();
       // print out time when done...no blocking anywhere!
       cf.thenAccept((time) -> System.out.println("Remote time is: " + time));
}

Note a few things:

1. There is no blocking anywhere.  This is true even though the actual time value is retrieved via a remote OSGi service
2. The remote service host doesn't have to provide any implementation of ITimeServiceAsync.  It's constructed by ECF's RS impl automatically
3. It's very easy to handle failure (e.g. network/io failure) via CompletableFuture.handle.  This is obviously a big deal for remote services...which are much more inclined to fail because of the network.
4. No reference to either OSGi classes or ECF classes anywhere in host or consumer code

This is nice for remote service consumers, because it gives them strong no blocking guarantees, and can be very efficiently implemented (no additional threads) by remote service providers using asynchronous messaging (e.g. JMS, etc).   It also allows them to use all of CompletableFuture's APIs (see CompletableFuture javadoc).

This will obviously be part of ECF Luna...and I've created some test code (like above) that I intend to use to create another tutorial over the next month. Watch the ECF wiki for that tutorial.

The only drawback is that this does, of course, depend upon Java8...and so requires that both the remote service host and consumer use Java8, and that the distribution provider be enhanced slightly to use CompletableFuture.   Fortunately it's not technically challenging to make these enhancements, and we will make support classes available for those that wish to Java8 enhance existing or their own RS provider.

[1] https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services
[2] https://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=420785

ECF 3.8.0 Released

ECF has just released 3.8.0.

New and Noteworthy

• Easily use ECF Remote Services in Apache Karaf
• New Tutorials, Examples, and Documentation
• MQTT-based Remote Services Provider
• Feature Refactoring...for Use of Remote Services Outside of Eclipse
• New Support for BndTools

New tutorial: Creating a RESTful Remote Service Provider

ECF's implementation of OSGi Remote Services supports the creation of custom distribution providers.  Why would anyone wish to do this, when they could simply reuse one of the existing providers?   Here are some good reasons:

Service Backward Compatibility:   There are cases where it's not a new service being developed, but rather a new facade for an existing (e.g. web) service.  With ECF, one can easily create a custom distribution provider that reuses the existing service to expose it as an OSGi service.  This allows existing services to continue to be exposed as they were originally written, but also be exposed as an OSGi Remote Service.

Custom Transport Requirements:  Remote services also frequently have specific transport requirements...for example using MQTT rather than HTTP, or using JSON rather than XML.  With ECF, distribution providers can completely control these transport-level decisions.

Standardization and Interoperability:  ECF fully implements both the OSGi Remote Services (RS) and Remote Service Admin (RSA) standards.   One thing this means is that all ECF Remote Service providers (both those created by us as well as others) are automatically compliant with the RS/RSA specifications.   Also, Remote Service providers can be proprietary/closed source or open source as desired.

We've created this tutorial to show how a custom RESTful (HTTP+JSON) remote service provider can be easily built:  Creating a RESTFul Remote Service Provider

New tutorial: OSGi Remote Services

ECF team has created a new introductory tutorial on creating standard OSGi Remote Services

Building your first OSGi Remote Service

Our plan is to create a number of such tutorials on OSGi Remote Services and focus on additional topics such as using/configuring alternative discovery or distribution providers, creating REST-based providers, asynchronous remote services and others.  They will generally first appear here.

ECF 3.7.1 Released

Just in time for EclipseCon Europe 2013, ECF has had our 3.7.1 maintenance release.  

ECF 3.7

ECF 3.7 was just released.

Highlights/What's New

• Servlet API -  for Creating OSGi Remote Services with HttpService and Servlets
• OSGi Remote Service Examples
• Testing Against OSGi R5 Compatibility Test Suite -  For Remote Services (chapter 100) and Remote Service Admin (chapter 122) in OSGi Enterprise Specification
• Zookeeper Discovery Server

Thanks and Congratulations are due to ECF committers, contributors, and community

Evolution of Cooperation

For some time in the Eclipse community, several people have repeatedly discussed the Tragedy of the Commons problem, and it's applicability to Eclipse.  In short, as 'platforms', Eclipse and OSGi can be seen as a kind of 'commons' that we all use and benefit from...for creating developer tooling/IDEs, for creating web servers, for creating mobile applications, etc.

The problem being that this 'commons'...if not sufficiently supported and maintained, will degrade over time...and all of us that depend upon, use, and in some cases profit from this commons will suffer from that degradation.   Some of us in this community (committers) feel that such degradation has been occurring...and continues to occur.  Even though many of us (including me) expend a lot of personal time/effort/expense to continue to support the community.

The question seems to be:  how do you get everyone to cooperate in order to maintain the commons?   Where 'cooperation' means real cost, and real effort on everyone's part.   It seems to me that a big part of the difficulty of doing this is that you have to get not just individuals (committers/people technically capable and knowledgeable enough about Eclipse to actually maintain things), but also both small and large corporations to recognize the need for cooperation and respond to it with more than what I would call lip service ('sure we'll pay for the EF, but we won't pay 8 full-time committers to work on maintaining the platform').   I've pointed out before that small and large groups have different ways of thinking about cooperation...aka collective action...and I further would assert that individuals have a totally different calculation about whether cooperation to maintain a commons even makes sense for them.

In any event, in a previous life I did research work in the psychology of judgment and decision making, and one of my areas of interest was in game theory and the prisoner's dilemma.  As part of this work I read a fascinating book called the Evolution of Cooperation by Robert Axelrod.  The main message of this work (by my interpretation) is that cooperative behavior..coming from self-interest...can be learned.  In my view this work opens up possibilities for solutions to the commons problem...but the hard nut (IMHO) is that group/org learning is an order of magnitude more difficult than individual learning.    And of course...individual learning of the self-interested benefits of cooperation is hard/slow enough.

Article on OSGi Remote Services in Newsletter

ECF has an article in the Eclipse Newsletter about our support of Remote Services/Remote Service Admin Standards.  

ECF Kepler/3.6.1 - Remote Services Takes Center Stage

As part of the Kepler simultaneous release, ECF has just released version 3.6.1.  The complete new and noteworthy is here, but the highlights are:

• Remote Service (RS) and Remote Service Admin (RSA) implementations passing the OSGi Test Compatibility Kit for OSGi R5 Enterprise Specification
• Support for SSL/TLS secure transports in ECF generic provider
• REST remote services provider based upon Restlet 2.2

ECF's implementation is the only existing RS/RSA implementation with an open and modular provider-architecture, which enables new discovery and distribution providers to be created...or existing ones extended...by us or others.   Any such extended/new providers are/will be automatically be RS/RSA standards compliant.

ECF 3.6.0

ECF has just released version 3.6.0. Download here.

Highlights since ECF 3.5.0

• ECF 'generic' remote services provider with secure (TLS/SSL) transport
• Restlet-based Remote Services Provider
• Improved implementation of OSGi Remote Services Admin (RSA) specification

The full 3.6.0 New and Noteworthy is available here.

Congratulations to the ECF committers, contributors, and community!

ECF 3.5.5

ECF has just released maintenance version 3.5.5. Download here.

ECF 3.5.4 and Restlet-based remote services

ECF has just released version 3.5.4. See here for download.

Through our github repo, we now have new OSGi remote services provider based upon Restlet. This allows Restlet to be used as the underlying implementation for OSGi remote services.

The small size and simple implementation of the Restlet-based provider (as well as all the providers) is made possible by ECF's provider architecture. This architecture also allows any transport (rest-based or not) to be easily used to implement any OSGi remote service.

It's probably unnecessary to say, but the use of OSGi services (and remote services), brings many systemic advantages...including built-in support for dynamism, security, version management, modularity, among other things.

ECF 3.5.3 and Restlet Remote Services

ECF has produced a maintenance/bug fix release...version 3.5.3. Go here to download. As per maintenance releases, this release does not have new features or API, but does have bug fixes. Go here for 3.5 New and Noteworthy.

Additionally...some ECF committers have been working with the Restlet team to create an OSGi remote services provider based upon Restlet.

This shows the flexibility of the ECF implementation of OSGi remote services/RSA specifications...as any communications protocol (rest-based or not), can be easily used to create a standards-compliant remote services provider.

Simulation Using OSGi, ECF remote services

There's a new paper about using OSGi (Equinox) and ECF remote services to create a transport-independent, service-oriented, simulation framework. Their paper is here.

I have thought for some time that the combination of OSGi, with standardized, open, remote/distributed services (as is provided by OSGI remote services and ECF's implementation of that spec)...would be a strong simulation environment, and now Martin Petzold, Oliver Ullrich, and Ewald Speckenmeyer have shown that thought to have some merit.

As well, the authors have made their own framework available as open source.

Thanks to Martin, Oliver, and Ewald for doing and reporting some terrific work...and to the ECF community for providing support.

ECF 3.5.2

I'm pleased to announce the immediate availability of ECF 3.5.2. This is a maintenance release, with bug fixes only. Much of the emphasis for this maintenance release was on OSGi remote services and Remote Service Admin (RSA) support.

Congratulations are due to the ECF community.

Restlet for OSGi Remote Services

The ECF project released a new version of it's implementation of the OSGi 4.2 Remote Services Admin (RSA) standard.

ECF's provider architecture allows new distribution modules (known as providers) to easily be created and inserted underneath the ECF RSA implementation. The remote service consumer can now use the OSGi services model for accessing remote services...without regard to the underlying transport. If desired, one can create a service using one transport (e.g. r-osgi), test it using another (e.g. ecf generic) and deploy it using yet a third (e.g. your custom protocol)...even changing the distribution protocol for a remote service at runtime. The application requires no code changes to change providers. This is the beauty of standardization (no lockin) for distribution systems.

What does this have to do with Restlet?

Now that Restlet has been well integrated with OSGi it's now easy to use Restlet as a distribution provider module...and that's what I've just finished implementing. So now, one can use standard remote services API (i.e. OSGi remote services spec)...along with standardized enterprise remote services management (i.e. OSGi RSA spec)...and use Restlet/http+rest as the underlying distribution mechanism for exposing and accessing the remote service.

Here's a simple Restlet example

public class HelloResource extends ServerResource {
  @Get("txt")
  public String sayHello() {
    return "Hello RESTful World";
  }
}

Note the @Get("txt") annotation...this is Restlet annotation that defines that http access to this method.

To turn this into an OSGi remote service, all that's necessary is to expose the desired service as a service interface

public interface IHello {
  @Get("txt")
  public String sayHello();
}

and then add '...implements IHello' to the HelloResource class...e.g.

public class HelloResource extends ServerResource implements IHello
...

And that's it. Now (with the Restlet provider and ECF 3.5.1 remote service admin) when the HelloResource is exposed via Restlet, a IHello service is exported...and published for remote discovery (via Zookeeper, Zeroconf, DNSSD, SLP, file-based discovery, or some custom discovery). Then, as per the OSGi RSA specification, remote service consumers will discover the remote service and import the remote service as a IHello proxy (with RSA's support for versioning, etc). For the client/service consumer, all of the mechanics of import is handled by RSA...the programmer does not have to be concerned with it if they don't wish to be.

As an example, here's the code for a java-based client (assuming DS injection/binding):

void bindHelloService(IHello hello) {
    // Now that we have discovered the service
    // We'll use it.  The implementation of sayHello 
    // remoting is provided by Restlet
    String response = hello.sayHello();
    System.out.println("Response to our hello was: '"+response+"'");
}

When run with the HelloResource server, the response is:

Response to our hello was: 'Hello RESTful World'

Of course, other clients (e.g. browser/javascript-based, php-based, etc) can also be used to access the same RESTful service.

Another nice aspect of this use of the ECF provider architecture is that other REST frameworks...e.g. JAX-RS, etc...can be used similarly...and even run concurrently in the same server, if desired.

ECF 3.5.1/Indigo - Supporting Standards

With ECF 3.5, we released an implementation of the OSGi 4.2 enterprise standard known as Remote Services Admin (RSA).

Using ECF's modular provider architecture, it's now possible to get the benefits of being completely standards compliant, while...if you wish...still using your favorite remote services distribution API (e.g. REST-based, SOAP-based, JMS, proprietary, open...your choice). Service-Oriented Architecture and Modularity working together via open implementations of open standards...hmmm :).

Standardized APIs make creating and managing remote services much easier...without sacrificing necessary flexibility. Standardization also allows easy integration with other frameworks, such as Declarative Services, Spring, and/or others.

In March we got access to the OSGi Test Compatibility Kit for Remote Services, and since then have fixed bugs in the implementation to guarantee full spec compliance, as well as addressed bugs reported by the community.

We've also significantly increased our documentation and examples...for remote services as well as other parts of ECF...and created a ECF documentation project to more easily incorporate community contributions...in the docs areas identified as most important by our community.

ECF 3.5.1 is available now here, and is part of Indigo simultaneous release.

See also a recent EclipseZone article about ECF for other exciting things that are part of this release.

Restlet and OSGI remote services - Part 2

In a previous posting, I described some of the advantages of integrating the Restlet framework with ECF's implementation of OSGi remote services admin (RSA).

In this posting, I'll describe a couple of the advantages of doing this for the service host side of things (the server that exports and implements the remote service).

Advantages for Remote Service Host

Modular re-use of Restlet Framework. The Restlet framework can be used to easily define remote services that are exposed via http access methods (e.g. GET, POST, PUT, DELETE). Restlet has become popular as a way to create and expose remote services, and all existing uses of Restlet can immediately and modularly be reused.

Use of standardized meta-data format. One of the most valuable things about the Remote Service Admin specification, I believe, is the standardization of the meta-data for a remote service. This is accomplished by standardizing the EndpointDescription format for remote services. Among other advantages, standardization of this meta-data allows the easy creation of tooling for reading/parsing, as well as writing these meta-data.

Modular re-use of network discovery. Since EndpointDescriptions are standardized, they can be easily published and discovered via various discovery protocols. ECF's discovery API is a transport-independent API for advertising and discovering services, and this API is used by the ECF RSA implementation. This allows discovery providers to be substituted...without any required changes in the export or import of a remote service. So not only can any of the existing ECF discovery providers be used interchangeably for EndpointDescription discovery (Apache Zookeeper, Zeroconf/Bonjour, Service Locator Protocol, DNSSD, xml-file-based discovery), it's also easy to create your own discovery provider, using proprietary or open protocols for remote service discovery...to meet enterprise requirements for security, integration, and customization.

The conclusion, I believe, is that standardization provided by the OSGi RS/RSA specs, along with ECF's modular, provider-based implementation (enabled by OSGi modularity and OSGi services) makes it easy to develop, deploy, manage, and maintain standardized remote services, without giving up flexibility...to determine how those remote services are discovered, accessed and managed in SOA-based systems.

Summary: Modularity and Standardization are complimentary for reuse, flexibility, and interoperability of remote services.

Restlet and OSGI remote services - Part 1

ECF recently released a standards-compliant implementation of OSGi 4.2 remote services admin (RSA).

RSA promises the easy integration with existing SOA frameworks in a standardized OSGi remote services context. To prove the utility of this to myself I decided to integrate the popular Restlet API with ECF's RSA impl expose REST-based web services as standards-compliant OSGi remote services.

I was very happy to find that with the Restlet API, the Restlet-OSGi-integration work, ECF's RSA impl, and ECF's REST API, that doing this was about two-days' work. In addition to being simple to do, there are several advantages of doing this...both for service consumers and service hosts.

Advantages for Service Consumers

• Many clients can/are immediately supported (e.g. browser, new clients, servers that access the service, etc)


• No client-side development at all. ECF's RSA impl creates a proxy (as well as an asynchronous proxy), and makes that proxy available within the local OSGi service registry...with no development at all. This makes it easy to also use OSGi declarative services, Spring/Virgo, or other frameworks to access remote services


• OSGi classloading subtleties are fully dealt-with, as ECF's RSA impl handles the proxy creation in a standardized, secure, service-independent way


• Service interface versioning is automatically supported...by the RSA spec


• RSA's discovery can be used to publish and discover a remote service. With ECF's impl of RSA, this allows the modular use of a variety of network discovery protocols, including Apache Zookeeper, DNS-SD, Service Locator Protocol, Zeroconf/Bonjour, xml-file-based...and also enables using one's own discovery mechanism (proprietary or not)

In another posting, I'll describe some of the advantages on the service host side (i.e. the OSGi server that publishes/exposes the Restlet service).

ECF enables Thermonuclear War at EclipseCon 2011

How's that for a title? :). ECF committers Mustafa Isik and Sebastian Schmidt are giving this talk at EclipseCon on Monday:

INTERSTELLAR THERMONUCLEAR WAR ... with ECF

Mustafa previously did much of the initiating work on real-time shared editing in ECF as part of his Google Summer of Code project. For Google Summer of Code 2010, Sebastian implemented a Google Wave provider for ECF.

Now they are at it again :). Mustafa and Sebastian are using/integrating several great technologies to do innovative and fun things with the Wave protocol for concurrency control in multiplayer games, OSGi servers, remote services, Android clients, ECF's multi-provider APIs, and other exciting technologies.

I know from working with Sebastian and Mustafa, as well as working on some of these technologies myself, that it will be a great talk. Please enjoy.

ECF 3.5 - Remote Services Admin

ECF 3.5 was just released. One of the New and Noteworthy for is a complete implementation of the OSGi enterprise standard known as Remote Services Admin (chapter 122 in the enterprise spec).

First: What are OSGi Remote Services?

OSGi remote services defines a simple, standard API...using normal OSGi services...for exposing services for remote access. ECF has supported the OSGi Remote Services specification for more than a year...and it's been hardened through community usage, bug reporting, and feedback.

What is RSA?

RSA is an enterprise management agent for OSGi Remote Services. As of ECF 3.5), we fully support the RSA specification, which allows very fine-grained control, management, and security for enterprise remote services. Specifically, it's possible for the both the remote service discovery and distribution to be customized or extended as dictated by the (enterprise) use case...without resorting to non-standard API.

Why ECF's Implementation?

ECF's implementation has a number of unique technical attributes, including transport independence through multi-provider architecture, support for asynchronous remote services, support for Felix and other OSGi frameworks, small code size, and open, community-based development process.

ECF 3.5

ECF 3.5 has just been released.

New and Noteworthy

• Full implementation of OSGi Remote Services Admin (RSA). Chapter 122 from the OSGi enterprise spec


• XML-RPC remote services


• ECF on Felix


• Documentation Project for community-contributed documentation

To be fair and balanced, give up centralized control

This posting is in response to Ed Merks' recent meandering To Be Fair and Balanced, That is the Question.

My suggestion is that to be fair and balanced, one has to give up control...and in this case turn the decision of project-level resource allocation away from any centralized body (like the EF Board of Directors...or the committer reps, or the EMO, or the strategic members, etc). In short, give that decision making power to the people that matter...the communities that the projects serve. That is the purpose of this new FOE disbursement bug.

The point is this: it's seems unlikely to me that any fair and balanced decision can/could be made by me, the committer reps, the EMO or the Board about project resource allocation across many very different projects...because there is probably permanent disagreement about what is fair.

And to Ed: let's get past the snarkiness and personal discrediting/attacking, shall we?

ECF 3.5 supports OSGi 4.2 Remote Services Admin (RSA)

OSGi 4.2 remote services support was the major theme for ECF 3.3 and 3.4.

For ECF 3.5 (late Feb 2011), we will release a full implementation of the OSGi Remote Service Admin (RSA) specification from the enterprise experts group. The RSA spec (chap 122) extends the remote service spec, and provides standard ways to monitor, control, secure, and extend the use of OSGi remote services.

ECF's impl of this spec is now complete, and we are engaged in testing (with the OSGI TCK), integrating with examples, adding new examples, and adding documentation.

One exciting thing about this implementation is that with ECF's open provider architecture, it's possible for other discovery and/or distribution systems to be easily introduced by anyone (us or others)...and all providers will automatically be standard compliant. This vastly simplifies the job of taking an existing protocols and transports (for example a REST-based protocol) and exposing them as OSGi remote services.

Further, ECF's impl already supports asynchronous remote services, and this support is exposed in a standards-compliant way.

ECF 3.4 Remote Services

ECF 3.4 was recently released. This release (along with Helios/3.3 and upcoming releases) heavily emphasized the implementation of OSGi 4.2's Remote Services specification. Our community is pushing us to continue this emphasis, and so we will.

Here are some reasons to use ECF's OSGi 4.2 Remote Services implementation:

1. Standards Compliant: It is fully compliant with the Remote Services standard. No lock-in...now and forever


2. Asynchronous Remote Services: Unlike other implementations of this standard, right now it provides support for Asynchronous Remote Services


3. Multi-Transport: Right now it supports multiple network discovery protocols (e.g. Zookeeper, DNS-SD, SLP, Zeroconf, static xml-file), and multiple distribution transports (e.g. r-OSGi, ECF generic, XMPP, JMS, Http/REST-based protocols, JavaGroups)


4. Extensibility through Modularity: The open discovery and remote services APIs allow new discovery and distribution implementations to be substituted at will...proprietary or open...without requiring any additional work to support the OSGi standard


5. Enterprise support: We are completing (for ECF 3.5) our implementation of the Remote Services Admin specification. The progress on this can be easily and publicly tracked...contributions, test/testing, and early uses are welcomed and encouraged.


6. Open Community: ECF is not just open source, but also has a completely open, diverse, growing, active...and most importantly...a contributing community


7. Open Process: We've moved to GIT, to make community support and contributions easier


8. Multi-Framework: ECF remote services now runs on Felix (and probably other OSGi frameworks as well)


9. Robustness through Community Usage


10. Low-license fee: $0 :)

Innovation and Openness

There is a Sunday NY Times article about what promises to be an interesting book:

Innovation: It Isn't a Matter of Left or Right

Johnson apparently makes the claim that 'collaborative, non-proprietary, open networks' are of high importance for technology innovation. This strikes me as true, and explains my intuition that open source projects like Eclipse and ECF are well-positioned to create value through innovation.

ECF 3.4 Released

ECF 3.4 is now available. There have been many community-driven, and community-contributed improvements...here are some of the highlights:

• DNS-SD Remote Service Discovery for WAN


• Atom/RSS REST Enhancements


• Distributed EventAdmin Improvements


• OSGi 4.2 Remote Services enhancements


• Bugs Fixed


• Moved to GIT


• Remote services runs on other OSGi frameworks

Congratulations are due to the ECF committers and community. Remember to see Fun with Remote Services talk at ESE for a taste of the things provided by ECF's open implementation of this OSGi standard.

Asynchronous Remote Services - choices, choices

In ECF's Helios release, we released an implementation of the OSGi remote services standard specification (chapter 13 in compendium).

In addition to the full spec implementation...which is based upon synchronous remote service proxies...we added support for asynchronous remote services. This provides non-blocking access to remote OSGi services. This gives remote service consumers choices...allowing them to invoke remote services synchronously (i.e. by making a blocking method call on the proxy), and/or asynchronously (with a guarantee that the calling thread will not block).

I think that one nice thing about this approach is that the service host implementer has to do exactly nothing to make these consumer choices available. The implementation of the service host is exactly the same.

There are two styles of asynchronous access supported: an asynchronous callback (like GWT), and a future result, from the Actor model of computation. These two styles of of asynchronous access...along with the specified synchronous proxy...provides remote services consumers with some useful choices for creating reliable distributed systems and applications.