OSGi for the Enterprise Gets a Bit Closer & LinkedIn Too

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


One response to “OSGi for the Enterprise Gets a Bit Closer & LinkedIn Too

  1. Perspective on OSGi for the Enterprise

    I once heard an OSGi guy from BEA (now Oracle) say that everyone thinks about OSGi for its deployment capabilities, but the real power is in its service model. I have mentioned this controversy before, i.e. whether or not the OSGi programming model is…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s