Removing a UDDI Registry node

 

Removing a UDDI Registry node

To completely remove a UDDI Registry node you need to remove the UDDI Registry application and delete the UDDI Registry database. However there may be situations where you only want to perform one of these tasks:

Removing the UDDI Registry application from an application server.

You might want to do this in order to reinstall the application because it has become corrupted for some reason, or to apply service. See also the topic on Reinstalling
the UDDI Registry application.

Deleting the UDDI Registry database

You might want to do this in order to use a different database product as the persistence store for your UDDI data, to delete all your UDDI Registry data in order to publish fresh data (for example, if you have completed a test cycle), or to cause the UDDI Registry node to re-initialize with new UDDI property settings (for example, to move from a default UDDI node to a customized UDDI node). Note that deleting a UDDI Registry database will cause all UDDI data for that UDDI Registry to be lost.

Moving a UDDI Registry to another server or profile

You might want to do this if you have created a new profile and want to move the UDDI Registry to it.

Completely removing a UDDI Registry node from an application server

You might want to do this to remove a UDDI Registry that has been used for testing.

Depending on what you wish to achieve, complete one of the following steps:

  1. Removing a UDDI Registry application

    To remove the UDDI application from an application server, run the wsadmin script uddiRemove.jacl, as shown, from the install_root/bin directory.

    The syntax of the command is as follows (this is a Windows platform example; for Unix or Linux platforms, add the .sh suffix to the wsadmin command) :

    Note: If running in a network deployment configuration, the command must be run against the deployment manager profile.

    wsadmin -f uddiRemove.jacl                node 
                   server_name
                   [default]
            

    [Version 6.0]

    wsadmin -f uddiRemove.jacl                node 
                   server_name
                   [default]
            

    [Version 6.0.1 and later]

    wsadmin -f uddiRemove.jacl                {node server_name | cluster_name}
                   [default]
            
    where

    • node and server_name are the names of the WebSphere node and application server in which the UDDI application is deployed (these are the names that you specified when you ran uddiDeploy.jacl to install the UDDI application).

    • [Version 6.0.1 and later]cluster_name is the name of the WebSphere cluster in which the UDDI application is deployed. This is the name that you specified when you ran uddiDeploy.jacl to install the UDDI application.

    • 'default' is optional and is applicable only for Cloudscape in a standalone application server environment , and then only if the default option was used when the uddiDeploy.jacl script was run to deploy the UDDI Registry. Specifying default will remove the UDDI Cloudscape datasource but not the UDDI Cloudscape database.

    Output will appear on the screen by default. To direct the output to a log file, add '> removeuddi.log' (where removeuddi.log can be any log name of your choice) to the end of the command. For example, to remove the UDDI application from server 'server1' running in node 'MyNode' on a Windows system, and send any messages to the file removeuddi.log:

    wsadmin -f uddiRemove.jacl MyNode server1 > removeuddi.log
    [Version 6.0.1 and later]To remove the UDDI application from cluster 'MyCluster' on a Windows system, and send any messages to the screen:
    wsadmin -f uddiRemove.jacl MyCluster

    Note: You can also remove the UDDI Registry application using the administrative console in the usual way (select the application in the Enterprise Applications view and click Uninstall). If you are removing the UDDI Registry from a cluster in a version of WebSphere Application Server that is earlier than Version 6.0.1, use the administrative console method.

  2. Deleting a UDDI Registry database Note that this will cause all UDDI data in that UDDI Registry to be destroyed.

    1. Stop the server that is hosting the UDDI Registry application.

    2. Delete the database:

      • For DB2, use the database facilities to delete the UDDI database.

      • For DB2 for iSeries, use either iSeries Navigator or a 5250 Session to delete the 'IBMUDI30' and 'IBMUDS30' schema.

      • For Oracle, delete the schemas IBMUDI30 and IBMUDS30.

      • For Cloudscape, delete the directory tree containing the UDDI database. By default, this will be located in install_root/profiles/profile_name/databases/com.ibm.uddi/UDDI30.

  3. Moving a UDDI Registry to another server or profile

    1. Make sure that the UDDI database will still be accessible. For example if you are using a remote database make sure that the new server can access it. If your database will not be accessible, or it will be deleted after the move, copy it to a new, accessible location. For example, if you want to move
      the UDDI Registry to a new profile and then delete the old profile, any databases stored in the profile (such as a Cloudscape database created as part of the creation of a default UDDI node) will also be deleted.

    2. Remove the UDDI Registry application by running the uddiRemove.jacl script as described above.

    3. If you ran the uddiRemove.jacl script using the default option, the datasource and related objects have already been deleted. If the default option was not valid for your configuration, delete the following objects:

      • the UDDI datasource that references the UDDI Registry database (this was created when you set up the UDDI Registry).

      • any UDDI JDBC provider that was created (if you did not reuse an existing JDBC provider).

      • any J2C Authentication Data Entry that was created.

    4. In the new server create a J2C authentication data entry (if appropriate),
      JDBC provider and datasource, to reference the existing database (for more information see the relevant steps in Setting up a customized UDDI node).

    5. Deploy the UDDI Registry application as described in Deploying the UDDI Registry application, noting that you should not specify the default option even if you previously used this option to set up a default UDDI node. If you use the default option, you might encounter an error during deployment, or in some circumstances your existing UDDI data might be overwritten.

      Note: The UDDI node name will remain the same as before. If the UDDI node name included the node name and server name of the original server, there will be a mismatch between the UDDI node name and the node name and server name of the new server. However this name mismatch will not affect the functioning of the UDDI Registry node.

    6. Check that the UDDI data can be accessed. If you are using a copy of the original UDDI Registry database, you can now delete the original as described above.

  4. Completely removing a UDDI Registry node To completely remove a UDDI Registry node from an application server, you need to remove the UDDI registry application and database, and also the resources that were used to reference the UDDI Registry database.

    1. Remove the UDDI Registry application by running the uddiRemove.jacl script as described above.

    2. Delete the UDDI Registry database, as described above.

    3. If you ran the uddiRemove.jacl script using the default option, the datasource and related objects have already been deleted so no further action is required. If the default option was not valid for your configuration, delete the following objects:

      • the UDDI datasource that references the UDDI Registry database (this was created when you set up the UDDI Registry).

      • any UDDI JDBC provider that was created (if you did not reuse an existing JDBC provider).

      • any J2C Authentication Data Entry that was created.