Hanen has posted 2 posts at DZone. View Full User Profile

SpringSource (and Other Top Vendors) Leading the OSGi Charge

  • submit to reddit

In a press release made available by the OSGi Alliance on 16th of September, several leading vendors including SpringSource, IBM, Oracle, RedHat, Sun, SAP, ProSyst, and Paremus joined forces in their support of OSGi as the foundation for next generation server platforms.

To highlight some of the key points:

Craig Hayman, VP IBM WebSphere said

[IBM] has been shipping WebSphere Application Server built on OSGi since 2006. As a result, IBM clients benefit from a modular platform built with proven components and the ability to automatically use only the components required by their application.

Steven G. Harris, SVP of Development at Oracle said

Oracle WebLogic Server is a great example of the customer benefits of modularization, with its reduced footprint, improved startup time, and flexible configuration options. OSGi technology provides the standards based foundation…

Sacha Labourey, VP of Engineering for RedHat's middleware business said

Running OSGi technology in JBoss Enterprise Middleware Solutions enables our customers to deliver safer services and applications in a more dynamic runtime environment.

Tom Kincaid, Executive Director of Application Platforms at Sun Microsystems said

Sun has seen strong demand for OSGi technology within the GlassFish community. The GlassFish community will be able to take advantage of the modularity and dynamic extensibility implemented via an OSGi-technology based microkernel in the upcoming GlassFish v3 Prelude Release.

What all of the vendors quoted in the release have in common, including SpringSource, is that they build their server platforms on top of OSGi. This has the potential to deliver a set of benefits to users of those platforms including more modular server structures with the ability to run in a smaller footprint and to dynamically alter server characteristics and capabilities.

You need to look a bit harder at the various vendor offerings to determine to what extent they have been able to realize those benefits for you as a user. At SpringSource you could say they were "lucky" in this respect. They had the good fortune to be able to design the SpringSource dm Server (part of the SpringSource Application Platform) from the ground up on OSGi, with no legacy to be concerned with. This has enabled them to exploit OSGi to the full. Other vendors have had to retrofit OSGi into large existing code bases. I know from first hand experience how difficult it is to retrospectively try and modularize a large existing code base. If you do manage to modularize it, making it behave well in a dynamic environment is even harder (even Eclipse struggles to pull off that latter requirement, often requiring restarts after updates).A characteristic you tend to see in products where OSGi has been retrofitted are a small number of large bundles (very coarse grained modularity) and limited dynamic support for managing modules at runtime.

Vendors such as SpringSource, Paremus, and ProSyst go one crucial step further. Building a server platform on OSGi can only get you so far. What if you actually want to take advantage of OSGi for building your own applications? For this you need an OSGi technology-based programming and deployment model. This is where the true frontier for next generation server platforms is - not in making things easier for the server vendor to build their platform, but in making things easier for the application developer to build and deploy their applications onto that platform.

The SpringSource dm Server supports traditional war files, OSGi bundles, and applications consisting of several bundles (modules) working together, with a gradual migration path from a war file allowing you to incrementally take advantage of OSGi.

Here are some key questions to ask your vendor when considering OSGi:

  • You say your server is built on OSGi, but how modular is it really under the covers? Is it a few very large bundles or have you been able to fully architect your platform to take advantage of OSGi?
  • To what extent are the dynamic capabilities of OSGi to add, remove, and update modules at runtime reflected in your server platform? Can I add and remove server capabilities or subsystems easily?
  • Can I deploy my own applications as OSGi bundles? Do you have management and administration tools to accompany this?
  • Do you offer a standards-based OSGi programming model? (This is a tough one, SpringSource uses Spring Dynamic Modules as the programming model, and is working to standardize this in release 4.2 of the OSGi Service Platform through RFC 124. This will form the cornerstone of the standards-based OSGi programming model for SpringSource dm Server.)
  • I need to use existing enterprise libraries in my application - how are they supported under OSGi on your platform? (Without special support, things like load-time weaving required by ORM vendors may not work correctly).
  • Do you package all of your own offerings as OSGi bundles that I can easily deploy? (The Spring Framework for example is OSGi-ready out of the box).
  • Where can I obtain OSGi-ready versions of commonly used third-party libraries to deploy to your platform? (SpringSource makes available the SpringSource Enterprise Bundle Repository for this purpose).

I think it's very safe to say that OSGi is here to stay. Welcome to the future, enjoy the ride!

Published at DZone with permission of its author, Hanen Ben Rhouma.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Otengi Miloskov replied on Wed, 2008/10/01 - 3:04am

