引言
有关J2EE应用程序到WebSphere应用程序服务器的移植，尽管IBM提供了很多的资料和文章来说明如何将运行在WebLogic上的应用程序移植到WebSphere上，但是大家可能还是有所疑惑：是否从WebLogic移植到WebSphere和从Tomcat、Jboss、Resin移植到WebSphere会有所不同呢?实际上，一个J2EE应用程序无论运行在什么平台上，我们都可以用相同的方法将其移植到WebSphere上，这也是J2EE规范给我们带来的好处。然而，移植往往不会是一帆风顺的，移植的难度不仅取决于J2EE应用程序对J2EE规范的遵循程度，更取决于它所用到的非J2EE成分的可移植性。对于标准的J2EE应用程序，我们可以通过固定的步骤完成移植任务，而对于其他的部分，我们只能通过耐心的调试和探索，以寻求最佳的解决方案。在这篇文章里，我们将详细说明移植的方法和常见的问题，在后续的文章里会具体讲述我们在各个平台移植过程中所遇到的特殊问题和解决方法。
本文假定您熟悉J2EE规范，并且使用WebSphere Studio Application Developer开发过部署在WebSphere应用程序服务器上的J2EE应用程序。在阅读完本文后，建议大家先从试验入手，完成参考文档中的样例程序，从而对移植任务有一个更加具体的理解。
移植方法
一、 学习WebSphere Studio Application Developer，参见参考文档1。
二、 从应用程序中挑选出最具代表性的子系统
1、这个子系统应该全面涵盖系统的技术难点，参见常见的问题
2、归纳总结系统所需的配置和所依赖的类库
三、 分析此子系统的架构，澄清其中各个模块之间的依赖关系
1、 包括业务模块之间的依赖关系，以及Web模块和EJB模块等程序模块之间的依赖关系等。
2、 如果应用程序中存在过多的交叉引用关系，可以考虑在一定程度上调整系统的架构和文件组织结构，尽量避免模块之间的交叉调用。
3、 一定要避免运行在同一个JAVA虚拟机的多个模块中包含相同JAVA 类或类库的多个副本。
四、 将这个剥离出来并重新调整过的子系统打包，并在原有的J2EE 服务器上验证其可用性
1、在原有J2EE服务器上能够单独运行此子系统
2、将系统的配置和所需的类库，针对WebSphere重新规划，为了能够有效地完成这一步骤，我们必须先熟悉WebSphere的基本概念，包括WebSphere classloader的体系结构，参见参考文档2。
3、测试通过的子系统打包成EAR文件，导入到WebSphere Studio Application Developer中，根据任务视图所提供的错误提示，修复所有构建时的错误。WebSphere Studio Application Developer提供了一个非常出色的错误诊断机制，可以让开发人员轻松的定位并修复应用程序中存在的错误，并且根据错误的提示，开发人员可以在J2EE规范中方便的找到相应的章节，查看详细信息
五、了解WebSphere classloader的体系结构，重新规划共享类库
1、避免共享类库在多个模块中存在副本
2、尽量提供一个移植性好的J2EE应用程序打包方案，在部署到不同的J2EE服务器时不需要做任何的改动
3、建议的方案
对于在Web模块中共享的JAR文件
将JAR文件移到WebProject/webApplication/web-inf/lib文件夹中，这样JAR文件会在构建时被自动装载并在运行时生效
对于在所有EJB模块和Web模块中共享的JAR文件
a)将JAR文件导入到EAR项目的根目录当中;
b)在EJB项目和Web项目中通过修改Manifest文件来添加对JAR文件的依赖关系。
注意：不推荐通过J2EE应用服务器的CLASSPATH来添加JAR文件，这样会降低应用程序的可移植性。要避免同时包含JAR文件的不同版本，如果原来系统里包含多个版本，则只保留其中一个即可。
六、调试子系统
1、先利用WebSphere Studio Application Developer的通用测试客户机(UTC)对服务器端的EJB进行调试
2、客户端应用程序和服务器端应用程序对接，调试客户端程序
七、将子系统导出为EAR文件，发布到WebSphere应用程序服务器中，进行测试
八、估算移植剩余子系统的工作量，分工完成
九、集成测试