WebSphere 迁移: 从 WebSphere Application Server Community Edition 迁移到其他 WebSphere Application Server 产品的原则和计划

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

Shyam Nagarajan (shyam@us.ibm.com), 认证 IT 咨询专家 , IBM

2006 年 1 月 01 日

学习如何利用这种高级清单将应用程序从 IBM® WebSphere® Application Server Community Edition 迁移到 IBM WebSphere Application Server Base，这有助于您处理与应用程序和环境有关的主要方面，从而确保迁移成功。

引言

IBM WebSphere Application Server Community Edition 是一个基于 Apache Geronimo 开放源代码应用程序服务器项目的应用程序服务器平台。WebSphere Application Server Community Edition（以下称为 Community Edition）包括一组核心功能和服务，以及由其他开放源代码项目提供的一些重要服务，它们一起提供 J2EE™ 应用程序服务器平台。

下表详细描述了集成到 Apache Geronimo（详细信息，请参阅参考资料）中的开放源代码项目：

作为 WebSphere 软件平台的基础，IBM WebSphere Application Server V6.0 是业界重要的基于 Java™ 的应用程序平台，可以根据业务的动态要求集成企业数据和事务。每种 WebSphere Application Server 配置都提供了丰富的带有应用程序服务的应用程序部署环境，这些服务提供了用于事务管理的增强功能，以及 WebSphere 产品所需的安全性、性能、可用性、连接性和可伸缩性。图 1 显示了 WebSphere Application Server 产品的概览。

对于客户来说，WebSphere Application Server Community Edition 是一个非常实用和有益的平台，使用该平台，他们无需支付任何许可费用即可快速开始进行 J2EE 应用程序开发。最后，如果开发团队希望在 Community Edition 之外的平台上集成、测试和扩展他们的应用程序，他们可以采取迁移到其他 WebSphere Application Server 产品的方式。

实际上，由于所有的 WebSphere Application Server 产品，包括 Community Edition，都支持 Java 2 Enterprise Edition (J2EE) 规范，因此尽管在迁移过程中有些方面需要给予特别关注，但从 Community Edition 迁移到其他 WebSphere Application Server 产品相对来说还是比较容易的。

J2EE 主要关注如何编写和打包应用程序代码；应用程序代码只是企业应用程序所有权的一部分，并且往往是迁移工作中相对较小的一部分。任何迁移都将带来开发团队中过程、环境、技能和文化方面的变化。

狭义地考虑迁移非常容易，但这样做却非常危险。应用程序开发人员常常倾向于只从更改应用程序代码方面考虑迁移，而管理员主要从运行时环境方面考虑。相反，应当从更广的方面来考虑迁移，并且必须（至少）考虑以下几方面：

• 开发环境
• 开发人员技能
• 要求和建议对应用程序代码的更改
• 管理员技能
• 运行时环境。

通常，迁移不是特别困难，但却是个漫长的过程。因此，开始迁移时尽可能开阔视野并且在开始之前充分估计需要做的工作，这非常重要。

本文是按照高级检查表的形式组织的，并旨在作为一个工具来帮助您充分考虑进行成功迁移所需了解的各个方面。在本文档的其余部分：

• Community Edition 指的是 WebSphere Application Server Community Edition。
• WebSphere Application Server 指的是 WebSphere Application Server – Express、WebSphere Application Server Base 和 WebSphere Application Server Network Deployment。

回页首

迁移计划

迁移必须考虑企业应用程序所有权的各个方面。概括地讲，迁移计划应当包括以下几个方面：

• 迁移评估
• 开发环境
• 技能
• 应用程序代码
• 运行时环境。

下面将详细讨论这各个方面。

回页首

迁移评估

综合评估是成功迁移的一个关键因素。评估的总体目标是发现可能影响迁移过程的问题，这样可以利用充足的资源来确保迁移成功。评估的主要活动和目标包括：

• 将相关部分集中在一起。
  迁移评估是将相关部分集中在一起的好机会。有意义的评估结果通常是对各组的总体情况有了更清楚的了解，并且更多地了解了其他方面的问题。

• 检查高级体系结构。
  将相关部分聚合在一起是在更高的层次上了解说明应用程序体系结构的极好机会。对总体情况的了解越清楚，对随后的评估过程的认识就越清晰。

