There might be a downturn in the construction industry in these parts right now, but there is one company of plumbers that is still working flat out. SpringSource, the company behind the Spring Framework, has always plumbed the nastier parts of APIs and Frameworks where nobody likes to go, in order to make them more hygenic to use. They are still doing this and more besides, and two of their number came to IT@Cork’s 3rd annual Java Conference to keep us up to date with their activities. Ben Hale and Jonas Partner from SpringSource gave interesting presentations on OSGi and Spring Integration respectively. I’ll try to give a summary of Ben’s presentation in this post. I’ll catch up with Jonas and the other speakers in later posts.
Before I get into the details, let me just say that I found the full-day format for the conference to be far preferable to the half-day format of previous years. The extended time allowed for more local speakers, and for a greater variety of speakers and topics in general. The fact that I can’t do justice to the event in one post is an indication of how packed it was with interesting presentations.
The first time I heard about OSGi it was from Rob Harrop 3 years ago when he came to Cork the first time to give a Spring course to DSI staff. I didn’t get it then (admittedly I was driving when he was talking about it, and I don’t do multi-tasking very well), but in the meantime every Spring event I’ve attended has been coloured with lots of OSGi content. If you throw enough mud against the wall, some of it is bound to stick (worringly enough, this was the motto of one of my teachers a long time ago!!) and the OSGi message is beginning to, well, stick.
If you use Eclipse, you use OSGi. The core that manages Eclipse’s plugins is an OSGi implemention called Equinox. Understanding its role helps you to understand what OSGi does. Eclipse plugins are bundles of functionality or services that can be updated, swapped, suspended and extended. In fact OSGi uses the word bundle in the way that the software industry has used the word component. OSGi is a service component framework or, as Ben Hale described it, a Dynamic Module System. That Springsource has become so committed to OSGi is interesting in itself, as it points not only what directions technologies might be taking, but also what’s currently happening to OSS business models.
The OSGi architecture provides for partitioning between, and visibility across, component boundaries, enforcing good software design practices as a consequence. It manages runtime dependency resolution and very importantly this includes the management of different versions of the same component within one application. The implementation is a simple one: Instead of letting the bootstrap class loader take responsibility for all classes in a running system, Equinox establishes a hierarchy of custom classloaders, using one (perhaps more?) for each component or bundle. This gives OSGi the control over partitioning and visibility mentioned above, as well as enabling the ‘dynamicity’ (which I’m assured is now a real word) of the architecture. The heart of the system is the Service Registry, which acts as an intermediary between cooperating components as well as a central point of operation control, permitting administrators to update, suspend and swap components at runtime.
OSGi offers the prospect of an enterprise application whose various services can be configured dynamically without bringing down the overall system. But it comes at the price of conforming to a new programming model. While the OSGi infrastructure may allow services to slip in and out of, erm, service, code that depends on that service needs to be able to cope with its occasional absence – not something we normally program for. Add to that the requirement to package your code in a way that an OSGi Service will recognise (admittedly lightweight) and you begin to see the investment required to use it.
That’s where the Spring plumbers come in. As Ben pointed out, OSGi is specified at a pretty low-level. Spring is perfectly positioned to intervene. Literally. The Spring pattern has always been to intercept API calls, or offer proxies, in such a way as to protect the hapless developer from the painful and repetitive code that some of these APIs inflict. In their approach to OSGi, they use the same technique. One obvious interception is when a service is called. With Spring’s abstraction of OSGi you can call your service as normal, and declaratively specify what you want to happen if that service turns out to be suspended. This does a great job of taming OSGi for the programmer and is a great fit with standard Spring techniques.
But SpringSource has done much more than just wrap OSGi in Spring goodness. There’s a much bigger picture – more on that in a moment. First, I want to point out why I will be cautious about using OSGi on an enterprise system just yet.
So far, its use is not very widespread, the most famous example of OSGi being the Eclipse platform, as mentioned above. The problem with the example of Eclipse as an OSGi system is twofold: Firstly, Eclipse was a plugin architecture looking for an implementation. It didn’t have to change its programming model to use OSGi – it was already a perfect fit. This cannot be said of the vast majority of software development projects. Secondly, Eclipse components are desktop, mostly-UI components rather than the kind of serverside service components which the Spring Application Platform is aiming at. Having spent many years trying to build both desktop and server-side components, I can tell you that these are not equivalent activities.
Spring Application Platform
Let’s just stand back and look what SpringSource have been up to over the last 18 months or so: The’ve ploughed their VC funds into developing the OSGI-based Spring Application Platform. They’ve made all the Spring Framework code OSGi-friendly, and actually gone to the trouble of packaging hundreds of other providers’ API into OSGi bundles. In short, SpringSource is putting every last one of their eggs into the OSGi basket. What makes this a viable proposal for them? Where is the return? The Spring Application Platform is not opensource. Nor is the Eclipse-based Spring Tools Suite that facilitates development for this platform. Having spent so long offering POJO solutions that were compatible with the standard platforms, they’ve finally come out with a platform of their own. And it’ll cost you. Either I’m missing something, or the Spring Application Platform is a non-standard alternative to the Weblogics and JBosses of this world. They remain true to what you might call the Principle of the Paramount POJO (no – let’s face it – you mightn’t call it that at all) but this move is a real shift in the industry and a very bold move by Rod Johnson et al.