Spring
The Spring Framework was very useful in allowing us to develop our application in a container-agnostic fashion. We took advantage of several of the many features of Spring.

1. Service Location: We used Spring application contexts for the integration with Struts, for deployments to Tomcat and WebSphere, in standalone utility applications, and even in JUnit tests. Spring allowed us to standardize how our service objects were found and initialized across all uses of those objects in a compelling way.
2. Bean Life Cycle and Dependency Management: By using Spring's application contexts, we successfully avoided stateless session beans that would have caused deployment issues across containers (not to mention the fact that Tomcat would not have readily supported EJBs).
3. JDBC Template Code: The Spring JDBC APIs allowed for facile database coding - much cleaner code and standardization along the lines of connection management and exception handling.
4. Flexible Data Sources: The Spring model of using beans to wire together dependent objects allowed us to use extra-container data sources. This came with the benefit of standardized usage of data sources across our runtime scenarios - no fiddling around with container-specific data source configuration.

Jakarta Commons Logging API
We used the Jakarta Commons Logging API from the beginning. It provides a very useful abstraction of typical logging needs while supplying useful hooks for plugging in various logging services such as Log4j, the Java Logging API, etc. WebSphere even provides a gateway to its own tracing facility. The ws-commons-logging.jar in the lib directory off the WebSphere installation root directory allows for logging of classes to be controlled via the WebSphere Administrative Console - as long as those classes were coded to use the Jakarta Commons Logging API.

Commons Logging allowed us to configure which plugin to use (e.g., Log4J in a Tomcat environment, WebSphere logging in that environment) and - via its default implementation that simply writes to the console - to trace unit test code without the need to configure or enable a logging service. In addition, we were able to completely turn off logging via configuration files. (This is done by placing a file called commons-logging.properties on the classpath with the line org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog in it). In fact, this was the standard configuration for running our unit tests, which were run as part of every build. Of course, if a unit test failed, logging could be turned on again as a diagnostic tactic by setting org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog.

What About the Risks?
After a year of real-life experience of developing several applications and performing multiple production deployments with this configuration, we feel that developing on Tomcat and deploying to WebSphere is a low-risk strategy. Once the environments were set up and the deployment process automated, there were very few problems. Spring provided the necessary container capabilities that we needed in a portable way. We were able to take advantage of Spring's bean management, service locator, data source, and JDBC abstractions.

Differences in the security infrastructure were overcome by using Tomcat's built-in features and by providing stub code in the service layer of the development envi-ronment that simulated the presence of TAM. We were able to use the same LDAP server in development (with Tomcat security) and in QA (with Tivoli Access Manager security).

Over time, the cost-saving aspect of cross-platform development became less important in favor of other advantages that were initially not anticipated. The lightweight development environment turned out to be a great advantage, and being forced to layer the application architecture to achieve isolation from the container produced cleaner and better maintainable application code - something that reduced the overall project risks, not increased them.

Summary
It takes a good amount of planning to develop on Tomcat and successfully deploy to a WebSphere environment. Open source frameworks, such as Spring and Struts, can be used to shield an application from platform-dependent implementation details. Ant is a handy tool that facilitates cross-platform deployments. Special consideration is required to handle application security across different platforms. Coding guidelines designed to avoid platform-dependencies must be followed rigorously.

With all these things in mind, cross-platform Java development is a rewarding goal, because your resulting application will be cleaner, easier to maintain, and can provide a real cost advantage.

Resources and Links

• JDBC package for Tomcat with JVM 1.3.1: http://java.sun.com/products/jdbc/articles/package2.html
• IBM WebSphere: www.ibm.com/developer-works/websphere
• IBM Tivoli Access Manager: www.ibm.com/developerworks/tivoli
• Struts: http://struts.apache.org
• Spring Framework: www.springframework.org
• Commons Logging: http://jakarta.apache.org/commons/logging
• jTDS JDBC Driver: http://jtds.sourceforge.net/
• Info Center for Tivoli - with related replication/fail-over configurations: http://publib.boulder.ibm.com/infocenter/tivihelp/ v2r1/index.jsp?toc=/com.ibm.itame.doc_5.1/toc.xml
• Great detailed intro to Tivoli Access Manager - must read for anyone considering TAM: www.red-books.ibm.com/redpapers/pdfs/redp3677.pdf