Editorial

Digg This!

The much awaited WebLogic Server 7.0 beta release was announced on Feb. 24, 2002, at BEA's eWorld conference in San Diego. Continuing in its path as the Number 1 Web application server, WLS 7.0 implements J2EE 1.3 technologies, Web services, and other Internet standards to provide a reliable framework for highly available, scalable, and secure applications.

WebLogic Server's seamless integration of disparate, heterogeneous platforms and applications enables your network to leverage existing software investments and share the enterprise-class services and data crucial to building mission-critical e-business applications. WLS 7.0 comes with very powerful features and enhancements in the area of Web services, clustered JMS, distributed destinations, and administration. BEA has completely rewritten the security infrastructure, J2EE connectors, and JCA adapters, and is offering some interesting new development tools.

Not only does it make sense to choose WLS 7.0 as the platform for enterprise e-business and integration application development and deployment, but also to upgrade from prior versions of WLS, whether 4.5.1, 5.1, or 6.1.

Special emphasis was placed on making sure that upgrading or migration to 7.0 is easy, straightforward, cost-effective, and, most important, that it doesn't require any code change in existing applications. WebLogic Server 7.0 comes bundled with power utilities that help with migration and upgrading and minimize the programmer or administrator's required intervention. This article makes an attempt to walk you through the step-by-step process to upgrade existing applications to WLS 7.0.

Upgrade from WLS 6.0/6.1 to WLS 7.0
The good news for upgrades from these versions is that you'll need to make little or no change to startup scripts and configuration repositories. Depending on installation, classpath options may need little or no change. Its no longer necessary to include the license file in the classpath. You should also have startup scripts in the domain directory itself. For the JVM version, WLS 7.0 installs 1.3.1_02 with server installation.

Installation/Configuration Changes
To provide greater flexibility in terms of configuration and management of application code and server systems, WebLogic Server 7.0 comes with a new structure for the domain directory. You're no longer required to have domains in the WebLogic Server installation directory. In fact, it's recommended to move the domains to a different directory while upgrading from 6.1 to 7.0. This directory structure change also comes with new startup scripts. Look for example startup scripts in the sample domains (PetStore and examples) created as part of installation.

Moving directory structure comes with ease of maintenance later on in the application life cycle but can be tricky while upgrading. Make sure that while moving directories, you identify all references to filepaths and resolve them to new filepaths. This is not an automated process.

Application/Deployment Changes
For the most part, all applications, exploded or archived, that were deployed in 6.x versions should work just fine with WLS 7.0. However, some considerations should be taken into account when upgrading applications.

Consider using local interfaces when migrating an EJB application from 6.0; they were included in 6.1. Also remote relations are not supported in 7.0. To upgrade an application from 6.0 to 7.0, you have to bundle all EJBs in EJB 2.0 CMP relations into one JAR file.

If WebLogic Server is used as a proxy to another WebLogic Server or cluster, it's recommended that you change the names of proxy servlets from weblogic.servlet.internal.Http ClusterServlet to weblogic.servlet.proxy.Http ClusterServlet, and from weblogic.t3.srvr.HttpProxyServlet to weblogic.servlet.proxy. HttpProxyServlet.

The WLS 7.0 distribution no longer includes the unmodified Xerces parser and Xalan transformer. However, WebLogic Server7.0 is bundled with WebLogic FastParser, specially written for SOAP and WSDL (small-to-medium) XML documents. Consider changing Xalan API references to JAXP. This will require code change but will help in future upgrades and maintenance of applications, as you won't be tied to vendor-specific code.

WebLogic's Java-COM bridge, JCOM, has also been upgraded. Its migration is very simple, as you're no longer required to write/install a bridge. Most of the command-line properties are no longer required or are configurable from the console.