• 检查应用程序代码。
  毫无疑问，检查应用程序代码肯定是评估过程的一部分。这不是对代码进行全面检查；相反，在迁移评估阶段，对代码的检查通常只关注是否发现使用任何非 J2EE 兼容代码的情况。一般来说，代码质量不会对迁移的复杂性有直接的影响。只有在需要重新对应用程序的体系结构进行重大更改或者当复杂性使得理解代码非常困难时，复杂性才会有所影响。

• 检查开发环境。
  当迁移到 WebSphere Application Server V6.0 时，一般也习惯于使用 WebSphere 开发工具，例如 IBM Rational® Application Developer for WebSphere Software V6.0。但是，如果保留现有的开发环境，可能需要改变当前的一些开发方式。作为评估的一部分，应当检查当前的开发环境以确定如何调整现有开发方式、工具和技能，从而基于 Rational Application Developer 构建新的开发环境。

• 评估应用程序开发技能。
  现有的应用程序开发技能应该作为评估的一部分。即使软件开发人员熟悉 J2EE，也需要提高某些技能，以使自己熟悉 J2EE、WebSphere Application Server 和新的开发环境。

• 检查运行时环境。
  大多数组织支持许多运行时环境，每种环境有不同的作用。这些环境（可能包括一种或多种开发测试、系统测试、预生产和生产环境）的配置应该作为评估的一部分，以确保现有要求、拓扑、配置和硬件适合 WebSphere Application Server。检查安全要求和实现是这一阶段评估的重要部分。

• 检查构建和部署过程。
  应当检查现有过程以确定 WebSphere Application Server 要求进行哪些方面的更改。可能需要更改现有构建脚本。必须编写新脚本来代替过去用于管理应用程序服务器的脚本。

• 检查和了解计划问题。
  对于迁移，计划总是一个问题。大多数组织的应用程序经常会在外部业务的驱动下进行一些改变。根据其他可交付产品实施迁移计划是一项繁重的工作，需要引起我们特别的关注。

• 检查测试方法。
  应当检查现有测试方法以确定它们是否提供了足够的覆盖范围。如果没有提供足够的覆盖范围，则可能需要增加一些测试方法。如果在迁移期间遇到问题，并且没有良好定义的可靠测试方法，通常很难知道迁移是否是一种暴露先前存在的问题的催化剂，或者迁移是否是问题的真正根源。这使得难以估计迁移的进度，并使迁移最终难以成功。全面的测试策略是企业应用程序所有权非常重要的一部分。

评估为您提供了了解您所拥有的、所需要做的以及正确计划迁移的机会，以便准备好所需资源。

回页首

开发环境

开发环境是迁移过程中要解决的首要环境之一。开发人员需要熟悉 IDE 和测试环境，以便高效地调试他们的应用程序。

Eclipse

为了与开放源代码的趋势保持一致，当今 Java 开发人员使用的最流行的开发环境是 Eclipse 3.1。Eclipse 是一种开放源代码 IDE 平台，使用该平台，可以通过插件轻松地进行扩展，而 Eclipse 组织鼓励基于 Eclipse 框架构建商业产品。IBM 提供了一种用于 Eclipse Web Tools Platform (WTP) 的插件，以便在 Community Edition 上测试和调试应用程序。

有关利用 Eclipse 在 Community Edition 上部署和测试应用程序的更多信息，请参阅 How to use the new Eclipse plug-in for Geronimo。

Rational Application Developer

IBM Rational Application Developer V6.0 是构建 WebSphere Application Server 应用程序的最合适的开发环境。Rational Application Developer 利用 Eclipse 技术构建应用程序，并以 Eclipse 提供的工具为基础，从而提供了一种进行 J2EE 开发的完善环境。Rational Application Developer 是一种开放的、可插入环境，旨在用于各种开发，包括用于构建和编辑 Java、J2EE 和 Web 站点内容（HTML、图像和其他资源）的组件。

图 4 显示了 Rational Application 系列产品的高级视图。

Rational Developer 产品、Rational Web Developer 和 Rational Application Developer，都为 J2EE 应用程序开发提供了不断增加的扩展支持级别。Rational Application Developer 提供构建、测试和部署 J2EE 应用程序所需的一切。在迁移过程的初期，必须选择最适合您需要的开发工具。

从 Eclipse 迁移到 Rational Developer 产品

