Spring Framework Certified on WebSphere

SpringOne is humming along nicely. This year it's a 3 day show, up from 2 days last year, and once again it's great to see hundreds of attendees at a Spring conference. For once I'm quite relaxed at a show, as after the opening keynote I have no further sessions, and don't need to work on slides.
Right now, Adrian is preparing to make a major announcement about Spring tooling. Well actually he's giving a uniquely personal take on duck typing, as I'm sure you'll hear…
More about that later, but first I need to share some news from yesterday. I was happy to be able to announce that we have worked with IBM to certify Spring on IBM's flagship WebSphere Application Server. As much of Interface21's customer base is in large enterprises, we see a lot of WebSphere and have wanted to ensure the ideal integration for years. It's good to see that IBM share this goal. Their commitment to the integration was also largely driven by customers, many of whom have adopted Spring and experienced great results with it. As Spring adoption has moved from project-by-project to strategic, such customers want to know that this combination is supportable and that both vendors are behind it.
You could read the press release. But as press releases are for managers and tend to get reviewed and bounced around between the companies and PR agencies involved to a point of meaningless, so it's probably easier for me to explain what this really means in English rather than marketing speak.
- IBM and Interface21 have worked together closely over almost a year to test the Spring Framework on Websphere. This is far beyond a mere marketing effort; it has involved extensive testing on the many and varied platforms WebSphere runs on, including mainframe platforms.
- We have resolved all known issues around the combination. Whatever your hardware and OS, you can use Spring with confidence on a WebSphere platform. Obviously Spring already worked well on WebSphere, but this closes off corner cases and, most importantly, means that even the most risk averse manager will understand that using Spring on WebSphere is safe and can be supported.
- The most important specific area of enhancement concerns transaction management, with code added to both WebSphere and Spring. This work has been led by Juergen Hoeller on the Interface21 side and WebSphere transaction architect Ian Robinson at IBM.
If you're familiar with the Java EE and JTA specs, you'll know that they leave gaps–notably, how you do the significant things, like transaction suspension, that you can't do with a UserTransaction. These are corner cases, but when you encounter one of them it may be hard to work around it. While it's far preferable to delegate transaction management to Spring than to use JTA directly (for reasons of testability, exception handling and semantic completeness), the gaps in the standard JTA functionality can be problematic if that's all that's available underneath.
Fortunately, a solution is at hand to allow Spring to maximize the potential of the underlying platform. Spring provides a transaction abstraction–PlatformTransactionManager–that is semantically more complete than JTA but makes no assumptions about its environment. It's a key example of what we call portable service abstractions. Normally you don't use the PlatformTransactionManager directly, because Spring's declarative transaction management gives you a uniquely powerful option for applying programmatic transactions to any POJO, but it is the foundation of both programmatic and declarative transaction management in Spring. Because we don't make any assumptions about the environment, and environmental details don't leak into your code and decrease portability, we can safely tie into platform specifics. We've done this for WebLogic, Oracle have done it for OC4J, and we have now worked with IBM to produce a first-class integration for WebSphere.
Following Spring's core value proposition, we take care of the plumbing so you don't have to. As you would expect, the new WebSphere transaction manager is very easy to use. If you're using WebSphere with Spring, you should use the new PlatformTransactionManager abstraction that we have developed with IBM. This is a trivial configuration setting. Instead of using JtaTransactionManager, you use the new WebSphereUowTransactionManager, like this:
class="org.springframework.transaction.jta.WebSphereUowTransactionManager"/>
More technical details are in an IBM DeveloperWorks article Using Spring and Hibernate with WebSphere Application Server. Note that if you've read this article before (or your manager has read the previous version and gotten scared) it has been updated significantly. Also on DeveloperWorks is an interview with myself and Paul Buck of IBM (Director, WebSphere Open Source) discussing the integration effort.
One of the authors of this article, Sara Mitchell of IBM's Hursley lab in the UK, is here at SpringOne and will be presenting tomorrow on Spring on WebSphere. Sara has done much of the technical work on the integration and it's been great to see here engaging in the Spring community through our forums and through presentations. Savio Rodrigues of IBM is also here, and appears to be enjoying the show.
Created

