IBM WebSphere Application Server version 8 (WAS 8) has been available for a while now, and so organizations are now evaluating whether to migrate of their application servers and applications to the newest version. IBM supplies tools to help with migration of a WAS profile from WAS 7 to WAS 8, which are simple if used correctly.  

Application server vendors like IBM upgrade their software like WAS to be in sync with the latest JEE specification. The following table shows the fundamental difference in specification levels between WAS 7.0 and 8.0.

The drivers for migration usually are:

• Old version of application server product going out of support
• Availability of new capabilities and improved performance levels of the newer version of product as supported by the JEE APIs implemented in a given release of WAS.

For some organizations, their applications may not require any specific changes. However for others this could be huge project, involving many application dependencies all relying on the JEE frameworks used in application design. Not only do their needs have to be considered for migrating application servers, but there is a clear need to migrate applications as well. Though related, the migration of application servers and applications may not be part of the same project deliverable.  An important point to note is application migration requires careful consideration.

Application migration is a huge and complex area due to many reasons. JEE has grown into a very vast set of application programming interfaces. JEE specification is upgraded continuously and with each release.

• New API’s, classes and methods are added to satisfy ever growing needs
• Some API’s, classes and methods are deprecated
• Some API’s, classes and methods are removed following deprecation in earlier releases
• Changes in behavior of some of the methods

 As part of the application migration process, one might also want to migrate the application’s supprintg databases, administration/deployment scripts, move to newer hardware and operating system etc.  If the JEE application uses vendor specific classes, then migration from one application server to another is even more challenging.  Even within WebSphere application server, migration of complex topologies that involves Job Manager and Deployment managers needs to be planned and executed carefully.

Note: Many organizations are skipping migration of WAS 6.1 to WAS 7 and are instead going straight to WAS 8. This is quite a jump and the intricacies are many, too much for succinct article on a WAS 6.1 to WAS 8 migration.

Migration tools

IBM provides several tools to make migration from an earlier version as smooth as possible. WAS v8.0 migration tools support the migration from WAS v6.0, v6.1 and v7.0.  See Figure 1, which explains the application of these tools.

There are many things to be migrated, but the most important things are:

• Migration of application server configuration (profile)
• Migration of applications

Figure 1

The Migration wizard is a GUI based tool, just like the profile management tool.  It internally uses the same set of programs used by WASPreUpgrade.sh and WASPostUpgrade.sh, which are command line scripts. To perform the migration of application server configuration in silent mode, one can use the command line scripts WASPreUpgrade.sh and WASPostUpgrade.sh.   

The Application migration tool is available as eclipse feature and can be installed into eclipse version 3.5 or higher. This toolkit can also be installed in Rational Application Developer version 7.5 to 8.5. This tool is a rule-based code analyzer and when run against an eclipse project, can identify issues that can impact migration of the application to the newer version of WAS. The tool also can automatically fix certain types of issues. With the help of this tool, one case migrates applications to the newer JEE specification very quickly. The migration wizard can also deploy the applications as it is in the new application server, but this may not work in many cases.

Migrating standalone application server

WebSphere Application Server supports the following topologies

• Standalone application server
• Administrative agent topology
• Network Deployment topology
• Job Manager topology

As an example, let us migrate a standalone application server profile called “appsrv03” that hosts a single application called EStore.  This application is a simple test application that uses derby database. This is the simplest case possible, but definitely helps us to understand the migration process.  Once this is done, one can plan for complex migration scenarios involving other types of topologies with ease.

During the migration, based on your requirements, you might want to reuse the port numbers used by the older profile.  The migration tool helps in this aspect as well. 

Configuration migration is a three step process as shown in Figure 2.

Figure 2

1. Execute WASPreUpgrade.sh tool and create backup directory
2. Create a new target profile using PMT/manageprofiles.sh
3. Execute WASPostUpgrade.sh tool and complete migration

Executing WASPreUpgrade.sh

The WASPreUpgrade.sh script copies the configuration of WAS 7.0 version of appsrv03 profile to a directory. This backup can then be utilized by WASPostUpgrade.sh script to complete the migration.  Note that this backup is not the same as the one created by backupConfig command. This backup mainly acts as the staging directory for migration and is tailor-made for migration. Remember to execute these scripts from /bin directory of WAS 8.0.

Creation of the new WAS 8.0 profile can be done any time before running WASPostUpgrade.sh script, though I have mentioned the profile creation as the second step.

Note that the WAS 7.0 version of appsrv03 (old profile) is not touched during the migration, so it is possible to roll back to the old version at any point in time, if you face any issue.  See below:

The following parameters are passed in this example

• backupDirectory -  directory where the tool stores the configuration
• Installation directory of WAS 7.0
• Profile name

Another parameter called “-machineChange=true” can be included if the target profile (WAS 8.0 version of appsrv03) is to reside in a different machine. This parameter forces WASPreUpgrade.sh to copy files that reside outside WAS product and profile directories to the backup directory. These files are then restored to the original location in the new machine by WASPostUpgrade.sh tool.

Let us inspect the files created in the backup directory, seen below. 

 

The tool creates a directory called logs and writes the log messages related to the migration within this folder.  This can be used for troubleshooting purposes. 

The tool writes the command that was issued in the log file. This serves as a record and helps in troubleshooting.  The first few lines of the WASPreUpgrade...log file is shown below.

 

The file PreUpgradeInfo.props also captures the arguments passed toWASPreUpgrade.sh.  The content of this file is shown below.

Create a WAS 8.0 standalone application server profile

The creation of the WAS 8.0 profile that should serve as the target for migration has to be done manually. The migration tools will not do this. So let us create a new WAS 8.0 standalone application server profile using PMT.

When you come to Port Values Assignment screen while using the profile creation wizard you need not worry about assigning the same ports as the WAS 7.0 version of appsrv03 profile. Accept the default values and proceed. Later on when we use WASPostUpgrade.sh tool, we can select to use ports from the source profile. (See Figure 3.)

Figure 3

Executing WASPostUpgrade.sh command

We completed the creation of a new WAS 8.0 standalone application server profile. Now run WASPostUpgrade.sh command. This command supports “-replacePorts true” option which maps the ports from the source to the target profile. When there is a port conflict, WASPostUpgrade.sh tool automatically uses the next higher port value.  It is also possible to provide a base port number with the help of “-portBlock” parameter for the allocation of new ports. If you do that, any new port numbers assigned will start from the base port number.

The “–includeApps true” parameter forces the tool to install user applications also. Due to this we expect EStoreApplication.ear to be automatically installed in the target profile when we execute WASPostUpgrade.sh.

The sample applications are always ignored by WASPostUpgrade.sh tool and are not migrated.

Now the migration is completed.  Next, run the Jython script called printWasPorts()to obtain the port numbers of the target profile. The ports listing of the target profile shows that they are modified by WASPostUpgrade.sh script and now match the ports in the source profile. The various columns present here are profile name, node name, server name, port number and port name.

Now check whether WASPostUpgrade.sh has created the necessary resources in the target profile. First, shutdownthe server in the source profile. This is necessary as both the source and target servers share the same port numbers.  The server in the target profile is started.

Figure 4 below shows that the JDBC provider is created by the migration tool.

Figure 4

Figure 5 shows the data source created by the tool.

Figure 5

Next, check the application, as seen in Figure 6.

Figure 6

The test application EStoreApplication works fine after the migration.  But, the test application is a very simple web application and hence worked as expected without any code modification. See Figure 7 below to see how the application should look.

Figure 7