熟悉 Eclipse 并且最初使用基于 Eclipse 构建的 Rational Developer 产品的用户将会很快习惯利用新工具执行应用程序开发和部署任务。来自 Eclipse J2EE 环境的代码可以作为 EAR/WAR 和 JAR 文件导出，并且可以轻松导入到 Rational Web 或 Application Developer 中，以便继续进行开发。（将不保存项目依赖项和 Eclipse 构建路径，可能需要在 Rational 环境中重新配置它们。）

团队

Rational Developer 产品支持许多软件配置管理 (SCM) 解决方案，包括 Rational ClearCase、Concurrent Versions System (CVS) 和其他使用供应商提供的插件的解决方案。作为迁移到 Rational 的一部分，如果现有的源代码树遵循 J2EE 打包结构，就不必修改它们。

构建过程

如果利用 Ant/Project Maven 来构建应用程序并将其打包到 EAR/WAR/JAR 文件，则可以集成 WebSphere Application Server 提供的一组预构建 Ant 任务并将其用于 RMIC 生成和自动部署集成。WebSphere Application Server 信息中心有更多关于利用 Ant 任务自动构建的信息。

回页首

技能

Rational 工具与其他开发环境不同，为了高效地使用该产品，开发人员需要花一些时间来掌握全面的技能。即使真正聪明的人也应当接受 IBM Rational Web 或 Application Developer 培训，以充分利用这些产品提供的强大功能。一般情况下，对于已经熟悉企业应用程序开发的应用程序开发人员而言，5 天的课堂培训就已足够了。

管理 WebSphere Application Server 与管理 Community Edition 有很大的不同。虽然许多概念是类似的，但细节却大不相同。操作人员需要花一些时间来学习 WebSphere Application Server，并了解如何对其进行配置和管理。需要重新构建用来管理 Community Edition 的现有脚本，以便将其用于 WebSphere Application Server。

管理一组 WebSphere Application Server 节点仍然是一项需要具有专业技能的任务，必须由专门的管理员负责。即使是熟练的管理员也会从正规培训中受益。一般情况下，5 天的课堂培训就足以使经验丰富的应用程序服务器管理员了解安装、配置和维护 WebSphere Application Server 所需的信息。

回页首

应用程序代码

只要应用程序遵循 J2EE 规范，就无需对作为迁移的一部分的应用程序代码进行重大更改。在大多数情况下，“Just Java”应用程序代码应当在两种产品上都可以运行。大多数控制和业务逻辑很可能都属于这类情况。大多数 Java 代码无需更改就可以迁移。由于 Community Edition 和 WebSphere Application Server 兼容 J2EE 1.4，因此对 servlet、JSP 和 EJB™ 组件之类的 J2EE 构件就不必进行任何更改。

但是，J2EE 中的其他部分需要给予更多的关注，例如：

• 代码组织
• 部署描述符
• 安全性
• JNDI
• EJB (CMP) Bean 迁移
• 第三方库和框架。

下面将讨论这几点。

代码组织

J2EE 定义了一种非常特殊的打包结构，它将不同的构件分别存放到不同的归档中。Web 构件，包括 servlet、JSP 和 Web 内容（如 GIF 和 JPEG 文件），都打包到一个 Web Archive (WAR) 文件中。EJB 构件一般由 EJB 类型组成，被打包到一个 EJB-JAR (JAR) 文件中。Enterprise Archive (EAR) 文件用来将所有的应用程序组件（WAR 和 JAR）文件集合到一个文件中。应用程序使用的其他库（JAR 文件）也可以位于 EAR 文件中。归档还可以包括应用程序客户机归档 (JAR)，它是另一种 J2EE 模块类型。

图 5 说明了如何组织各种不同的归档（在 J2EE 文档中也称作模块）。

每个模块都有一个 XML 部署描述符。该部署描述符说明模块中组件的组织以及在运行时如何配置它们。

Rational Application Developer 要求按照 J2EE 的方法来组织应用程序代码。正如前面所提到的，必须将 Web 构件放置在一个 Web 项目中，将 EJB 构件放置到一个 EJB 项目中。在这些项目类型中，还需要一种特定的目录结构。例如，Web 项目必须有一个包含所有项目内容（除了源代码之外的所有内容）的 Web 内容目录。

如果以某种方式组织代码，使构建过程将不同模块捆绑到 J2EE 构件中，那么这可能表明，作为迁移工作的一部分，必须更改现有的代码结构。

部署描述符

