WebSphere客户端迁移的一般问题

现象：J2EE 应用在迁移时因为之前使用特定厂商的特殊实现，因此各种编译或者运行时的异常
原因：厂商实现的差别
解决办法：

一、 对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("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/