Migrating to Pramati Studio

In today's fast changing technology, while new releases are needed to stay ahead of competition and also in-step with the EJB and J2EE specifications, applications cannot be built again and again. Pramati Studio allows a migration path from other J2EE development environment ide and other application server platforms into a new Desk or an existing Desk in Studio. This chapter describes how to use the Migration tool.

From Migration to Deployment

Enabling developers to deliver robust, and fast J2EE applications, Studio provides an integrated full lifecycle solution that allows applications to be migrated from different ides and application servers, and then deployed on yet other servers. The image below explains the complete lifecycle of how Studio can be used to migrate, develop and then test-deploy applications.

How Migration Works

All the J2EE archives and their corresponding sources are used to create Studio Desk. The Migration Tool organizes the sources as per the Desk semantics, moving all the EJB components into an EJB Module, the Web components into a Web Module and the remaining sources into a Java Module. Source package hierarchy is also enforced during the process.

The Migration tool creates an EJB Module for each EJB JAR and a Java Module for each Utility JAR. A Web Module is created for each WAR, containing all the Web components. If the WAR contains other supporting classes, then a Java Module is created and all the sources are stored inside the module.

Pending Tasks

Tasks that could not be resolved during migration are displayed as Pending Tasks. These include tasks like

No source file found for a class

The CMP Queries in the Proprietary Languages, which can not be converted

Resources to be added on the server

Migration Report

A report is generated for each migration in the Desk directory. The report provides a summary of the migration and gives a fair estimate of the tasks to be completed after the Migration, if any. This report also provides an estimate of the non-J2EE and also the proprietary API usage in the code. It can be accessed via UI in the Staging Area or from the following location in the file system - <desk_dir>/Migration.report, where <desk_dir> is the Desk Root of the target Desk. The Report consists of the following sections:

Desk Structure This section contains the names of the Desk Modules that were created per Archive.

J2EE Components Contains the information about the J2EE components found. For example - the number of CMP 2.0, CMP 1.1, BMP, JSP etc. This section also contains the number of CMP fields and finder queries. This information maybe used in deciding the amount of work needed for OR-MAP.

Proprietary Package Usage Contains information about usage of the Server Specific Proprietary API in the code.

Pending Tasks Lists all the pending tasks that are yet to be resolved.

Staging

The Migration tool can create a Pramati Studio 3.0 Desk in two different modes, With or Without Staging. Performing migration with Staging allows the user to customize the Desk to be created using the temporary Desk that is displayed on the left side of Studio. Staging gives the user greater control on the structure of the target Desk, and also helps resolve all the Pending Tasks with the appropriate UI. For example tracing missing sources or writing queries.

When a module is moved from the Staging area to the destination Desk, all the meta-data required are also moved transparently. Moving files individually requires the user to move the corresponding meta-data files separately. For example, the ejb-jar.xml in EJB Module. To know more about working with Staging, refer the section Starting Migration.

Types of Migration

There are two types of migration that are supported in Studio - Generic and Specific application Server migration.

Generic Migration In this type of migration, the Desk is created using the J2EE and utility archives and their corresponding sources. The Desk created in this case, contains only the packaging information, and does not contain any deployment information.

The Desk created here can be deployed using the Deploy Tool using Tools > Deploy from the main menu. When the Deploy tool comes up, all information required for deploying the application is completed using the Deploy tool. Since, all the deployment information is filled in Pramati Studio 3.0, the Migration tool can be used to migrate sources and archives from practically all J2EE environments.

Specific Application Server Migration In this type of migration, the Desk is created using the packaged archives and deployable archives from other servers with package and deployment time information. The Desk created in this case, is always in a "ready-to-deploy" state and can be deployed using the Express Development feature.

The Migration tool supports migration of packaged archives and deployable archives from the following application servers:

BEA WebLogic 5.1

BEA WebLogic 6.1

Sun Reference Implementation 1.2

Configuring Migration Tool

To migrate application from different J2EE environments and other application server platforms, and then develop the same with additional features in Studio, the Migration tool needs to be configured in Studio. Click on Tools > Configure from the main menu. In the Tools Configure dialog that comes up, check against the option - Migrate, and close the dialog box. This brings up the Migration tool in Studio menu bar.

Starting Migration

To bring up the Migration tool, select Tools > Migration from the main menu. When the Migration tool comes up, enter the following information to start migrating:

The first panel that comes up comprises two sections: - Migrate From and Migrate To.

