First Look at the Spring 2 Application Platform

2008-05-10T07:08:00.000-07:00

Hey, my name is SpringFan. I'm a Spring user since 2004. I've held various positions as senior Java architect and senior Java consultant. I've used the Spring Framework in dozens of projects, big and small.

I've contributed to several open-source Java projects - including Spring. I've also co-founded a few open-source Java projects myself, some incubating, some well-known. I'm an editor at Java-related websites and author and co-author of a number of Java-related books.

I know most people working for SpringSource, including its founders. I'm familiar with the frameworks in the Spring portfolio and worked extensively with most of them. I regularly submit bug reports and suggestions for improvements to the various SpringSource frameworks (about 20 tickets in the last 12 months).

You could say I'm somewhat familiar with Spring. One thing I'm not familiar with though is OSGi and this is exactly the road the SpringSource guys have decided to take.

SpringSource thinks OSGi is the future and they're putting their money where their mouth is. They've started work on Spring DM (Spring Dynamic Modules, previously Spring OSGi) more than two years ago with a few of their consultants working on it. Rod Johnson claimed in April 2008 that SpringSource has been working on the new Spring 2 Application Platform (S2AP) for over one year and I know they have a lot of people working on it.

And they've kept it secret. None of the SpringSource people I've talked to informally during the last year has ever mentioned S2AP. Then one day we woke up and there was S2AP in beta.

I've never thought Spring DM was useful for my purposes, particularly since using OSGi in applications that are deployed in servlet containers or application servers is either tricky or impossible.

At it's core OSGi is a structured ClassLoader hack. And since servlet containers and application servers also play with ClassLoaders they typically impose restrictions on the kind of ClassLoader hackery OSGi employs, making the overall experience for developers less than comfortable. (Note: some application servers use OSGi internally, but they don't offer support to use OSGi in the applications you deploy on them.)

Developers typically have a hard time with application servers. If you're using the top of the line (Weblogic) you still have a fair chance at agility. Otherwise you're out of luck, especially if you're working with application server resources like JMS queues, JDBC DataSources or JCA connections in combination with distributed transactions. Add OSGi to the picture and you have take even more restrictions and limitations into account to make your applications work. S2AP seems to solve exactly this problem which makes it promising and interesting.

OSGi - through its ClassLoader hackery - offers certain advantages that if you can make them work for you could return important benefits. Eclipse is obviously a powerful platform for developing plugins and it's based on OSGi. (Note: I feel strongly that developing Eclipse plugin is harder than it could and should be, but the advantage of the OSGi features is obvious.)

So, which features does OSGi offer? The most important feature from where I'm standing is limited ClassLoader visibility. In a Java VM without using OSGi or similar ClassLoader hacks all public classes that are available on the class path are accessible from any other class. This is annoying, and OSGi allows you to impose restrictions on this. In fact, by default you only have access to the classes in your "bundle".

Another OSGi feature is to have multiple versions of the same classes in one Java VM. You then have to choose which version you want to use. This could be useful in theory. Yet, as far as I know Eclipse does not use this feature and I have yet to hear from a usage in practice.

Lastly, OSGi gives "bundles" a life cycle which allows "bundles" to be loaded, unloaded, reloaded, started, stopped, ... on a live Java VM. See, OSGi has been conceived for embedded, low resource applications and environments (BMW cars use OSGi). You can work with this life cycle dynamically through the OSGi APIs or via OSGi management consoles. And it's a useful feature. Ever wished you could dynamically load and unload Spring configuration files instead of loading them when your application starts? S2AP offers this through Spring DM and OSGi.

A bundle is a regular JAR file with OSGi-specific headers in its MANIFEST.MF file that has to be loaded by an OSGi container (e.g. Eclipse Equinox). OSGi features (access restrictions, versioning and bundle life cycle) are only available in OSGi bundles that have been loaded by an OSGi container.

So, why is S2AP promising then? Before I can even start to answer that question we have to take look under the hood. And there we find Spring DM and the Eclipse Equinox OSGi container.

I've never used Spring DM in anger. But I do know it adds Spring Framework capabilities to OSGi bundles. For example, when a bundle gets loaded Spring XML files that are included in the bundle (JAR file) are automatically loaded in an ApplicationContext that is local to that bundle. When the bundle in unloaded the ApplicationContext is closed. In these Spring XML files it is possible to declaratively obtain services exposed by other bundles. You can also declaratively expose services for the benefit of other bundles.

Spring DM certainly offers useful features, and a new deployment model. Unfortunately it's hard or even impossible to use Spring DM from inside applications that are deployed in application servers, which is your typical Java enterprise application ($$$).

That problem could be solved, for example by starting the Eclipse Equinox OSGi container and run it next to a Weblogic application server (so not in the same Java VM). You could then use Spring DM in your bundles and access Weblogic resources remotely, like its JTA TransactionManager or JMS queues and ConnectionFactories.

You could do that but it comes with some penalties. First, you now have at least two Java VMs to configure, run and monitor. Also, not all Weblogic resources can be accessed from other Java VMs, like CommonJ thread pools or schedulers.

SpringSource has cleverly taken this approach and turned it upside down. With BEA bought by Oracle for its customer base and not necessarily it's Weblogic application server technology SpringSource introduces a completely new deployment model. And it may turn out to be a pretty good one.

S2AP is actually an application server, but not a JEE application server like Weblogic, WebSphere or JBoss. It appears to offer some pretty advanced, for-money monitoring and logging capabilities which is something loaded enterprise customers want.

They offer the OSGi-based Spring DM deployment model for applications and they also offer SPIs (Service Provider Interface) for vendors to integrate their JMS servers, transaction managers and JNDI trees. Which is clever.

Because while Weblogic is the best integrated application server the features it offers are also available elsewhere and often for free. Atomikos offers an open-source JTA TransactionManager with support for distributed transactions which can be used in combination with JMS servers like ActiveMQ, IBM MQ Series or Weblogic server.

Nothing stands in the way of deploying the Atomikos JTA TransactionManger as an OSGi bundle, instantly offering distributed transaction management capabilities to other bundles. Clever. It's not hard to see how Atomikos and other vendors would be happy to work with SpringSource to make their valuable products work seamlessly on S2AP. S2AP probably offers some value in return for these vendors through its for-money advanced monitoring offering.

And it doesn't stop there. S2AP also seems to have support for hot class weaving, probably on top of the OSGi bundle life cycle. Handy, and not only to integrate AspectJ (btw, I guess we will see things moving in AspectJ land soon too).

Imagine Terracotta's open-source distributed memory - which requires load-weaving - available as an OSGi bundle. I'd have to look into how class weaving works in S2AP. But knowing the SpringSource guys they'll offer some powerful, stable semantics in this area. If Terracotta gets integrated into S2AP in this way it would offer powerful clustering features for the benefit of application code. This would literally be wild, since it would allow us to apply clustering with a very fine and comfortable brush.

From where I stand, and given we're talking about SpringSource which is now loaded with venture capital to invest I think S2AP will become pretty successful in enterprise environments at which it is clearly targeted.

The price to be payed by developers is that there's a new deployment model to learn. That's pretty daunting. Yet I believe it will happen. I don't believe it strongly yet, I first have to dive into OSGi and S2AP. But things are certainly looking promising.

Also, expect to wait at least another 6 months, probably more, for S2AP 1.0. Which is good news for the community since it gives us the time it will take to acquire new skills.

Painful OSGi

First Look at the Spring 2 Application Platform