Thursday, 1 May 2008

SpringSource Application Platform

Yesterday SpringSource announced the release of their application platform:
a completely module-based Java application server that is based on the new SpringSource Dynamic Module Kernel™ (dm-Kernel). The dm-Kernel harnesses the power of Spring, Apache Tomcat and OSGi-based technologies to give the platform incredible flexibility and resilience for both development and production.
Effectively an OSGi container with some Spring stuff thrown in and another step in the right direction away from the J2EE world.

Referred to as S2AP, the SpringSource Application Platform announcement generated a fair amount of interest and discussion so I decided to cut to the chase and ask Rob Harrop of SpringSource to clarify a few issues.

Firstly, not being a lawyer or Open Source license expert I was a little confused about the implication of using GPL as the Open Source license for the server. Rob managed to clarify this succinctly:

If you are running applications on the S2AP, then there are no requirements placed on you. If you distribute an application including S2AP or GPL components thereof, then you would either need to license your application under GPL or purchase a commercial license from us.

A useful summary of what using GPL means. Next up, I was interested in what S2AP brings to the table if, like me, you're not a user of Spring and currently have no plans to be.

S2AP contains a lot of additional benefits on top of plain OSGi. For starters, OSGi aside, its just a good, solid server platform. We have extensive serviceability features including active deadlock monitoring, detailed trace and first failure data capture. We have provisioning support that makes it easier to handle the installation of hundreds of bundles into your runtime environment. The pre-embedded Tomcat is plus point - that was a lot of work.

There a lot of under the hood tweaks, including resource loading support that works in standard libraries such as Jasper (JSP), load-time weaving support and advanced refresh that handles more module dependencies than those currently handled by the OSGi spec.

My interest is definately peaked now, so I think I will be checking it out in my next development lul or as a distraction from development grind. However, I had one outstanding question regarding a specific piece of functionality that I have been hoping someone would save me the bother of having to implement. It occurs to me that it would be very helpful if I can register a service with the OSGi context and some other bundle automatically makes that service available as a web service. Spring has some functionality enabled rapid development of WebServices, so I asked Rob if this is something that S2AP can help me out with.
Publishing OSGi services as WebServices is on our roadmap, but it won't be available for 1.0 final.
Fair enough. As it happens there is already a Knoplerfish bundle that can do this, but its implementation is not compatible with newer SOAP clients.

So in conclusion, it looks as though S2AP is worth keeping an eye on for the future of OSGi containers. If it lives up to its instant hype and the features described by Rob it is will be a robust platform for purist OSGi developers like myself, as well appealling to those already in the Spring camp.

For more information on S2AP, you can check out Rob's blog entry: Introducing the SpringSource Application Platform


Davanum Srinivas (dims) said...

Christopher, Please see my response here -

Anonymous said...

Hi Chris,

Are you going to attend to Spring One? There are few presentations about S2AP and OSGI...


Chris Brind said...

Hi Ced,

Nope, for a number of reasons including the fact I'm getting married the following week, I'm not that big a Spring fan and can't afford it (nor will my employer let me have the time off or fund it).