In the last few weeks I have heard the term OSGi come up more and more, and one blog posting I read suggested that it was the hot topic of 2008. So I started to research a little. I am currently working heavily with the Eclipse Rich Client Platform building applications which use services deployed to IBM WebSphere. Both these platforms are built up on OSGi (the standard) and both use Eclipse Equinox (an implementation of the standard). So it must be important right?
Well you don’t have to read too much before you start to get the feeling that you have been there and done that before. One aim of OSGi is to provide a micro kernel for deploying and managing services. Well, from a high level, JMX (MBeans) already does that. Not enough? Well there used to be a project called Apache Avalon Phoenix, which was a mirco kernal and although that project died and was resurrected as Loom from Codehaus (which incidentally has a very interesting history of Apache and Phoenix), it is still the basis of some big projects like the Apache James mail server.
Other micro kernals? How about JBoss? There is a good blog article dicussing how JBoss has been based on a micro kernel for some time now. The idea is nothing new and in fact in their case, OSGi does not really go far enough that they could be solely based on it.
Actually, doesn’t the Java EE EJB specification let you deploy “services”? It even helps with transactions, security, robustness and scalability of your services.
So I start to get the feeling that as someone who spends a lot of time creating services, that OSGi might not really help me directly. Furthermore, I think about how I use Java. I know what it does, I know its API, but how it does it is of little concern. Ocassionally I will debug into a Java library, but not very often. In this same manner, do I really care about OSGi, or is it simply something that an application server or client framework will use as a means to an end, namely making services available, manageable and discoverable?
I then read on The Register that Sun has JSR 277 and OSGi doesn’t like it because its competition. Well, I’m sure Phoenix didn’t like its competition. And I’m sure OSGi has killed a few other similar specifications.
Before I get too excited about OSGi, I will also think about the opening line of its mission statement “Our mission is to create a market for universal middleware.” That sounds a lot like Sun saying that the Java EE standard is great because you do not get locked into vendors. Erm… so within minutes of the Java EE specifications coming into existence, vendors all around the globe were adding value-added features to their application servers to give them market differentiation and unique selling points – things they need in order to survive normal day to day business. Just because a vendor is now OSGi compliant, does not mean their components will really deploy to other OSGi platforms does it? Not at least without a little bit of work.
A friend who works in Formula 1 recently told me a story of how his team added a little wing to their car after doing minimal wind tunnel testing to ensure it had no negative effects. The aim was not to give them an advantage. The aim was to get other teams to spend a lot of money and time in their wind tunnels trying to work out what the hell this little wing was doing on that car! Once something like OSGi has enough wind in its sails, and one big vendor starts using it, the others are almost compelled to use it in order to keep up with its competitors.
That all said, OSGi still looks useful, and I will not ignore it. I am a consultant who taylors my skills to my clients needs. If I need OSGi skills, I will aquire them. I recently had to dig a little deeper into OSGi in order to solve a problem I had deploying a web application. I found it interesting and I now understand it. But that doesn’t mean I liked it. The problem was that my web application could not load up my plugin to display the plugin help online (see my blog about it). But come on, what happened to a good old ClassNotFoundException
?! Instead I got no error at all. The thing simply didn’t work. All thanks to the framework being based on OSGi, which provides the framework with hot deployable services, which in this case is a feature not even being used… Great. But at least I now have some OSGi skills.
=========
UPDATE!
A year on and I ask myself what I now think, having used more and more OSGi on my current project. I have seen an implementation of Declarative Services which was more complex than it needed to be. And I have lost a lot of time fiddling with configuration of OSGi Modules (especially when it comes to import/export packages and version numbers). I think a fair statement right now is that the most useful feature of OSGi is that it allows you to deploy multiple versions of the same library and your application can sort out which one it loads depending upon which version it was built against. In our current application where we deploy two sub-applications to a workbench, this is quite powerful (albeit theoretical because until now the release schedules of the two applications have matched and so they were always built against the same library versions). So basically, I’m still not a great fan, although I do see it has power in certain situations. In the mean time I shall not convert all my applications to use OSGi, unless I happen to use RCP or something that is dependent upon it, in which case I will use not much more than just the versioning which it provides.