级别： 初级 Wayne Beaton, 高级软件顾问, IBM Software Services for WebSphere
2004 年 7 月 01 日 本文是关于在 IBM® WebSphere® Application Server 不同版本之间迁移的高级检查表。它能帮助您在应用和环境相关的领域工作，进而帮助您进行成功的迁移。
引言
尽管在 IBM WebSphere Application Server 不同版本之间的迁移仍然不是平常的事情，但是这已经变得越来越简单了。WebSphere Application Server Version 5.x 上可以运行为 4.0 创建的应用程序，但其实应用程序兼容性只不过是迁移过程中的一部分问题。
我们容易从狭隘的角度理解迁移，然而这样是危险的。应用程序开发人员常倾向于认为迁移只是对应用程序代码的修改，管理人员考虑的主要是产品的运行时。实际上，迁移应该从更广义的角度来理解，其领域应该扩展到包括开发运行时环境、开发人员和管理人员的技能等等。
对于大多数使用 WebSphere Application Server V4.0 的组织来说，迁移到 V5.x 版并不是特别难，但这却是一个繁琐的流程。因此，在开始迁移的时候，对此流程尽可能了解、对于开始之前需要做什么事情有足够的估计，将是至关重要的。
本文之所以被组织成一个高级检查表，是想作为一个工具来帮助您充分掌握成功迁移所涉及的领域。
版本兼容性
WebSphere 5.x 产品家族提供了很多向后兼容性。WebSphere Studio Application Developer 5.x 版对 J2EE 1.2 和 1.3 应用程序的开发都提供支持。事实上，它还可以和 WebSphere Application Server 4.0、5.0，以及 5.1 版的运行时测试环境一起安装。此外，在 WebSphere Application Server V5.x 上，J2EE 1.2 和 1.3 应用程序都可以运行。
图 1 说明了 WebSphere Studio 不同版本的使用方式。（在写本文时，WebSphere Studio Application Developer 5.1.1 版已经可以使用了。建议使用此版本来进行所有的 WebSphere 开发。）
图 1. WebSphere Studio V5.1 可以用来创建 WebSphere Application Server V4 和 V5 的应用程序
为 WebSphere Application Server V4.0 开发和封装的应用程序代码，一般不用修改就可以在 WebSphere Application Server V5.x 上运行。图 2 显示了可能和 5.x 版有关的一些配置。一个 WebSphere Application Server V5.x 实例可以同时运行 J2EE 1.2 和 1.3 应用程序。
图 2. WebSphere Application Server V4 只能运行 J2EE 1.2 应用程序，在 V5 版上，J2EE 1.2 和 1.3 应用程序将都可以运行
如图 2 所示，在 WebSphere Application Server V5.1 上运行 J2EE 1.2 应用程序完全有效。这意味着可以只升级您的运行时环境而不需升级您的应用程序。您也可以只升级那些需要使用 5.1 版特有功能的应用程序，而保持其他应用程序的当前状态。
更好的是，J2EE 1.3 Enterprise Application Archive (EAR) 文件可以包含 J2EE 1.2 模块（如图 3）。这意味着，如果需要升级到 J2EE 1.3，可能只需要升级那些需要升级的部分。实际上，EJB 2.0 模块定义 EJB 1.1 bean 是很灵活的。如果必要，您可以升级部分，而不是所有的 bean 以利用特有功能。
图 3. J2EE 1.2 模块可以被部署在 J2EE 1.3 企业应用程序中
在 WebSphere Application Server V4.0 和 V5.1 之间，一个重要的改动是 Java 版本支持。WebSphere Application Server V5.1 运行在 JDK 1.4 上。在这个新版本里，Java 语言发生了很多的变化，在一些非常特殊的情况下，这些改动将影响您的应用程序（例如，JDK 1.4 包含的 XML 实现可能会和您应用程序使用的 XML 库冲突）。在大多数情况下，这些改动将没有任何影响。在某些情况下，使用 JDK 1.4 编译器重新编译应用程序代码将是解决迁移相关问题的简单方法。然而，在极少的情况下，将需要对应用程序代码或封装结构进行改动。
版本之间的兼容性并不包括对运行时环境的管理。应用服务器的管理方式已经发生了巨大的变化。WebSphere Application Server V4.0 管理域（domain）时所依赖的管理数据库已经不复存在，取而代之的是在 WebSphere Application Server V5.x 中的 XML 配置文件。甚至术语也已经发生了变化，域已经被单元所取代。
迁移路线
迁移必须考虑企业应用程序所有权的各个方面。从高层次来看，您的迁移计划应该包括如下领域：
以下部分将提供每个领域的详细情况。
迁移评估
全面的评估是迁移成功的关键要素。评估一般情况下需要 5 到 10 天，而且要由熟悉 WebSphere Application Server V5.x 和 WebSphere Studio 的人来做。评估总的目标是发现会影响迁移过程的问题，以保证有足够的资源使迁移成功。评估的主要活动和目标包括：
-
将有关各方聚集在一起。
迁移评估是将有关各方聚集在一起的好机会。评估的一个有意思的结果常常是，不同群体之间对总体的情形获得更加清楚的理解，以及对其他领域所面临的问题也有更深入的认识。
-
检查高层次体系结构。
将有关各方聚集在一起提供了一个极好的机会从高层次来表述应用程序体系结构。通过对总体情形的更清楚的了解，评估后续部分的各阶段将可以被巧妙的安排。对高层次体系结构的检查不应该超过几个小时。
-
检查应用程序代码。
当从 WebSphere Application Server V4.0 迁移到 V5.x 时，应用程序代码通常不是主要的关注点。J2EE 1.3 规范保留了与 J2EE 1.2 的兼容，所以为部署在 WebSphere Application Server V4.0 上而创建的 J2EE 1.2 应用程序，在 5.x 版上运行时一般不需要重新创建。更确切的说，您可以直接把同一个 EAR 文件在新版本上部署。而且，应用程序代码是您应用程序很重要的一部分，因此这将是令人惊讶的。虽然大部分 J2EE 代码可以不作任何修改就运行，但是那些不严格符合规范的代码将不能正常工作。一般情况下，代码质量对迁移的复杂性不会有直接的影响。当应用程序架构需要做大的改动，或者如果代码非常难于理解时，此时迁移的复杂性就会体现出来了。对每一个应用程序，应用程序代码检查一般需要花费 1 到 2 天时间。
-
检查开发环境。
WebSphere Studio Application Developer 是与 WebSphere Application Server V5.0 开发相对应的开发环境。作为评估的一部分，应当检查当前的开发环境，以确定现有的惯例（practice）、工具和技能应该如何改变或改进，从而能在新的环境里更有效的工作。
-
评估应用程序开发技能。
软件开发人员将会从一些技能的升级中受益。现有的应用程序开发技能应当作为评估的一部分来评价，而且应当同向 J2EE 1.3 迁移所需的技能进行比较（J2EE 1.3 对 EJB 规范进行了很多的更改，对 servlet 规范进行了许多有价值的扩充）。迁移技术和工具，包括 WebSphere Studio 中附带的 J2EE Migration 向导，也必须学习。
-
检查运行时环境。
大多数组织都支持很多运行时环境，他们每一个都有不同的用途。这些环境的配置（可能包括一个或多个开发测试、系统测试、预生产和生产环境）应当作为评估的一部分被检查，以保证现有的需求、布局、配置和硬件对 WebSphere Application Server 来说是足够的。对安全需求和实现的检查是这一阶段评估的重要部分。检查运行时环境一般至少需要 1 天。
-
检查创建和部署流程。
应当检查现有的流程，以确定在转而使用 J2EE 1.3 封装和部署时需要考虑的细微差别。
-
检查和理解进度问题。
进度永远是伴随迁移的一个问题。大部分组织都有为了应付外部业务驱动而不断改变的应用程序。围绕其他发布版本（deliverable）来制订迁移计划将是一件令人生畏且特别需要耐心的任务。
-
检查测试惯例。
应当检查现有的测试惯例，以确定其覆盖范围是否足够。如果覆盖范围不足，那么测试管理可能需要增加。当迁移中遇到问题，但却没有定义完善且可靠的测试惯例，将很难知道是迁移是以前存在的问题暴露出来，还是迁移导致了问题。这将导致很难对迁移的过程和最终的成功进行评价。全面的测试策略对于企业应用程序所有者来说是十分重要的。
评估使您有机会了解您所拥有的和您需要做的，以准确的计划您的迁移进而使所需的资源能够合理的使用。
开发环境
如果您已经开始使用 WebSphere Studio Application Developer 的 5.x 版本，那么就已经处于良好的状态了。然而，如果您正在使用此产品的 4.0 版，那么您需要升级。
当最终转向 5.1.1 版时，您使用 WebSphere Studio 的方式将需要一些改变。首先，相对于 4.0 版，5.1.1 版的性能已经大大的的改进了，所以您所开发的任何旨在改进 4.0 版性能的编码或处理工作区应当重新审查（revisit）。因为有大部分的插件，此产品的观感也发生了变化。WebSphere Studio V5.x 也支持多存储类型的同时使用，这将影响您与源代码管理方案的交互方式。
您将需要一段时间来熟悉这些变化。对于没有参加过 WebSphere Studio 以前版本正规的课堂训练的开发人员，强烈推荐其参加正规的课堂训练。接受指导 对于开发人员在开发环境中获得使用产品的技能，并快速提高生产效率来说，是一条捷径。
技能
在将 J2EE 1.3 介绍给您的组织的同时，也需要新的技能。例如，EJB 2.0 包含很多重大的变化（包括消息驱动 bean，及对 CMP 实体 bean 主要的改动），现在 servlet 规范包括像 servlet 过滤器（filter）、生命周期监听器等规范。要发挥这些新技术的优势，开发经理（development leader）和架构师很可能需要花费几天时间来学习。每一个迁移计划都应该包括对开发小组的指导，以便在刚开始接触 J2EE 1.3 和 WebSphere Studio V5.x 的几周里帮助他们。
由于管理模式发生了基础性的变化，脚本和工具管理人员也将需要训练。很多 WebSphere Application Server V5.x 术语已经发生了变化，而管理数据库也被基于 XML 的配置文件取代。管理大量的 WebSphere Application Server 节点仍是一项需要有特殊技能的专业管理员来做的工作。
即使熟练的管理员也将会从正规培训中受益。一般情况下，5 天的课堂培训对于经验丰富的 WebSphere Application Server 管理员来掌握他们安装、配置和维护 WebSphere Application Server V5 时需要的信息，是足够的。
应用程序代码
作为迁移到 5.x 版的一部分，当前部署（或可部署）在 WebSphere Application Server V4.0 上的应用程序代码一般不需要改变。然而，如果要利用 WebSphere Application Server V5 的新特性，代码就必须做一些改变。例如，要使用 EJB 2.0 的功能，则现有的 EJB 项目将必须升级到 EJB 2.0。但是，这不是一个“全是或全否”的命题，因为有可能只升级某些模块而不升级其他模块。例如，要使用 servlet 过滤器，可能需要把现有的 Web 模块升级到 J2EE 1.3，但是 EJB 模块可以继续使用 J2EE 1.2 标准。您可以只升级应用程序中那些需要升级的部分而保留其他部分不变。（当然，不能保证这些应用程序会和 WebSphere Application Server 未来的版本保持兼容性，所以在（可预见的）将来的某个时间，可能还会需要进行代码迁移。）
在评估您的应用程序代码迁移的方式时，您需要考虑：
这几点将在下面讨论。
针对规范的改动
如果您的应用程序不需要使用 J2EE 1.3 规范所引进的新技术，那么不需要对它们进行升级以在 WebSphere Application Server V5.x 上运行。正如前面所提到的，即使您需要发挥这些新技术的优势，您的大部分 J2EE 1.2 代码应该可以不经过任何修改而运行。 您应该知道在 1.2 和 1.3 版之间组成 J2EE 的各个规范都已经发生了一些改动. 这些改动大部分是添加性的，包括 servlet 过滤器和消息驱动 bean 。
EJB 消息驱动 bean（对本地接口可能会有异常）发生了微小的变化，因此要使他们符合 EJB 2.0 标准，需要进行很小的改动。然而，某些改动将是根本性的。例如，根据 EJB 2.0 的介绍，对 EJB CMP 实体 bean 的定义方式进行了较大的改变。在 EJB 2.0 中，使用 EJB Query Language (EJB-QL) 需要进行 finder 查询，如果您为了使用容器管理关系（CMR）而将现有的 EJB 1.1 CMP 实体 bean 升级到 EJB 2.0 ，那么作为升级的一部分，所有的 finder 也必须升级。
要发挥 servlet 过滤器的优势，现有的 Web 项目可以升级以支持 servlet 规范的 2.3 版，而 EJB 项目可以继续使用 EJB 1.1 版本。对 servlet 规范的改动是添加性的，现有的 servlet 可以不用升级。
WebSphere Studio Application Developer Version 5.x 提供的 J2EE Migration 向导会帮助您完成将现有的 J2EE 1.2 项目迁移到 J2EE 1.3。此向导可以从 J2EE Hierarchy 视图中的弹出式菜单中打开（图 4）。
图 4. 打开 J2EE Migration 向导
此向导可以升级项目元数据（由此项目知道它们是 J2EE 1.3 项目）和部署描述符（对于 EJB 和 Web 项目），甚至对某些代码进行修改。
J2EE Migration 向导首先把 Enterprise Application 项目迁移到 J2EE 1.3。这一般会比升级部署描述符需要的时间多一点。然后向导逐步迁移作为 Enterprise Application 一部分的 EJB 项目和 Web 项目。
当迁移 EJB 组件时，向导迁移：
- CMP 持久性域映射
- IBM 专有的 EJB 1.1 CMP 关系到 EJB 2.0 容器管理关系（CMR）
- CMP 实体 bean "bean" 类
- 其他元数据。
图 5. 添加本地客户端视图
作为迁移过程的一部分，您可以为现有的企业 bean 添加本地接口。图 5 在 J2EE Migration 向导中显示了“图 5. 添加本地客户端视图”页。虽然向导使很大一部分迁移过程自动化了，但还是需要一些人工干预。把 EJB 实体 bean 升级到 EJB 2.0 需要将现有的 finder 查询手工转换成 EJB-QL。被修改过的代码可能也需要一些手工清理。同样，对于使用了 EJB 组件的代码没有做任何修改。如果您用本地接口代替了远程接口，那么客户端代码将需要进行相当大的修改。
迁移 Web 项目将比为了映射新的版本而对项目元数据和部署描述符的修改需要时间稍多一些。J2EE 1.2 servlets、JSPs 以及其他 Web 构件一般会和 J2EE 1.3 100% 兼容。
专有技术的使用
“专有技术（proprietary technology）”在本文中是指标准中没有提供的功能。以前曾经从 WebSphere Application Server V3.5 到 V4.0 迁移过的组织可能还在使用某些专有技术，这些专有技术作为 3.5 版的一部分目前还可用。这包括：Visual Composition Editor (VCE) 和 Enterprise Access Builders (EAB)。通过这些（或其他）技术所产生的代码将还可以在 WebSphere Application Server V4.0 和 V5.0 上执行，但是 WebSphere Studio 中没有对其提供编辑器支持。许多组织选择了继续使用 VisualAge for Java 来编辑这些组件。如果您也是他们中的一员，要知道 VisualAge for Java 在 2003 年 12 月以后将不再被支持，现在是完成您的迁移转到新的 WebSphere Studio 开发环境的时候了。
VCE 一般使用可视化编程来创建用户界面，现在不包含在 WebSphere Studio 之中了。WebSphere Studio 也提供窗口创建器，它提供装配窗口（通过双向传递（round tripping））所需要的一些工具。但是 WebSphere Studio 中没有可视化编程的概念（不支持各部分之间的连接）。VCE 所产生的代码是标准的 Java AWT 或 Swing 代码，它们可以不作任何修改而直接运行，也可以使用常规手段进行编辑。把 VCE 产生的代码迁移到 WebSphere Studio 时，更为费力的地方是对您的开发人员进行的再培训，而不是通常的修改代码。要进行这些修改，您的开发人员需要学习更多的有关 AWT 和 Swing 的知识。 关于 VCE 迁移的进一步信息，请参阅
参考资料中的 [winchester]。
Data Access Builder (DAB) 在 Java 语言中用来表示关系数据库表中的行。代码生成器技术在 VisualAge for Java 中运行，但是其生成的标准 Java 代码可以在 WebSphere Application Server V5.x 上不用任何修改而直接运行。然而，却不支持编辑生成的数据访问 bean，除非直接对 Java 代码进行编辑。作为长期迁移策略的一部分，或许应该使用 EJB CMP 实体 bean 来代替对数据访问 bean。
EAB 和 Common Connector Framework (CCF) 用来生成“连接器（connector）”代码以便使 Java 能够和运行在企业系统上的流程（比如 CICS、IMS 等等）进行通讯。和 DAB 一样，生成的代码可以在 WebSphere Application Server V5.0 上运行，但是在 WebSphere Studio 中却没有相应的编辑支持，除非对生成的代码进行手工修改。长期的迁移策略是，使用 WebSphere Studio Application Developer Integration Edition 将连接器迁移到 Java Connection Architecture (JCA)。有关 EAB 和 CCF 迁移的进一步信息，请参阅
参考资料中的 [searle]。
VisualAge Persistence (VAP) Builder 提供了关系数据库表和 Java 对象之间非常复杂的映射。如果与 WebSphere Application Server V4.0 一起使用，VisualAge Persistence Builder 是不推荐的，现有的代码应当迁移到 EJB CMP 实体 bean。对生成的组件同样也没有编辑支持，但是它们将可以（经过细微的修改）在 WebSphere Application Server V5.0 上运行。
第三方库
WebSphere Application Server 将第三方库和您的应用程序代码同等对待。在 WebSphere Application Server V5.0 上，由“just Java”构成的库不用做任何修改就可以继续使用。然而，许多库是依赖于特定版本的应用服务器的。使问题更为复杂的是，大多数库的提供商并不提供源代码或不允许修改他们的代码，这将使您常常需要他们提供支持。
作为迁移工作的一部分，应当联系第三方提供商，并要求他们提供与 WebSphere Application Server 兼容的声明。兼容性应该经过彻底的测试，为以防万一，在迁移周期的早期就应该寻找替代产品。
运行时环境
大多数组织拥有一套以上的运行时环境，包括开发测试、系统测试、性能和预生产。应该还有用于其他目的的其他的环境。
迁移生产运行时环境绝大多数情况下不可能是简单地关闭所有程序、安装新硬件和重新启动所有程序。对于开发测试和系统测试环境有可能是这样，但是由于其他运行时环境的限制，使得这些操作即使不是不可能的，就是不切实际的。几乎在所有的情形下，生产运行时环境迁移时必须保持运行状态。一般说来，即使是对于预生产环境，停机也是难以接受的。如果不同开发团队以不同的发布时间表开发多个应用程序，这将使得生产运行时的迁移更为复杂。在这类情形中，您可能需要在一段时间内并行的运行两个应用服务器。
可能会形成“滚动迁移（rolling migration）”，这取决于您的运行时配置。图 6 显示了一个运行时布局的例子。
图 6. 一个运行时布局的例子
在滚动迁移场景中，应用服务器以下列步骤或单独或以小组为单位进行升级：
- 选择一个或多个应用服务器节点。
- 从负载平衡器（load balancer）的路由表中将选定的节点删除（图 3）。
- 从服务中将相应节点删除（关闭）。
- 删除（或停止）WebSphere Application Server V4.0。
- 安装、配置和测试 WebSphere Application Server V5.x。
- 安装、配置和测试迁移后的应用程序代码。
- 激活升级后的节点并进行配置使其能接受外来的请求（例如，将其重新添加到负载平衡器的路由表中）。
这个流程对其余的节点依次重复进行。
图 7. 被剪切并迁移的分支
这只是一个非常简单的综述，有可能和您的具体配置不太相符。本场景假定您至少有 3 台应用服务器，提供的处理能力超过您的需求（例子中有 4 台应用服务器，可以认为这个配置提供的处理能力除了满足需求外还有 50% 的剩余）。如果您的运行时环境接近于满负荷运转，您应该考虑在滚动迁移期间为您的配置临时增加一些额外的硬件。
被迁移的第一个节点将成为新的 WebSphere Application Server V5.x “单元”中的第一个服务器。其后加入的节点将被加入这个单元中。您当前配置中的每一个 WebSphere Application Server V4.0 域，在新的配置中都很可能成为一个单元。
每一个迁移计划都应该包括回滚策略。在以上的步骤中，建议将 WebSphere Application Server V4.0 改为停止状态，而不是完全删除 4.0 版的安装，您可以改为仅仅将其关闭（在配置系统时不启动它），然后从 HTTP 服务器中删除它的插件。如果稍后的测试中发现迁移中存在问题，那么恢复原来的应用服务器实例将会相对容易一些。
如果您有多个应用程序，那么滚动迁移将会持续几周（或者甚至是几个月）。如果您只有一个应用程序，或者您所有的应用程序在运行时迁移之前已经进行了迁移，那么滚动迁移将会在大约几个小时或几天内完成。无论哪种情况下，能意识到下列情况将是至关重要的：至少在一段时间内，您必须对同时运行两个 WebSphere Application Server 版本节点的运行时环境提供支持。图 8 显示了某一次迁移的中间点。在运行时迁移过程中的这个时间点上，只有一半的节点完成了迁移。
图 8. 在运行时迁移的过程中，一段时间内互操作性是必不可少的
不同版本的混和使用隐含着一些有趣的问题。首先，如果同一个应用程序的两个不同版本运行在 WebSphere Application Server 的不同版本上，应该努力确保应用程序在用户看来是一致的。即应用程序在应用服务器不同版本上的外观和操作是相同的。如果您的应用程序使用了 HttpSession 状态，您可能得考虑引入（如果您还没这么做）服务器 “stickiness”，以保证来自特定用户的所有请求直接被引向同一个服务器实例。不幸的是，HttpSession 状态不能被不同版本的 WebSphere Application Server 所共享。这将有可能导致失败。
如果您的应用程序跨不同的层，您可能需要考虑互操作性选项。有可能会存在从运行在 WebSphere Application Server V4.0 上的 servlet 到运行在 5.x 版上的 EJB 组件之间的连接（以及反过来的情况），但是要这样做可能会导致更大的复杂性以及需要更多的配置。
上面的图 8 说明了包含应用程序数据的数据库被多个版本的 WebSphere Application Server 实例共享。这是可能的，但是也许需要使用特定 fix pack 的特定版本。作为迁移的一部分，您可以决定升级您的硬件、操作系统以及其他组件（比如 HTTP Server 和数据库）。WebSphere Application Server 对产品的需求有
详细的文档说明。
测试
在开始迁移您的生产运行时之前，应该确保您的运行时迁移计划已经在实验环境中进行了测试。迁移比仅仅安装新产品要难。需要考虑一些现有的惯例和流程。 为了利于演化到 Java Management Extensions (JMX) 标准，WebSphere Application Server V4.0 的脚本语言（WSCP，XMLConfig）在 5.x 版本中不再受支持。您现在用来管理服务器的所有脚本都需要重新审查，而且可能需要重新创建（现在还没有任何可用的工具能自动完成这个变换）。
关于运行时迁移的进一步信息，请参阅
参考资料中的 [yu]。
战略计划
当编制最适合您的组织的迁移计划时，以下几个主要领域有很大的灵活性：
掌握新技能
技能迁移的时间严重依赖于迁移其他方面的时间。对于有好几个月没有使用过这些技能的开发人员来说，安排 J2EE 1.3 培训几乎是没有什么意义的。培训以后立即安排相应的应用工作，这样的培训才是有效并且有益的。也就是说，实际的代码迁移工作应该在开发人员接受 J2EE 1.3 培训和开发环境改变后的几周之内立即开始。
同样地，管理员培训被安排在运行时迁移工作开始的几周或几天之前进行，操作人员将会从中受益很大。当然，运行时迁移也需要仔细的计划，因此培训进度也需要进行适当的调整，以适应编制和测试有效的迁移计划所需的时间。
任何培训计划都应该包括一段时间的指导，且应该由已经熟悉新平台的开发人员和管理员来进行这样的指导。
迁移开发
使用 WebSphere Studio V4.0 来开发将要部署在 WebSphere Application Server V5.x 上的应用程序是可能的。当然，这是假定这些应用程序使用的功能局限于 J2EE 1.2 所提供的范围之内。例如，如果不是所有的开发团队都能同时升级到新的开发环境，那么一些开发团队可能还在使用 4.0 版的开发工具，而他们的运行时环境已经升级到了 5.x 版本。
更好的情形是，在运行时环境之前，开发环境已经进行了很好的升级。因为 WebSphere Studio V5.x 提供了部署到 WebSphere Application Server 4.0.x 上的 J2EE 1.2 应用程序开发工具。请注意 WebSphere Studio V5.x 提供了优于以前版本的功能和性能。
开发环境升级的时间取决于开发团队的需求。如果需要 J2EE 1.3 特性，那么开发环境必须升级。如果团队只限制于交付 J2EE 1.2 版本的应用程序，那么他们可以在运行环境升级以后的很长时间里继续使用 WebSphere Studio V4.0。
迁移运行时
现有的 J2EE 1.2 的应用程序一般都可以不用任何修改而直接在 WebSphere Application Server V5.x 上运行。因此，运行时环境可以在开发环境迁移之前进行迁移，这样应用程序可以使用 J2EE 1.3 提供的新功能。或者，可以在引入基于 J2EE 1.3 的新应用程序代码的同时对运行时环境进行迁移。
在修改应用程序之前，对运行时环境进行迁移将有助于减少相当多的风险。如果运行时环境的迁移处于整个过程中靠前的位置，管理员可以将精力集中在这个单一的迁移活动上。在对代码的底层进行大的改动的同时进行运行时环境的迁移将会使问题复杂化，并且会增加该流程中的固有风险。
持续的测试
测试应当已经是您应用程序开发、发布生命周期的一部分了。迁移仅仅只是生命周期过程中的一部分，因此严格的测试应该包括在项目的各个阶段当中。
结束语
仅仅在一篇文档中很难覆盖迁移的所有方面。毫无疑问，每一个组织和应用程序都是不相同的，因而可以断定每一个迁移的经历也都是不相同的。在本文中，我们描述了许多必须作为迁移的一部分来考虑的问题。更多的关于向 WebSphere Application Server 迁移的具体技术信息，请参阅
参考资料。
迁移总是一项重大的任务。即使对您的应用程序代码不需要做任何改动，当考虑了所有的因素以后，也可以预计到迁移将会花费一定程度的时间和精力。迁移不仅仅包括代码或单一的环境。您的迁移计划应当解决从开发环境和技能到管理技能和运行时环境的每一个问题。
经过了仔细计划的迁移将有可能成为最成功的迁移。
参考资料
关于作者  | | |
Wayne Beaton是一名负责 IBM Software Group 的 Software Services for WebSphere 部分高级软件顾问。他的研究重点是将 WebSphere 的早期版本和竞争产品（包括 Visual Basic）迁移到 WebSphere Application Server 5.0。他与别人合著过两本关于迁移主题的 IBM 红皮书。Wayne 担任的各种角色使他要涉及很多有趣的领域，从 WebSphere Skills Transfer 和迁移程序到一般顾问等。Wayne 在空余时间喜欢说服别人，让他们相信极限编程、重构和单元测试真的是有用的。
|
对本文的评价
| 
