03.23.10
Do we really need OSGi?
With the coming of Spring (framework, season, take your choice), but more to the point, concurrent announcements of the OSGi Enterprise Edition 4.2 and the Eclipse Gemini and Virgo projects, debate over OSGi has renewed. OSGi has seen great success where it is not seen – as the framework for dispensing Eclipse plug-ins, and as the invisible engine by which most of the household name Java EE servers are now factored.
We’ve always been pretty bullish on what OSGi could do. It allows your server footprint to be truly dynamic – you can deploy and kill runtime components at will without taking the whole mess offline. There’s a potential sustainability appeal to any technology that helps reduce footprint – as less apps mean less server, less power, and less space.
Interestingly, OSGi could provide a lot of the elasticity at the appserver level that virtualization promises for OS images and cloud promises for application deployment. And there’s the rub – OSGi is hardly the only path to keeping your webfarm footprint contained. Significantly, while the goal is the same for each strategy – you only want as much resource as you need – they all take different ways of getting there. OSGi is a developer decision that addresses which application or middleware modules (or functionality) do you actually want running at any time, while virtualization and cloud are largely IT operations decisions pinpointing images and choice of what and how much infrastructure to provision.
Although the goal is common, the choice of strategy differs based on where elasticity is needed; furthermore, these are not all or nothing decisions. Conceivably, if you have a highly variable application that requires, not only different amounts of processing capacity, but different functionality at different times, then OSGi could complement your virtualization and/or cloud strategies. Let’s say you process market feeds, the composition and mix of which changes by time of day and which trading centers are active around the globe. Or your organization is number crunching end of period reports. Those are a couple possibilities.
The problem is in knowledge and awareness. For most IT customers, OSGi is a black box. It’s the way that WebSphere and WebLogic are architected. But that makes a difference to the vendors, not the customers because they don’t know how to provision OSGi bundles and there are no best practices for bundling bundles into bigger pieces that can be identified as tangible modules. There is still a lot of OSGi misinformation and still a lot of debate out there. Of course, while virtualization and cloud are much better known, there’s plenty of hype and debate about cloud, and concerns about unchecked use of virtualization.
So a couple years after OSGi gained critical mass vendor acceptance, there remains a lack of tooling for configuring OSGi servers, not to mention best practices for deploying them. SpringSource, one of the first to develop an OSGi server, has now donated the technology to Eclipse as reference implementation in Gemini, with Virgo becoming the technology development project. SpringSource’s commercial direction is tc Server, which commercializes the tiny Tomcat servlet container; as of March 8, VMware is pushing tc Server through its channels and for the next couple months, is giving away two production CPU licenses and 60 days evaluation support to VMware customers.
SpringSource’s fork in the road symbolizes the existential dilemma facing OSGi: if your goal is to simply reduce your web container footprint, 10-MByte Tomcat containers should do just fine. It scales out quite nicely as well, with LinkedIn serving 40 million web pages daily on Tomcat. So again, we ask, why do we need OSGi?
Give us your answers.