OSGI Case Studies == Pain
Every time I see someone give both sides of their OSGi tale, it reminds me a lot of my EJB 1.x experiences, and I remind myself to stay away unless I absolutely have to.
At QCon (2007?), I saw a presentation on Spring Dynamic Modules. They pointed out some of the issues you might have with OSGi and how Spring DM might help. Mostly, it made me want to avoid OSGi.
I've just quickly skimmed Atlassian's presentation on how they've used OSGi for their plugin architecture, and while I'm sure it has provided them with benefits, and it may be worth it for their needs, my key takeaway is still, "stay away from OSGi unless you have no other choice."
Basically, just looks like it's going to come with a fair amount of pain, so you'd best know in advance that you absolutely need the benefits to offset the cost.
5 comments:
Hi... I replied in much the same vein on Twitter, but I may as well repeat myself here since a comment allows me more than 140 characters.
As an enthusiast of OSGi I find this new case study from Atlassian, and also some of SpringSource's marketing efforts, to overstate the pain involved with OSGi.
In SpringSource's case, it's clear why: they have products built on top of OSGi which they would like to sell you, and they have to do that by saying something like "OSGi is great but you also need to do this, this and this and that's too hard without our stuff". Take this with a pinch of salt. SpringSource's platform and tools are good, but plenty of people are being productive in OSGi without them.
Atlassian's approach seems to be to over-complexify the problem. They dismiss many standard approaches and tools for the thinnest of reasons (e.g. "DS doesn't do constructor injection") and instead appear to adopt their own parallel module system called "Atlassian Plugins", along with a corresponding build and runtime system!
So, some people want to make your life complex in order to sell you stuff. Other people want to make their own lives complex. This happens with everything but don't mistake it as having anything to do with the underlying tech.
I've hopefully clarified a few things on my blog.
For me, it's a matter of uploading a slim WAR file instead of the current typical 30MB-50MB monster that takes an eternity to upload. OSGi is definitely in my TODO list.
I wrote a response that turned into a blog http://www.osgi.org/blog/ ...
Peter Kriens
Peter's comments about legacy code and OSGi are spot on. Much of the pain with OSGi stems from integrating OSGi with code that was never designed to run in an OSGi environment.
Much of what we have done with dm Server is to reduce the pain of that integration. Some of this work is now starting to see light in the OSGi specifications, such as the ongoing work to standardise what it means to be a WAR file running in OSGi.
The other area of pain that our customers encounter with OSGi is simply to do with handling new container dependencies. For us at least, this is handled using standard dependency injection mechanisms powered by Spring Dynamic Modules.
With Spring DM approach being standardised now under the Blueprint Service banner and the pre-existing Declarative Services service, there are plenty of options for simplifying OSGi programming.
I'll also say that Neil's assertion that we are saying OSGi is difficult only to sell stuff is a bit backwards. We created our OSGi products to address the needs of our customers. We are not in the business of inventing problems, there are plenty of real problems to solve :)
Rob Harrop
SpringSource dm Server Team
Post a Comment