从经验中学习: 把一个WebLogic Server Application移植到WebSphere Studio中

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

级别： 初级

Wayne Beaton (wbeaton@ca.ibm.com), 资深软件顾问, IBM Software Services for WebSphere

2003 年 10 月 01 日

把应用程序从竞争对手的平台移植到WebSphere®Application Server中的时候应当要考虑到各种问题。应用程序源代码就是其中一个，并且由于源代码在很多情况下大多数是纯Java的，所以移植 相对来说比较简单。

© IBM版权所有，2003年。

引言

把应用程序从竞争对手的平台移植到WebSphere®ApplicationServer中的时候应当要考虑到各种问题。应用程序源代码就是其中一个，并且由于源代码在很多情况下大多数是纯Java的，所以移植相对来说比较简单。尽管如此，纯Java的源代码也可能带来一定的挑战性，正如从WebLogic移植到WebSphere Application的案例。

回页首

应用程序

在这个特定的案例中，应用程序源码是为了部署WebLogic Server6.1而构造的。应用程序包含许多无状态会话EJB，一些servlet，两百个JSP，还有大约三百个实用的类，所有这些内容都被包含在一个单一的源代码树里面。这些代码通常组织良好，并且成功的采用了很多最好的被广泛接受的应用程序开发方法。应用程序内部只是松散的耦合，只有很少的重要例外(更多内容，参看下文)

这里的大多数应用程序是纯Java的，也就是说，代码的大部分是独立于J2EE或任何特定的J2EE应用服务器。应用程序所包含的servlets和EJBs是非常简单的，并且它们只用到很少的扩展部署描述符中存储的信息(唯一重要的条目是提供给EJBs的JNDI名)。

Apache Ant是用来构建工程的。Ant脚本用单一的操作编译整个源代码树，提取不同的类放入不同的JAR文件中，然后构造一些EJB JARs。这个构建工程的过程不是非常精确的，一些类文件在多个JAR文件里面重复了，一些包的内容在多个JAR文件里面被扩展了。这些都不是严重的错误，但是确实给跟踪定位各个类的归属带来了困难。

回页首

问题

在把代码移植到WebSphere Studio Application Developer(下面简称ApplicationDeveloper)并且试图将之重构为单独的J2EE模块之前，处理代码本身是轻而易举的事情。我们的计划有三个方面：

1. 建立一个企业应用程序项目（Enterprise Application Project）。
2. 建立一个Java Utility Project并且把它作为Utility JAR加入到企业应用程序项目:
   • 把所有的代码装载进入Java Utility Project.
   • 为源代码树中的每个 ejb-jar.xml文件 创建一个EJB项目(并把它作为一个模块加入到企业应用程序项目)并把相关联的EJB代码放入那个企业应用程序项目。
   • 为源代码树中的每个 web.xml文件 (这里只有一个）创建一个Web项目(并把它作为一个模块加入到企业应用程序项目) 并把相关联的servlet代码放入那个企业应用程序项目。
3. 配置工程之间的Java JAR依赖关系。

标识来自部署描述符的EJBs需要的种类是比较容易的。一旦这些种类被标识，我们就把它们移入项目中。然而，ApplicationDeveloper会用一些编译错误显示这些改变。我们指出我们将会在最后一步解决这些问题，但是当建立我们创建的不同项目之间的依赖关系时，很快我们就会很发现有一些循环依赖关系有待解决；特别的，有些在Java项目中的代码引用EJB和被EJB引用（见图1），这种情形称为循环引用，并且发现这些代码在大量的包中形成不同类型的交叉。

通常，都不希望出现循环引用，因为它们引入了复杂性和强耦合性。当遇到循环引用的时候首选的方法是删除它们。不幸的是，识别和重新关联这些引用是很需要技巧和费时间的，因为这需要很熟悉这些应用程序代码。

然而，由循环引用引发的问题是一个由WebSphereStudio强加的限制：当Application Developer检测到一个循环引用的时候，Application Developer将要停止构造过程。有耐心的用户可以强制Application Developer通过重复开始构造过程直到构造完成（有时会有效果）。但是在这样的情况下，包含的那部分会使得“重复开始构造过程”不太实际可行。

回页首

解决方案

当移植代码到一个新的平台（在本例中是WebSphere ApplicationServer)时,标准的做法通常是让应用程序在新环境中尽快运行起来。要达此目的，你应当尽量最小化对源代码的修改，这可能(至少是临时的)对你来说是一个最好的方法。而且，还有很多实际原因让你这样做：

• 这让你能够专注于一个任务而不是多个。
• 移植代码是一个任务，重构代码是另一个任务。如果你试图把太多行为作为移植的一部分去做，将会增加失败的危险。
• 通过保持尽可能小的代码修改量会使应用程序可以更快的运行，这将会给你成功的信心。
• 这实际上会使得必要的重构容易实现，因为可以运行的并可以实际测试的代码更容易修改。

记住这一点，我们尝试一些不同的途径去解决由循环引用引发的问题。最后，以下假定是构成我们解决方案的基础：

• 所有的Java代码必须包含在单一项目中，以使得代码能在循环引用完整的情况下被编译。
• 我们有若干个EJB工程与这些循环引用相关。
• 我们要保持修改最小化(特别是关于结构的修改)。
• 我们知道这将是临时的解决方案，在项目的下一步必须重新从应用程序代码中提取出这些依赖关系。

EJB代码不必真正的包含在EJB项目中，只要能被EJB项目访问即可。该访问可以这样提供：把所有的代码放到一个单一的Java项目中，并且将EJB和Web项目之间的Java JAR依赖关系指定到那个Java项目。对EJB来说，只有部署描述符需要存储在EJB项目里。属于Web项目的所有东西(包括WEB-INF目录的内容，JSPs和其他静态资源)必须在Web项目中提供；然而，代码可以保存在Java项目中(见图2)。

