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