 |
 |
| ||||||||||||||
| ||||||||||||||||
|
|
| ||||||
|
WebSphere 迁移: 从 BEA WebLogic Server 到 IBM WebSphere Application Server V5.x 的迁移 | |
| |||
| ||||||
| ||||||
|
引言 J2EE 主要涉及如何编写和包装应用程序代码。应用程序代码只是企业应用软件所有权的一部分，并且往往是迁移中相对较小的部分。即使当程序代码不需要更改时，仍然还需要修改流程、脚本、环境以及最终功能，也就是说从 WebLogic Server 到 WebSphere Application Server 的迁移可能仍然还需要几个星期（或甚至几个月）。 我们容易从狭窄的角度理解迁移，然而这样是危险的。应用程序开发人员常倾向于认为迁移只是对应用程序代码的修改，管理人员考虑的主要是产品的运行时。实际上，迁移应该从更广义的角度来理解，其领域应该扩展到包括开发运行时环境、开发人员和管理人员的技能等等。 通常，迁移不是特别困难，但是它可能是一个繁琐的流程。因此，在开始迁移的时候，对此流程尽可能了解、对于开始之前需要做什么事情有足够的估计，将是至关重要的。 本文之所以被组织成一个高级检查表，是想作为一个工具来帮助您充分掌握成功迁移所涉及的领域。 迁移路线 接下来的部分将详细介绍各个领域。 迁移评估
评估使您有机会了解您所拥有的和您需要做的，以准确的计划您的迁移进而使所需的资源能够合理的使用。 开发环境 WebSphere Studio WebSphere Studio 家族的产品包括下列各项：
这些产品中的每一个都提供 J2EE 应用程序开发，并不断提高扩展支持的级别。WebSphere Studio Application Developer 提供创建、测试和部署 J2EE 应用程序所需的一切。WebSphere Studio Application Developer Integration Edition 通过使用 JCA 连接器、业务流程编排及其它功能来集成遗留系统，以扩展对 J2EE 的支持。WebSphere Studio Enterprise Developer 增加了对其他遗留的企业开发的支持，包含了其他快速应用程序开发工具。在迁移过程的前期，必须选择最适合需要的 WebSphere Studio 版本。 其它工具 作为迁移到 WebSphere Studio 的一部分，现有的资源树可能需要修改。 WebSphere Studio V5 需要按照 J2EE 封装线路 使应用程序代码结构化。例如，Web 组件必须在一个“Web 项目”里且 Enterprise JavaBeans（EJB）组件必须在一个“ EJB 项目”里。每一个项目都代表一个单独的资源树。在 SCM（在维护各种组件的的历史记录时）中修改现有的资源树将是困难的和费时的。 开发小组还可以使用其他的工具，这些工具必须评估来确定它们对 WebSphere Application Server 开发的适用性。 技能 WebSphere Application Server 的管理与 WebLogic Server 的管理差别很大。虽然许多概念是相似的，但是细节有很大区别。操作人员可能需要花费时间来学习 WebSphere Application Server 并且了解怎样配置和管理它。现有的用于管理 WebLogic Server 的脚本需要重新创建，以使其能够在 WebSphere Application Server 上运行。管理 WebSphere Application Server 节点集仍然是一项需要具有专门技能的专业管理员才能完成的任务。 即使是熟练的管理员，也会从正式的培训中受益。一般说来，5 天的课堂培训完全可以提供给经验丰富的应用服务器管理员足够的信息，以便他们掌握如何安装、配置和维护 WebSphere Application Server。 应用程序代码 在评估如何迁移应用代码中，需要考虑： 下面讨论这些要点。 代码组织 图 1. 说明了如何组织各种各样的档案文件（在 J2EE 文档中被作为模块）。 封装各个模块的是 XML 部署描述符，这个描述符描述了模块中组件的组织和在运行时如何配置它们。 WebSphere Studio 需要将应用程序代码按照 J2EE 线路来结构化。根据上面提到的，Web 组件必须放在 Web 项目里，且 EJB 构件放在 EJB 项目里。在这些项目类型中，也需要特定的目录结构。例如：Web 项目需要 Web 内容目录来包含项目所需要的全部内容（源代码除外）。 在很多情况下，部署在 WebLogic Server 上的应用程序代码是任意构造的，并且依赖创建过程来理解它。这个意味着作为迁移工作的一部分很可能必须修改现有的代码组织。这在维护代码历史记录的链接时是很难（或甚至不可能）完成。一些组织简单地选择了把代码的历史记录归档和开始更新。 针对规范的改动 Servlet 规范做了许多小的变动，可能会影响代码，这取决于 Weblogic 应用程序的年限。像方法 HttpSession#getValue(String) 已经不推荐使用，而建议使用重新命名的等价方法，如 HttpSession#getAttribute(String)。Servlet 规范最重大的变化与会话范围有关。最新版的 servlet 规范把 HttpSession 范围限制到 Web 模块。也就是说，多个 Web 模块不可能（根据规范）共享 HttpSession 数据。 在 servlet 规范以前的版本中（包括那些由老版本的 WebLogic Server 支持的规范），所有的应用程序共享单一的 HttpSession 范围。如果代码是根据该语义编写的，那么就需要修改。为了使迁移变得容易，WebSphere Application Server V5.x 提供一个转换，该转换允许将由多个 Web 模块共享的 HttpSession 状态封装到单一 EAR 文件中。为了方便，在少数情况下可以不遵从该规范。 在绝大多数情况下，将打算部署在 WebLogic Server 上的 JavaServer Pages（JSP）迁移到 WebSphere Application Server 相对比较容易。WebLogic Server 特有的标签库将被替换（这个更像是一个许可问题而不是技术问题）。WebLogic Server 与 WebSphere Application Server 之间的一个显著性差异是 WebLogic Server 的 JSP 编译器自动包含 假如 bean 符合 EJB 2.0 规范，则 EJB 代码不需要修改就能运行。WebSphere Application Server 在对 EJB 规范的一致性要求上显得更加严格，因此在迁移时可能需要注意修改 WebLogic Server 允许的对规范的轻微偏离。 因为在缺少部署 bean 所需的任何详细资料时，EJB 规范都会中止，所以重新部署 EJB 组件将是一个费时的过程。例如，规范没有提及到如何为 Java Naming 和 Directory Interface（JNDI）中的 bean 提供名字。该信息在扩展部署描述符中说明。 重新部署使用容器管理持久性（CMP）的实体 bean 需要做更多的工作。每个企业 bean 和持久字段必须重新映射到相应的数据库表和列。如果实体 bean 上的字段名与表中的列名严格匹配，那么 WebSphere Studio 的 meet-in-the-middle 映射向导能够在大约几分钟内完成这项工作。但是如果域名与列名不相匹配，就必须手工重新构造映射。该过程是费时的且如果不仔细容易出错。 虽然手工生成所需要的扩展部署描述符从理论上说是可行的，但是这么做是不切实际的。相反，应考虑使用 WebSphere Studio Application Developer 或 Application Assembly Toolkit 来创建 bean 的部署描述符。WebSphere Application Server 的 Application Assembly Toolkit（可免费下载）提供一个 WebSphere Studio 功能的子集，它专门针对 J2EE 构件的部署。 老版本的 WebLogic Server 使用专有的 WebLogic Query Language（WL-QL）来为 CMP 实体 bean 指定 finder 查询。作为迁移的一部分，需要把这些查询语句转化为 EJB Query Language（EJB-QL）。 Servlet、JSP 和 EJB 组件构成了迁移工作的大部分。 专有技术的使用 或许专有技术最常见的例子就是所谓的“t3”服务，其中最受欢迎的就是用于 RMI 与 EJB 组件通信的 t3 协议。通常，替换该协议意味着产生 WebSphere 特定的 EJB 部署代码，并且在用于 JNDI 初始上下文结构的统一资源定位符（URL）中用 第二个最常用的 t3 功能是 T3StartupDef，它用于提供应用服务器启动时运行的代码。该代码在 WebSphere Application Server 上不能运行，所以应该被更换。更多的关于迁移 WebLogic Server 启动代码的信息，请参阅 将 WebLogic 启动代码迁移到 WebSphere Application Server 5.0。 WebLogic Server 特有的优化技术对于 WebSphere Application Server 来讲是没有作用的。性能调整练习会帮助您确定怎样更好的配置 WebSphere Application Server 来满足所需的性能。 第三方库 作为迁移工作的一部分，应当联系第三方提供商，并要求他们提供与 WebSphere Application Server 兼容的声明。兼容性应该经过彻底的测试，为以防万一，在迁移周期的早期就应该寻找替代产品。 迁移工具 如果应用程序符合 J2EE 1.2 规范（包括 EJB 1.1），那么出色的 WL2WAS 工具就能够提供重要的帮助。一旦 J2EE 1.2 应用程序迁移部署到 WebSphere Application Server 上，就容易被导入到 WebSphere Studio Application Developer 中，这时就可以利用 J2EE Migration Wizard 来完成向 J2EE 1.3 的迁移。关于 WL2WAS 的更多信息，请参阅 将 BEA WebLogic Server 应用程序迁移到 IBM WebSphere Studio 和 WebSphere Application Server。 其它问题 在不同包或项目中类之间的循环引用通常被认为是不好的编程习惯（这些类在不同组件之间构成了紧耦合）。当在不同项目之间发现引用循环时，WebSphere Studio 的创建流程将会停止（可以改变配置使其继续下去）。创建流程在创建单一树的代码时不存在依赖问题，且也不会影响其结构。关于处理循环依赖的更多帮助，参见 经验学习：将 WebLogic Server 应用程序迁移到 WebSphere Studio。 运行时环境 迁移生产运行时环境绝大多数情况下不可能是简单地关闭所有程序、安装新硬件和重新启动所有程序。对于开发测试和系统测试环境有可能是这样，但是由于其他运行时环境的限制，使得这些操作即使不是不可能的，就是不切实际的。几乎在所有的情形下，生产运行时环境迁移时必须保持运行状态。一般说来，即使是对于预生产环境，停机也是难以接受的。如果不同开发团队以不同的发布时间表开发多个应用程序，这将使得生产运行时的迁移更为复杂。在这类情形中，您可能需要在一段时间内并行的运行两个应用服务器。 可能会形成“滚动迁移（rolling migration）”，这取决于您的运行时配置。图 2 显示了一个运行时布局的例子。 在滚动迁移场景中，应用服务器以下列步骤或单独或以小组为单位进行升级：
这个流程对其余的节点依次重复进行。 这只是一个非常简单的综述，有可能和您的具体配置不太相符。本场景假定您至少有 3 台应用服务器，提供的处理能力超过您的需求（例子中有 4 台应用服务器，可以认为这个配置提供的处理能力除了满足需求外还有 50% 的剩余）。如果您的运行时环境接近于满负荷运转，您应该考虑在滚动迁移期间为您的配置临时增加一些额外的硬件。注意本场景中，在迁移时将单一的 HTTP 服务器作为单一的故障点。从而极大的增加了迁移时的风险。在理想情形下，至少应该保持 3 个 HTTP 服务器可用，从而转移风险。 每一个迁移计划都应该包括回滚策略。在以上的步骤中，建议将 WebSphere Application Server V4.0 改为停止状态，而不是完全删除 4.0 版的安装，您可以改为仅仅将其关闭（在配置系统时不启动它），然后从 HTTP 服务器中删除它的插件。如果稍后的测试中发现迁移中存在问题，那么恢复原来的应用服务器实例将会相对容易一些。 如果您有多个应用程序，那么滚动迁移将会持续几周（或者甚至是几个月）。如果您只有一个应用程序，或者您所有的应用程序在运行时迁移之前已经进行了迁移，那么滚动迁移将会在大约几个小时或几天内完成。无论哪种情况下，能意识到下列情况将是至关重要的：至少在一段时间内，您必须对同时运行两个 WebSphere Application Server 版本节点的运行时环境提供支持。图 4 显示了某一次迁移的中间点。在运行时迁移过程中的这个时间点上，只有一半的节点完成了迁移。 图 4.在运行时迁移期间，在某段时间内的协同工作能力是必不可少的 不同版本的混和使用隐含着一些有趣的问题。首先，如果同一个应用程序的两个不同版本运行在 WebSphere Application Server 的不同版本上，应该努力确保应用程序在用户看来是一致的。即应用程序在应用服务器不同版本上的外观和操作是相同的。如果您的应用程序使用了 HttpSession 状态，您可能得考虑引入（如果您还没这么做）服务器 “粘度（stickiness）”，以保证来自特定用户的所有请求直接被引向同一个服务器实例。不幸的是，HttpSession 状态不能被不同版本的 WebSphere Application Server 所共享。这将有可能导致失败。 如果您的应用程序跨不同的层，您可能需要考虑互操作性选项。有可能会存在从运行在 WebLogic Server 上的 servlet 到运行在 WebSphere Application Server V5.0 上的 EJB 组件之间的连接（以及反过来的情况），但是这个这样做会增加复杂性和不允许的相关风险。 图 4 显示了一个包含 WebLogic Server 和 WebSphere Application Server 两者共享的应用程序数据的数据库。这是有可能的，但是需要应用一个具有特有 fix pack 的特定版本。作为迁移的一部分，您可以决定升级您的硬件、操作系统和其它组件（如 HTTP 服务器和数据库）。WebSphere Application Server 对产品需求有详细的文档说明。 测试 其它的场景在 迁移到 WebSphere V5.0：端到端的迁移指导中详细介绍。 结束语 迁移总是一项重大的任务。即使对您的应用程序代码不需要做任何改动，当考虑了所有的因素以后，也可以预计到迁移将会花费一定程度的时间和精力。迁移不仅仅包括代码或单一的环境。您的迁移计划应当解决从开发环境和技能到管理技能和运行时环境的每一个问题。 经过了仔细计划的迁移将有可能成为最成功的迁移。
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
