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: http://www.ibm.com/developer-works/websphere
• IBM Tivoli Access Manager: http://www.ibm.com/developerworks/tivoli
• Struts: http://struts.apache.org
• Spring Framework: http://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: http://www.red-books.ibm.com/redpapers/pdfs/redp3677.pdf

SIDEBAR 1

Configuring Ant for Deployments Between Different Application Servers
We used Ant (Ant 1.6+) to manage configuration, builds, and deployments from local development environments to the integration server, from there to the staging server, and finally to production. The ant scripts needed to handle two main server differences:

1. The WEB-INF/lib directory had to be populated with any JARs not provided by the application server. Specifically, our Tomcat environment required the optional JDBC 2.0 Package while WebSphere already came with the necessary classes installed.
2. The security-* elements of the Web deployment descriptor (web.xml) needed to include security-role definitions for deployments to Tomcat. In WebSphere, the security roles were defined at the enterprise application level (application.xml).

<!-- Server Type property-override customizations (if any) -->
<property name="server.type.config.file"
location="${build.modules.home}/deployment/servertypes/${server.type}.properties"/>
<echo message="server.type.config.file=${server.type.config.file}"/>
<property file="${server.type.config.file}"/>

Having a separate properties-file for each server type was helpful, because it made the deployment process agnostic of the type of server that we deployed to. The main property set in each of these files was deploy.tomcat or deploy.websphere (essentially deploy.server-type). Having these properties allowed us to configure the build-war macro according to the server type to handle the inclusion/exclusion of the JDBC 2.0 optional package (see Listing 1).

Only one of the war-* targets is being called depending upon whether the deploy.websphere property is defined or not. This results in a macro definition of build-war, which has been configured for the target server.

Similarly simply, the appropriate definitions for the security-* elements of the web.xml are handled according to the value of server.type.

<!-- Copy the environment-specific version of the web-security.xml XDoclet merge file -->
<target name="web-security-websphere" if="deploy.websphere">
<copy file="${web.merge.dir}/was-web-security.xml"
tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
</target>
<target name="web-security-tomcat" unless="deploy.websphere">
<copy file="${web.merge.dir}/tomcat-web-security.xml"
tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
</target>

The targets web-security-tomcat and web-security-websphere are then named as dependencies in other targets that use the XDoclet webdoclet task (which uses the web-security.xml deployment descriptor snippet).