OSGi – The placebo that will rejuvenate this industry (just ask your vendor) May 19, 2008Posted by Sacha in JBoss.
In the last few weeks, the amount of noise around OSGi was embarrassing. It seems the IT world discovered it was indeed possible to have non-monolithic architectures. These days, it is enough to say that your runtime is “OSGi-compatible” or “based on OSGi” to look like David Lynch’s new egeria.
Don’t get me wrong, I do like OSGi, it is a pretty decent spec. No, what’s interesting is how most middleware vendors only seem to care about micro-kernel-based architecture since 2007-2008 – while OSGi has been around for ages. When a vendor tells you “we are now OSGi-based”, it is actually very similar to the good old “our new software release is 200% faster than the previous one!”: 101 of anti-marketing. What users actually hear is “our previous architecture was horribly bad” and “it was also slow as a dog”.
JBoss AS has been based on a micro-kernel architecture since its 2.x series – around 2000 – (thanks to the work done by Rickard around JMX, RMI dynamic proxies, etc.) and then further extended in the 3.x series with the hot-deployable services concept (SAR files, thanks to Scott and Marc).
In the last two years, Adrian Brock and his team have been working on the next.gen JBoss Microcontainer based on our past experience with JBoss AS 3.x micro-kernel. I’ll soon write a more complete blog entry on JBoss MC features of. Without digging too much in JBoss MC’s architecture, I can tell you it was clearly not conceivable to base our microcontainer on OSGi directly: OSGi doesn’t define many of the concepts we required (services lifecycle and extended dependency management, deployment customization, metadata management, etc.). We wanted to make sure OEMs&ISVs could deeply customize JBoss Middleware through JBoss Microcontainer: from embedding it in another runtime, to hook or replace the meatadata, classloading, bytecode, lifecycle, etc. subsystems.
Then, does it mean OSGi is a bad spec? No, not at all. First, it is an open specification, which is a good start. Then it provides a standard way to extend a given runtime while controlling what gets imported/exported. That’s quite an achievement considering the erratic situation we have gone through in the last 10 years with such an underspecified classloading mechanism in EE. OSGi is a good way to define how to cleanly plug third-party/user-provided extensions to a runtime, but it is certainly not complete enough to provide what’s needed by a fully customizable application server. It is about writing an AS vs. using an AS.
Furthermore, specifications come and go, requirements stay. That’s why JBoss Microcontainer features what we call “Personalities”. A Personality is a specific view of our POJO-based Microcontainer (its services, its dependencies, its metadata, etc.). JBoss Microcontainer currently features two personalities: OSGi (almost finished) and JMX (done). It also provides a Spring-deployer that reads OSGi Spring’s DI descriptors and map them to JBoss Microcontainer constructs. Trivial to implement. That’s where we are going: runtimes à la carte. Everybody in middleware has its own religion these days, fair enough. We are providing the common infrastructure that will bridge those needs. Whatever is the programming model or DI you favor, your applications will always rely on the same set of enterprise aspects: security, transaction, messaging, etc. We care about offering the most stable and performing enterprise services/aspects. We will then provide you with bridges to whatever programming model/API you like, that’s the easy part.
So, next time somebody tells your their runtime is OSGi-based or that “their framework is available as an OSGi-bundle”, ask yourself “what does it really do for me?”. If the answer isn’t obvious, you’ve probably just stepped into BS.