Eric Newcomer's Blog

The goal of distributed OSGi is to extend the OSGi framework for distributed computing capabilities by configuring an existing distributed computing software system (such as Web services, CORBA, or Eclipse ECF) behind an OSGi service.

David Bosschaert and I recently gave the first demo of the new design for distributed OSGi, based on the current draft of the Enterprise Expert Group's RFC 119, at the OSGi Community Event in Berlin.

Eric Newcomer appearing in a SYS-CON.TV Power Panel with Jeremy Geelan live from Times Square, NY

The demo showed a Web services solution using Apache CXF as the distribution software, but the design should work with any distributed computing system.

The demo used Apache Felix for the OSGi framework and shows the configuration and publication of a remote OSGi service and uses CXF facilities to generate a WSDL file and consumer and provider proxies for the service.

The goal of distributed OSGi is to allow a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM). Today the OSGi standard defines how services talk to each other only within a single JVM. Extensions are needed to allow services to talk with each other across multiple JVMs - thus the requirements for distributed OSGi on which the design is based.

We did not want to invent a new distributed computing system, since so many already exist. (In fact we had pretty strong feedback on that point!) The design introduces some new OSGi properties to identify a service as remote and a discovery service through which a local service can find a remote service and obtain the metadata necessary to interact with that remote service. The design is intended to support any communication protocol and data format (with some constraints of course, having to do with the use of Java request/response interfaces as the service contract). Another goal of the design is to allow services in an OSGi framework to interact with services external to OSGi, both as client and server.

The design uses SCA intents to express a service's capabilities, and a requester can use these intents as a filter to help discover services with the required capabilities (e.g. security or reliability).

Overall we recieved good feedback, and a lot of questions pertaining to work that still needs to be done. We hope to be able to publish the code to Apache and publish a draft of the design doc this summer, perhaps in August, after we have a chance to formally review the initial implementation with the EEG membership, and get their blessing (no doubt there will be some changes as well since this is just the start).