Migrating to Version 3 of the UDDI Registry

Use this topic to migrate to a Version 3 UDDI Registry that uses a DB2 database, from a previous version of the UDDI Registry.

Use this topic to migrate to a Version 3 UDDI Registry that uses a DB2 database, from a Version 2 UDDI Registry (as defined in UDDI Registry Terminology).You can use the process described in this topic to migrate a UDDI Registry to UDDI Version 3, running in WebSphere Application Server Version 6, subject to the following constraints:

• Your existing registry uses a DB2 database.

• Your existing registry runs in WebSphere Application Server Version 5 or later.

If you are migrating from IBM WebSphere UDDI Registry Version 1.1 or 1.1.1, which ran on WebSphere Application Server Version 4, you should first migrate to UDDI Version 2 running on WebSphere Application Server Version 5 (as described in the WebSphere Application Server Version 5 Information Center), then complete the steps described in this topic.

You can only run the Version 2 UDDI Registry (supplied in WebSphere Application Server Version 5) in a WebSphere Version 6 server if you are running in a mixed cell migration mode. In this configuration, the WebSphere Application Server Version 6 Deployment Manager manages the version 5.x nodes, and the Version 2 UDDI Registry is supported only for migration purposes; it is not supported for normal execution.

This task describes in detail the process of migrating from a Version 2 UDDI Registry running on WebSphere Application Server Version 5, to a Version 3 UDDI Registry running on WebSphere Application Server Version 6.

If you have the UDDI Registry deployed in a clustered application server and you migrate to WebSphere Application Server Version 6, you will not be able to run UDDI across the mixed-version cluster. You can continue to run the UDDI Registry on the server or servers that remain at Version 5 of WebSphere Application Server, but you will not be able to run the UDDI Registry in the Version 6 servers of WebSphere Application Server until all
nodes in the cluster have been migrated to WebSphere Application Server Version 6. This is because the UDDI data needs to be migrated from the UDDI Version 2 format to the UDDI Version 3 format.

If you are migrating the UDDI Registry from a WebSphere Application Server version 5.x Network Deployment configuration, or from a WebSphere Application Server version 5.x standalone application server, the steps are very similar. For a Network Deployment migration to a WebSphere Application Server version 6 Network Deployment configuration, a number of choices are available, including having a mixed version cell where the WebSphere Application Server version 6 Deployment Manager can manage application servers at different levels. In this way, individual application servers can be migrated when convenient in a step by step manner. See Migration overview for more details.

To migrate a Version 2 UDDI Registry to UDDI Version 3, running in WebSphere Application Server Version 6, complete the following steps (this is assuming that you have migrated the WebSphere Application Manager Version 5 Deployment Manager to Version 6 first):

1. Stop the UDDI Registry application that is running in your Version 5.x application server. This prevents further UDDI requests being directed to the UDDI Registry and ensures that no new data is published during the migration process.

2. Record information about the

   uddi.properties values being used. This file is located in the DeploymentManager_install_dir/config/cells/cell_name/nodes/node/servers/server_name directory on your WebSphere Application Server Version 5.x system (or in the properties subdirectory if you are migrating a standalone application server).

3. Migrate from WebSphere Application Server Version 5.x to Version 6 (see Migration overview). This results in a new directory tree for the migrated Version 6 application server.

4. Start the new migrated (Version 6) application server.

5. Create a new datasource for the Version 2 UDDI database. This is known as the UDDI migration datasource . Note that the JNDI name must be

   datasources/uddimigration. To complete this step see Setting up a UDDI migration datasource.

6. Follow all the instructions in Setting up a customized UDDI node, including its subtopic relating to node initialization, to set up the UDDI Version 3 Registry and migrate the Version 2 data. The topic describes how to perform the following actions:

   • Create the Version 3 DB2 database

   • Create the J2C authentication data entry

   • Create the JDBC provider and datasource

   • Deploy the UDDI registry application

   • Start the server

   • Configure and initialize the node. The UDDI Registry node initialization detects that there is a UDDI migration datasource, and migrates the Version 2 data as part of the UDDI node initialization processing.

     Note: This can take some time depending on the amount of data in your UDDI Registry.

7. Verify the migration process has completed successfully. The following message should appear in the server log:

   CWUDQ0003I: UDDI registry migration has completed

   Should the following error appear:

   CWUDQ004W: UDDI registry not started due to migration errors

   it means that an unexpected error has occurred during migration. The UDDI Registry node will not be activated. Check the error logs for the problem and, if it cannot be fixed contact your IBM representative for advice.

8. Once migration is complete the UDDI migration datasource may be removed, and the registry is available for use.

Related tasks
Setting up a customized UDDI node