Upgrading the security information is probably the single most complex upgrade in the exercise. WebLogic Server 7.0 ships with an embedded LDAP server enabled on the admin server in the domain. WLS 7.0 can automatically run in "compatibility" mode, allowing you to keep earlier versions' file-based security configuration for users, groups, and ACLs. It's up to customers to decide whether to keep the 6.1-based security realms or to upgrade to the 7.0 security framework to take advantage of some of the new features, such as a fully compliant JAAS authentication model and better configuration and administration for security constraints for applications. GA release of WLS 7.0 will provide automatic migration utilities to upgrade earlier version file-based security information to the new WebLogic Security Realm stored in an embedded LDAP server. However any storage medium can be used for authentication and authorization.

An application using "NULL" or "guest" user must change to specify a valid username. Alternatively for a guest user, you can configure "guest" as a valid user; however, a NULL user is no longer supported. This might require a code change in an application, but in general, production applications use valid security credentials and this change won't be required.

Web services have been improved to use the new JAX RPC-based API. The new model for client-side programming is standards-based and assumes that a Web services client can be written using the same API and standards using JAX RPC specification. WLS 7.0 even provides an optional Java client JAR file that includes all the classes, interfaces, and stubs that are needed on the client side. This JAR file includes the generic implementation of the JAX-RPC specification as well as Web service-specific implementations to minimize the amount of Java code needed to invoke a particular Web service. Benefits aside, however, this improvement means that your Web services clients written on 6.1-based Web services will have to be rewritten based on new JAX RPC-based APIs.

A WebLogic Web service has to be assembled and packaged in an enterprise archive EAR file. This includes assembling and packaging all the components of the service (such as the EJB JAR file, the handler classes, etc.) and generating the web-services.xml deployment descriptor file in a single deployable EAR file. Changes and enhancements in Web services runtime require repackaging for EAR files. WebLogic 6.1 provided the wsgen Ant task to automatically assemble all components for a Web Service in an EAR file. WebLogic 7.0 provides the servicegen Ant task to assemble an RPC-based Web service. For upgrading an RPC style 6.1 Web-Service component represented by an EAR file, the EAR should be reassembled using the new build XML script and Ant task.

Due to support for multiple back ends, the use of message-style Web services is no longer recommended. As the new Ant task, servicegen, and the new build script only support RPC-style Web services, message-style Web services can be upgraded in one of two ways. Either they can be rewritten using new multiple back-end support or a new EAR can be generated manually by carefully extracting the components from the old EAR file and editing deployment descriptors.

WebLogic Server 7.0 supports two-phase application deployment to ensure homogenous application deployment in clusters and also for better status reporting for success/failure of deployments. Old-style deployment will continue to work "as is" in WebLogic 7.0; however, use of the two-phase deployment model is recommended, as it is flexible and rich in terms of new features, such as application ordering, application-scoped configuration (a JDBC resource, for example), better deployment tracking and status, improved redeployment without loss of service, and flexible multiple options for application staging.

Suggested Design Changes To Implement During Upgrade

• WebLogic JMS takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments. This allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure. When upgrading, restructure your JMS framework to take advantage of these features.
• While upgrading or designing new JMS applications, consider distributed destinations. By enabling you to configure multiple physical destinations as members of a single distributed destination set, WebLogic JMS offers a level of redundancy, and therefore service continuity, in the event of a single Weblogic Server failure within a WebLogic Server cluster. Once properly configured, your producers and consumers are able to send and receive to the distributed destination. WebLogic JMS then distributes the messaging load across all available destination members within the distributed destination. When a destination member becomes unavailable, traffic is then redirected toward other available destination members in the set. However, producers and consumers that are pinned to a failed destination member must be closed and re-created.

• Upgrade your servlet code to take advantage of the new Servlet 2.3 spec ServletRequest/ ResponseWrapper objects. I strongly recommend using these objects in your design as some of the old code may not compile if it's dependent on undocumented internal WebLogic implementation details.
• While upgrading Web services, consider changing existing Web services applications to allow asynchronous (one-way) requests, access to request/response SOAP messages for further processing by handlers in the chain, user defined data types and SOAP attachment handling, all available with the new WLS 7.0 architecture. Figures 1-3 depict the various architectures supported by WebLogic Server 7.0.
• Selectively expose EJB methods via Web services rather than exposing all methods (a system limitation in 6.1 required you to expose all methods in a remote interface of an EJB).
• Consider configuring the staging and active directory name for each managed server. Consider using different staging modes that affect the file distribution for applications and allow using storage data networks or shared file systems for application staging. These are new parameters in support of the new two-phase deployment model. Old-style behavior can be achieved using the two-phase attribute on the ApplicationMBean defining the application.