nicolas de loof says:
Added on June 21st, 2007 at 6:25 am -QuoteI'm also at springone'07 and sit by chance jut behind Rod during keynote, when he typed this blog entry. Really funny to see a 10M$ company CEO and all his staff working with laptop on knees for a strategic announcement on IBM collaboration. I can't imagine my company bosses in such a situation. Is this the silicon valley way of life ?
Thank for great sessions at Spring-one, and especially this incredible duck-typing demo.
Julien Dubois says:
Added on June 21st, 2007 at 9:07 am -QuoteNicolas, I'm happy to see you made it to SpringOne once more! And I can't imagine any manager in your company in such a situation either
PM says:
Added on June 25th, 2007 at 7:45 pm -QuoteIs WebSphereUowTransactionManager supported on WebSphere 5.1? If so, do i need get the latest release of spring to use the transaction manager.
PM
Juergen Hoeller (blog author) says:
Added on June 29th, 2007 at 8:26 am -QuoteWebSphereUowTransactionManager, building on IBM's new UOWManager API, is only supported on WebSphere 6.0.2.19 and 6.1.0.9 . On WebSphere 5.1, the best you can do is to keep using Spring's standard JtaTransactionManager in combination with WebSphereTransactionManagerFactoryBean (which has already been available in Spring 1.2 and 2.0; if you don't need transaction suspension, stick with a plain JtaTransactionManager).
That said, note that Spring 2.1 still supports WebSphere 5.1 in general, since Spring 2.1 remains compatible with JDK 1.4.2 and J2EE 1.3 (as far as possible).
Johan Eltes says:
Added on June 30th, 2007 at 7:16 am -QuoteMany of our customers are suffering from the Local Transaction Scoping in WebSphere 5 . There are some articles on it - sorry for not having it at hand. In short, WebSphere does not allow the developer to design the use of transaction demarcation often required to minimize the lease time of none-transactional (read-only) usage of database connections. With most J2EE-compliant application servers (I'm not aware of any exception, except for WebSphere), running a request outside of an active JTA transaction, makes jdbcConn.close() make the connection immediately available to serve concurrent requests. Unfortunately, WebSphere creates a local transaction scope for the complete web request, which forces the lease to of connections to last for the complete (none-transactional) web request. Imagine a Struts action forwarding to the next etc… Many internet-facing web applications have ratio for transactional / none-transactional web requests of 20-to-1. Optimization of connection lease time becomes a critical factor for scalability. On behalf of one of the worlds largest companies, I filed a request to IBM for adding a configuration option to disable the local transaction scoping feature. The reason for having it there is - according to the IBM technician - to be able to help the developer avoid leaking connections. If the developer forgets to close a connection within a read-only DAO operation, the local transaction scoping allows websphere to close all connections that was created during the scope. This is however not consistently implemented in WebSphere. If the same DAO operation is invoked from an MDB, the DAO will leak connections. This behavior only applies to Sharable datasources. Unsharable ones are not "trapped" by the local transaction scoping mechanism - and thus immediately returned to the outer connection pool for re-use by concurrent threads. The solution is then to configure two data sources instead of one - a Sharable to use for transactional requests and a Unsharable for read-only requests. There is - however - no fully general way for a DAO operation to know which one to use - i.e. to know if the operation is executing within an active JTA transaction or not. If the application team can standardize on bean-managed transaction demarcation - which is the typical Spring scenario - DAO operation could query the transaction status of the UserTransaction. This will however require the DAO operation to have a UserTransaction injected, which breaks the value of the portable platform abstraction I expect from my Spring usage. My code will not run out-of-container, unless I have a transaction platform abstraction that uses UserTransaction as the api. Spring doesn't. It also doesn't provide a way of querying the transaction status. In this sense, Springs platform abstraction is not semantically complete. Having the UserTransaction interface as the api of a portable platform abstraction, isn't semantically complete either, which was of cause the reason for Spring to role their own api. Where am I heading, the reader may wonder. On my wish list for making Spring integrating seamlessly with websphere, I would request from IBM to add the possibility to disable local transaction scoping for Sharable datasources. At some customers, we hav had to role our own transaction abstraction based on the UserTransaction interface, with out-of-container transaction manager for integration testing, and all that comes with it. This has been integrated into Spring DI, but we would definitely have preferred to use what Spring provides in terms of transaction platform abstraction.
Chris Moon says:
Added on August 8th, 2007 at 10:42 am -QuoteDid the certification include Spring MVC and Spring Portlet MVC running on WebSphere Portal?