Last week Progress Software hosted OSGi expert group face to face meetings - one day for CPEG and one and a half days for EEG. Aside from complaints about the cold weather (as in why anyone in their right mind would schedule such a thing in January for the Boston area), we had a very good two and a half days, and a couple of nice dinners. Tuesday night we ate at the Flatbread Company in Bedford, where we got pizza with nitrate-free pepperoni.This photo shows us hard at work (!) reviewing one of the many documents in process for the upcoming 4.2 release of the OSGi specifications.
The highlights of the meeting included Alex Buckley joining to discuss JSR 294, which has been recently reactivated. Unfortunately, he faced a difficult task in explaining to this group why JSR 294 had not based their work on the OSGi specificiations. Alex offered two answers: the first was about the benefits of aligning design time and runtime modularity, and the second was about the preference to include metadata about modularity directly in the language rather than in an external source.
We could only allocate about 90 minutes or so to this discussion, since we had a lot of other items to cover, so we were really only able to start the discussion. Alex was invited in the spirit of cooperation, and what I expect out if it is a definition of how the OSGi framework and JSR 294 can leverage each other. However, we will need more time to get to the bottom of this. IBM and Oracle are on the JSR 294 expert group, and with Alex's participation in the OSGi EGs, there should be good opportunities to continue the discussion in both forums.
On the basic work of the OSGi EGs, the theme is now getting things ready for the release. Several of the design documents have been voted on, meaning Peter Kriens can start updating the specifications to include them. As you may know if you have read the current OSGi Specifications, they are divided between the core specification and the compendium specification. The work of CPEG is basically aimed at updating the core, and the work of EEG basically aimed at updating the compendium. It's never exactly that simple, of course, but that's the main idea.
As usual, I'm going to focus my report on the EEG portion of the meeting. The major docs to pass EEG vote were distributed OSGi and the Spring-inspired blueprint component model. The JMX and JTA mappings also passed, but at least for JTA there's a relationship with JDBC and JPA as yet to be completed since the JDBC and JPA design docs are still in progress.
Another highlight of the EEG meeting was the discussion focused on evaluating what our work adds up to for enterprise developers. What kinds of applications can they create? What is the enterprise release good for, and what is it not good for? What are the gaps in our work, especially those that can be filled quickly (i.e. for this release).
As you may recall, if you have been following the EEG work, we are focusing now on which parts of Java EE make most sense to map to the OSGi framework. It seems that with Web apps, JTA, JDBC, JNDI, JPA, and JMX (although this is more precisely Java SE), distributed OSGi and Spring/Blueprint, we are in pretty good shape for meeting the requirements of most enterprise applications we could bring to mind. One important gap is JAAS, and so we will begin working to add that, too.
A large part of the discussion focused on issues that enterprise developers encounter when starting to incorporate OSGi bundles/services into their applications. First of all, what is an application? Unlike Java EE, where you can find the definition in an external file, the OSGi framework is dynamic, and the practical definition of an application therefore becomes whatever bundles are loaded at the time. In other words, the application is more or less self-describing.
But this isn't very helpful to someone who wants to figure out which bundles are in which "business applications" and how to build and maintain that application. I understand the resistance among OSGi folks to import a traditional static definition of such a thing, but on the other hand the world of OSGi software and existing Java code has to be integrated somehow. This is of course a lot of what SpringSource has been doing with its dm Server product - adapting existing Java code so it can be successfully used in OSGi projects.
Now let's take a step back for a moment, because the reasons to invest in OSGi based development need to be clear and of sufficient value to justify the effort. The two major benefits are modularity and dynamic deployment, which includes the ability to update an application without taking it down (there I go, using that word "application" again). The benefit of moduality is basically a development time benefit and can be achieved without a lot of recoding - although if one wants to support multiple deployment options (i.e. on an OSGi framework and also on Tomcat, an application server, or a proprietary container), then it gets more complicated.
But to obtain the ultimate benefit of 100% uptime, to deploy and update an application without having to cycle the container, you have to invest in making all modules into OSGi services. And here we start getting into the kinds of issues that Peter Rietzler and others have been blogging about lately. This inevitably brings up the question of "green field" applications, i.e. to what extent enterprise applications are likely to be coded completely from scratch (as opposed to having to use existing code).
Listening to the discussion, including Yan Pujante's summary of his experiences at LinkedIn, I became convinced that green field applications in the enterprise space are going to be highly unlikely. In other words, we are definitely going to have to deal with the compatibility issue - otherwise the adoption barrier would just be too high. I mean, you could argue (as I did) that the benefits of adopting OSGi services are so significant as to justify a rewrite, but the more I think about it, the less likely it seems to me that enterprises are in a position to do so.
Given this, it seems like we'll need a good sample application to illustrate how it's done, especially how it should be done, and how using an OSGi framework is different from using a Java EE container, or subset thereof. And it's probably even more important to describe how best to do it than it is to simply show the example.
Something that enterprise developers would also probably find helpful is the bundle repository, something along the lines of Oscar or the Spring dm Seerver's bundle repository. And BTW in general the SpringSource guys have done a lot of work to address the issues enterprise Java developers encounter when using OSGi.
An effort also was made to standardize the bundle repository capabilty, and the OSGi Alliance continues to discuss the possibility of hosting one (Peter Kriens and Frank Mittag are pushing for it) but work on the design doc was suspended a couple of years ago, more or less for lack of interest (this is how we do things at the OSGi Alliance, we rely on someone taking sufficient interest to put in some time and effort on something ;-).
Having a bundle repository available though would not only allow developers to search for needed bundles, but also provide support for provisioning bundles and automating several other deployment related capabilities. So we decided to try to pick this work back up and try to get something done for the next release.
One last comment relates to tooling. It isn't really in the EEG scope, but Peter Kriens said he would try to organize a joint meeting with some folks from the Eclipse Foundation, perhaps during EclipseCon (which is co-located with OSGi Dev Con) to talk about it. Bits and pieces of tooling for OSGi exists, but nothing comprehensive yet for enterprise developers. This would also help, of course.
And just to wrap up - everyone got out of Boston just in time. The morning after the meeting ended we had -13F (-25C) on the outdoor thermometer in our kitchen. And the same the next morning. And then over the weekend, several inches of snow. But I conveniently left the grill out on the deck, just to remind myself that someday, yes, once again we will be out there using it to cook something tasty, and warm. See you next time.
