WebLogic Server

BEA retired its WebLogic Server 5.1 on February 1, 2004. It had been supported for four years prior to retirement. One of the options for migrating applications that are running on 5.1 is to use WebLogic Server 8.1, which provides a range of new features for J2EE 1.3-based applications.

I'll give you an overview of the significantly important features in WebLogic Server 8.1 and the high-level activities involved in migrating applications from WebLogic Server 5.1 to 8.1.

New Features in WebLogic Server 8.1

JDBC Features
WebLogic Server 8.1 SP1 includes a new JDBC driver from BEA for connecting to a Microsoft SQL Server database. The BEA WebLogic Type 4 JDBC MS SQL Server driver replaces the WebLogic jDriver for Microsoft SQL Server that's been deprecated. The new driver:

• offers JDBC 3.0 compliance and better performance
• supports distributed transactions through XA support
• supports multilingual application development on any operating system platform to access both Unicode- and non-Unicode-enabled databases

Administration Features
WebLogic Server 8.1 provides a System Administration Console that's a web browser-based graphical user interface (GUI) to manage a WebLogic Server domain. One instance of WebLogic Server in each domain is configured as an Administration Server. The Administration Server provides a central point for managing a WebLogic Server domain. All other WebLogic Server instances in a domain are called Managed servers.

The features offered by WebLogic Server 8.1 System Administration Console are:

• Configure, start, and stop WebLogic Server instances
• Configure WebLogic Server clusters
• Configure WebLogic Server services such as database connectivity (JDBC) and messaging (JMS)
• Configure security parameters including managing users, groups, and roles
• Configure and deploy applications
• Monitor server and application performance
• View server and domain log files
• View application deployment descriptors
• Edit selected runtime application deployment descriptor elements

The Administration Console provides additional runtime data for servers running with the JRockit Virtual Machine.

Security Features
The SSL implementation of WebLogic Server supports KeyStores for storing Private Keys and trusted Certificate Authorities (CAs). KeyStores add a level of protection to the flat files used in past releases of WebLogic Server.

WebLogic Server 8.1 supports standard J2EE security technologies such as Java Authentication and Authorization (JAAS), Java Secure Sockets Extension (JSSE), and Java Cryptography Extensions (JCE).

Supported Standards
WebLogic Server 8.1 supports the Java standards shown in Table 1.

WebLogic Server 8.1 supports the Web Services Standards shown in Table 2.

Table 3 shows some additional standards supported in WebLogic Server 8.1.

Migration Strategy

Steps (Tasks) for Migrating from WebLogic 5.1 to WebLogic 8.1
Creation of a WebLogic Domain
A domain is the basic administration unit for WebLogic Server instances. It consists of one or more WebLogic Server instances that can be managed with a single administration server. A domain can include multiple WebLogic Server clusters or non-clustered WebLogic Server instances. A minimal domain can contain only one WebLogic Server instance, which functions as both an administration server and as a managed server. But, it's best to use a dedicated administration server and create one or more managed servers, depending on the applications.

Each server instance in a WebLogic environment must have a unique name, regardless of the domain or cluster in which it resides, or whether it's an administration server or a managed server. In a domain each server, machine, cluster, virtual host, and any other resource type must be uniquely named and must not use the same name as the domain. For WebLogic JMS, this strict unique naming rule also applies to JMS resources, such as JMS servers and stores in multi-domain environments when using the WebLogic Messaging Bridge or the Foreign JMS Server feature for intra-domain operability.

A simple production environment can consist of a domain with several managed servers that host applications and an administration server to do the management operations. In this configuration, applications and resources are deployed to individual managed servers; similarly, clients that access the application connect to an individual managed server.

Production environments that require increased application performance, throughput, or availability can configure two or more managed servers as a cluster. Clustering allows multiple managed server to operate as a single unit to host applications and resources.

The managed servers in a production WebLogic Server environment are often distributed across multiple machines and geographic locations.

Node Manager is a Java utility that runs as a process separate from WebLogic Server and lets you perform common operations tasks for a managed server, regardless of its location with respect to its administration server. While using Node Manager is optional, it provides valuable benefits if your WebLogic Server environment hosts applications with high-availability requirements.

If you run Node Manager on a machine that hosts managed servers, you can start and stop the managed servers remotely using the Administration Console or command line. Node Manager can also automatically restart a managed server after an unexpected failure.

