OSGi tutorial at ApacheCon Dublin
June 28, 2006
ApacheCon Europe 2006 is being held in Dublin this week. I couldn’t attend the whole week, but I did get to go to a half-day OSGi tutorial given by longtime OSGi evangelist Peter Kriens. Peter, who is the current editor of the OSGi specification, says:
“OSGi is kind of SOA”
“OSGi is kind of a Java Operating System” or at least a “mini-kernel”
OSGi is “the Dynamic Modularity Layer for Java”
OSGi is a Java framework for developing remotely deployed service applications. OSGi started life in 1998 with the original use case of home automation. OSGi applications can run on different software and hardware architectures. There is a lot of buzz around it right now, particularily in the enterprise space, partially because of Eclipse Equinox, which is OSGi R4 based and the technology underlying Eclipse bundles (actually Equinox goes beyond pure OSGi). But there are a bunch of other implementations, including the Apache Felix project. The specification is freely available and royalty free.
OSGi applications adhere to a basic SOA, the contract between client and service is based on a Java interface and discovering and binding available implementations is done through the framework. Client and service are softly coupled. So it provides an in-VM service model. Declarative services, introduced in R4, are akin to having dependency injected components. Applications declare their service dependencies in an XML file, and are notified by the framework at runtime as services becomes available and go away. The last is an important point: services can go away at runtime, just as they can be dynamically discovered. The next major release of Spring is adding support for OSGi. One of the tutorial attendees made the point that OSGi is a generic event notification framework.
OSGi applications are packaged as bundles, handled by the OSGi Module Layer. The Module Layer addresses packaging, class loading modularization, protection and versioning (multiple versions of the same package) – things Java does not do well, or at all, by itself. In addition, OSGi provides basic Life Cycle Management. An API for managing bundles allows them to be installed, resolve their dependencies, started, stopped, refreshed, updated and uninstalled. So basically, bundles register one or more services with the framework service directory, and other bundles can use those services. Service contracts are just Java interfaces, so service implementations are just POJOs and no special classes need be extended nor interfaces implemented.
Its a pity OSGi wasn’t somehow used as the basis of JBI, there are so many similarities.
Its also a pity that there are currently two rival JSRs attempting to establish a dynamic modularity layer for Java SE. JSR-291 is the OSGi Alliance backed one that aims to “define a dynamic component framework including component lifecycle for existing Java SE platforms”. Peter is on the expert group. JSR-277 aims to do more or less the same thing, expect not as well according to Peter – who is is not on the expert group despite his best efforts! Richard Hall was at the tutorial, he is on both groups. According to Richard he is trying to steer the 277 folks in the right direction. It will be interesting to see what happens. Richard was giving a couple of OSGi related talks in Dublin, I wish I had been able to attend them.
And I think the Eclipse Rich Server Platform proposal deserves some serious attention. There is so much happening in the module/component/service packaging, assembling and deployment space (the McSPAD space) (ok, I guess thats several kind of overlapping spaces). We’ve got JBI, SCA (though don’t hold your breath) and now (yes it has been around for quite some time) OSGi. What we really need to do is get everyone in an aircraft hanger (big enough?), seal the doors and tell them they are not getting out until there is only one. One McSPAD to rule them all.