将J2EE应用程序移植移植方法和常见问题
引言　　

有关J2EE应用程序到WebSphere应用程序服务器的移植，尽管IBM提供了很多的资料和文章来说明如何将运行在WebLogic上的应用程序移植到WebSphere上，但是大家可能还是有所疑惑：是否从WebLogic移植到WebSphere和从Tomcat、Jboss、Resin移植到WebSphere会有所不同呢?实际上，一个J2EE应用程序无论运行在什么平台上，我们都可以用相同的方法将其移植到WebSphere上，这也是J2EE规范给我们带来的好处。然而，移植往往不会是一帆风顺的，移植的难度不仅取决于J2EE应用程序对J2EE规范的遵循程度，更取决于它所用到的非J2EE成分的可移植性。对于标准的J2EE应用程序，我们可以通过固定的步骤完成移植任务，而对于其他的部分，我们只能通过耐心的调试和探索，以寻求最佳的解决方案。在这篇文章里，我们将详细说明移植的方法和常见的问题，在后续的文章里会具体讲述我们在各个平台移植过程中所遇到的特殊问题和解决方法。
　　本文假定您熟悉J2EE规范，并且使用WebSphere Studio Application Developer开发过部署在WebSphere应用程序服务器上的J2EE应用程序。在阅读完本文后，建议大家先从试验入手，完成参考文档中的样例程序，从而对移植任务有一个更加具体的理解。
　　
移植方法
　一、 学习WebSphere Studio Application Developer，参见参考文档1。
　　二、 从应用程序中挑选出最具代表性的子系统
　　1、这个子系统应该全面涵盖系统的技术难点，参见常见的问题
　　2、归纳总结系统所需的配置和所依赖的类库
　　三、 分析此子系统的架构，澄清其中各个模块之间的依赖关系
　　1、 包括业务模块之间的依赖关系，以及Web模块和EJB模块等程序模块之间的依赖关系等。
　　2、 如果应用程序中存在过多的交叉引用关系，可以考虑在一定程度上调整系统的架构和文件组织结构，尽量避免模块之间的交叉调用。
　　3、 一定要避免运行在同一个JAVA虚拟机的多个模块中包含相同JAVA 类或类库的多个副本。
　　四、 将这个剥离出来并重新调整过的子系统打包，并在原有的J2EE 服务器上验证其可用性
　　1、在原有J2EE服务器上能够单独运行此子系统
　　2、将系统的配置和所需的类库，针对WebSphere重新规划，为了能够有效地完成这一步骤，我们必须先熟悉WebSphere的基本概念，包括WebSphere classloader的体系结构，参见参考文档2。
　　3、测试通过的子系统打包成EAR文件，导入到WebSphere Studio Application Developer中，根据任务视图所提供的错误提示，修复所有构建时的错误。WebSphere Studio Application Developer提供了一个非常出色的错误诊断机制，可以让开发人员轻松的定位并修复应用程序中存在的错误，并且根据错误的提示，开发人员可以在J2EE规范中方便的找到相应的章节，查看详细信息
　　五、了解WebSphere classloader的体系结构，重新规划共享类库
　　1、避免共享类库在多个模块中存在副本
　　2、尽量提供一个移植性好的J2EE应用程序打包方案，在部署到不同的J2EE服务器时不需要做任何的改动
　　3、建议的方案
　　对于在Web模块中共享的JAR文件
　　将JAR文件移到WebProject/webApplication/web-inf/lib文件夹中，这样JAR文件会在构建时被自动装载并在运行时生效
　　对于在所有EJB模块和Web模块中共享的JAR文件
　　a)将JAR文件导入到EAR项目的根目录当中;
　　b)在EJB项目和Web项目中通过修改Manifest文件来添加对JAR文件的依赖关系。
　　注意：不推荐通过J2EE应用服务器的CLASSPATH来添加JAR文件，这样会降低应用程序的可移植性。要避免同时包含JAR文件的不同版本，如果原来系统里包含多个版本，则只保留其中一个即可。
　　六、调试子系统
　　1、先利用WebSphere Studio Application Developer的通用测试客户机(UTC)对服务器端的EJB进行调试
　　2、客户端应用程序和服务器端应用程序对接，调试客户端程序
　　七、将子系统导出为EAR文件，发布到WebSphere应用程序服务器中，进行测试
　　八、估算移植剩余子系统的工作量，分工完成
　　九、集成测试

