将J2EE操纵程序移植移植办法和常见问题[Java编程]

        引言

　　有关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利用程序.在阅读完本文后,倡议大家先从试验动手,完成参考文档中的样例程序,从而对移植任务有一个越发具体的理解.

　　移植办法

　　1、 学习WebSphere Studio Application Developer,拜见参考文档1.

　　2、 从利用程序中挑选出最具代表性的子系统

　　1、这个子系统应当全面涵盖系统的技术难点,拜见常见的问题

　　2、归纳总结系统所需的配置和所依靠的类库

　　3、 解析此子系统的架构,澄清此中各个模块之间的依靠关系

　　1、 包含业务模块之间的依靠关系,以及Web模块和EJB模块等程序模块之间的依靠关系等.

　　2、 假如利用程序中存在过量的穿插引用关系,可以考虑在一定程度上调整系统的架构和文件组织构造,尽大概避免模块之间的穿插调用.

　　3、 一定要避免运行在同一个JAVA虚拟机的多个模块中包含相同JAVA 类或类库的多个副本.

　　4、 将这个剥离出来并重新调整过的子系统打包,并在原有的J2EE 服务器上考证其可用性

　　1、在原有J2EE服务器上可以单独运行此子系统

　　2、将系统的配置和所需的类库,针对WebSphere重新筹划,为了可以有效地完成这一步骤,我们必须先熟习WebSphere的基本概念,包含WebSphere classloader的体系构造,拜见参考文档2.

　　3、测试通过的子系统打包成EAR文件,导入到WebSphere Studio Application Developer中,按照任务视图所供应的错误提醒,修复全部构建时的错误.WebSphere Studio Application Developer供应了一个非常超卓的错误诊断机制,可以让开辟人员轻松的定位并修复利用程序中存在的错误,并且按照错误的提醒,开辟人员可以在J2EE标准中便利的找到呼应的章节,查看具体信息

　　5、理解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文件的差别版本,假如本来系统里包含多个版本,则只保存此中一个便可.

　　6、调试子系统

　　1、先操纵WebSphere Studio Application Developer的通用测试客户机(UTC)对服务器端的EJB举行调试

　　2、客户端利用程序和服务器端利用程序对接,调试客户端程序

　　7、将子系统导出为EAR文件,公布到WebSphere利用程序服务器中,举行测试

　　8、预算移植剩余子系统的工作量,分工完成

　　9、集成测试

　　1、 对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之间不存在调用关系

　　2、 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举行基于表单的认证.

　　3、 客户端的移植问题

　　客户端的构成多种多样,可以是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的功效,但存在很多限制,所以不举荐利用

　　4、 数据映射

　　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)的映射

　　利用程序特定的问题

　　每一个利用程序城市有自己独特的地方,在移植历程中或多或少会呈现超越"常见问题"范围的其他问题,相信通过耐烦的调试都可一一办理.在今后的文章里会介绍我们在项目中碰到的特定的问题和办理办法.