Or so an Industry Analyst recently informed me.
Yet the flurry of Twittering & Blogging concerning the distributed OSGi section of the new <a href=”http://www.osgi.org/download/osgi-4.2-early-draft.pdf”>OSGi 4.2</a> specification is certainly interesting. Is OSGi approaching some sort of enterprise adoption tipping point? These along with other commercial indications imply this is likely.
This is good news. OSGi deserves to be wildly successful, OSGi is one of the key enablers for the next generation of enterprise.
Yet a danger lurks in the shadows.
The use of OSGi does not in itself guarantee any sort of coherent architecture, nor is capable of addressing the current complexity crisis with the enterprise. OSGi is simply a tool – and in the wrong hands OSGi runtime systems will seem orders of magnitude more complex than the systems they replaced. Meanwhile, the distributed OSGi section of the 4.2 specification is simply an acknowledgment that “things” exist outside the local JVM – no more – no less.
Distributed OSGi has little to say about how to address <a href=”http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing”>Deutsch’s 8 Fallacies</a> ( actually if you follow the link you’ll notice that Wikipedia now have a 9th 🙂 ). How these distributed entities discover each other, interact with each other, and which protocols are used is left as an exercise to the software vendor. This is not a criticism of the standard – this is a good thing. OSGi doesn’t constrain distributed architectures.
Yet this allows business as usual for the Software Vendors. And so we see the same old tired SOA rhetoric.
“ESB’s & WS-*, would you like OSGi with that sir?”
But joking aside – the real danger is that OSGi’s fate may become hopelessly entangled with the current disillusionment surrounding the web of vendor <a href=”http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html”>SOA Market-ectures</a>.
Paremus have always argued that OSGi deserves to be complemented by a network SOA framework that is as adaptable and dynamic as OSGi is locally within the JVM. A Self-Similar Architecture!
It was for this reason that Paremus fused OSGi (the new Cool technology) with Jini (was Jini ever Cool?) within the <a hef=”http://newton.codecauldron.org/site/index.html”>Newton project</a> in 2006. A solution, in its commercial <a href=”http://www.paremus.com/products/products.html”>Infiniflow</a> guise, which has been in customer production for over 2 years.
As for Cloud Computing – that story has only just started 😉