Distributed OSGi Discussion

The reaction to Distributed OSGi (aka RFC 119) has been mixed. Those involved in the OSGi community seem to like it, while Java EE folks seem to be a little cranky about it, at least if I interpret the comments on the Server Side article correctly.

(A somewhat longer article on InfoQ includes more history and perspective, but no comments yet.)

The Eclipse ECF project has recently released its support for Distributed OSGi, including the discovery service part of the design (which is not yet included in the Apache CXF code referenced above). The session on Distributed OSGi at EclipseCon next month should be very interesting, given participation from both Eclipse ECF and Apache CXF communities.

Mike Francis of Paremus confirmed in a comment to my previous entry that they intend to implement Distributed OSGi in the future, as part of their planned move to OSGi R4.2.

I also have heard some discussion about the Eclipse Riena project adopting Distributed OSGi, but no confirmation as yet. And no statement yet from the WS02 Carbon folks... But the RFC 119 design does seem to be gaining ground overall.

I have received a suggestion (see comments to blog entry referenced above) to extending the design to allow developers to directly control the distribution software (i.e. avoiding the dependency on generated proxies). I don't think anything in the design prevents this today, just as I don't think anything prevents the use of RMI to serialize executable code. I have written before about the tension between abstraction and control. Finding the right balance is not easy.

In terms of adding this to the standard, it could definitely be a discussion topic for a potential new requirement. Given where we are in the OSGi process (which I outline in the InfoQ article referenced above), we are more focused now on refining the current design and updating the spec than thinking about new requirements.

I have noticed that the Eclipse ECF implementation does add some features and functions to the design, which I think is a good sign. A good standard does not define all possible features and functions, but only those necessary for compatbility across multiple projects/products -- a common foundation on which to build good, interoperable solutions. So far it looks to me like we are on the right road.