博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
WebSphere客户端迁移的一般问题
阅读量:2495 次
发布时间:2019-05-11

本文共 3573 字,大约阅读时间需要 11 分钟。

现象: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_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("java:comp/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)的映射。
 
总体上来说,WAS的使用难度较WLS大很多
文中提到的“Java Application客户端使用IIOP请求访问WebSphere应用程序服务器,则只能使用WebSphere专用的JDK”
和“而IIOP协议则为应用程序带来了更好的移植性”
看起来前后矛盾噢

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-410069/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-410069/

你可能感兴趣的文章