A Node Manager process isn't associated with a specific WebLogic domain. Node Manager resides outside the scope of a domain, and you can use a single Node Manager process to start managed servers in any WebLogic Server domain that it can access.

WebLogic Server administration domain and server configurations can be created using the Configuration Wizard, which can also be used to configure resources like database connectivity (JDBC), Messaging Services (JMS), security groups, security roles, and user accounts. It can also be used to modify existing domains.

Understanding WebLogic Domain Directory Structure
The servers and applications in WebLogic Server 8.1 are managed in WebLogic Server domains. It's best to locate the domain directories outside the WebLogic Server installation directory. They can be in any location that can access the WebLogic Server installation and JVM. The tree in Figure 1 depicts the directory structure of a typical WebLogic domain.

Converting the WebLogic-related property files
WebLogic Server 5.1 used a "weblogic.properties" file to configure applications.

In WebLogic Server 8.1, configuration is handled by a domain configuration file, config.xml, and by deploying descriptor files. Converting a "weblogic.properties" file to the config.xml file creates a WebLogic Server 8.1 domain for your applications and generates the XML files that define how your applications are set up. The important things to consider for migrating a WebLogic property file from 5.1 to 8.1 are listed in table 4.

Location of the application-related property files
Every application - Web application or enterprise application - has its own property files that are meant to configure the application. These property files can be part of the application-related archive files (EARs or WARs) or they can be stored in the WebLogic Server 8.1 domain directory.

The WebLogic Server 8.1 domain directory will be the "Current Working Directory" for all applications deployed in a particular domain.

The property files that are common across different applications deployed in a particular WebLogic Server 8.1 domain can also be stored in the domain directory.

Modifying the Startup Scripts
When the WebLogic Server 8.1 domain is created using the "WebLogic Server 8.1 Configuration Wizard," four script files will be created:
- startWebLogic.cmd
- installService.cmd
- uninstallService.cmd
- setEnv.cmd

The "startWebLogic.cmd" script can be used to start the WebLogic Server in the console mode. This script is generally used for running the WebLogic server in development mode.

The "installService.cmd" script is used to install the WebLogic 8.1 administration server as a Windows NT service. The default Windows NT service name that's created when the "installService.cmd" script executes is "beasvc <domain name>_<server name>." Some tuning needs to be done in the "installService.cmd" script before installing the Windows NT service. Some of the changes that can be done are:

• Change the minimum and maximum memory to be used by the JVM for running the WebLogic 8.1 Server
• Add any JVM parameters that need to be passed
• Extend the classpath environment variable to include external classes or JAR files

Migration from JDK 1.3 to 1.4
WebLogic Server 5.1 was certified on JDK 1.3 whereas 8.1 is certified on JDK 1.4. As a result, all the application sources have to be migrated to JDK 1.4. The most commonly used method that's been deprecated in JDK 1.4 is the constructor for the "java.util.Date" class. The "java.util.Calendar" class has to be used to create the "java.util.Date" object.

Converting Applications to Enterprise Archives or Web Application Archives
Enterprise applications and Web applications could only be deployed in WebLogic Server 5.1 as exploded archive directories. They couldn't be deployed as archive files (EARs or WARs). With this approach, there was a good chance patches could be installed as individual class files or JSP files in the exploded archive directories.

WebLogic Server 8.1 supports deployments that are packaged either as archive files using the Jar utility, or as exploded archive directories. WebLogic Server 8.1 supports deployment of J2EE-specified standalone modules like Enterprise Java Beans and Resource Adapter modules. Standalone modules generally provide parts of a larger, distributed application, but don't necessarily provide a direct user interface.

WebLogic Server 8.1 supports deployment of all three types of J2EE applications, namely: Web applications, enterprise applications, and client applications. Table 5 provides information on the constituents in each type of J2EE application that can be deployed in WebLogic Server 8.1.

Recommendations

• Deploy standalone Web applications, resource adapters, and EJBs as part of an enterprise application. It allows easier application migration, additions, and changes.
• Deploy applications in exploded archive format only if:
  - Partial updates are necessary for the application without redeploying the entire application
  - The administration console has to be used for editing the deployment descriptors
  - The application performs direct file system I/O through the application context
  - The application contains static files that are periodically updated (for example, the use of Brio Reporting scripts as part of the Web application)
• Package deployment files in an archive format (.ear, .jar, or .war) when distributing files to different users or environments.

