Tooling Related Challenges for OSGi EEG

During EclipseCon last week there was a BOF about tools for OSGi, and the day after an OSGi Tool Summit (Chris Aniszczyk posted a good summary).

Two significant challenges for the EEG emerged from these excellent discussions: complete the OBR design and define the term "application" as it relates to a collection of OSGi bundles and the resources they depend on. The OBR design work was partially completed in 2006, before the EEG started, and we had initially hoped to pick up the work from where it was left off.

At the main OSGi BOF it quickly became apparent that the Eclipse/OSGi community had diverged somewhat in this area, with Eclipse P2 taking a different approach. Among the attendees, Jason van Zyl probably put it best when he said (basically) "I don't care which one I have to follow, I just want a single standard" to support build, provisioning, and deployment lifecycle activities for OSGi. (Jason's company, Sonatype, is developing Maven based tooling for OSGi application development that promises to address a lot of these challenges.)

The challenge for Tim and me will be getting the OBR and P2 folks together and hashing out something agreeable to all. Unfortunately for Hal, he was the one to volunteer to drive this effort ;-) (The EEG work depends on volunteers to drive requirements and design docs.)

To be fair, none of us in the EEG really knew much about what was going on with P2, so it's important to take a step back and essentially reset the discussion. Unfortunately, during the January EEG F2F we identified progressing OBR as the highest priority work item...and with the strident calls for address the tooling challenges, we are going to continue to strongly focus on it.

A related topic for the EEG is the definition of an application as it relates to a deployment on an OSGi framework. A simple answer to this question is that an application is the same as a bundle, or anyway a bundle that references or includes all the other bundles it needs. But for enterprise applications, a strong requirement has been given to ensure consistency across the develop-test-deploy into production cycle.

The dynamic nature of the OSGi framework, usually one of its most attractive benefits, can be a liability in this area. So it seems there needs to be some way to formalize some metadata for what it means for a collection of bundles and associated resources to be used for a specific application. We have just started on the requirements document for this, but this is strongly related to the bundle repository/provisioning standard - the application definition is something that could be stored in and retrieved from the repository, and used to filter the collection of bundles and resources that need to be resolved and provisioned...

Should be fun!

OSGi BOF at EclipseCon

Update 3/16: Multiple OSGi BOFs at EclipseCon - Monday evening is the general OSGi BOF and Tuesday evening is the Enterprise OSGi BOF.

A week from Monday (wow time flies) the OSGi BOF will be held at EclipseCon. My EEG co-chair and I will be presenting an overview of the upcoming 4.2 OSGi specification release. The goal is to summarize the release and start a discussion. BJ and Peter are also going to be there, as are several other members of the core platform and enterprise expert groups, so this should be a good opportunity to engage the folks working to finish things up.

As this last sentence implies, the release is not yet completed, although it is being released in stages, and the core is about done. The compendium will follow, and later this year a collection of Java EE component mappings. So there is still an opportunity for feedback and input.

This week we also prepared another early release draft (third one) for approval by the OSGi Board, and with any luck this will be available early next week. It includes further updates to the RFCs (i.e. design docs) from which the specification updates are derived, some RFCs for Java EE mappings that haven't been previously published, and early drafts of the updated core and compendium.

We also just completed three days of (intense!) EG meetings, and therefore will have some recent updates to share.

Hope to see you at the 'Con! If not, please take a look at the early drafts and submit feedback.

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.

Distributed OSGi Tutorials

David Bosschaert, Progress Fellow and one of the drivers behind the Distributed OSGi/RFC 119 design and implementation, has posted a couple of good tutorials about it on his blog.

Here's his simple example to get started using the Distributed OSGi Reference Implementation and a more complex example using an Ajax client for a service invocation from an external source.

When we initially wrote the requirements for Distributed OSGi to start the EEG process of designing a solution that could be included in the next rev of the OSGi Specifications, we focused not only on the use case in which an OSGi service is able to invoke another OSGi service in a different (potentially remote) JVM, but also on the use cases in which an OSGi service might be invoked by an object external to an OSGi Framework.

David will be at the OSGi Dev Con in March (co-located with EclipseCon) and will be giving a presentation and demo about Distributed OSGi/RFC 119 along with Scott Lewis and others. ECF will be supporting Distributed OSGi/RFC 119, and there's note to the bottom of this page (and a comment to a previous post) that seem to indicate that Eclipse Riena also will, and apparently Paremus InfiniFlow too (if I have understood this interview correctly). So it looks like we are well on our way toward our goal of completing this work during the next few months.

In any case, please be sure to take a look and let us know what you think of Distributed OSGi/RFC 119, either in response to the blog posts or in person at OSGi Con.