Andi Egloff's Weblog

Why is OSGi on everyone's tongue
- or why you should take the red pill

In a JBoss blog on "OSGi - The placebo that will rejuvenate this industry (just ask your vendor)" Sacha paints a picture of everyone just following the latest buzz-word and (at least in title) not much substance.

So is that really the end of the story?

Hold on, wouldn't that be a really strange story for Sun which had quite a mixed and turbulent affair with OSGi in the past? And now we (as in Sun) are barrelling ahead with native OSGi support in GlassFish v3 as well as Open ESB with Project Fuji... Doesn't seem to make sense that they'd just change their minds for a cheap thrill of name dropping...

I'll admit it now. before digging into it I was very skeptical of OSGi; not that I didn't like the premise of abolishing classpath hell, but oftentimes enterprise quality features come at a large cost of complexity. Also the worry was if the "API" based services of OSGi would mesh well with the message-based, mediated services architecture we require for our SOA / integration platform with lofty goals and a lot to live up to. Project Fuji is all about looking at every aspect of our platform and making it more approachable and flexible, so if a technology doesn't add enough there is no way I'm going to add it.

Now, I'm completely sold. It turns out the OSGi spec does its core job very well and in a very stable fashion; plus it actually is surprisingly straight forward for our platform to take advantage of without being overly intrusive. In fact to start with it only required one minor enhancement (adding some additional entries in the jar's manifest.mf) to make our existing adapters, containters as well as applications run in OSGi enabled environments.

Also it turns out that the current standard for message based, mediated exchanges - Java Business Integration (JBI) - sits very well on top of OSGi and in fact our experiences so far in Project Fuji indicate that the specs add features to each other that really have the potential to bring out the best in both. We simply made our JBI framework implementation an OSGi bundle which then can listen for bundle deployments it should service..

What we gain from OSGi in Fuji

• Take control of classpath hell - by being very explicit about what "services" (interfaces) to expose from a jar (bundle) and in turn declaring exactly what external services and their versions we consume from other bundles it creates a very robust way of managing dependencies and easily allows for multiple versions without conflct
  
• Sizes to fit your problem. Only installs the containers / adapters needed, no need to add complexity or overhead with parts of the system you don't need
  
• Easy to dynamically add features to the platform. We leverage a whiteboard pattern for example to add interceptors within the message routing.
  
• Trivial to create a stand-alone distribution that can be zipped up and installed anywhere. The well defined dependencies of your application and the OSGi enabled pieces allow us to easily find and package all the required pieces for a given application with one command/click.
  
• Allows us to focus on the real value of the platform and leaves the lower level grunt work of a component model to a very robust solution with multiple implementation choices. The core runtime implementation of Fuji on top of OSGi is currently under 300K!
  
• The ability to safely exchange optimized payload representations (such as POJOs) between loosely coupled services becomes a reality
  
• More deployment options, easy to run on any OSGi enabled runtime, small size allows flexibility to embed even in platforms wtihout OSGi out of the box

Some of what OSGi currently gains with Fuji

• Mediated model allows for easily adding platform value-add such as auditing, security, routing features ...
  
• A message based, very loosely coupled service layer can make for more stable production system with lower maintenance; it also meshes well with other SOA systems.
  
• Inherent scalability without explicit coding of a SEDA based architecture; threads are not tied to specific requests, components choose the optimal way to process the messages
  
• Interoperability of any component plugged into this layer; standard contract for exchanging messages without prior knowledge of the provider or consumer
  
• More choice of adapters and containers, from multiple vendors; combined with interoperability this can allow for best of breed in a unified platform
  
• A very productive way of defining routing / message flows between services using common patterns that closely match the problem domain by using the Integration flow language (IFL) - a domain specific language (DSL)

Now also throw in all the capabilities of an application server getting modularized and natively supporting OSGi; as the GlassFish team is doing with GlassFish v3, and Fuji gains even more capabilities it can leverage to add scripting, web container, ejb, comet etc... support; without having to create one huge deployable that you may only use 10% of... (hint: stay tuned for what we're cooking up with GlassFish ESB v3 as well ;) ).

Now with the above said, I don't expect all our users to rush out and learn the deepest ins and outs of OSGi. Just like JBI, I primarily see this as an enabling technology for the platform, only if you want to extend the platform itself would you typically touch it directly. As an example I'd expect users to develop simple scripts or POJOs and for example use Spring DM to consume and provide services; so you inherit the advantages of the platform without necessarily having to explicitly touch the underlying technologies.

Coming back to the original blog I am curious how easy it will be to leverage the OSGi-on-the-side story and "don't use it directly" approach JBoss seems to be talking about so far, I would personally like to see Fuji on top of JBoss with an easy way to natively leverage all it's capabilties in the near future as well :)

Posted at 05:42PM May 21, 2008 by Andreas Egloff in Software Architecture  |  Comments[4]