WebSphere客户端迁移的一般问题

2798人阅读 评论(0) 收藏 举报

现象:J2EE应用在迁移时因为之前使用特定厂商的特殊实现,因此各种编译或者运行时的异常

原因:厂商实现的差别

解决办法:

一、 J2EE标准的遵循
几乎没有一个J2EE应用程序,在不经过任何改动的情况下,可以运行在WebSphere 应用服务器上,其中一个原因就是大多数的应用程序没有完全遵循J2EE规范,并且很多J2EE应用服务器都在某种程度上放宽了对于应用程序的限制。

1 何时使用PortableRemoteObject进行对象造型

  • 基于IIOP协议,我们需要使用PortableRemoteObject来转换返回的stub对象,而基于WebLogic使用的t3协议,这个操作是可选的
  • 如果stub对应的是远程接口,此方法是必要的;如果stub对应的是本地接口,此方法是可选的
  • 如果在不需要的情况下(例如访问本地接口的EJB时)使用了此方法,系统可以正常运行,但不推荐使用;如果在必需的情况下(例如访问远程接口的EJB时)没有使用此方法,那么系统会抛出ClassCastException

2 EJB引用

  • 根据EJB2.0规范,使用本地的JNDI上下文(javacomp/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_CMPCMP connection factory实现和数据库的绑定。

2. MDB/JMS的部署
MDB/JMS
的部署在不同的平台上会有所差别,但我们并不需要关心这种差别,只需要关心他们在WebSphere上的配置情况,详细步骤请查阅参考文档3174176页。

3. 本地接口的使用
WebSphere中使用本地接口的EJB,需要在部署描述符中配置本地引用,并在客户端代码中使用前缀为"java:comp/env/"的本地JNDI上下文进行JNDI查询。

4. J2EE 基于表单的认证

  • WebLogic使用weblogic.servlet.security.ServletAuthentication类实现基于表单的认证;
  • WebSphere使用J2EE规范中的 j_security_check Servlet进行基于表单的认证。

三、 客户端的移植问题

户端的构成多种多样,可以是ServletJSPJava ApplicationDelphi 客户端等等,而客户端程序和服务器端程序通信的方式也是多种多样,可以通过HTTPRMI/IIOPSOAPWeb 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("java:comp/UserTransaction")

5、客户端程序所需要的EJB interfacesstubs

  • 推荐的方法
    a)
    将这些文件添加到客户端的JAR文件当中,或者

    b)
    将这些文件打包到新的JAR文件中,然后再将此JAR文件添加到CLASSPATH当中
  • 动态下载interfacesstubs
    RMI
    协议提供了动态下载interfacesstubs的功能,但存在很多限制,所以不推荐使用

四、 数据映射

1、使用第三方的数据绑定技术(如TopLinkHibernateCastorKodo等等)可以在一定程度上提高可移植性

2CMP CMR

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

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1426358次
    • 积分:19339
    • 等级:
    • 排名:第462名
    • 原创:490篇
    • 转载:19篇
    • 译文:2篇
    • 评论:191条
    最新评论
    文章分类
    文章存档