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.
2 Responses to “OSGi Discontent - Part 2”
Leave a Reply
Kirk,
In your comment on my blog you said you think we are more in agreement than it might appear.
I think that is generally the case, but it is very frustrating to have things taken out of context. No one is claiming that OSGi is ready for widespread enterprise adoption. You are therefore effectively gainsaying something no one is saying.
We are working on the enterprise edition of OSGi because people have already been using it for enterprise applications. Some of these folks approached the OSGi Alliance about the possibility of developing an enterprise edition to provide additional support in the Framework for enterprise applications. This is not something that someone just sort of decided would be a cool thing to do - it started at the grass roots.
We are doing out best to respond to this interest and address the requirements. But as you know OSGi was never intended for use in the enterprise, and so it is missing a lot of things that software designed for the enterprise would have. It’s a bit like criticising Word for not making it easy to create bullet point slides.
We have been publicizing our work to engage the community and get feedback. The enterprise release isn’t even out yet - the first part is due in June/July and the second part at the end of 2009.
I think you have an exceptional understanding of OSGi from a technical point of view. It would be really helpful if you would characterize your comments within the overall context in which we’re working, and according to where we are in the adoption cycle.
Thanks,
Eric
ps I just wanted to clarify what we *are* saying. We can agree that OSGi is not ready for enterprise adoption as a mainstream technology. But OSGi has been proven to *work* in enterprise deployments, unlike some other proposed enterprise standards (which have yet to be proven to work on that scale). It is just not easy enough yet…