Upgrading Enterprise Java Beans Applications
WebLogic Server 5.1 supported J2EE Enterprise Java Beans (EJB) version 1.1. WebLogic Server 8.1 supports both EJB v1.1 and EJB v2.0. This means that the 1.1 Beans used in WebLogic Server 5.1 can be deployed on WebLogic Server 8.1. But, it's best to migrate EJB 1.1 Beans to EJB 2.0 Beans before deploying them on WebLogic Server 8.1.

To migrate applications from WebLogic Server 5.1 to 8.1, it's best to migrate the EJBs from v1.1 to v2.0. These minimal changes have to be made for migrating EJBs from v1.1 to v2.0 on WebLogic Server 8.1:

• Update the reference to DTD in the J2EE deployment descriptor (WEB-INF/ejb-jar.xml) to "<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>"
• Update the reference to DTD in the WebLogic deployment descriptor (WEB-INF/weblogic-ejb-jar.xml) to "<! DOCTYPE weblogic-ejb-jar PUBLIC "-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN" http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd" >"
• Change the INITIAL_CONTEXT_FACTORY property for JNDI Lookup to use "weblogic.jndi.WLInitialContextFactory"
• Change the PROVIDER_URL property for JNDI Lookup to use "t3://localhost:<port>"

Please refer to the J2EE specifications for EJB 2.0 and WebLogic documentation (http://e-docs.bea.com/wls/docs81/ejb/index.html) for the complete upgrade of EJBs from v1.1 to v2.0. The WebLogic Server DDConverter utility can also be used for converting EJB 1.1 Beans to EJB 2.0 Beans.

SSL Configuration Changes
The SSL Configuration has changed significantly from WebLogic Server 5.1 to WebLogic Server 8.1. Some of the important changes that have been made are:
- The Private Key file and the server certificate file can't be deployed as individual files in WebLogic Server 8.1. The Private Key file and the server certificate file have to be secured in a Java KeyStore before being deployed in WebLogic Server.
- The client certificate files can't be deployed as individual files in WebLogic Server 8.1. The client certificate files have to be secured in a Java KeyStore before being deployed in WebLogic Server.

The Private Key file in WebLogic Server 5.1 used to be in 'DER' format. It has to be converted to 'PEM' format before being imported into a Java KeyStore. These are the steps involved in converting a Private Key file that's in 'DER' format into 'PEM' format and loading it into a new Java KeyStore file:

1. Copy the Private Key file xenon-key.der and certificate file xenon-cert.pem into <Drive>:\tmp\certs directory
2. Create a text file called <Drive>:\tmp\certs\header.txt file and store the following information. Note that the header.txt file should end with a new line.
   -----BEGIN RSA PRIVATE KEY-----
3. Create a text file called <Drive>:\tmp\certs\footer.txt and store the following information. Note that the footer.txt file should end with a new line.
4. -----END RSA PRIVATE KEY-----
5. Open a command window
6. Run <Drive>:\bea\wls810\user_projects\domains\WSDomain\setenv.cmd
7. Change the directory to <Drive>:\tmp\certs and execute java utils.der2pem xenon-key.der header.txt footer.txt.

   A new file named xenon-key.pem file has to be created in <Drive>:\tmp\certs directory.

8. Import the Certificate-Key pair xenon-cert.pem/ xenon-key.pem files into a KeyStore file using the following steps:
   a. Copy the xenon-cert.pem into xenon-cert-chain.pem
   b. Append the contents of the VerisignRSACA root certificate (or any other root certificate) in Base 64 format to xenon-cert-chain.pem
   c. Execute the following command to create a new Private KeyStore:

java utils.ImportPrivateKey xenon.ks filepass xenonAlias keypass xenon-cert-chain.Pem xenon-key.pem

Check if the KeyStore is valid by opening it in the KeyTool GUI. The SSL setup in WebLogic Server 8.1 can be done using the administration console.

Summary

WebLogic Server 8.1 SP1 provides a stable environment for Web applications and enterprise archive applications. The WebLogic Server Administration Console, WebLogic Workshop, and the numerous other tools that are part of WebLogic Server 8.1 provide additional value when migrating or developing new applications on WebLogic Server 8.1. The steps mentioned in this article are some of the crucial tasks that architects and developers should be aware of while migrating or developing new applications on WebLogic Server 8.1.

Acknowledgements

I would like to thank Venkataraman Sridharan, Pankaj Khandar, and Asha Veerabhadraiah for their assistance in preparing this article. Special thanks also to Linnae DeSanto and Venkataraman Sridharan for providing feedback and peer, editorial, and technical reviews.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...