Purity or Compromise?

Update August 7: David Bosschaert has started a new OSGi blog for topics related to the EEG direction etc. I recommend every reader of this blog to check it for updates on what's happening at the EEG from here on.

Also a colleague pointed out that my diagram and text below is a bit optimistic about the availability of the Blueprint Container as a development model for Web apps in the near future. The current version of the design (documented in RFC 66) does not actually address this, although a future version is definitely expected to. The current version of the design simply standardizes the deployment of a WAR file onto an OSGi framework, which is a good first step but not the end goal.


This is my last blog as co-chair of the OSGi EEG. In fact as of last Friday David Bosschaert has officially taken over the position. But I was co-chair for last week's face to face meeting in Dublin, so I'll write a bit about what happened.

We have completed the R4.2 Core and Compendium specifications, which were submitted to the 45-day member review July 14. Assuming the vote goes well, publication will be early September. The Compendium includes the new Remote Services and Blueprint Container specifications, and the Core includes several enhancements and extensions resulting primarily from requirements gathered at the enterprise workshop.

That leaves the R4.2 Enterprise Profile, scheduled for release in December, for the EEG to work on. The major part of this work will be mapping various Java EE specifications to OSGi, such as JTA, JMX, JDBC, JNDI, JPA, and last but certainly not least Web apps. The profile will likely also include (by reference) the Blueprint Container and Remote Services parts of the R4.2 compendium.

Enterprise Profile Summary Diagram

I created the diagram to illustrate what we're trying to achieve, and presented it last week to help facilitate the planning part of the meeting to provide context around prioritizing the remaining work (it is not part of any formal OSGi document). Time is getting tight ;-) The OBR continuation is for example looking more like an R5 item at this point.

The main point is that defining a mapping for Web apps (.WAR files) using the Blueprint Container as the development environment and JDBC/JPA for persistence would seem to meet the requirements for a large number of enterprise applications, and represent a good starting point for the initial release of the Java EE mapping work.

What I call "system services" on the side represents the optional use of additional Java EE components (such as transactions, security, directory, and management) that such a Web application might choose to use if it needs them, along with Remote Services for invoking OSGi services deployed in other frameworks.

Because the Java EE components were not designed for OSGi, they depend on mechanisms such as context classloaders and file URLs to instantiate required classes and resources. Which of course breaks fundamental OSGi abstractions, since the framework is responsible for loading classes and managing the access to required resources. We had a very lively debate on the subject of how much the Java EE components should be required to change vs how much the OSGi specification should have to change. We did not reach consensus.

I think the solution may be found in a kind of mapping layer or adapter mechanism (conceptually similar to JCA), like the one in SpringSource dm Server, or in the ServiceMix Kernel (which has been moved to a separate project called Apache Karaf). But all I can really say at this point is that I will be very interested in hearing the results of the ongoing discussion.

Next Monday I start my job as an integration architect for Credit Suisse in New York. And they are not members of the OSGi Alliance - at least not yet ;-)

Thanks to everyone who followed the posts on this blog, and who participated in the discussion. Please keep it going! And support David and Tim and the rest of the EEG members...