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?