Migrate From Select the type of migration to be used in this section. The list shows all the supported types of migration. To migrate to a Pramati Studio 3.0 Desk without the deployment information, select the Generic Archives. The deploy tool can then be used to complete the deployment Information.

To migrate from one of the listed application servers, select the specific server. Migrating in this case contains all the deployment information.

Migrate To This section comprises all the information about the target Desk and information about the migration process.

Select from the two options Create New Desk and Use Existing Desk to decide the target Desk.

Name Selecting Create New Desk allows the name of the Desk to be entered in this field. Selecting the option Use Existing Desk displays a list of all the open Desks in Studio.

Directory This option is enabled only when the option Create New Desk is selected. Browse and select the location to store the Desk.

Use Staging Check this option to use staging in the migration process. The Staging option facilitates the users to customize the Desk structure created. Using this option shows the discovered Desk to the user in a separate panel called the Staging Area, and the target Desk in Studio.

When the Staging Area comes up, the user can choose the modules or files required in the target Desk and customize the target Desk. It gives the user the freedom to merge the content of two or more modules into one module, or create multiple modules using the content of a single module.

Migrating into Pramati Studio 3.0 Desk after un-checking the option Use Staging, converts the discovered Desk into the target Desk directly. Click Next after filling all the information in the panel.

The second panel that comes up requires all the archives and/or the source directories to be selected for migration. The source directories contain all the sources for the archives selected.

The checkbox is selected when all the sources not corresponding to classes in the archives are to be migrated. These migrated source files are then stored in a Java module called "RemainingSources". These sources may be the sources corresponding to the clients or tests cases.

The third panel that comes up displays the migration progress. To cancel migration at any stage, click Cancel. During migration, if multiple sources are found for a single class, the user is prompted for the right file.

After the migration process is complete, the Staging Area comes up, if the option Use Staging was checked in the first panel. If the Use Staging option was un-checked in the first panel, the Staging Area does not come up and the target Desk is created automatically in Studio.

The Staging Area that comes up resizes Studio to fit in the screen. The Staging Area shows the discovered Desk and a set of pending tasks. The target Desk is displayed in Studio.

To move modules/files from the discovered Desk to the target Desk, select one or more files in the Staging Area, and a single node in the target Desk, and click the forward arrow button. This moves the selected files from the discovered Desk to the target Desk. Modules can also be moved to the target Desk using this button. To undo and redo the tasks, use the Undo and Redo buttons in the Staging Area. To move the entire Desk from the discovered Desk to the target Desk, select the Desk root node in the Staging Area and click the forward arrow icon.

Resolving Pending Tasks

All the pending tasks that could not be automatically resolved during migration are displayed in the Pending Tasks area. To resolve the pending tasks, double click on the pending task in the Pending Tasks list. A dialog comes up, that can be used to resolve the task. For example if the pending task is a missing file, then the file chooser dialog box pops up, which can be used to select the file. After the task has been resolved, it is removed from the Pending Tasks list and the Generated Migration Report.

No source files found for a class is treated as a pending task. A query in a proprietary language, which cannot be converted to a query for Pramati Studio 3.0, is also treated as a pending task. Resources to be added to the Desk are also shown as Pending tasks.

Staging Restrictions

In order to maintain the Desk semantics, there are some restrictions in moving file(s)/folder(s) to the target Desk from Staging Area:

If a module is moved to a target Desk, then irrespective of the target node selected the module always is moved to Desk Root node.

If the target node is the Desk Root node and the selected node in the Staging Area is not a module, then the move is invalid and the selected nodes are not moved to the target Desk.

If the node selected in the target Desk is a file node, then the selected items are moved to the to its immediate parent node (which could be a normal folder or module).

Making the Migrated Desk "Ready-to-be-Deployed"

Add the resources using the Resources Tool, only in case Staging was not used to migrate. Using the Staging option to migrate, displays this as a pending task.

Change the sources to remove the Proprietary API usages, if any.

Add the required classpaths.

Compile all the files using Clean Build.

Use Bean Properties panel to modify and complete the packaging and deployment information.

WebLogic 6.1 Migration Restrictions

Some points to be kept in mind, while migrating source files from WebLogic 6.1 are:

Studio does not expose the local JNDI names of the beans. It takes the LOCAL JNDI name to be JNDIName_local. Therefore, while migrating WebLogic 6.1 sources, the JNDI names if present are made the JNDI name of the bean.

If JNDI name is not present, then the local JNDI name is used as the JNDI name. When the code uses the local JNDI name, sources are to be changed accordingly.

The information about the Third Party JMS Server used is not extracted during migration. It must be configured in the server configuration for each server.