Tuesday, April 8, 2008

OSGi is Irrelevant

There has been a lot of talk about OSGi in the last 18 months with many vendors and open source projects adopting OSGi at various levels. For many, OSGi is a new technology that is sometimes difficult to grasp since its applicability is not always obvious.

OSGi stands for Open Services Gateway Initiative and was born out of efforts from the embedded Java world some 8-9 years ago. In a nutshell OSGi is a dynamic module system for Java. It provides a class-loading framework and framework for managing relationships between modules, known as bundles.
The driving force for OSGi is to provide a secure, pluggable system so that bundles can be hot deployed to the OSGi container. The container provides good isolation between bundles so that no bundle can interfere with another bundle unless that bundle explicitly exposes its services to the others. This means you can avoid all the class-loading tomfoolery we have with JEE where you deploy your application and then get cryptic non-standard, messages about conflicting versions of Log4J on your
classpath.

This isolation also means you can have different versions of the same bundle available in the container. That might sound like a bad thing, but in a well-defined environment such as the OSGi container it’s a very good thing. Imagine you have an SOA with a few services running. At some point the API for a public service changes. You have loads of clients out there relying on this service. Rather than just redeploy the new service and have al your clients hammering your support because the service no longer works, you can deploy the new service and keep the old one. Over time you can retire the old service once your clients have switched. The point is that you have a much cleaner migration and your clients and support team will appreciate it.

Recently, I did an OSGi 'fireside' talk with Rod Johnson at TSSJS Las Vegas this year. I thought it was bizarre that we had a room full of people who wanted to know more about OSGi, since it’s something that should really be invisibly to most users in the same way Java class-loading is (or at least should be). We analogized OSGi to anti-lock breaks on a car. Breaks are generally a good thing in a car and we all need them. Anti-lock breaks are very cleaver and provide a lot of value to our driving experience. However, they are not very interesting on their own and they are something we just expect to be there at our disposal when driving.

OSGi isn’t interesting on its own. It’s what OSGi enables that becomes interesting to consumers. Hot deployment of bundles, relationship management between bundles and bundle versioning is much more interesting once made available within the framework/platform that you build your applications such as the application server, Mule, Spring or even the JDK (i.e. JSR-277).

The point is by next year I doubt there with be any more fireside chats about OSGi since nobody will care. Instead I hope we will be talking about designing and enabling well-designed applications to take advantage of OSGi.

11 comments:

AlBlue said...

JSR277 doesn't support hot deployment and unloading of modules. It also tightly binds the concept of modules to compile-time rather than run-time, which makes it impossible to swap out a module for a different implementation (mock, logging etc.)

I think people will be interested in using Spring Dynamic Modules which will enable them to code to an environment that they know about but will handle the dynamics under the covers automatically. I dare say in time Spring will also be able to sit on top of JSR277, albeit with more limited functionality.

Ross Mason said...

I haven't looked much at JSR277, but I am very surprised to see it's not based on OSGi since that is a standard that has already been baked out. This is quite typical of of the JSR process. I can feel a rant coming on...

Neil Bartlett said...

I had an uh-oh moment when I read this title, but I sort of see what you're saying: in a few years OSGi will be ubiquitous and taken for granted, to the extent that nobody talks about it much.

I agree. The same could be said for oxygen though, and it would be going a little far to say that oxygen is "irrelevant" ;-)

Ross Mason said...

yes, but we don't have to educate people about oxygen further than letting them know of it's existence and that we'd be buggered without it.
I do think OSGi should and will be ubiquitous within a few years, but the real value of it (as with oxygen) is what it enables us to do.

Right I'm off to go and write my own module container and I'm calling it oxygen!

Peter said...

I'd love to see OSGi become part of the fabric and as ubiquitous as you predict! However, just like plumbing, you better maintain or otherwise one day you're deep in the ...

And there is one issue that I think where you underestimate the complexity and state of the art. OSGi is not only a module system, it is also a component system. The reason I do my work is that I want to build software with large components. Though the OSGi is in my (humble) opinion by far the best foundation for this, we need to do lots more work to get to the stage where you can reliably build large systems of dynamic components. This will not happen on its own, it will require active participation of companies that will gain the most of having a first class component infra structure and market. You can leave this up to other companies, but then do not complain one day that someone charges you for the oxygen you use (or CO2 you exhale).

Kind regards,

Peter Kriens

Yuen-Chi Lian said...

Like Neil, I had a short moment of "uh-oh" when I read the title.

I had a chat with Edward during a supper after FOSS meeting 2 weeks ago, on OSGI. Edward is one of the committers of Pax Logging and it's so interesting to learn a clearer concept about OSGi from him.

I haven't yet gotten my hand dirty to write something out from it (not even a demo) though.

- yc

Ross Mason said...

Peter, I do agree with you that like plumbing a broad understanding would be needed to maintain OSGi-enabled applcations, but this isn't much different from the knowledge developers require of the JRE classloading mechanism. But I also think that much of the complexity of OSGi (and it is complex to use) can be hidden neatly and correctly by frameworks and maybe the JDK one day.

sboulay said...

does anyone know if OSGI would be relevant in a .NET environment? Do they already do something like this with assemblies?

Brad said...

I realize this is an older blog entry but it appears that your take on it here really was trending to "uh-oh". There don't appear to be any anti-lock breaks in the latest Mule.

Brad said...

I realize this is an older blog entry but it appears that your take on it here really was trending to "uh-oh". There don't appear to be any anti-lock breaks in the latest Mule.

Ross Mason said...

Hi Brad,
I didn't understand your comment about anti-lock breaks, can you explain what you mean by that?