Is OSGi the Untold Story?

Over the last 12 months I continue to be amazed by the investment and adoption of the OSGi standard in the enterprise software world. For instance, IBM hosting Websphere on OSGI, BEA announcing their msa strategy is using OSGi, Spring support for OSGi, JoNas support, and a slew of Apahce projects (Directory, Cocoon, James, Tuscany, Geronimo) using OSGi and of course essentially anyone using Eclipse via Equinox is using OSGi.

These are some major corporate and open source adopters. However, if you then look at what is getting reported in the media and blogsphere there seems to be very little written. Of course there are exceptions, EclipseZone just did a great series on OSGi. InfoQ gives it decent coverage. The question becomes why is there so little written on OSGi and should we care?

OSGi is well on the way to becoming the first component model that spans embedded, desktop and server applications. OSGi started in the embedded industry and continues to have strong adoption in this space. As previously mentioned, OSGi is now breaking out on the server, so we might now actually have one software component model that finally allows for the convergence of embedded and enterprise IT software development.

Things are changing in terms of OSGi coverage. The guys at Interface 21 are doing a great job talking about their support for OSGi. I also think next week at EclipseCon there will be lots of OSGi news. For instance, Parmeus is talking about their vision of SOA/OSGi and Eclipse. The OSGi Developer Conference is co-located with EclipseCon, so it is a great opportunity to highlight the synergies between Eclipse and OSGi.

7 Responses to Is OSGi the Untold Story?

  1. Neil Bartlett says:

    Ian,

    Regarding the EclipseZone OSGi series: present tense please, not past. There’s more to come!

    I think part of the reason that OSGi is still somewhat under the radar is that it’s mostly been used so far for infrastructure. Sure, most of the app servers are starting to use it, and Lotus Notes will be using it soon, and various Apache projects like their LDAP server, mail server, etc. But it still hasn’t really caught on with the application developers — people who build commercial applications for J2SE and J2EE platforms. That’s the biggest population of Java developers. However I think two things are going to start to bring those guys on board as well.

    The first will be their realization that the infrastructure products they build on are all moving to OSGi, so there must be something good about it.

    Second will be the influence of Spring with their OSGi support, which will make wiring up interdependent services really easy. Almost everybody I talk to in industry either uses Spring, or has used it, or wants to use it, so it’s hugely influential.

    Anyway, like you I’m looking forward to next week’s news.

    Neil

  2. Erkki Lindpere says:

    Personally, I think OSGi is the god damn philosopher’s stone, but I haven’t managed to convince others that it’s valid for web applications yet. I’m also hoping that ties with Spring will have a positive influence on OSGi adoption.

  3. Alex Blewitt says:

    Just one correction — Geronimo shouldn’t be in that list, as I’m sure Glyn would be happy to also point out if he came across this entry.

  4. […] fit so many people but I will try to post the slides. The plan is to talk about the importance of OSGi and Equinox, plus the above […]

  5. GB says:

    OSGi and SCA seem similar from an initial glance. And, interestingly IBM seems to be supporting both. Is anyone knowledgeable enough of both component models to provide a comparison?

  6. Neil says:

    Hi GB,

    OSGi and SCA have superficially similar goals, but they operate at different levels. OSGi is a lower-level specification that defines how services can bind to each other dynamically at runtime, within the scope of a single JVM.

    SCA aims at a higher-level component wiring model, connecting up components both within the JVM and across network boundaries according to a hierarchy of XML descriptors. It is cross-language, so you could (in theory) construct a system that is a mix of plain-old Java, EJB, .NET, C++, PHP and BPEL.

    Various people are looking at building a “binding” for OSGi to SCA, allowing you for example to implement SCA components using OSGi. In fact the newly-formed OSGi Enterprise Expert Group (EEG) are looking at doing exactly that, amonst other things.

    Finally, Paremus have a product that combines OSGi, SCA and Jini. There is an open-source version called Newton, available from http://newton.codecauldron.org/.

    Now having said all that, I believe that SCA is the wrong model. It has the distinct whiff of WS-Splat (or WS-DeathStar) to it, and I hate the idea of polluting the beatifully clean and small OSGi APIs with a huge pile of XML “assemblies”, WSDL files, Web Services bindings, etc. I really don’t see SCA catching on as a practical solution for anything.

    IBM supporting both doesn’t really mean much… IBM is not a single company, it is a loose federation of competing factions.

    I hope this helps,
    Neil

%d bloggers like this: