Intelligent Enterprise

Just when you thought the Java application server market was pretty well saturated (if not in actual decline), along comes a brand new entrant with familiar-sounding promises of "lighter, faster, easier." What's doubly ironic is that this new contender comes from the very folks who've done so much (intentionally or not) to make "Java appserver" a bad name in recent years. I'm talking about the people at SpringSource (purveyors of the celebrated Spring Framework).

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.

Diagram

OSGi, by way of background, is a fairly mature specification (dating to 1999) encompassing a dynamic component model in which Java classes are deployed as bundles, which are in turn registered as services within the OSGi execution environment. The OSGi framework provides automatic versioning, dependency resolution, and secure "find and bind" functionality such that bundles can discover and safely call the right versions of each other. (Think of it as a kind of SOA microcosm inside a running JVM.)

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.

What (if anything) makes SpringSource Application Platform better than any of the other OSGi-enabled app servers? On a purely technical level, SSAP tends to expose low-level OSGi internals more directly, for developers who want programmatic access to OSGi-based magic. (Other appservers tend to hide OSGi's innards.) Also, SSAP is more flexible with regard to deployment options. And (oh yes), it uses Spring.

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.)

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.

For people who implement, customize, maintain, upgrade, and/or administer Java-based content management systems, the potential payoffs of OSGi are many. Note that the WCMS vendors best positioned (in theory, at least) to benefit from the new paradigm are those already using Spring, such as Alfresco, CoreMedia, Enonic, and Hannon Hill. Mind you, it's not a given that any vendor currently using Spring will migrate to the SpringSource Application Platform. But it's definitely something to watch for. I'll be following the situation closely; and I intend to let you know what "develops."

Kas Thomas is an Enterprise Architecture analyst at CMS Watch. He previously evaluated J2EE and content-related technologies for Novell. Write him at kthomas@cmswatch.com.