升级到WebLogic Server 7.0
等待已久的WebLogic Server 7.0 beta版终于在2002年2月24日圣地亚哥的BEA eWorld会议上发布，延续了其第一号网络应用服务器的美誉， WLS 7.0实现了J2EE 1.3技术、网络服务和其它互联网标准，为高可用、可扩展、以及安全的应用提供了可靠的架构。
WebLogic Server对不同的、异种平台和应用的无缝集成，使您的网络能够利用已有的软件投资、共享企业级服务和数据，以创建关键任务型电子业务应用。WLS 7.0在网络服务、JMS集群、分布式目的地以及管理方面带来了功能强大的新特性和增强。BEA彻底重写了安全体系结构、J2EE连接器、JCA适配器，并且提供了颇具吸引力的新开发工具。
重要的是，我们不仅需要了解WLS7.0作为一个企业电子业务和集成应用开发部署平台的优势，而且需要了解如何从WLS以前的版本4.5.1、5.1或6.1升级到WLS7.0。
特别强调的是，确保升级或移植到WLS7.0易于进行、直接、并且节省费用。最重要的是无需对已有应用的代码进行任何修改。 WebLogic Server 7.0产品包含了功能强大的实用工具，能够帮助完成移植和升级，使编程人员和管理人员的干预最小化。
本文将对已有应用向WLS 7.0移植的过程和步骤进行讨论
从WLS 6.0/6.1升级到WLS 7.0
好消息，从这些版本升级只需对启动脚本（startup script）和配置库做少量修改或根本无需修改。依赖于安装选项，classpath可能需要少量改动或无需修改。在classpath中包含许可证文件（license file）已非必要。启动脚本（startup scripts）应该放在应用域目录内。而, WLS 7.0在服务器安装时的 1.3.1_02 JVM 版本。
安装/配置修改
为了提供应用代码和服务器系统配置和管理的最大灵活性，WebLogic Server 7.0提供了新的应用域目录结构。 在WebLogic Server安装目录中您不再需要有应用域。实际上，在从6.1向7.0升级时，推荐将应用域移至不同的目录中。目录结构的变化导致新的启动脚本。可以查看安装时创建的应用域样例（PetStore 和例程）中的启动脚本样例。
目录结构的改动将为以后的应用生命周期的维护带来很大的方便，但在升级过程中可能会复杂。确保在移动目录时，识别所有对路径（filepath）的引用，并将其替换为新的文件路径（filepath）。因为这不是自动完成的。
应用/部署修改
在6.x版本上部署的所有应用的大部分部件，无论分散的或是打包，应该与WLS7.0工作良好。然而，当升级应用时，还是应该进行详细考虑。
考虑移植6.0版的EJB应用时采用本地接口，6.1版也提供这些接口。目前7.0不支持远程关系（remote relation）。为了从6.0升级到7.0，必须将在EJB2.0的CMP关系中的所有EJB打包到一个JAR文件中。
如果WebLogic Server用作到另一个WebLogic Server 或集群的代理，那么建议将代理servlet的名字从WebLogic.servlet.internal.Http ClusterServlet修改为WebLogic.servlet.proxy.Http ClusterServlet，并且从WebLogic.t3.srvr.HttpProxyServlet修改为WebLogic.servlet.proxy. HttpProxyServlet。
WLS 7.0正式版本载体中不再包含原始的Xerces解析器（parser）和Xalan转换器（ transformer）。但是，WebLogic Server7.0捆绑了WebLogic FastParser，一种特别为SOAP和WSDL (小到中规模) XML文档编写的解析器。 这时需要考虑将Xalan API修改成JAXP。这将需要修改代码，但对未来应用升级和维护有帮助，因为，您肯定不愿意锁定在厂商特定代码上。
WebLogic的Java-COM桥（ bridge）,称为 JCOM也进行了升级。它的移植非常简单，不再要求编写和安装桥。大多数命令行属性不再需要或可通过控制台进行配置。
项目中单个最复杂的升级可能是安全信息升级。
WebLogic Server 7.0在发货时就内嵌了将在应用域的管理服务器上运行的LDAP服务器。WLS 7.0能够自动以“兼容”模式运行，这样允许您保留早期版本中的基于文件的对用户、组和ACL（访问控制表）安全配置。由用户决定是保留基于6.1安全域，还是升级到7.0安全架构，从而能够利用一些新特性，如彻底兼容的JAAS认证模型和更好的应用安全限制配置和管理。WLS 7.0公开发现版将提供自动移植实用工具，将原有的基于文件的信息移植到存储在内嵌的LDAP服务器中的新型WebLogic 安全域（Security Realm）。但是，任何存储媒体均可用于认证和授权。
采用"NULL" 或"guest"应用的用户名必须修改为有效用户名。替代访客用户的方法是将"guest"配置为有效用户。无论如何，不再支持NULL用户。这就要求修改应用代码。但通常情况下，生产系统采用有效安全证书，使得这种修改没有必要。
网络服务（Web service）已经进行了改进，采用新的基于JAX RPC的API。新的客户端编程模型基于标准，并假定网络服务客户端可以采用同样的JAX RPC规范中的API和标准编写。WLS 7.0甚至提供了一个可选的Java客户端JAR文件，其中包含了所有客户端需要的类、接口和根（stub）。
此JAR文件包含了JAX-RPC规范一般的实现和特定网络服务的实现，以使激活特定网络服务的Java代码量最小。尽管有这样的好处，这种改进将意味着基于6.1网络服务编写的网络服务客户端必须基于信贷基于JAX-RPC的API进行重写。
WebLogic网络服务必须在企业档案库EAR文件中集成和打包。这意味着在单一的可部署的EAR文件中集成和打包所有服务组件（如EJB JAR文件、处理程序类等）并生成web-services.xml部署描述文件。网络服务运行库的修改和增强要求对EAR文件重新打包。WebLogic 6.1提供了wsgen Ant 任务能够自动在EAR文件中集成所有网络服务组件。WebLogic 7.0提供了servicegen Ant 任务以集成基于RPC（远程过程调用）的网络服务。为了将一个EAR文件代表的6.1网络服务组件升级到RPC方式，EAR文件需要采用新建的XML脚本和Ant任务重新集成。
至于对多个后端的支持，不再推荐采用消息型网络服务。由于新Ant任务servicegen以及新建脚本只支持RPC类型的网络服务，消息型网络服务将采用两种方式之一进行升级，两种均可采用新的多后端支持重写，或通过手工精心从旧式EAR文件中抽取组件并编辑部署描述。
WebLogic Server 7.0支持两阶段部署以确保集群的应用同质部署并提供部署成功/失败最佳的状态报告。旧式部署在WebLogic 7.0中仍能继续使用，但是，建议采用两阶段部署模型，因为两阶段部署具有灵活丰富的特性，如应用次序、应用范围内的配置（例如，JDBC资源），更好的部署跟踪和状态，改进的重写部署而不会失去服务，灵活多样的应用分阶段上线选项。
升级实施中的设计修改建议
* WebLogic JMS利用了WebLogic Server集群环境核心实现的迁移架构，这使得WebLogic JMS能够对迁移请求进行适当的响应，并以一种有序的方式启动和退出JMS服务器。这种架构包括预先安排的迁移和针对WebLogic Server失败响应进行的迁移。当升级时，重新调整JMS架构以充分利用这些特性的优势。
* 当升级或设计新的JMS应用时，请考虑分布式目的地。通过使您能够为单一分布式目的地集合配置多个物理目的地方式，WebLogic JMS提供了冗余，因而在WebLogic Server集群中单个WebLogic Server失败的情况下，提供了服务的连续性,适当配置之后，消息生产者和消费者就能够通过分布式目的地发送和接收消息。WebLogic JMS将在分布式目的地的可用目的地成员之间分配消息负载。当一个目的地成员不可用时，通讯流量将导入到集合的其它可用成员目的地。然而，固定在失败目的地成员上的生产者和消费者必须关闭并重新创建。
*升级您的servlet代码以利用新的Servlet 2.3规范中ServletRequest/ ResponseWrapper对象的优势。我强烈建议在您的设计中采用这些对象，因为如果依赖于未建文档的WebLogic内部实现细节，则旧式代码可能不会通过编译。
* 当升级网络服务时，考虑修改已有网络服务应用，使其能够：异步（单向）请求、为处理链的下一步访问请求/应答SOAP消息、用户定义数据类型和SOAP附件处理，这些功能在新的WLS 7.0体系结构中都可用提供。 图1-3描述了WebLogic Server 7.0所支持的各种体系结构
*有选择地通过网络服务公开EJB方法，而不是公开所有方法（6.1系统限制要求公开EJB中所有远程接口的方法）。
* 考虑配置预演和每个被管理服务器的活动目录，考虑采用采用不同的预演模式对应用文件发布的影响并允许采用预演存储数据网络或共享文件系统进行预演预演。
有一些新参数支持新的两阶段部署模式，旧式行为模式能够采用两阶段部署属性ApplicationMBean定义应用。
从WLS 4.5.1/5.1 升级到WLS 7.0
安装/配置修改
您必须将4.5.1/5.1版的许可证升级到6.1。可以通过将旧式XML许可证文件提交到http://websupport.beasys.com/custsupp完成。然后运行WebLogic bin目录下的实用工具UpdateLicense将新获得的许可证与已有的许可证文件合并。
WebLogic 4.5.1和5.1 采用WebLogic.properties文件(全局、每个集群、和每个服务器相应的WebLogic.properties文件)作为每个服务器的配置库。从WLS 6.0开始，所有一个管理应用域的所有服务器的所有配置信息将存储在单一的命名为config.xml的配置库中，这个文件将驻留在应用域管理服务器的应用域根目录下。升级的第一个任务是将所有WebLogic.properties文件转换到一个单一的config.xml文件。这个过程看上去似乎非常复杂、冗长并且容易出错，但是，WebLogic提供了转换工具，采用图形化控制台使转换工作即简单又直观。
启动WebLogic Server 7.0，按照"convert WebLogic.properties"超级连接说明，将引导您通过将所有WebLogic.properties 文件转换到单一应用域config.xml文件的全过程。
在配置转换过程中，所有WebLogic.properties文件中与安全相关的所有信息将被存储在6.1风格的文件Realm.properties中。所有Servlet、JSP以及 4.5.1 和 5.1文档根目录下的其它类被转换工具集成到一个网络应用中（Web application），并为新的网络应用生成web.xml和WebLogic.xml 文件。
由于WLS 6.0及以后版本中classload主要的检查功能改变，不再有WebLogic classloader，并且WebLogic.class.path不再要求作为系统属性，所以启动脚本必须进行修改。过渡性接口的输出和接口中对WebLogic classloader 类引用使得4.5.1/5.1中的EJB升级十分困难。新的classload模型在针对运行中的服务器变化方面提供了更大的灵活性，新模型支持每个引用使用单一classloader，因此，使单一应用能够成为部署/重新部署的基本单元。
WLS 6.0及以上版本提供了新的配置和管理模式，所以管理服务器和被管理服务器相应的启动脚本需要重新做。已有的 4.5.1 和5.1启动脚本几乎不能利用。
应用/部署修改
* 将网络组件以下列显示的格式集成并作为J2EE应用档案库的单独组成部分部署。
WebApplicationRoot\(Publicly available files such as
| .jsp, .html, .jpg, .gif)
| +WEB-INF\-+
|
+ classes\(directory con
| taining Java classes
| including servlets
| used by the
| Web Application)
|
+ lib\(directory containing
| JAR files used by the
| Web Application)
|
+ web.xml
|
+ WebLogic.xml
* 会话cookie信息和会话持久特性已从WebLogic.properties移到特定网络应用的WebLogic.xml中。
这样，多个网络应用可用具有不同的会话属性。转换实用工具将自动为转换工具生成的网络应用创建WebLogic.xml文件。
* WLS 7.0 EJB容器支持EJB 1.1和EJB 2.0的bean. 但是，我们建议新开发的应用采用EJB2.0。 WebLogic 5.1支持EJB 1.1，所以在WebLogic 5.1上部署的EJB可以直接部署在WLS 7.0上，EJB2.0具有更严格的XML解析器。某些早期版本容许出现的错误不再允许。
* 可以采用DDCreator 和DDConverter实用工具将WLS 4.5.1中的EJB 1.0部署描述升级到EJB 2.0，但这些描述符必须首先升级到1.1。采用DDConverter实用工具，可以将WLS 5.1部署描述升级到7.0，以利用WLS 7.0的新特性的优势。
* EJB部署包含了ejbjar.xml文件中标准的部署描述。ejb-jar.xml必须遵循EJB 1.1 DTD (文档类型定义)或EJB 2.0 DTD。
* EJB部署还需要WebLogic-ejb-jar.xml文件，这个文件包含了WLS特定的部署描述说明EJB容器的配置信息。这个文件必须遵循WLS 5.1 DTD 或WLS 7.0 DTD。为了说明到数据库的映射关系，容器管理的持久性实体Bean要求CMP部署描述必须遵循WLS 5.1 CMP DTD、 WLS 7.0 EJB 1.1 DTD,或WLS 7.0 EJB 2.0 DTD。
* JMS升级采用下列步骤:
1. 采用WebLogic 7.0提供的JMS配置转换实用工具，将WLS4.5.1/5.1风格基于WebLogic.properties的JMS配置转换为新的基于config.xml配置。当配置信息被转换后，JMS管理员需要对生成的配置进行审查，以确保转换后配置满足应用的需要，如果必要时调整参数值。
2. 在WLS 5.1中，JMS数据以及永久订阅信息被保存在五个数据库表中，通过JDBC进行访问。在WLS 7.0中，在配置时定义了JMS队列，不再需要存储到数据库表。消息数据和永久订阅消息或者存储到两个JDBC表中，或者存储到文件系统的一个目录中。WLS5.1中JDBC数据库存储内容格式与WLS 7.0不兼容。
3. 已有代码升级要求能够反映特性功能的变化。例如，createQueue()和createTopic() 方法不能动态创建目的地；它们只通过给定的目的地名，创建到已有目的地引用。
4. 启动WebLogic Server，已有的JDBC数据库存储会自动移植。如果自动移植由于某种原因失败，那么在下一次WebLogic Server启动时重试.
* 用java.rmi.Remote替换WebLogic.rmi. Remote ，java.rmi.*Exception替换WebLogic.rmi.*Exception。并且，必须采用WebLogic.rmic 生成新的stubs 和skeletons。旧式stub和skeleton与WLS 7.0不兼容。
* 对于安全性，转换实用工具将从WebLogic.properties文件的用户、组和ACL（访问控制表）信息创建FileRealm.properties文件。
这只是到达了6.1版的安全域。要将这个文件转换到WebLogic Server 7.0形式的WebLogic Realm（安全域）并将这些消息存储在内置的LDAP或另一个安全库中，应按照6.x到7.0升级说明进行。
一些API在WLS 7.0中不赞成使用。所以需要考虑采用推荐的替代API修改设计，或删除这些API重新编写代码以适应修改（参见 表1）。
升级过程中修改设计建议
建议引入一个新服务器实例作为整个应用域的管理服务器。即将管理和应用分配到不同应用服务器实例。
您可能希望采用J2EE-兼容的应用集成和部署规则，而不是个别组件的部署。WLS 7.0是一个J2EE-兼容的应用服务器，支持企业档案库和个体组件应用部署，包括网络应用、EJB、和J2EE连接器。这些应用和组件可以采用分散或档案库格式部署（.ear, .war, .rar, 或 .jar，依赖于组件）。. 企业应用格式如下：
EnterpriseApplicationStagingDirectory\
|
+ .jar files
|
+ .war files
|
+ .rar files
|
+META-INF\-+
|
+ application.xml
您可能希望采用本地接口以提高性能，并在升级过程中将EJB和网络服务捆绑到单一的应用档案库中。
考虑采用EJB2.0 CMP关系模型提供的功能强大的对象到关系数据库映射（OR Mapping）获得更好的数据库实体提取。
在WLS 7.0中采用WebLogic Builder工具，使CMP 关系模型更易于配置和管理，并带来关系数据库查询性能的显著提高。
考虑采用数据源（Data sources）和TxDataSources从EJB进行JDBC 访问，取代JDBC 1.0 API 或WebLogic 连接池或采用WebLogic提供的JTA JDBC驱动程序的连接池。数据源（Data sources）使应用更易于配置、移植和跨服务器平台。
您可能希望重新配置JMS应用，以利用JMS应用的新属性、模版和逻辑抽象的优势。JMS从6.0版本开始成为集群服务。也需要评估JMS从6.x向7.0升级过程中的设计考虑。所有考虑均适用于这里。
采用用户定义队列分发进入请求可能比较合适。用户定义队列是6.1版支持的新特性之一。
结论
所有已有应用，除网络服务例外，在WLS 7.0平台上能够很好地运行，而不会丧失性能和原有版本的特性。但是，正如这篇文章描述的那样，应该考虑这里的设计修改建议，以优化新的体系结构并利用新特性的优势。移植过程正是考虑修改的机会。要了解新的安全、部署模型以及分布式JMS目的地功能还需要更深入的 学习。
我认为，重新设计应用的体系结构需要需要消耗时间和资源，并且很大程度上依赖于这些特性在系统灵活性、基于标准的实现、整体的可靠性、可扩展性和可用性方面的回报。
BEA专业服务和BEA技术支持一如既往，能够为您的特定移植问题和/或移植任务提供帮助。
版权(c) 2002 SYS-CON Publications, Inc.
|
|
