Eric Newcomer's Weblog

Here's this year's Christmas tree.

Christmas 2008

After all the ice and snow, and the people without power for two weeks tomorrow, let's have a great holiday, and good wishes for everyone.

Last week I attended my last OSGi Board meeting, which was hosted by SAP near Heidelberg. Although I'll remain EEG co-chair, Gordon is replacing me on the board.

As you might imagine, one of the hot discussion items was Sun's recent announcement of Project Jigsaw, their latest modularity initiative. Hal, Mirko, Peter, and Neil have already recorded their thoughts in their blogs, and I don't want to repeat what they've already said.

One way I like to sum it up is that it wasn't the breakthrough we were hoping for. After Sun rejoined the OSGi Alliance last year, and announced they were using OSGi in Glassfish, OpenESB, and ProjectFuji - not to mention hiring the Apache Felix project lead - many of us started thinking Sun might finally bury the hatchet. But no, Sun has apparently decided to cooperate with us by competing with us.

We knew, of course, that Sun is kind of schizo about OSGi. I did my best to encourage them to participate in the EEG, and after Sun hired Richard, I guess you could say that sort of happened. But he still is primarily focused on Felix, which is understandable. We have not seen or heard anything from Mark Reinhold and his colleagues, however.

And now we have to worry about the confusion Sun's announcement creates. I can't see the customer or the industry benefit in having to choose between two modularity systems. Do we really expect all the vendors that are currently shipping hundreds of products on the OSGi Framework, to invest in supporting an additional modularity framework for their products, just because Sun proposes it? Yet it is certain to raise questions and generate debate, just as the end is in sight for the OSGi enterprise release.

We have released an updated draft (warning: this is a pdf link) of the current design documents. Several of these have been submitted to expert group vote so that the final phase can begin - writing the specifications. (BTW it's not too late for comments and feedback on the updated drafts.)

You may know that the OSGi Alliance is unique (at least among standards consortia I've worked with) in hiring someone to write all the specifications (Peter Kriens, of course). I think this is one of the reasons the OSGi specifications are so good - and because Peter has been with OSGi since the beginning, he can ensure continuity and consistency.

With any luck, we will be more or less done by March, 2009. I am not exactly sure what the bits and pieces of designs we have add up to yet - I think one of the major work items (in significance if not effort) is to check the current designs against the original requirements, and against several scenarios people are likely to want to use OSGi technology for in the enterprise - such as building web applications, distributing an application's processing work, or managing persistent data.

I want to be sure the release adds up to something, and that it will have the best chance at being adopted. This was, of course, another important discussion item during last week's Board meeting: getting the enterprise release out and ensuring its success.

For me one of the big factors has always been, and still is, whether or not enterprise developers will adopt the OSGi programming model. I am optimistic.

Last week at IBM Montpellier the upcoming OSGi 4.2 release got a bit closer, and Yan Pujante presented LinkedIn's requirements.

Peter can't believe what Yan is saying... !

In the now usual pattern for a two-day expert group face to face, the first day was given to the core platform expert group (CPEG) and the second day to the enterprise expert group (EEG).

Neither can the rest of us...!

The work to produce the enterprise edition of the OSGi specifications is roughly divided between these two groups, based on whether a particular work item changes the core platform framework itself (CPEG), or to extends the core platform with new features (EEG).

The goal is to complete work on R4.2 in time to deliver compliant software in the Eclipse Ganymede release, scheduled for June 2009. This is because the Eclipse platform, Equinox, is currently the reference implementation of OSGi. However, we have had good participation in the meetings from the other platform providers, including Apache Felix, Prosyst, and sometimes Makewave. It is looking tight, but do-able. And we made some good progress Wed-Thurs last week.

Since I'm EEG co-chair I'll concentrate on that from here on. During Thursday's meeting we pretty much closed out the major design documents: Blueprint Component Model (Spring-"inspired") and Distributed OSGi. The Blueprint, aka Spring/DM (see discussion here) and is nearly complete, just working on the final collection of bugs, most of which have been submitted by Rick McGuire of the Apache Geronimo team, who's developing the conformance test suite (TCK). SpringSource is providing the reference implementation, which has been available for some time in the Spring-DM project.

Needless to say, the Spring mapping document, aka RFC 124 (see Adrian's excellent summary for what it means) is probably the most important work item for the EEG.

Next is probably the Distributed OSGi document, aka RFC 119, which defines extensions for configuring OSGi services to communicate remotely using existing distributed software systems. The RI we recently demo'd for this is hosted at Apache CXF, and David Bosschaert recently posted a Spring-DM update for it. Tibco is working on the TCK, so we are in pretty good shape overall now.

During the afternoon, Yan presented LinkedIn's view of OSGi, including information about their requirements for using it in their next-generation platform. Jan drew pictures on the whiteboard, and used bits of this slideshow. Their major interests are improving the modularity of their applications, and updating them more easily and dynamically. It's great to have a user company participate in the meetings - we could actually use more and I hope more will consider joining.

LinkedIn's Distributed OSGi design

After Yan's presentation we focused on the Java EE mapping work, which has progressed intermittently throughout the past couple of years. It was always a goal of enterprise OSGi to include components of Java EE, but it was not always easy getting everyone to focus on the work and agree on a direction. At the Board meeting in June however, the Java EE work was identified as a priority for the release, and since then we we have been more focused on it and are starting to get somewhere, although significant work remains.

After discussing the topic with others, I believe the priorities are improving the support for Web applications, and for mapping JNDI, JPA, and JDBC. The design docs are in pretty good shape for JTA and JMX, so those are ok. It will be tight, but it looks like we have the right people assigned from Oracle, IBM, and SpringSource to make it happen. Maybe security is also needed...?

Of course, it's easy for me to say the design docs are in pretty good shape now, and that several from CPEG and a few from EEG are ready to move into the formal specification phase, but Peter Kriens actually has to write the specs now, and we will have to see how he gets along...

Place de la Comedie, Montpellier (Peter's home town ;-)

ps on the drive back to the airport, I took a brief detour to Arles, and toured the old Roman town, including the collesium, which is still used, apparently for bullfights (not Christians and lions anymore..)

Find your seat

No bulls today

Inside the collesium walls