OSGi Discontent - Part 2

Posted by: Kirk Knoernschild on 2009-03-26 15:09:00.0

For the first part of the story, see my blog post titled OSGi Discontent - No Migration Path.

I’m a bit surprised by the response I’ve gotten about that post. There has been healthy discussion on Javalobby, with folks standing on each side of the debate. Eric Newcomer has posted a partial rebuttal, stating that he validates my technical analysis and concern about lack of tooling and a migration path, but that I’ve drawn an incorrect conclusion. Ian Skerrett also supports my observation with his latest tweet.

I thought I was stating something that was pretty obvious. OSGi isn’t ready for enterprise web development. Not today. The problem isn’t the OSGi specification. It’s not Equinox or Felix. The problem is the current generation of application platforms and tooling. I recognize that OSGi can be used to develop enterprise applications, but it’s cumbersome to do so. Early adopters can leverage OSGi, but they must be willing to incur the complexity and cost of doing so. Most organizations aren’t willing, nor should they be willing, to do that. That is my conclusion.

Eric does make a key point. We aren’t dealing with black and white here, but instead shades of gray. That reinforces my point. Today, organizations that want to leverage OSGi may decide it’s not feasible because of lack of tooling and platform support. As the technology and tools mature, more organizations will decide they can leverage OSGi. That’s a good thing, especially for the large and complex enterprise projects that could stand to benefit from modularity, but aren’t willing to incure the technical burden required today.

Keep in mind, I’m an ardent supporter of OSGi. I want it to succeed, and I believe it will. I’ve posted quite a few blog entries about OSGi, including a number of simple examples that illustrates it’s capabilities. The intent of my most recent post was to illuminate some deficiencies. The benefits it will bring to enterprise development, especially for large software systems, is substantial. But unfortunately, the cost to leverage OSGi today is high. High enough, in my opinion, that it’s simply not feasible for most organizations.


be the first to rate this blog


About Kirk Knoernschild

Kirk is an industry analyst at Burton Group. For 15 years, he has worked in the trenches on real software projects. He takes a keen interest in design, architecture, application development platforms, agile development, and the IT industry in general, especially as it relates to software development.

In 2002, Kirk wrote the book Java Design: Objects, UML, and Process, published by Addison-Wesley. He has also written numerous whitepapers and articles, including The Agile Developer column for The Agile Journal. Kirk is the founder of Extensible Java, a growing resource of component design pattern heuristics for Java that can easily be applied to most other platforms, including .Net. Kirk has trained thousands of software professionals, teaching courses on UML, Java J2EE technology, object-oriented development, component based development, software architecture, and software process. He enjoys hacking in a variety of languages, including Java, .Net, Ruby, and PHP.