OSGi - the next big thing? (a beginner's view)

Eclipse has been using it for years, and a number of open-source and non open-source Java application servers, such as SpringSource dm server and JBoss, are now providing server-side OSGi support.

I have been hearing the term OSGi for quite some time now. I have always known it to be some kind of modularization framework in Java. It is often mentioned alongside with the other wonderful buzzword that is SOA (Service Oriented Architecture). But what is it really? I decided that I should get a full understanding straight from the horse's mouth. So I went to http://www.osgi.org/About/HowOSGi, read the articles and tried out some examples. After a couple of hours, I learnt (and saw for myself) how using OSGi:

- you can divide up your ugly monolithic application into self-contained, loosely-coupled deployment units / modules known as bundles.

- a single bundle exists as a single JAR file.

- a bundle can access functionality provided by other bundles, but each bundle inherent provides a strict level of encapsulation. The creator of a bundle decides what functionality to expose. Everything else inside the bundle is private otherwise.

- bundles can be installed, updated, uninstalled without restarting the application.

- different versions of a single bundle can be deployed concurrently.

- the current OSGi model assumes that all bundles run in the same JVM, so no distributed SOA ("Don’t distribute your objects." - Martin Fowler’s “First Rule of Distributed Object Design" :-) )

The idea of modularization of course has existed since the dawn of software engineering, and OSGi is not the first framework to provide modularization in Java. Yes, this idea of being able to hotswap/upgrade bundles during runtime sounds cool. But does an average IT manager REALLY want to be able to swap in a FTSE-lookup service for a DOW JONES-lookup service during runtime? (Oops I think I have just sparked controvery) My point is while OSGi provides an excellent framework for dynamically linking bundles, developers still has to write extra code to handle when a bundle goes offline, for example. For most projects, this kind of flexibility probably spells more trouble than it is worth. And if non-runtime-configurable dependency injection is what you are after, then just stick with simple Spring!

So I was beginning to think whether OSGi is just yet another "grand" idea.

It then suddenly dawned on me that, forgetting about all this hotswappable bundle magic, the basic idea of self-contained deployment units is the answer to the single biggest cause of Java developers' stress - jar hell. I am sure a lot of you have used or are using Maven, Ivy to manage your hundreds of jars. While they do a decent job of managing dependencies and jar versioning, the simple fact remains - without writing custom classloading code, in Java, you cannot have two versions of a same jar in the same classpath and expect one bit of your application to use the 1st version and another bit of your application (maybe you are using some third-party classes) to use the 2nd version. Now, implemented as OSGi bundles, your different "bits" of the application can be packaged with the required versions of the jars (inside their respective OSGi bundle jar) without interfering with each other. Essentially each bundle has its own classpath/classloader. Is that not great?

OK nothing in this world is free. There is obviously the overhead in having to create these bundles, which is something I have yet to try in a real project. Nonetheless, knowing that there is a chance of forever emancipation from jar hell, there is more of a reason now why I should at least consider trying out OSGi for real! Umm it may be a long road, but perhaps a road worth travelling. Well, at least I know it is possible to embed Equinox in Tomcat. That is a start...

Don't get me wrong. I am not knocking OSGi's ability to dynamically manage and link bundles. I am just saying that the more immediate benefit of adopting OSGi may lie in the fact that you can have many versions of the same jar in your project! Yes, a simple problem, but a real problem.

Any comments welcome!


Unknown said…
Other related "simple" but important benefits that we hear a lot, and that come from simply the "jar management" (i.e. bundle) part of OSGi include:
* the ability to share libraries across "applications" (made more tractable because of the versioning you mentioned)
* a more granular unit of deployment (wars getting too BIG)
* ability to run more "stuff" in a single VM because apps can share libs at runtime too

For the "dynamic" part - since you mentioned Spring, you might like to check out the Spring Dynamic Modules project (Spring DM) that aims to make this much easier.
See Wah Cheng said…
Thanks Adrian,

You are right. I totally agree that the benefits of jar management go far beyond the elimination of "jar hell".
Markus said…
So, if you do want two versions of the same "bundle" in your application, how would you specify which bundle to use? Is there some framework that lets you do something like OSGi.getClassLoaderForBundle("Frob-2.0").getClass("com.frab.Frob").newInstance(), or how does it work?
Peter Kriens said…
As so many people you confuse cause and effect :-( Hot swapping of bundles is a consequence of strong modularity. It is pretty cool to see a system that you an continue to develop (look at bndtools) without restarts, the enthusiasm with which with this was told has been confused that hot swapping is OSGi's unique selling point. It isn't. OSGi is a technique to create systems out of components in an orderly organized way. We used strong modularity to enforce the components to be truly modular (unlike all other VM based hacks). As a consequence, hot swapping becomes very easy since there are only well defined touch points between the modules. So the same cause that gives you side-by-side versioning (the solution to JAR hell) actually allows you to hot swap.

So the cool part of OSGi is organization and discipline it puts into your application.

Popular Posts