从 BEA WebLogic Server 到 IBM WebSphere Application Server V5.x 的迁移

jialiguo

		中国 [ 选择]     使用条款 dW 全部内容 -----------------   DB2   Lotus   Tivoli   WebSphere -----------------   Java 技术   Linux   Open source   Security   SOA & Web services   Web architecture   Wireless   XML ----------------- IBM 全部内容
首页     产品     服务与解决方案     支持与下载     个性化服务

developerWorks 中国 > WebSphere >

	WebSphere 迁移: 从 BEA WebLogic Server 到 IBM WebSphere Application Server V5.x 的迁移

内容： 引言 迁移路线 迁移评估 开发环境 技能 应用程序代码 运行时环境 测试 结束语 参考资料 关于作者 对本文的评价 相关内容： developerWorks 迁移专题 WebSphere Application Server 迁移资料 从 WebSphere Application Server V4.0 到 V5.x 的迁移 订阅: developerWorks 时事通讯 　　级别: 中级 　　Wayne Beaton 高级软件顾问, IBM Software Services for WebSphere 2004 年 7 月 从 BEA® WebLogic® Server 到 IBM® WebSphere® Application Server 的迁移相对容易，但是可能会遇到一些难题。本高级迁移检查表能够充分帮助您处理主要的相关应用程序和环境，这些是成功迁移所必需的。 　　引言 BEA WebLogic Server 的近期版本，如 WebSphere Application Server V5.x，支持 Java™ 2 Enterprise Edition（J2EE）规范。尽管在没有遇到难题时，可以允许不符合规范，但是严格遵照规范会使从 WebLogic Server 到 WebSphere Application Server 的迁移变得相对容易。 　　J2EE 主要涉及如何编写和包装应用程序代码。应用程序代码只是企业应用软件所有权的一部分，并且往往是迁移中相对较小的部分。即使当程序代码不需要更改时，仍然还需要修改流程、脚本、环境以及最终功能，也就是说从 WebLogic Server 到 WebSphere Application Server 的迁移可能仍然还需要几个星期（或甚至几个月）。 　　我们容易从狭窄的角度理解迁移，然而这样是危险的。应用程序开发人员常倾向于认为迁移只是对应用程序代码的修改，管理人员考虑的主要是产品的运行时。实际上，迁移应该从更广义的角度来理解，其领域应该扩展到包括开发运行时环境、开发人员和管理人员的技能等等。 　　通常，迁移不是特别困难，但是它可能是一个繁琐的流程。因此，在开始迁移的时候，对此流程尽可能了解、对于开始之前需要做什么事情有足够的估计，将是至关重要的。 　　本文之所以被组织成一个高级检查表，是想作为一个工具来帮助您充分掌握成功迁移所涉及的领域。 　　迁移路线 迁移必须考虑到企业应用软件所有权的全部方面。从高层次来看，迁移计划应该包含以下几个领域： 迁移评估 开发环境 技能 应用程序代码 运行时环境 测试. 　　 　　接下来的部分将详细介绍各个领域。 　　迁移评估 全面的评估是迁移成功的一个关键要素。一般说来，评估将需要 5 到 10 天时间并且应该包括熟悉 WebSphere Application Server V5.x 和 WebSphere Studio 的人员。评估的总体目标是发现可能影响迁移过程的问题以便分配足够的资源来保证迁移取得成功。评估的主要活动和目标包括： 将有关各方聚集在一起。 迁移评估是将有关各方聚集在一起的好机会。评估的一个有意思的结果常常是，不同群体之间对总体的情形获得更加清楚的理解，以及对其他领域所面临的问题也有更深入的认识。 检查高层次体系结构。 将有关各方聚集在一起提供了一个极好的机会从高层次来表述应用程序体系结构。通过对总体情形的更清楚的了解，评估后续部分的各阶段将可以被巧妙的安排。对高层次体系结构的检查不应该超过几个小时。 检查应用程序代码。 对程序代码的检查当然必须是评估过程的一部分。这个过程并不是对代码进行全面铺开的检查，更确切一点，在迁移评估上下文中的代码检查通常只涉及到发现非 J2EE 标准代码的使用。一般情况下，代码质量对迁移的复杂性不会有直接的影响。当应用程序架构需要做大的改动，或者如果代码非常难于理解时，此时迁移的复杂性就会体现出来了。对每一个应用程序，应用程序代码检查一般需要花费 1 到 2 天时间。 检查开发环境。 当迁移到 WebSphere Application Server V5.x 时，通常也适合于使用 WebSphere 的开发工具，例如 WebSphere Studio。但是如果要保留现有的开发环境，那么可能需要修改某些现行的开发惯例。作为评估的一部分，应当检查当前的开发环境，确定现有的惯例、工具和技能应该如何改变，以建立起围绕 WebSphere Studio 的新开发环境。 评估应用程序开发技能。 现有的应用程序开发技能应当作为评估的一部分来评价。即便是熟悉 J2EE 的软件开发者，也需要提升一些技能来熟悉 J2EE、WebSphere Application Server 以及新的开发环境。 检查运行时环境。 大多数组织都支持很多运行时环境，他们每一个都有不同的用途。这些环境的配置（可能包括一个或多个开发测试、系统测试、预生产和生产环境）应当作为评估的一部分被检查，以保证现有的需求、布局、配置和硬件对 WebSphere Application Server 来说是足够的。对安全需求和实现的检查是这一阶段评估的重要部分。检查运行时环境一般至少需要 1 天。 检查创建和部署流程。 应该检查现有的流程以确定 WebSphere Application Server 需要的改变。可能需要修改现有的创建脚本。必须编写新的脚本来代替管理应用服务器的旧脚本。 检查和理解进度问题。 进度永远是伴随迁移的一个问题。大部分组织都有为了应付外部业务驱动而不断改变的应用程序。围绕其他发布版本（deliverable）来制订迁移计划将是一件令人生畏且特别需要耐心的任务。 检查测试惯例。 应当检查现有的测试惯例，以确定其覆盖范围是否足够。如果覆盖范围不足，那么测试管理可能需要增加。当迁移中遇到问题，但却没有定义完善且可靠的测试惯例，将很难知道是迁移是以前存在的问题暴露出来，还是迁移导致了问题。这将导致很难对迁移的过程和最终的成功进行评价。全面的测试策略对于企业应用程序所有者来说是十分重要的。关于测试的进一步信息，请参阅 参考资料。 　　 　　评估使您有机会了解您所拥有的和您需要做的，以准确的计划您的迁移进而使所需的资源能够合理的使用。 　　开发环境 WebSphere Studio 是最适合于为 WebSphere Application Server 创建应用程序的开发环境。开发环境可能是迁移中所作改变最大的部分之一。 　　WebSphere Studio WebSphere Studio 应用 Eclipse 技术创建应用程序。Eclipse 被认为是 Java 开发可利用的最好工具之一。WebSphere Studio 建立在 Eclipse 提供的工具之上，为 J2EE 开发提供完善的工具。WebSphere Studio 是一个开放的可插接的环境，可供各种各样的开发使用，包括创建组件以及编辑 Java、J2EE 和 Web 站点内容（HTML、图像和其它资源）。 　　WebSphere Studio 家族的产品包括下列各项： WebSphere Studio Application Developer WebSphere Studio Application Developer Integration Edition WebSphere Studio Enterprise Developer. 　　 　　这些产品中的每一个都提供 J2EE 应用程序开发，并不断提高扩展支持的级别。WebSphere Studio Application Developer 提供创建、测试和部署 J2EE 应用程序所需的一切。WebSphere Studio Application Developer Integration Edition 通过使用 JCA 连接器、业务流程编排及其它功能来集成遗留系统，以扩展对 J2EE 的支持。WebSphere Studio Enterprise Developer 增加了对其他遗留的企业开发的支持，包含了其他快速应用程序开发工具。在迁移过程的前期，必须选择最适合需要的 WebSphere Studio 版本。 　　其它工具 WebSphere Studio Application Developer 支持许多软件配置管理（SCM）解决方案，包括 Rational® ClearCase® 和 Concurrent Versions System（CVS），及其它（使用厂商提供的插件）。 　　作为迁移到 WebSphere Studio 的一部分，现有的资源树可能需要修改。 WebSphere Studio V5 需要按照 J2EE 封装线路 使应用程序代码结构化。例如，Web 组件必须在一个“Web 项目”里且 Enterprise JavaBeans（EJB）组件必须在一个“ EJB 项目”里。每一个项目都代表一个单独的资源树。在 SCM（在维护各种组件的的历史记录时）中修改现有的资源树将是困难的和费时的。 　　开发小组还可以使用其他的工具，这些工具必须评估来确定它们对 WebSphere Application Server 开发的适用性。 　　技能 WebSphere Studio 与其它开发环境不同，您应该预料到开发者全面提高使用该产品进行高效工作所需的技能，是需要花费一段时间的。即使是真正的聪明人，也应该接受针对 WebSphere Studio 的培训来全面驾驭产品所提供的强大功能。一般说来，5 天的课堂培训对于一个已熟悉企业开发环境的应用程序开发者来讲是足够的。每个迁移计划应该包括为开发小组准备顾问来指导他们在最初的几个星期使用 WebSphere Studio。 　　WebSphere Application Server 的管理与 WebLogic Server 的管理差别很大。虽然许多概念是相似的，但是细节有很大区别。操作人员可能需要花费时间来学习 WebSphere Application Server 并且了解怎样配置和管理它。现有的用于管理 WebLogic Server 的脚本需要重新创建，以使其能够在 WebSphere Application Server 上运行。管理 WebSphere Application Server 节点集仍然是一项需要具有专门技能的专业管理员才能完成的任务。 　　即使是熟练的管理员，也会从正式的培训中受益。一般说来，5 天的课堂培训完全可以提供给经验丰富的应用服务器管理员足够的信息，以便他们掌握如何安装、配置和维护 WebSphere Application Server。 　　应用程序代码 作为迁移的一部分，应用程序代码可能不需要做重大的修改。在大部分情况下，纯 Java 的应用程序代码在两个平台上都能够运行。更改的大多是控制和业务逻辑这一类。一些 J2EE 构件（如 servlet、JSP 和 EJB 组件）甚至不需要修改就可以在新平台上运行。 　　在评估如何迁移应用代码中，需要考虑： 代码组织 针对规范的改动 专有技术的使用 第三方库 迁移工具 其它问题 　　 　　下面讨论这些要点。 　　代码组织 J2EE 定义了一个非常特定的封装结构，该结构把各种构件分离放入不同的档案文件中。Web 构件，包括 servlet、JSP 和 Web 内容（如 GIF 和 JPEG 文件），被封装到 Web Archive（WAR）文件中。一般说来，把由各种 EJB 类型组成的 EJB 构件封装成 EJB-JAR（JAR）文件。Enterprise Archive（EAR）文件用于把所有的应用程序组件（WAR 和 JAR）文件聚集为单一的文件。也可以把应用程序使用的其它库文件（JAR 文件）放置到 EAR 文件中。档案文件也可以包括属于另一个 J2EE 模块类型的应用程序客户端档案文件（JAR）。 　　图 1. 说明了如何组织各种各样的档案文件（在 J2EE 文档中被作为模块）。 　　图 1. J2EE 封装结构 　　封装各个模块的是 XML 部署描述符，这个描述符描述了模块中组件的组织和在运行时如何配置它们。 　　WebSphere Studio 需要将应用程序代码按照 J2EE 线路来结构化。根据上面提到的，Web 组件必须放在 Web 项目里，且 EJB 构件放在 EJB 项目里。在这些项目类型中，也需要特定的目录结构。例如：Web 项目需要 Web 内容目录来包含项目所需要的全部内容（源代码除外）。 　　在很多情况下，部署在 WebLogic Server 上的应用程序代码是任意构造的，并且依赖创建过程来理解它。这个意味着作为迁移工作的一部分很可能必须修改现有的代码组织。这在维护代码历史记录的链接时是很难（或甚至不可能）完成。一些组织简单地选择了把代码的历史记录归档和开始更新。 　　针对规范的改动 大多数 J2EE 构件迁移到 WebSphere Application 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 编译器自动包含 java.util 包。为了使您的 JSP 在 WebSphere Application 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 组件构成了迁移工作的大部分。 　　专有技术的使用 在该文中“专有技术”是指 WebLogic Server 特有的且没有根据规范来管理的功能。如果应用程序使用了这些专有技术，那么就需要修改。 　　或许专有技术最常见的例子就是所谓的“t3”服务，其中最受欢迎的就是用于 RMI 与 EJB 组件通信的 t3 协议。通常，替换该协议意味着产生 WebSphere 特定的 EJB 部署代码，并且在用于 JNDI 初始上下文结构的统一资源定位符（URL）中用 iiop 来替换 t3 。一般说来，应该像 J2EE 规范中推荐的那样，明确地显示提供者 URL 的代码应该改为隐含地从环境中获取 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 将第三方库和您的应用程序代码同等对待。在 WebSphere Application Server V5.0 上，由“just Java”构成的库不用做任何修改就可以继续使用。然而，许多库是依赖于特定版本的应用服务器的。使问题更为复杂的是，大多数库的提供商并不提供源代码或不允许修改他们的代码，这将使您常常需要他们提供支持。 　　作为迁移工作的一部分，应当联系第三方提供商，并要求他们提供与 WebSphere Application Server 兼容的声明。兼容性应该经过彻底的测试，为以防万一，在迁移周期的早期就应该寻找替代产品。 　　迁移工具 真正有助于将 WebLogic Server applications 迁移到 WebSphere Application Server 的工具非常少。WebSphere Studio 或许是这个领域中最有价值的工具，因为它对于确定、诊断和解决代码问题提供了相当多的帮助，这些问题都是迁移过程的一部分。 　　如果应用程序符合 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。 　　其它问题 将代码从 WebLogic Server 迁移到 WebSphere Studio 时，循环引用是最常见的问题之一。当项目中的一个类引用另一个已引用了该项目中类（可能是同一类）的其他项目中的类时，循环引用就发生了。 　　在不同包或项目中类之间的循环引用通常被认为是不好的编程习惯（这些类在不同组件之间构成了紧耦合）。当在不同项目之间发现引用循环时，WebSphere Studio 的创建流程将会停止（可以改变配置使其继续下去）。创建流程在创建单一树的代码时不存在依赖问题，且也不会影响其结构。关于处理循环依赖的更多帮助，参见 经验学习：将 WebLogic Server 应用程序迁移到 WebSphere Studio。 　　运行时环境 大多数组织拥有一套以上的运行时环境，包括开发测试、系统测试、性能和预生产。应该还有用于其他目的的其他的环境。 　　迁移生产运行时环境绝大多数情况下不可能是简单地关闭所有程序、安装新硬件和重新启动所有程序。对于开发测试和系统测试环境有可能是这样，但是由于其他运行时环境的限制，使得这些操作即使不是不可能的，就是不切实际的。几乎在所有的情形下，生产运行时环境迁移时必须保持运行状态。一般说来，即使是对于预生产环境，停机也是难以接受的。如果不同开发团队以不同的发布时间表开发多个应用程序，这将使得生产运行时的迁移更为复杂。在这类情形中，您可能需要在一段时间内并行的运行两个应用服务器。 　　可能会形成“滚动迁移（rolling migration）”，这取决于您的运行时配置。图 2 显示了一个运行时布局的例子。 　　图 2 一个运行时布局的例子 　　在滚动迁移场景中，应用服务器以下列步骤或单独或以小组为单位进行升级： 选择一个或多个应用服务器节点。 从负载平衡器（load balancer）的路由表中将选定的节点删除（图 3）。 从服务中将相应节点删除（关闭）。 删除（或停止）WebSphere Application Server V4.0。 安装、配置和测试 WebSphere Application Server V5.x。 安装、配置和测试迁移后的应用程序代码。 激活升级后的节点并进行配置使其能接受外来的请求（例如，将其重新添加到负载平衡器的路由表中）。 　　 　　这个流程对其余的节点依次重复进行。 　　图 3. 被剪切并迁移的分支 　　这只是一个非常简单的综述，有可能和您的具体配置不太相符。本场景假定您至少有 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：端到端的迁移指导中详细介绍。 　　结束语 仅仅在一篇文档中很难覆盖迁移的所有方面。毫无疑问，每一个组织和应用程序都是不相同的，因而可以断定每一个迁移的经历也都是不相同的。在本文中，我们描述了许多必须作为迁移的一部分来考虑的问题。更多的关于向 WebSphere Application Server 迁移的具体技术信息，请参阅 参考资料。 　　迁移总是一项重大的任务。即使对您的应用程序代码不需要做任何改动，当考虑了所有的因素以后，也可以预计到迁移将会花费一定程度的时间和精力。迁移不仅仅包括代码或单一的环境。您的迁移计划应当解决从开发环境和技能到管理技能和运行时环境的每一个问题。 　　经过了仔细计划的迁移将有可能成为最成功的迁移。 　　参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文. WebSphere 应用程序测试 将 WebLogic 启动代码迁移到 WebSphere Application Server 5.0 经验学习：将 WebLogic 服务器应用程序迁移到 WebSphere Studio 将 BEA WebLogic 服务器应用程序迁移到 IBM WebSphere Studio 和 WebSphere Application Server 迁移到 WebSphere V5.0：端到端的迁移向导，IBM 红皮书：SG24-6910-01 将 WebLogic 应用程序迁移到 WebSphere V5，IBM Redpaper：REDP-0448-00 　　 关于作者 Wayne Beaton是一名负责 IBM Software Group 的 Software Services for WebSphere 部分的高级软件顾问。他的研究重点是将 WebSphere 的早期版本和竞争产品（包括 Visual Basic）迁移到 WebSphere Application Server 5.0。他与别人合著过两本关于迁移主题的 IBM 红皮书。Wayne 担任的各种角色使他要涉及很多有趣的领域，从 WebSphere Skills Transfer 和迁移程序到一般顾问等。Wayne 在空余时间喜欢说服别人，让他们相信极限编程、重构和单元测试真的是有用的。 对本文的评价 　　您对这篇文章的看法如何？ 太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？ developerWorks 中国 > WebSphere >

关于 IBM     隐私条约     联系 IBM