Kas Thomas of CMS Watch writes a thoughtful piece on the pros and cons of the new SpringSource Application Server.

Posted by Kas Thomas
Tuesday, May 13, 2008
5:41 PM

He begins with an overview:

The recently announced SpringSource Application Platform is (according to its creators) “a completely module-based Java application server that is designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability.” Spring geeks will recognize it as the long-awaited integration of Spring with OSGi.

The real value-add of OSGi comes in terms of lifecycle management of classes, cleaner isolation of code, and more thoroughgoing code reuse. With OSGi, there’s no need for every deployed web app to hide its own copy of xalan.jar (or whatever) under WEB-INF, as so often happens on J2EE appservers. A bundle gets exposed once, and the various apps that need to use that code can do so without getting caught in classloader hell.

More interesting is that bundles can be hot-swapped without breaking any running apps. You can update part of an app (just the bundles that need updating) without disturbing the rest of the app or having to bounce the server.

There are other benefits as well, but efficient code reuse and the ability to hot-swap code modules are core to what OSGi is about. Which may explain why WebSphere, WebLogic, JBoss, Jonas, and others are moving to (or already have moved to) OSGi-based architectures.

He covers the downside:

Still, there’s a down side to all the wonderfulness. New programming patterns are in play with OSGi (representing a new learning curve for developers), and overall complexity has not gone down; it has merely been shifted around. Also, some people are put off by the project’s GPLv3 license. (Spring itself will continue to use the Apache license, however.)

He concludes that it is a good thing:

My take? The OSGi-powered SpringSource Application Platform represents an important paradigm shift, one that has the potential to revitalize Java EE development (much as Spring itself did when it debuted on the first day of Spring in 2004). How? By raising expectations around code reuse, serviceability, reliability, remote management, hot upgrades that don’t break anything, version-based conflict resolution, and other difficult issues that (frankly) have long needed solving in order for Java EE development to go to the next level.

Tags: SpringSource