I think its merited - that's why I'm writing about it. The Spring framework has done a lot to shake up the Java Enterprise world by popularising the dependency injection (DI) pattern both as a way to wire application components together and as a way to provide the enterprise services those applications need. This was a “good thing”, as was the adoption by EJB3/JPA and JAX-WS Web Services of DI-based POJO programming models, enabling POJO-based business logic to be developed and more easily tested outside a JEE environment thus accelerating and simplifying the development experience. Enterprise qualities of service, such as security and transactions, get applied by the JEE container without requiring changes to the application when the application is deployed into the JEE container. The Spring framework goes further with this than Java EE because the Spring framework is itself a “lightweight container” that is bundled with the application regardless of whether the application runs in a Java SE or Java EE environment. The lightweight container that is a part of the Spring framework
spring.jar abstracts away some of the differences between an underlying Java EE runtime vs an underlying Java SE runtime. For example, the Spring framework transaction support provides a common local transaction demarcation model regardless of whether the underlying runtime is SE or EE. Actual transactional work within the demarcation scope is delegated to the underlying resource managers wired into the application – for example JDBC or JMS providers.A common misunderstanding I see from people coming into contact with the Spring framework for the first time is that the Spring framework itself provides many of the enterprise qualities of service available in a Java EE container. Again, Spring support for transactions is a good illustrative example. The Spring framework reference documentation, for example, says “One of the most compelling reasons to use the Spring Framework is the comprehensive transaction support.” In my opinion, comprehensive transaction support is one of the most compelling reasons to use a JEE AppServer which actually provides a recoverable 2PC transaction manager. The Spring framework does not – it simply delegates to whatever is already there. In a Java SE environment, this means the resource (JDBC, JMS etc) provider; in a Java EE environment this means the JEE AppServer’s JTA transaction manager.
The core Spring framework has done a good job of integrating with various underlying Java EE providers. Its complimentary nature and popular adoption by Java developers have led WebSphere and all of the major JEE vendors to demonstrate integration with and exploitation by the Spring framework. People like the Spring framework because it provides a nice, simple composition and deployment model and gives them portability between Java SE and EE runtimes.
This portability is different from portability of JEE applications between JEE vendors. Portability across Java EE vendors is at the level of Java EE APIs (EJB, JMS, JTA etc) standardized through the Java Community Process. The Spring framework libraries define their own Java programming interfaces; these interfaces are not part of any standard but applications that use them are portable between Java SE and EE runtimes because the Spring framework libraries are packaged as part of the application rather than as part of the underlying runtime platform. This Spring "lightweight container" isolates the application from the differences between SE and EE runtimes. In an EE runtime, the lightweight container delegates to the EE container to engage the EE qualities of service.
While there clearly is synergy between JEE providers and the core Spring framework, it remains to be seen how the new SpringSource Application Platform will change the dynamics of the relationship between SpringSource and the other JEE vendors. I say “other” because SpringSource now, for the first time, is going to be positioned as a JEE vendor. This may not be SpringSource’s primary intention but it is inevitable given comments like “It is highly likely that the SpringSource Application server will become Java EE 6 Compliant in some form” from SpringSource’s Rod Johnson on InfoQ. But JEE is not the SpringSource end game here – OSGi is. There has been a great deal of interest expressed over the last year in combining OSGi’s modularity with Spring’s application configuration model, which is what the Spring Dynamic Modules project offers – under an Apache open source license. The next logical step is the dynamically provisioned application server platform that hosts Spring-OSGi applications as the deployable unit, a step SpringSource have taken with their new SpringSource Application Platform offering. But there remains a “roll-your-own” approach towards familiar JEE enterprise services such as messaging, persistence and transaction support – these are services that need to be plugged in, they are not provided by "S2AP" itself. Perhaps that will change over time and S2AP will evolve its own positioning into a complete enterprise Java application server.
Does any of this affect WebSphere? Well, nothing has changed in the core Spring framework. Regardless of what the future holds for the SpringSource Application Platform, the core Spring framework project remains complimentary to WebSphere. Like fish and chips.