Upgrading from WLS 4.5.1/5.1 to WLS 7.0
Installation/Configuration Changes
You must upgrade the existing license file from 4.5.1/5.1 to 6.1. This can be done online by submitting the old XML license file to http://websupport.beasys.com/custsupp. You can then run the utility UpdateLicense from the WebLogic bin directory to merge the newly obtained license with the existing license file.

WebLogic 4.5.1 and 5.1 used weblogic.properties files (global, per cluster, and per server weblogic.properties files) as configuration repositories for each individual server. From WLS 6.0 onward all configuration information for all servers in an administrative domain is stored in a single configuration repository named config.xml, which resides in the domain root directory on the admin server machine of the domain. The first task in upgrading is to convert all weblogic.properties files to a single config.xml file. This process seems very complex, tedious, and error-prone, but WebLogic provides conversion utilities and help from a GUI-based console that make it very easy and intuitive.

Start WebLogic Server 7.0 and follow the "convert weblogic.properties" hyperlink, which will navigate you through the entire process to convert all weblogic.properties files to a single domain config.xml file. During conversion all security information from weblogic.properties files is stored in the 6.1 style file Realm.properties. Servlets, JSPs, and other classes in the document roots of 4.5.1 and 5.1 are assembled in a Web application by a conversion utility and the web.xml and weblogic.xml files for the new Web application are generated.

Due to major overhauls in classloading in WLS 6.0 and above, startup scripts must change, as there is no more WebLogic classloader, and weblogic.class.path isn't required as a system property. Export of transitive closures of interfaces and class references in interfaces to WebLogic classloader made it difficult for EJBs to evolve in 4.5.1/5.1. The new classloading model provides more flexibility in terms of what can change in a running server. The new model supports a single classloader for each application, thereby allowing a single application as a deployment/redeployment unit.

WLS 6.0 and above provides new configuration and administration models, thereby requiring some rework around writing new startup scripts for admin and managed servers. There is little in terms of migration that can be used from existing 4.5.1 and 5.1 startup scripts.

Application/Deployment Changes

• Assemble the Web component in the format shown below to deploy a Web application as an individual component or part of a J2EE application archive.

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


• Session cookie information and session persistence properties have moved from weblogic.properties to weblogic.xml of the respective Web application. This allows multiple Web applications to have different session attributes. The conversion utility automatically creates a weblogic.xml for the Web application generated by conversion utility.

• The WLS 7.0 EJB container supports EJB 1.1 and EJB 2.0 beans. However it is recommended that new development be done with EJB2.0. WebLogic 5.1 supported EJB 1.1, so EJBs deployed in WebLogic 5.1 can be directly deployed in WLS 7.0. which has a stricter XML parser. Some errors allowed by earlier versions are no longer permitted.
• You can upgrade EJB 1.0 deployment descriptors used in WLS 4.5.1 to EJB 2.0 using the DDCreator and DDConverter utilities, but first those descriptors must be upgraded to 1.1. Using DDConverter utilities, WLS 5.1 deployment descriptors can be upgraded to 7.0 to take advantage of new features in WLS 7.0.
• An EJB deployment includes a standard deployment descriptor in the ejb-jar.xml file. The ejb-jar.xml must conform to either the EJB 1.1 DTD (document type definition) or the EJB 2.0 DTD.
• An EJB deployment requires the weblogic-ejb-jar.xml file, a WLS-specific deployment descriptor that includes configuration information for the EJB container. This file must conform to the WLS 5.1 DTD or the WLS 7.0 DTD. In order to specify the mappings to the database, container-managed persistence entity beans require a CMP deployment descriptor that conforms to the WLS 5.1 CMP DTD, the WLS 7.0 EJB 1.1 DTD, or the WLS 7.0 EJB 2.0 DTD.
• For a JMS upgrade follow these steps:

