引言
把应用程序从竞争对手的平台移植到WebSphere?Application Server中的时候应当要考虑到各种问题。应用程序源代码就是其中一个，并且由于源代码在很多情况下大多数是纯Java的，所以移植 相对来说比较简单。尽管如此，纯Java的源代码也可能带来一定的挑战性，正如从WebLogic移植到WebSphere Application的案例。
应用程序
在这个特定的案例中，应用程序源码是为了部署WebLogic Server 6.1而构造的。应用程序包含许多无状态会话EJB，一些servlet，两百个JSP，还有大约三百个实用的类，所有这些内容都被包含在一个单一的源代码树里面。这些代码通常组织良好，并且成功的采用了很多最好的被广泛接受的应用程序开发方法。应用程序内部只是松散的耦合，只有很少的重要例外(更多内容，参看下文)
这里的大多数应用程序是纯Java的，也就是说，代码的大部分是独立于J2EE或任何特定的J2EE应用服务器。应用程序所包含的servlets和EJBs是非常简单的，并且它们只用到很少的扩展部署描述符中存储的信息(唯一重要的条目是提供给EJBs的JNDI名)。
Apache Ant是用来构建工程的。Ant脚本用单一的操作编译整个源代码树，提取不同的类放入不同的JAR 文件中，然后构造一些EJB JARs。这个构建工程的过程不是非常精确的，一些类文件在多个JAR文件里面重复了，一些包的内容在 多个JAR文件里面被扩展了。这些都不是严重的错误，但是确实给跟踪定位各个类的归属带来了困难。
问题
在把代码移植到WebSphere Studio Application Developer(下面简称Application Developer)并且试图将之重构为单独的J2EE模块之前，处理代码本身是轻而易举的事情。我们的计划有三个方面：
建立一个企业应用程序项目（Enterprise Application Project）。
建立一个Java Utility Project并且把它作为Utility JAR加入到企业应用程序项目:
把所有的代码装载进入Java Utility Project.
为源代码树中的每个ejb-jar.xml文件创建一个EJB项目(并把它作为一个模块加入到企业应用程序项目)并把相关联的EJB代码放入那个企业应用程序项目。
为源代码树中的每个web.xml文件(这里只有一个）创建一个Web项目(并把它作为一个模块加入到企业应用程序项目) 并把相关联的servlet代码放入那个企业应用程序项目。
配置工程之间的Java JAR依赖关系。
标识来自部署描述符的EJBs需要的种类是比较容易的。一旦这些种类被标识，我们就把它们移入项目中。然而，Application Developer会用一些编译错误显示这些改变。我们指出我们将会在最后一步解决这些问题，但是当建立我们创建的不同项目之间的依赖关系时，很快我们就会很发现有一些循环依赖关系有待解决；特别的，有些在Java项目中的代码引用EJB和被EJB引用（见图1），这种情形称为循环引用，并且发现这些代码在大量的包中形成不同类型的交叉。
图1. 工程之间的循环引用：Java代码,资源和Deployment Descriptors是在EJB/Web项目中的。
通常，都不希望出现循环引用，因为它们引入了复杂性和强耦合性。当遇到循环引用的时候首选的方法是删除它们。不幸的是，识别和重新关联这些引用是很需要技巧和费时间的，因为这需要很熟悉这些应用程序代码。
然而，由循环引用引发的问题是一个由WebSphere Studio强加的限制：当Application Developer检测到一个循环引用的时候，Application Developer将要停止构造过程。有耐心的用户可以强制Application Developer通过重复开始构造过程直到构造完成（有时会有效果）。但是在这样的情况下，包含的那部分会使得“重复开始构造过程”不太实际可行。
解决方案
当移植代码到一个新的平台（在本例中是WebSphere Application Server)时,标准的做法通常是让应用程序在新环境中尽快运行起来。要达此目的，你应当尽量最小化对源代码的 修改，这可能(至少是临时的)对你来说是一个最好的方法。而且，还有很多实际原因让你这样做：
这让你能够专注于一个任务而不是多个。
移植代码是一个任务，重构代码是另一个任务。如果你试图把太多行为作为移植的一部分去做，将会增加失败的危险。
通过保持尽可能小的代码修改量会使应用程序可以更快的运行，这将会给你成功的信心。
这实际上会使得必要的重构容易实现，因为可以运行的并可以实际测试的代码更容易修改。
记住这一点，我们尝试一些不同的途径去解决由循环引用引发的问题。最后，以下假定是构成我们解决方案的基础：
所有的Java代码必须包含在单一项目中，以使得代码能在循环引用完整的情况下被编译。
我们有若干个EJB工程与这些循环引用相关。
我们要保持修改最小化(特别是关于结构的修改)。
我们知道这将是临时的解决方案，在项目的下一步必须重新从应用程序代码中提取出这些依赖关系。
EJB代码不必真正的包含在EJB项目中，只要能被EJB项目访问即可。该访问可以这样提供：把所有的代码放到一个单一的Java项目中，并且将EJB和Web项目之间的Java JAR依赖关系指定到那个Java项目。对EJB来说，只有部署描述符需要存储在EJB项目里。属于Web项目的所有东西(包括WEB-INF目录的内容，JSPs和其他静态资源)必须在Web项目中提供；然而，代码可以保存在Java项目中(见图2)。
图 2. 一个Java项目中的所有Java代码: 只有部署描述符和资源在EJB/Web项目中
要将现有的应用程序代码导入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代码。
图4. 创建新的EJB项目，作为一个模块加入到企业应用程序项目
图5. 在EJB Project Create向导中加入一个Module Dependency
Java代码将不拷贝到EJB项目中。EJB项目将可以访问BankingCommon项目中的代码，但是记住如果那些代码被移动的话，循环依赖会导致编译错误。(是的， 这确实有效)
WL2WAS是一个用来把WebLogic J2EE模块转换为WebSphere Appllication Server的实用工具。
以下的DOS命令行为名为wl.ear的WebLogic 6.1 EAR执行WL2WAS(AMF.BAT)，并产生名为as.ear的WebSphere 4.0 EAR。包含在这个EAR里的所有J2EE模块转换为在WebSphere Application Server上运行。
amf -wl "-in wl.jar -out was.ear -wlv 61 -wasv 40
WL2WAS当前只能应用于EJB 1.1兼容的JAR文件。WL2WAS产生的日志包含了容易理解的移植信息，这些信息包括一些可能不适用于WebSphere的WebLogic扩展部署描述符。
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项目的Web Contents/WEB-INF目录中。
代码也不应该拷贝到Web项目中。Web项目将可以访问BankingCommon项目中的代码。移动Web代码可能会导致当代码从BankingCommon中删除的时候，循环依赖关系中断。
结论
在本练习的最后，我们得到了一个包含了所有Java代码的Java项目，以及几个EJB和无任何实际Java代码的Web项目(只有部署描述符和非Java的Web构件)。只要必需的类型是能被EJB和Web项目访问的，它就能运行良好。
然而，这只是解决方案的第一步。毕竟，正确的解决方案是要重构应用程序代码(将EJB代码移入EJB项目，将Web代码移入Web项目)来消除循环引用。实际上，循环引用也不总是有害的，有时它是完全必需的。然而，通常模块之间的引用应该是单向的。而其他方式则会增加这些结构间的耦合，并且使得应用程序的长期维护变得更困难。
这个解决方案帮助我们快速的将代码导入WebSphere Studio，它使得重构过程非常容易??并且能工作的代码(无论什么形式)比不能工作的代码更容易重构。
参考
把部署到 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