所有的应用程序都需要标准 J2EE 部署描述符（如 web.xml、ejb-jar.xml 等），以便在 J2EE 容器中定义组件和操作参数。除了这些部署描述符之外，还有特定于应用程序服务器的部署描述符，有些应用程序需要在容器内运行它们。特定于应用程序服务器的部署描述符不遵循任何标准，因此它们随着 J2EE 容器的不同而不同。

下表列出了 Community Edition 和 WebSphere Application Server 所使用的部署描述符：

扩展部署描述符（在 Geronimo 领域中也称为部署计划）提供了有关应用程序和容器的更多信息。通过将应用程序导入到 Rational Application Developer 或 Application Server Toolkit (ASTK) 中，可以轻松地将这些扩展部署描述符迁移到 WebSphere Application Server 特定的容器中。

安全性

Community Edition 利用在 JVM 中执行的基于 JAAS 的安全性，并且没有服务器范围内的缺省安全领域配置。可以配置任意数量的安全领域，并且每个应用程序模块都必须在其部署计划中指定要使用的安全领域的名称。这限制了进行单点注册以及将标识传播到下游服务器的能力。安全领域利用 JAASLoginModules 进行实施，JAASLoginModules 提供了提示用户输入用户名和密码以及利用该用户的主体创建 JASS 主题的功能。

Community Edition 附带了最常用的 LoginModules 以执行下列功能：

• 根据存储在磁盘文件中的用户与组列表进行身份验证。
• 根据存放用户与组的数据库进行身份验证。
• 通过 Kerbero 进行身份验证。
• 通过 SSL 客户机证书进行身份验证，其中属性文件将证书名称映射到用户与组。

所有的安全领域都可以通过部署计划进行配置。有关 Geronimo 安全性的信息也适用于 Community Edition。

WebSphere Application Server 提供了一个缺省安全领域，可以对其加以设置并在整个服务器中进行使用。WebSphere 管理和应用程序安全身份验证与授权之间可以共享同一个领域。WebSphere Application Server 遵循 JAAS 标准，并且 Login 模块可以很容易地插入到应用程序服务器中，因此可以非常方便地对其进行访问。安全领域由四种类型的 UserRegistry 实施：

• FileBasedUserRegistry
• LDAPUserRegistry
• LocalOSRegistry
• CustomUserRegistry。

顾名思义，用户注册表用于进行基于磁盘的、LDAP 和本机操作系统身份验证。更复杂的安全要求可以通过 CustomUserRegistry 加以解决。有关编写自定义用户注册表的更多信息，请参阅 WebSphere Application Server Information Center。

此外，如果已经编写了自己的 JAASLoginModule，则可以通过管理控制台或脚本来配置它们，从而可以在 WebSphere Application Server 中使用相同的 JAASLoginModule。信息中心还有更多关于 configuring JAAS Modules within WebSphere Application Server 的信息。

安全实现中的更改并不保证应用程序代码本身的任何更改，因为它们都是由采用 JAAS 标准的 J2EE 容器执行的。

JNDI

一般情况下，对于所有的应用程序服务器，Community Edition 和 WebSphere Application Server 的 JNDI 上下文工厂是不同的。如果应用程序中的所有 JNDI 查找都是本地上下文查找（包含在同一 EAR 中），那么这不会影响应用程序代码。WebSphere Application Server 使用上下文工厂 com.ibm.websphere.naming.WsnInitialContextFactory，并且也将要求 J2EE 应用程序客户机程序在 WebSphere J2EE 客户机容器中运行以利用 WebSphere Application Server 的所有功能。

有关利用 WebSphere J2EE Application clients 进行开发的更多信息，请参见信息中心。

EJB (CMP) Bean 迁移

Community Edition 使用 OpenEJB 作为它的 EJB 容器，使用 Castor JDO 作为它的 CMP 实现机制。虽然 EJB 实现遵循 J2EE 1.4 与 EJB 2.1 标准，但容器的内部工作方式却大不相同——特别是 Entity CMP Bean，它利用扩展部署描述符给对象提供数据库映射信息。通过使用映射文件，WebSphere Application Server 具有类似于从 CMP Bean Java 对象映射到数据库的方式，而这些映射文件可以使用 Application Server Toolkit 或 Rational Application Developer 生成。有关 using Container Manager Persistence within WebSphere Application Server 的更多信息，请参见信息中心。

如果使用外部持久性机制，例如 Hibernate 或 iBatis，则无需进行任何更改就可以保留持久性模型，并通过将依赖库部署为应用程序的一部分而在 WebSphere Application Server 中运行它。

