OSGI boost for middleware innovation?
November 11th, 2008 | Published in open standards, soa | 5 Comments
OSGi could mean a big boost for middleware innovation.Current application servers all try to be as complete as possible, so they rank high in industry analyst’ charts, like the one you see here. Being up there in the right top corner is what it’s all about. So they all include everything and the kitchen sink, resulting in huge applications. Some of them even require more than one installation dvd.
But is this really what users need? Most people don’t need everything that is included in these middleware solutions. For most solutions a web container is sufficient. You also have to wonder if every component offered by the middleware vendor is the right component for your problem.
Wouldn’t it be much better if you could pick a small application server and extend it with the functionality required? And be able to select components from multiple vendors? This is actually the biggest benefit of OSGi. With OSGi you can use a small OSGi container (like apache felix) and extend it with the components that you need. For example a Spring bundle, a web container bundle, and an ESB bundle.
And because you’re not limited to the components provided by your OSGi vendor, you can pick any OSGi complient component, we’ll see more competition and more innovation. Don’t like BPEL for orchestration? Replace it with something else. Don’t like doing ESB the visual way? Just replace it with something like Apache Camel.
I think we need a lot more innovation before we can standardize on the right SOA approach, and OSGi will play a big part in enabling this innovation. Good thing OSGi is becomming the standard for application servers, as you can see from this list on InfoQ: OSGi in the Enterprise.
November 12th, 2008 at 4:50 pm (#)
Andrej – I like the way you’re thinking, but can you tell me which of the ‘visionary’ vendors in the bottom right corner currently either use OSGi in their products or make OSGi available to the developer?
November 12th, 2008 at 5:31 pm (#)
At least two: ow2 (jonas) and apache (felix/servicemix). Both have released osgi components which compete more or less with bpel. Ow2 has a bpmn solution. I also like apache camel very much as an alternative to service integration.
November 13th, 2008 at 4:06 pm (#)
Andrej
Agree with your assessment.
OSGi is definitely one of the cornerstones of next generation middleware. I think that’s now pretty much a done deal. However, attitudes need to change. There is no real value in simply re-implementations of the current application servicer and middleware stacks that we see around us in OSGi.
Rather we need to embrace design approaches that promote highly Agile & Robust distributed SOA runtimes based in industry standards including OSGi. Enabling the agility across multiple JVM’s that OSGi provides within a single JVM. The OSGi EEG group have made some small steps in this direction – but there is a long way to go.
Paremus/Infiniflow – (in your Garter innovator quadrant) – is unique in this respect; i.e. a fully distributed OSGi runtime (available since early 2007) – built with a ground up with focus on distribution / agility and robustness.
If you are interested in this sort of technology keep an eye on the Paremus site for more background information over the next few months.
Best Wishes
Richard
Cheers
Richard
November 13th, 2008 at 4:51 pm (#)
Hi Richard,
Thx for the info. I read about the needs for distributed OSGi on Matt Raible’s blog where he also mentioned paremus: Building LinkedIn’s Next Generation Architecture with OSGi by Yan Pujante.
Andrej
January 6th, 2009 at 8:33 pm (#)
[...] look at a framework like Apache Camel and you know that it can do many things better than BPEL. OSGI is also proving to be useful when working with Services. And i think REST has many advantages over [...]