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!