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.