Chapter 2   Migrating Applications


This chapter describes the procedures required to redeploy iPlanet^TM Application Server 6.0 SPx applications to iPlanet Application Server 6.5.

iPlanet Application Server 6.5 programming model is for Java applications only. C++ applications continue to use the NAS 2.1 model. Note the following compatibility issues:

• Due to changes in the compiler used to build iPlanet Application Server 6.5, AppLogics based applications on Solaris® will have to be recompiled to run on 6.5.

• iPlanet Application Server 6.5 is backward compatible with NAS 2.1 applications. NAS 2.1 applications can run on iPlanet Application Server 6.5 without code alteration.

• iPlanet Application Server 6.5 is compatible with NAS 4.0 applications with conversion to the J2EE standard. NAS 4.0 applications do require some conversion.

This chapter describes the following topics:

• Migrating 6.0 SPx applications to 6.5

• Migrating NAS 4.0 Applications to iPlanet Application Server 6.5

• Migrating NAS 4.0 Applications to iPlanet Application Server 6.5

• Migrating NAS 2.1 Applications to iPlanet Application Server 6.5

Migrating 6.0 SPx applications to 6.5

---

Follow the procedures described in this section to migrate your iPlanet Application Server 6.0 SPx to iPlanet Application Server 6.5.

The following topics are covered in this section:

Before You Start

Before starting the migration process, ensure that:

• Install additional OS/JDK/Compiler patches as documented in the Release Notes for iPlanet Application Server 6.5.

  The Release Notes are available at http://docs.iplanet.com/docs/manuals/ias.html.

• Meet the Software and Hardware requirements as listed in iPlanet Application Server Installation Guide.

• Check that you have followed all the prerequisites for installing iPlanet Application Server as listed in iPlanet Application Server Installation Guide.

• Take backup of deployed applications' .ear, .war, .jar, .xml files and Applogics by copying them to a temporary directory.

  Usually, all the deployed .ear or .war files will be under iASInstallDir/ias/JAR directory.

• Note the changes that have been done to the scripts/batch files on the 6.0 SPx application server.

  This will be required if you want to replicate those changes in 6.5 also. For 6.0 SP1 and SP2 users, it is important to know that there is a single script where most of the environment parameters are maintained: iasenv.ksh.

  The iasenv.ksh script is available under the iASInstallDir/ias/env directory. You will have to replicate the changes done in the other scripts (e.g. kjs, kxs, etc.) to iasenv.ksh.

• Take backup of LDIF files used to create users for deployed applications.

  If LDIF files are not available, ldif-to-db export can be taken from the directory server. This is required if the bundled directory server will be used for storing both the configuration and user data.

During Installation

After you have the steps in Before You Start, uninstall the previous version of iPlanet Application Server and restart the machine (Windows only).

While installing iPlanet Application Server 6.5, you must specify the same configuration information as those used with the previous installation. For example, specify the same number of engines, ports, database drivers, cluster information, etc. This will ensure that your old application server settings are retained.

For more information on the installation procedure, see iPlanet Application Server Installation Guide.

Post Installation Tasks

After installation, perform the following procedures to deploy your applications. These points are common to both J2EE and Applogic applications:

• Transactions support for iPlanet Native (Type 2) drivers is no longer available.

  Therefore, you will have to use 3rd party drivers for transactional support. This will not affect Applogics (Java/C++).

• For global transactions, you will have to upgrade the database. For example, if you are using Oracle, Oracle 8.1.7 or later is required.

  See the list of certified databases and clients in iPlanet Application Server Installation Guide.

• If you are using JDK1.2 on the Rich client side, you must migrate to JDK1.3.

  You should remove all references to the old ORB by removing iioport.jar, rmiorb.jar, etc., from the classpath or from the ext directory.

  You must also copy j2eeorb.jar to ext directory or place it in the classpath. The old iasclient.jar and orb.properties has to be replaced with those available in iPlanet Application Server 6.5.

  For more details, see iPlanet Application Server Developer's Guide.

The following section describes procedures specific to J2EE and Applogic applications:

• Deploying J2EE Applications

• Deploying Applogic Applications

Deploying J2EE Applications

Follow these steps to deploy your J2EE applications on iPlanet Application 6.5:

• Regenerate stubs and skeletons for J2EE applications and repackage them to .ear, .war and .jar files using either command line option (deploycmd) or by using the Deployment Tool.

• Deploy the applications on iPlanet Application Server 6.5.

• Ensure that the correct database drivers are installed.

  If not, create database drivers using the Administration Tool, as documented in iPlanet Application Server Administrator's Guide.

• Register the datasource XMLs using the iasdeploy -regdatasource option.

• Create users in the directory server for the deployed applications. This step is required if you are using the bundled directory server for configuration and user data.

• Reconfigure iPlanet Application Server 6.5 using the Administration Tool or by editing the registry.

  This step is required if you have modified the configuration of the previous installation and want to replicate them in the new installation. (Optional)

• Modify iasenv.ksh (on Solaris), or the specific batch file (on Windows) according to your need. (Optional)

Deploying Applogic Applications

Follow these steps to deploy Applogic applications on iPlanet Application 6.5:

• Recompile C++ applications on Solaris.

  If re-compilation gives an error, then the application needs to be re-worked as the C++ code should follow ANSI/ISO C++ standard. On Windows, re-compilation is not necessary since there is no change in the compiler.

Migrating NAS 4.0 Applications to iPlanet Application Server 6.5

---

NAS 4.0 uses Netscape and older Java standards which have been replaced with J2EE 1.3 standards in iPlanet Application Server 6.5. You need to replace deprecated methods and redeploy your applications with the new XML descriptors. Tools are provided to help with the process. For more information, see Chapter 5 "Running NAS 4.0 Applications."

Migrating NAS 2.1 Applications to iPlanet Application Server 6.5

---

Migration involves altering an application written for the NAS 2.1 programming model so that it conforms to the iPlanet Application Server 6.5 programming model. There are three approaches to this process, each of which is covered in this document:

• No migration. This approach involves no actions by the developer and depends solely on backward-compatible support by the server. This is an acceptable approach if you do not want to take advantage of the flexibility and power that the new standards-based model provides, although many of the APIs supported in NAS 2.1 are now deprecated and may not be supported in future releases.

  Backward-compatibility is described in ."

• Partial migration. In this approach, part of the application conforms to the new programming model, while the rest relies on backward-compatibility. This enables developers to migrate one portion of an application at a time (for example, one level of interaction with a user, or one programming tier) while still retaining the portions of the application that are known and tested.

  iPlanet Application Server 6.5 supports partial migration by providing "glue" between the old components and the new components. This support is described in

• Complete migration to the new programming model. This approach requires a lot of development resources and involves a full redesign, but it enables the application to take full advantage of the features of the new programming model.

  This approach is described in ."