第三方库与框架

WebSphere Application Server 将第三方库和应用程序代码一样看待。由“Just Java”代码组成的库无需修改就可以在 WebSphere Application Server 上继续运行。但是，许多库确实与依赖库的特定版本（例如 Xerces 或 Xalan）相关。作为迁移工作的一部分，要求第三方库或框架能够在 WebSphere Application Server 中兼容工作。在迁移过程的初期，如果需要寻求备选方案，则应当彻底地测试兼容性。

回页首

运行时环境

安装、管理和控制

Community Edition 用于引导开发团队和敏捷企业快速进入应用程序开发和部署过程。可以在几分钟之内安装并运行（包括下载）Community Edition。Apache Geronimo 项目的部分吸引力在于能够自定义运行时以适应部署在服务器上的应用程序。还可用一个简单的管理控制台来查看应用程序的当前状态和管理应用程序服务器内的运行组件。

安装 WebSphere Application Server 的工作量比较大。安装大型企业应用程序可能需要一些时间，并且需要熟练的人员来完成。WebSphere Application Server Base 可以即装即用，很少或根本不需要调试就可以开始运行企业应用程序。WebSphere Application Server Network Deployment 具有支持在一个单元内进行集群和中心应用程序/服务器管理的功能。任何与管理和控制相关的任务都可以通过基于 Web 的管理控制台或 wsadmin 脚本完成。有关安装与管理的更多信息，请参见信息中心。

只要 Community Edition 与 WebSphere Application Server 使用的端口不冲突，这些服务器就可以共同安装在同一台物理服务器上。运行时进程是单独的 JVM，并且只要物理服务器具有足够的内存和硬盘空间，它们就可以相互并行运行。

运行时迁移

当提到运行时环境时，大多数人会首先想起生产环境，但应当认识到运行时环境并不止这些；它还包括开发测试、系统测试、性能和预生产测试。考虑到许多开发人员和企业都可能利用 Community Edition 作为他们的测试平台，因此考虑迁移运行时环境的策略非常重要。

正如前面所提到的，最简单的运行时迁移方法是 Community Edition 和 WebSphere Application Server 共存于相同的硬件之上，直到开发和测试团队熟悉了他们正在迁移的新系统为止。一旦用于部署到 WebSphere Application Server 的新过程就绪，就可以关闭 Community Edition 并将其从系统中删除（如果需要）。

生产环境也可以遵循相同的方法。此外，共存策略假定没有端口冲突并且物理系统能够支持在同一机器上同时运行两个服务器或进程。

在决定构建 WebSphere Application Server 环境之前，团队应当熟悉不同 WebSphere 部署拓扑，这些 WebSphere 部署拓扑将确保应用程序具有最佳的高可用性和可伸缩性选项。要了解更多有关选择适当网络拓扑的信息，请参阅红皮书 WebSphere Application Server Network Deployment V6:High Availability Solutions。

回页首

结束语

从 WebSphere Application Server Community Edition 迁移到其他的 WebSphere Application Server 系列产品相对来说比较简单，但必须要谨慎进行。每个组织和应用程序都各不相同，因此迁移体验也将不同。本文概述了从 WebSphere Application Server Community Edition 迁移到 WebSphere Application Server Base 或 Network Deployment 需要考虑的基本问题。随着组织和应用程序数量与复杂性的不断增加，自然要走迁移途径，可扩展的、高可用性和功能齐全的平台越来越成为成功实现业务目标的竞争要求。

首先进行周密计划才最有可能使迁移成功。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Geronimo 专题
  
  
• Getting started with Apache Geronimo
  
  
• 发挥 Tomcat 在 Geronimo 中强大功能
  
  
• 了解 Geronimo 的部署架构
  
  
• WebSphere Application Server 6.0 Information Center
  
  
• IBM Rational Developer:Powerful support for rapid Java and J2EE development
  
  
• WebSphere Ant task reference
  
  
• WebSphere Ant API reference

关于作者

		Shyam Nagarajan 是 IBM WebSphere 软件服务部高级技术实践组的一位认证 IT 咨询专家。他目前专注于将竞争平台和早期版本迁移到 WebShpere Application Server 和 Web 服务上。以前，Shyam 为基于 Java 的迁移开发了自动解决方案，并撰写和发表了几本关于该主题的白皮书。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首