Removing a UDDI registry node
We can remove the UDDI registry application, delete the UDDI registry database, move a UDDI registry to another server or profile, or remove a UDDI registry node completely.
A UDDI registry node consists of the following elements:
- An enterprise application.
- A store of data that is referred to as the UDDI registry database and that uses a relational database management system.
- A way to connect the application to the data, that is, a data source and related elements.
All the data that relates to UDDI is stored in the UDDI database and therefore that data is separate from the UDDI application. Therefore, there are several options when you remove a UDDI registry node:
- We can remove a UDDI registry node from the application server without deleting the database. You delete only the UDDI application and any associated resources, such as the data source, and J2EE Connector Architecture (J2C) authentication data if it is used. We might do this for the following reasons:
- You no longer want a UDDI facility on a particular application server. We can then move the UDDI registry node to a different application server.
- You want to reinstall the application, for example to apply service changes or because the application has been corrupted.
- We can delete the UDDI registry database. If we do this, all UDDI data for that UDDI registry is lost. We might do this for the following reasons:
- You want to use a different database product as the persistence store for the UDDI data.
- You want to delete all the UDDI registry data and publish fresh data, for example after you complete a test cycle.
- You want to initialize the UDDI registry node with new UDDI property settings, for example, to move from a default UDDI node to a customized UDDI node.
- We can move a UDDI registry to another server or profile.
We might do this after we create a profile and we want to move the UDDI registry to the new profile.
- We can remove a UDDI registry node completely from an application server. We remove the UDDI registry application, the UDDI registry database, and the resources used to reference the UDDI registry database.
We might do this to remove a UDDI registry used for testing after testing has finished.
To start a new UDDI registry node, we do not need to remove the UDDI application. Instead, we create a new replacement node by changing the data source that the UDDI application uses to access the new UDDI database.
Depending on what we want to do, complete one of the following steps.
Tasks
- To remove a UDDI registry node from the application server without deleting the database, complete the following:
- (iSeries) Start a Qshell session by entering the STRQSH command from the IBM i command line.
- Run the uddiRemove.jacl wsadmin script from the app_server_root/bin directory.
In a WebSphere Application Server, Network Deployment configuration, run the command when using the deployment manager profile.
The syntax of the command is as follows.
(UNIX) Note: For the UNIX or Linux operating systems, add the .sh suffix to the wsadmin command.
wsadmin [-profileName profile] -f uddiRemove.jacl {node server | cluster_name} [default](ZOS)wsadmin.sh [-profileName profile] -f uddiRemove.jacl {node server | cluster_name} [default]The attributes of the command are as follows:
- -profileName profile is optional, and is the name of the profile in which the UDDI application is deployed. If we do not specify a profile, the default profile is used.
- node and server are the names of the WAS node and the application server in which the UDDI application is deployed. These are the names specified when we deployed the UDDI application, for example when we ran the uddiDeploy.jacl script.
- cluster_name is the name of the WebSphere Application Server cluster in which the UDDI application is deployed. This is the name that we specified when we deployed the UDDI application, for example when we ran the uddiDeploy.jacl script.
- default is optional. Use this option only for the Apache Derby database in a stand-alone application server environment and only if we ran the uddiDeploy.jacl script and used the default option to deploy the UDDI registry. This option removes the UDDI Apache Derby data source but does not remove the UDDI Apache Derby database.
- Optional: By default, output is displayed on screen. To direct the output to a log file, add the following to the end of the command, where removeuddi.log can be any name chosen for the log file:
> removeuddi.log
(Dist) For example, to remove the UDDI application from server server1 that runs in node MyNode on a Windows operating system, and send any messages to the file removeuddi.log:
wsadmin -profileName myProfile -f uddiRemove.jacl MyNode server1 > removeuddi.log(Dist) To remove the UDDI application from cluster MyCluster on a Windows operating system, and send any messages to the screen:
wsadmin -profileName myProfile -f uddiRemove.jacl MyCluster(iSeries) For example, to remove the UDDI application from server server1 that runs in node MyNode and send any messages to the file removeuddi.log:
wsadmin -profileName myProfile -f uddiRemove.jacl MyNode server1 > removeuddi.log(iSeries) To remove the UDDI application from cluster MyCluster and send any messages to the screen:
wsadmin -profileName myProfile -f uddiRemove.jacl MyCluster(ZOS) For example, to remove the UDDI application from server server1 that runs in node MyNode and send any messages to the file removeuddi.log:
wsadmin.sh -profileName myProfile -f uddiRemove.jacl MyNode server1 > removeuddi.log(ZOS) To remove the UDDI application from cluster MyCluster and send any messages to the screen:
wsadmin.sh -profileName myProfile -f uddiRemove.jacl MyClusterWe can also remove the UDDI registry application using the administrative console in the usual way, by selecting the application in the Enterprise Applications view and clicking Uninstall.
- To delete a UDDI registry database, complete the following steps. Remember that all UDDI data in the UDDI registry is deleted.
- Stop the server that hosts the UDDI registry application.
- Delete the database.
- For DB2, use the database facilities to delete the UDDI database.
- (iSeries) For DB2 for i, use either Navigator for i or a 5250 session to delete the IBMUDI30 and IBMUDS30 schemas.
- (iSeries) For Oracle, delete the IBMUDDI, IBMUDI30 and IBMUDS30 schemas.
- For Apache Derby, delete the directory tree containing the UDDI database. By default, this directory tree is in the profile_root/databases/com.ibm.uddi/UDDI30 directory.
- To move a UDDI registry node to another server or profile, complete the following steps:
- Ensure that the UDDI registry database remains accessible after the move. We might need to copy the database to a suitable new location. For example, if the database is remote, the new server must be able to access it. Also, the database might be deleted after the move. This situation occurs if you move the UDDI registry to a new profile and then delete the old profile, because any databases that were stored in the profile are also deleted. An example of such a database is an Apache Derby database created as part of creating default UDDI node.
- Remove the UDDI registry application. See the step to remove a UDDI registry node from the application server.
- Optional: Delete the data source and related objects.
For the Apache Derby database, if we ran the uddiRemove.jacl script and used the default option to remove the UDDI registry application, the data source and related objects are deleted already and we do not need to complete this step. In all other situations, delete the following objects:
- The UDDI data source that references the UDDI registry database, that is, the data source created when we set up the UDDI registry.
- Any UDDI JDBC provider created if we did not reuse an existing JDBC provider.
- Any J2C authentication data entry.
- In the new server, if appropriate, create a J2C authentication data entry, and create a JDBC provider and a data source to reference the existing database. See the relevant steps in Set up a customized UDDI node.
- Deploy the UDDI registry application. See Deploy the UDDI registry application. If we use the supplied script, do not use the default option even if we used this option previously to set up a default UDDI node. Do not use the default option because an error might occur during deployment, or, in some circumstances, existing UDDI data might be overwritten.
The UDDI node name does not change. If the UDDI node name includes the node name and server name of the original server, after the move there is a mismatch between the UDDI node name, and the node name and server name of the new server. However, this mismatch does not affect the UDDI registry node function.
- Check that the UDDI data can be accessed. If we are using a copy of the original UDDI registry database, we can now delete the original database. See the step to delete a UDDI registry database.
- To remove a UDDI registry node completely, complete the following steps:
- Remove the UDDI registry application. See the step to remove a UDDI registry node from the application server.
- Delete the UDDI registry database. See the step to delete a UDDI registry database.
- Optional: Delete the data source and related objects.
For the Apache Derby database, if we ran the uddiRemove.jacl script and used the default option to remove the UDDI registry application, the data source and related objects are deleted already and we do not need to complete this step. In all other situations, delete the following objects:
- The UDDI data source that references the UDDI registry database, that is, the data source created when we set up the UDDI registry.
- Any UDDI JDBC provider created if we did not reuse an existing JDBC provider.
- Any J2C authentication data entry.
What to do next
If we removed a UDDI registry node from the application server without deleting the database, we might want to reinstall the UDDI registry application.
Reinstalling the UDDI registry application Deploy the UDDI registry application Uninstall enterprise applications using the console Set up a customized UDDI node