Spring and WebSphere – fish and chips, or fish on a bike?

The announcement by SpringSource last week of a Spring-OSGi based application server – the SpringSource Application Platform – has generated quite a storm of discussion in the blogosphere from fans and detractors alike. Is all the excitement merited? And what impact, if any, does it have on WebSphere's support for Spring applications?

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.

Is WS-Transaction useable in the real world today?

The WS-Transaction specifications can be used by a Web service to include the processing of the service in a distributed transaction. But Web services themselves are often simply a means to integrate existing applications into new composites and/or a means to expose those applications to new types of clients/channels. So, in a bottom-up design where new Web services that can exploit WS-Transaction capabilities are wrappering existing back-end applications, do the back-end applications have to have been designed to be used with transactions?

The answer is: it depends...

The back-end applications might provide a core business service that has been doing its job well for many years and runs in an environment that ensures the transactional integrity of any data updates performed by the application, such as a CICS program. Or the back-end application might be a database stored procedure, or a purchase order workflow or anything else.

Most of them will have been around for longer than the WS-Transaction specifications but equally most of them can be exposed through Web services that exploit WS-Transaction capability.

• WS-AT is typically useful only when the back-end application runs in an environment that supports some form of distributed 2PC, although the precise manner of the 2PC really doesn't matter since the WS-AT provider can adapt the AT protocol messages to the desired domain-specific transaction protocols. So, for example, WebSphere Application Server represents a received WS-AT context as a JTA transaction within the AppServer process and hence subordinates any XA resource managers (including XATransaction JCA resource adapters) and downstream OTS resources (and on zOS, any RRS unit of recovery) to the received WS-AT context.
• WS-BA is typically useful when any work performed by the back-end application can be undone/reversed through a compensation handler that drives another back-end application (or by the same back-end application with a different set of data). The compensation handler logic itself is application logic but the determination of when/if such a compensation handler should be driven and the recoverable recording of data to be used by the compensation handler is what the WS-BA infrastructure must provide.

WAS provides robust runtime support and application assembly for Web services to exploit WS-AT or WS-BA which can be used in highly available configurations as well as mediated/proxied toplogies. The development tasks associated with supporting WS-AT and WS-BA in WAS are focussed on application assembly and configuration rather than Java programming, the only coding requirement being the CompensationHandler class (a plain old Java object) in the case of WS-BA.

There's plenty of information in the WAS 6.0 and 6.1 InfoCenters on how to use this feature of WAS and samples that can be downloaded from developerWorks. As a general guide through all that information, I posted an article on Web Service Transaction support in WAS on the WebSphere Community Blog. There's also a good article on Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction that describes how to configures both systems for WS-AT interoperability.

Going back to the title of this article, I believe the answer is a resounding Yes and there are numerous commercial runtimes - including IBM's WebSphere Application Server and CICS - that have tried and tested production-ready support available today.

Feel free to comment on any gaps in the information that could be usefully filled.