常见的问题
　　一、 对J2EE标准的遵循
　　几乎没有一个J2EE应用程序，在不经过任何改动的情况下，可以运行在WebSphere 应用服务器上，其中一个原因就是大多数的应用程序没有完全遵循J2EE规范，并且很多J2EE应用服务器都在某种程度上放宽了对于应用程序的限制。
　　1、 何时使用PortableRemoteObject进行对象造型
　　基于IIOP协议，我们需要使用PortableRemoteObject来转换返回的stub对象，而基于WebLogic使用的t3协议，这个操作是可选的
　　如果stub对应的是远程接口，此方法是必要的;如果stub对应的是本地接口，此方法是可选的
　　如果在不需要的情况下(例如访问本地接口的EJB时)使用了此方法，系统可以正常运行，但不推荐使用;如果在必需的情况下(例如访问远程接口的EJB时)没有使用此方法，那么系统会抛出ClassCastException
　　2、 EJB引用
　　根据EJB2.0规范，使用本地的JNDI上下文(java：comp/env)来查找EJB是必须的。但是很多J2EE服务器对此放宽了要求，在使用全局的JNDI上下文时，同样可以正常运行。然而，WebSphere则严格遵循了这一约束。
　　在部署描述符中需要添加EJB引用
　　每个EJB home都需要绑定一个全局的JNDI名称，绑定信息会存放在ibm-ejb-jar-bnd.xmi文件中
　　在WebSphere中，每个EJB引用(ejb-ref)必须绑定一个全局JNDI名称;而在WebLogic中，全局JNDI名称不总是必需的，当使用ejb-link时，全局JNDI名称是可选的
　　如果使用的是EJB的远程接口，按照规范，需要通过本地的JNDI名称和EJB引用来访问。如果使用了全局的JNDI名称访问，也可以在WebSphere中正常运行，但这个操作是违规的，而且可能会导致将来的不兼容问题
　　3、对于本地接口的EJB引用
　　在WebSphere中，如果没有使用本地JNDI名称查找本地EJB，将会出错
　　不需要使用PortableRemoteObject进行类型转换
　　必须使用本地JNDI名称
　　必须使用EJB引用
　　4、构建时的错误
　　先修复部署描述符的错误信息。根据任务视图的提示，可以轻松定位和修复错误(主要包括部署描述符的版本信息、JNDI名称、各种引用等等)
　　然后根据任务视图的提示定位和修复编译错误(比如JAVA CLASS的丢失等等)
　　5、异常处理
　　本地Home接口的方法中不允许抛出RemoteException
　　Bean方法中不允许抛出RemoteException
　　MDB不允许抛出应用程序异常，因为应用程序和MDB之间不存在调用关系
　　二、 J2EE1.3的特性
　　1. CMP2.0 连接工厂的部署
　　在WebSphere中，如果我们建立一个名为jdbc/Sample的数据源为CMP提供数据库连接，则CMP将使用名为eis/jdbc/Sample_CMP的CMP connection factory实现和数据库的绑定。
　　2. MDB/JMS的部署
　　MDB/JMS的部署在不同的平台上会有所差别，但我们并不需要关心这种差别，只需要关心他们在WebSphere上的配置情况，详细步骤请查阅参考文档3的174和176页。
　　3. 本地接口的使用
　　在WebSphere中使用本地接口的EJB,需要在部署描述符中配置本地引用，并在客户端代码中使用前缀为"java:comp/env/"的本地JNDI上下文进行JNDI查询。
　　4. J2EE 基于表单的认证
　　WebLogic使用weblogic.servlet.security.ServletAuthentication类实现基于表单的认证;
　　WebSphere使用J2E