Lies, Damn Lies and OSGi

OSGi, the little Java framework that could, seemed to hit critical mass last year as it achieved active or tacit support across virtually every Java platform provider. To recap, OSGi is a dynamic component framework first developed for set top boxes in the waning days of the original dot com bubble, which subsequently gained new life after the Eclipse Foundation embraced it as its new component model. It grew popular because the framework allows middle tier platforms to not only modularize their stack, but dynamically reduce their footprint to the minimum number of components necessary to run the server at any given time.

In other words, with OSGi, you could run a pretty thin Java, or for that matter, PHP or Ruby server.

In our Ovum research last year, we concluded that OSGi was becoming the de facto standard for next generation Java servers.

Not so fast. It appears that a backlash has emerged. While IBM and SpringSource have fully embraced OSGi and refactored their server platforms, others have been grudging or slow. JBoss, which already had its own microkernel, has reluctantly added OSGi as a deployment option; Sun meanwhile has spoken out of both sides of its mouth, supporting OSGi for Glassfish but opposing JSR 291, which made OSGi as JCP specification, while backing rival efforts in the form of JSR 294 and Project Jigsaw, which rethinks modularizing Java.

We’d be tempted to state that all this talk about re-modularization is occurring after the horses left the barn. But a year later, the controversy refuses to fade. Eric Newcomer of Progress, who also co-chairs the OSGi Enterprise Expert Group, acknowledged that the Project Jigsaw demo looked “interesting,” he not surprisingly added that the effort behind the demo was “pretty scary when you think how far away that is from what’s already available in the OSGi Framework.” Fellow OSGi evangelist Chris Aniszczyk blogged a conversation with Newcomer based on Darryl Taft’s recent eWeek interview with Java creator James Gosling, where Gosling dissed OSGi as overkill and too fat.

It’s all quite entertaining. But our sense is that while, a year ago, the Java world seemed to be coalescing around OSGi, progress has stalled because vendors have gotten too far ahead of the market. Later on this year we’re going to take a renewed look at OSGi as part of our Ovum research.

For now, OSGi is essentially a chicken-and-egg dilemma. Having a server based on OSGi technology provides little benefit to the customer unless they change the way they deploy server images. OSGi’s ultimate benefit is that you could significantly reduce the footprint of middle tier servers to only what’s needed, which has clear cost and green/sustainability advantages. For customers upgrading to OSGi (or whatever microkernel)-compliant servers is only the first step. To get anything out of it (aside from a version upgrade), they must then get educated on how to get, literally, the least out of them. As a result, OSGi still seems pretty abstract to most customers, and therefore, there’s been little market clamor.

So, while IBM and SpringSource have already made the transition, tacit supporters like Oracle have not yet made any definitive moves to embrace OSGi in its BEA product roadmap beyond the OSGI-compliant event processing server that it inherited through the acquisition. And with pending acquisition of Sun, Oracle’s OSGi strategy remains a blank slate. This one ain’t over till it’s over.