Wednesday, March 25, 2009

Good information, bad conclusion

Kirk has written an interesting blog post about OSGi for the Enterprise. He may have done a good job at finding a controversial point to pursue, but unfortunately does not get it right. It is true there is currently no migration path, and tooling is an issue, but neither is to the point of enterprise adoption.

I'm currently sitting in the OSGi tools BOF at EclipseCon, and I can strongly validate the lack of tooling as a big issue. Kirk is pretty much on the money with his technical analysis, but the conclusion he draws is incorrect. This is a common trap people fall into when comparing a new, disruptive technology against an established, mature technology.

I remember clearly in the late '90s when most people in the TP monitor community said that Java application servers would never be used in the enterprise. Before that the conventional wisdom in the database world was that relational database would never be fast enough for update intensive applications.

The question is not how OSGi compares to Java EE application servers, but how it meets enterprise application requirements in its own right. If you compare a new, disruptive technology directly to a mature, established technology you cannot possibly reach the right conclusion. This phenomenon well documented in the "Innovator's Dilemma" for example. It is not the technology that's important but the requirements it's designed to address.

The enterprise is not a monolithic environment. One size does not fit all and many application requirements are better met by OSGi than Java EE, and many applications are less demanding than others. Kirk does a good job understanding and presenting OSGi technology and its benefits, but he does not ask the right questions about how well its features and functions match application requirements. The fact that something exists in the enterprise does not necessarily or predictably indicate what is needed next.

The issue is not whether OSGi can replace Java EE application servers but whether enterprise applications, and which ones, can benefit from using OSGi. Furthermore the enterprise development process is often a long term effort, and although features may be missing today for using OSGi in some applications, many of these things will be solved soon.

The people in this room complaining strongly about the lack of tooling are equally passionate about the benefits of OSGi, and are intent on using it to solve problems that application servers can't, and won't. They would not be here if they thought it wasn't ready.


  1. Eric,

    I'm not suggesting OSGi should replace Java EE. I am suggesting that given today's infrastructure and operating environments within most organizations, it's unrealistic to build applications that leverage OSGi. I wish it were different, and I'm excited for the day it is different.

    I look forward to the day that I can go to a client and recommend they leverage OSGi. I cannot do that today.

  2. Kirk,

    When I talked with you a few months ago I got the impression that the your significant expertise and experience was in the Java EE world. I don't remember you mentioning any other area of significant expertise and experience, so I am assuming you are viewing OSGi through that lens. I apologize if I have the wrong impression.

    I agree with you. I wouldn't want you recommending OSGi to your customers, either, since I doubt they are the type of early adopter currently using OSGi for enterprise applications.

    The point I am trying to make is that the situation is not black and white. The problems you point out are very real, and there are definitely barriers to adoption.

    But this does not invalidate the value proposition of using OSGi for enterprise applications, and it does not deter early adopters from seeking ways to exploit that value, for example ahead of the competition.

    I hope you understand the technology adoption curve. At one time Java was an immature language and application servers based on it were similarly characterized as not ready for prime time. Yet somehow they managed to catch on, anyway.


  3. Eric,

    I've posted a follow-up blog entry at

    I'm not so sure we don't agree more than we disagree. There are barriers to adoption today that prevent widepread use. As those barriers are removed, more organizations will be able to leverage OSGi, especially the benefits of modularity that can be had when developing large enterprise applications.

  4. Kirk,

    Yes, I think the main point is the adoption curve, and where we are on it. The fact that OSGi is in the early stages of adoption for the enterprise doesn't mean it isn't ready, just that is isn't yet ready for everyone and everything. It is ready enough for the early adopters willing and able to invest and overcome the barriers - and while these folks may be taking a risk, they also stand to reap the rewards of being among the first to exploit the benefits of OSGi.