路由器

电脑

手机

网络

怎么样将J2EE应用程序移植到WebSphere服务器？

来源：www.45fan.com  2016-08-31 11:11:41

怎么样将J2EE应用程序移植到WebSphere服务器？

 

将J2EE应用程序移植到WebSphere应用程序服务器（第一部分）

 

引言
有关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使用J2EE规范中的 j_security_check Servlet进行基于表单的认证。

三、 客户端的移植问题
客户端的构成多种多样，可以是Servlet，JSP，Java Application，Delphi 客户端等等，而客户端程序和服务器端程序通信的方式也是多种多样，可以通过HTTP、RMI/IIOP、SOAP、Web Services等等。在移植过程中我们需要注意下面几点：

1、 Java Application客户端

  • 如果Java Application客户端使用HTTP请求访问WebSphere应用程序服务器，则可以使用不同厂商提供的JDK
  • 如果Java Application客户端使用IIOP请求访问WebSphere应用程序服务器，则只能使用WebSphere专用的JDK

2、 T3协议

T3协议在某种程度上给程序员带来了一些便利，然而由于T3协议是私有协议，所以降低了应用程序的可移植性。而IIOP协议则为应用程序带来了更好的移植性。在WebSphere中只能使用IIOP协议进行JNDI的访问，因此需要将引用T3协议的地方改成IIOP的方式。

3、 始上下文工厂和供应商可以被存放在配置文件中，也可以使用Java的-D参数进行配置，下面的示例展示了如何在代码中直接设置初始上下文工厂和供应商

  • WebLogic
    Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL,"t3://localhost:7001"); 
InitialContext ctx = new InitialContext(h);
  • WebSphere Properties h = new Properties(); h.put(Context.INITIAL_CONTEXT_FACTORY," com.ibm.websphere.naming.WsnInitialContextFactory "); h.put(Context.PROVIDER_URL,"iiop://localhost:2809/"); InitialContext ctx = new InitialContext(h);

4、 事务出理（java.user.Transaction）

  • WebLogic
    (UserTransaction)getInitialContext().lookup("javax.transaction.UserTransaction");
  • WebSphere
    (UserTransaction)getInitialContext().lookup("jta/usertransaction")

5、客户端程序所需要的EJB interfaces和stubs

  • 推荐的方法
    a) 将这些文件添加到客户端的JAR文件当中，或者
    b)将这些文件打包到新的JAR文件中，然后再将此JAR文件添加到CLASSPATH当中
  • 动态下载interfaces和stubs
    RMI协议提供了动态下载interfaces和stubs的功能，但存在很多限制，所以不推荐使用

四、 数据映射
1、使用第三方的数据绑定技术（如TopLink，Hibernate，Castor，Kodo等等）可以在一定程度上提高可移植性

2、CMP 和 CMR

  • 当EJB的名称与表的名称一致并且EJB成员变量的名称与表的列名一致时，在WebSphere Studio Application Developer中选择自顶向下(top-down)的映射即可；
  • 当EJB的名称和表的名称不一致或者EJB成员变量的名称与表的列名不一致时，在WebSphere Studio Application Developer中选择中间相遇(meet-in-middle)的映射

应用程序特定的问题
每一个应用程序都会有自己独特的地方，在移植过程中或多或少会出现超出"常见问题"范围的其他问题，相信通过耐心的调试均可逐一解决。在以后的文章里会介绍我们在项目中遇到的特定的问题和解决办法。
 
推荐阅读