1. WebLogic 7.0 provides a JMS configuration conversion utility that should be used to port the 4.5.1/5.1 style weblogic.properties-based JMS configuration to the new config.xml-based configuration. Once your configuration information is converted, the JMS administrator needs to review the resulting configuration to ensure that the conversion meets the needs of the application, and adjust the values, if necessary.
2. In WLS 5.1, the JMS data and durable subscriber information was kept in five database tables that were accessible via JDBC. In WLS 7.0, JMS queues are defined during configuration, and no longer saved within database tables. Message data and durable subscriptions are stored either in two JDBC tables or in a directory within the file system. The JDBC database store content format from WLS 5.1 is not compatible with WLS 7.0.
3. Update existing code, as required, to reflect the feature functionality changes. For example, the createQueue() and createTopic() methods do not create destinations dynamically; they create only references to destinations that already exist, given the vendor-specific destination name.
4. Start up WebLogic Server, and the existing JDBC database stores are ported automatically. If the automatic porting fails for any reason, it is retried the next time WebLogic Server boots.

• Use java.rmi.Remote instead of weblogic.rmi. Remote and java.rmi.*Exception instead of weblogic.rmi.*Exception. Also, weblogic.rmic must be used to generate new stubs and skeletons.Old stubs and skeletons are not compatible with WLS 7.0.

• For security, the conversion utility creates the FileRealm.properties file from user, group, and ACL information in the weblogic.properties file(s). This gets you to the point of 6.1-style security realm. To convert this file to a WEb Logic Server 7.0-style WebLogic Realm and to store this information in embedded LDAP or another security repository, follow the instructions for upgrade from 6.x to 7.0.

A number of APIs were deprecated in WLS 7.0, so consider changing your design to use a recommended replacement API or deleting the API and rewriting your code to accommodate the change (see Table 1).

Recommended Design Changes During Upgrade
It is recommended that you introduce a new server instance that will act as administrator of the entire domain. Segregate the administration and application work to different server instances.

You may wish to use J2EE-compliant application assembly and deployment rules rather than individual component deployment. WLS 7.0, being a J2EE-compliant application server, supports application deployment for enterprise archives or individual components such as Web applications, EJB, and J2EE connectors. These applications and components can be deployed in exploded or archived format (.ear, .war, .rar, or .jar depending on component). A format for an enterprise application is shown below.

EnterpriseApplicationStagingDirectory\
|
+ .jar files
|
+ .war files
|
+ .rar files
|
+META-INF\-+
|
+ application.xml

You may wish to use local interfaces to boost performance and bundle EJB and Web applications in a single application archive while upgrading.

Consider better abstraction for database entities using powerful object-to-relational mapping provided by the EJB 2.0 CMP relational model. The CMP relational model is easier to configure and manage in WLS 7.0 using WebLogic Builder, and comes with huge performance enhancements for relational database queries.

Consider using Data sources and TxDataSources for JDBC access from EJB instead of the JDBC 1.0 API or the WebLogic connection pool using pool or JTA JDBC drivers provided by WebLogic. Data sources allow your applications to be more configurable, as well as portable, across server platforms.

You may wish to reconfigure your JMS applications to take advantage of new attributes, templates, and logical abstractions in JMS applications. JMS is a clustered service from version 6.0 onward. Also review the design considerations in the JMS upgrade from 6.x to 7.0 (all of them apply here too).

Using user-defined queues for dispatching incoming requests may be appropriate. User-defined queues were introduced as a publicly supported feature in 6.1.

Conclusion
All existing applications, with the exception of Web services, will continue to work fine on WLS 7.0, without any penalty on performance or features that were available in earlier versions. However, as described in this article, you should consider the proposed design changes to optimize new architecture and features. Migration is a good opportunity to consider making such changes. There is a small learning curve in understanding the new security and deployment model and distributed JMS destinations.

I think some time and resources spent on re-architecting applications heavily based on those features will pay off in the form of flexibility, standards-based implementation, and overall better reliability, scalability, and availability for the system. As always, BEA Professional Services and BEA Support can help with any specific migration questions and/or migration assignments.