Awesome article!, So all the major JEE players support already OSGi on their Application Servers and there is one I'm very interested the upcoming GlassFish v3.


Mike Funk replied on Wed, 2008/10/01 - 5:48am

If you're building enterprise applications, don't bet your business on OSGi. It's a bundling nightmare to support anything but the simplest of applications. And wars are not the answer in an OSGi world. Try to get beyond the hype with a realword enterprise OSGi prototype; then, proceed with great care.;)

Jacek Furmankiewicz replied on Wed, 2008/10/01 - 6:44am in response to: Mike Funk

There is nothing wrong with OSGi per say, it's a great technology with some great implementations.

But it isn't the single solution to every problem out there. Something like an app server definitely needs it, but your typical internal accounting app has no reason to use OSGi at all, IMHO.


Carlos Luis replied on Wed, 2008/10/01 - 9:28am

Does any of you could point me to an article explaining OSGi's pros and cons. I have been hearing about this standard for a while now, but haven't found any resource that does not feel like vendor propaganda.


I'd really like to determine wether it's worth starting my next project using OSGi.



Jacek Furmankiewicz replied on Wed, 2008/10/01 - 9:40am in response to: Carlos Luis

a) Do you deal with 3rd party SDKs that may have conflicting library versions (e.g. different versions of Apache Commons)?

b) Do you need to reload bits and pieces of your app dynamically at run-time without bringing down the server?

If you answer No to any of these questions, I would say you do not need OSGi. But I am sure every vendor will tell you otherwise.

Denis Robert replied on Wed, 2008/10/01 - 11:23am in response to: Jacek Furmankiewicz

c) Do you have to insulate parts of your system one from the other?

d) Do you often find youself packaging jars inside your wars, rather than be able to share them between wars by placing them at the app server level? (equivalent to question a), but far more likely to get a yes answer).

A lot of people tend to criticize OSGi's classloading, but that's typically because of a lack of experience or understanding of the classloading model. Now that Spring is completely OSGi-aware, there's little need or requirement for an app to use ClassLoader.loadClass() directly, a major source of annoyance in OSGi. There are some other framework libraries which tend to use a lot of dynamic class loading, but more and more are now moving to OSGi.

With SpringSource's Enterprise Repository, most of the issues in finding OSGi-friendly 3rd party libraries have gone away. There's also far better documentation now than there was 3 years ago (when I first started using OSGi). So now's probably a good time to give it a chance...


Andrew McVeigh replied on Wed, 2008/10/01 - 1:37pm in response to: Denis Robert

d) Do you often find youself packaging jars inside your wars, rather than be able to share them between wars by placing them at the app server level? 

that's a very good point.  J2EE/JEE apps are a nightmare for dependencies and class loading problems.   anything that addresses that aspect has got to be worth a look at, even if it has some problems of its own.


khaled essghaier replied on Thu, 2008/10/02 - 2:46am

Nice article!

Mike Funk replied on Thu, 2008/10/02 - 1:42pm in response to: Mike Funk

Sorry, I meant to say...real world enterprise OSGi prototype....

 That said, if you'd like to better understand the deep pain associated with deploying JEE applications to an OSGi container, peruse this site: http://www.dynamicjava.org/


Slim Ouertani replied on Tue, 2008/10/07 - 4:12pm


Using osgi on the server side will be the tomorrow dream!!. Yes, with osgi we can have some facilities such as dependencies and services bind but  waiting to automated tools, IDES, OSGI and MDA... to recall and choose osgi by default.

Using JEE on the top of osgi is one of best choice today, and don't forget that many java developers don't hear about osgi but they know JEE :)

Peter Huber replied on Fri, 2008/10/10 - 7:38am

It's interessting to find to find "spring source" in the lead regarding OSGi framework. It seems like they "wrote the OSGi book". I'm into the topic of OSGi a bit longer than the hype that currently started out and I think it's fair to mention other very mature implementations of OSGi like for instance knopflerfish and it's bundle repository http://www.knopflerfish.org/releases/current/repository.xml.  Or take a look at http://oscar-osgi.sourceforge.net/#bundles.

I guess those repositories offer pretty much of what you need to build a simple but yet very capable server platform (webservice, http, xml-rpc,...all there, you might even include spring as a fragment if you like). So I'd say it's just fair to take a broader look and include all those OSGi "vendors" that had been there before "the (spring) source" of everything started it's OSGI-initiative.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.