要将现有的应用程序代码导入WebSphere Studio,我们依照以下步骤进行：

1. 将代码导入WebSphere Studio

• 创建一个企业应用程序项目,在本例中命名为 Banking 。
• 创建一个Java 项目，名为BankingCommon ,然后在这个项目中建立一个源代码目录(这不是必需的，但是这 通常使得在该Java项目中工作更方便)。
• 把BankingCommon添加为属于Banking的一个实用JAR(见图3)。
• 把现有的源代码树的内容导入到BankingCommon中。
• 解决任何问题(例如必须要有附加的库以解决一些编译错误)。

图 3. 把"BankingCommon" 作为Utility JAR加入到Banking的部署描述符

至此，代码被装载到WebSphere Studio并且问题已解决。然而，代码却还不能运行，因为我们还没有创建任何必需的J2EE内容(如EJB和Web工程)。当然，任何针对纯Java的单元测试都可以运行以保证质量。

2. 创建一个EJB项目

如前所述，Ant是用来构造该应用程序的WebLogic版本。Ant提供了一个专门的"weblogic"任务去构造兼容WebLogic的EJB-JAR文件。为了这样做，它找到所有名为 *-ejb-jar.xml 的文件并以之确定需要作为JAR的一部分而打包的类型。在这过程中，它把这些文件重命名为期望的 ejb-jar.xml 文件并实际创建JAR。

为了使得总工作量最少，我们有效利用现有的WebLogic build过程：

• 运行WebLogic build脚本。
• 在以上步骤中得到的兼容WebLogic EAR文件上运行 WL2WAS 。
• 对于包含在导出的EAR文件里的每个EJB-JAR文件：
  • 在WebSphere Studio中，用一个相应的名字(例如： analysisEJB.jar 对应BankingEJBAnalysis)创建一个EJB项目。
  • 将这个新的EJB到加入到Banking企业应用程序项目，作为这个企业应用程序的模块(见图4）。
  • 为新的EJB项目添加一个模块依赖性（Module Dependency），名为BankingCommon的一个(见图5）。
  • 从EJB-JAR文件拷贝 ejb-jar.xml , ibm-ejb-jar-ext.xmi ,和 ibm-ejb-jar-bnd.xmi 到EJB工程的 META-INF 目录(作为可选项，你也可以拷贝 weblogic-ejb-jar.xml 文件来维护一个应用程序的WebLogic版本)。
  • 生成EJB项目的Deploy和RMIC代码。

Java代码将 不拷贝到EJB项目中。EJB项目将可以访问BankingCommon项目中的代码，但是记住如果那些代码被移动的话，循环依赖会导致编译错误。(是的，这确实有效)

3. 创建Web项目

WebLogic构造过程创立一个WAR文件并将它包含到EAR中。当和EJB在一起时，这个产生的WAR文件的内容也可以被利用。对于这种特殊的客户机，只有一个名为 banking.war 的文件 ：

• 创建一个新的名为 BankingWeb 的Web项目。
• 将BankingWeb加入到Banking的模块集合中。
• 将BankingCommon作为一个Java JAR Dependency加入到Web项目的属性里。
• 将 META-INF 目录的内容从WAR文件拷贝到 Web项目的 Web Contents/META-INF 目录。
• 将 WEB 目录的内容从WAR文件拷贝到Web项目的 WebContents/WEB-INF 目录中。

代码也不应该拷贝到Web项目中。Web项目将可以访问BankingCommon项目中的代码。移动Web代码可能会导致当代码从BankingCommon中删除的时候，循环依赖关系中断。

回页首

结论

在本练习的最后，我们得到了一个包含了所有Java代码的Java项目，以及几个EJB和无任何实际Java代码的Web项目(只有部署描述符和非Java的Web构件)。只要必需的类型是能被EJB和Web项目访问的，它就能运行良好。

然而，这只是解决方案的第一步。毕竟，正确的解决方案是要重构应用程序代码(将EJB代码移入EJB项目，将Web代码移入Web项目)来消除循环引用。实际上，循环引用也不总是有害的，有时它是完全必需的。然而，通常模块之间的引用应该是单向的。而其他方式则会增加这些结构间的耦合，并且使得应用程序的长期维护变得更困难。

这个解决方案帮助我们快速的将代码导入WebSphereStudio，它使得重构过程非常容易--并且能工作的代码(无论什么形式)比不能工作的代码更容易重构。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 把部署到 BEA WebLogic Server 上的 WebGain VisualCafé Web 应用程序迁移到 IBM WebSphere Studio Application Developer — 第 1 部分, Barry Searle, Ellen McKay; October 2002
  
  
• 把部署到 BEA WebLogic Server 上的 WebGain VisualCafé Web 应用程序迁移到 IBM WebSphere Studio Application Developer — 第 3 部分, Ann Black, Mihaela Herescu, Barry Searle, Ellen McKay; October 2002
  

关于作者

		Wayne Beaton是一位负责IBM Software家族中WebSphere的软件服务的资深软件顾问。他专注于把老版本的WebSphere和竞争对手的产品移植到WebSphere 5.0。他和别人合著过两本关于移植方面的IBM红皮书。Wayne的不同角色使他介入许多其他的有趣的工作，包括WebSphere Skills Transfer编程和通常的咨询。Wayne喜欢利用他的余暇时间让人知道：极限编程,重构和单元测试是实际上很有效的。你可以通过 wbeaton@ca.ibm.com和他联系。

对本文的评价

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

回页首