Set up and deploying a new UDDI Registry

Set up and deploying a new UDDI Registry

Overview

Start the Installation of WebSphere Application Server and create the profile for your application server (for example, server1) to be used to host UDDI.
You have a choice of deploying either a default UDDI node, or a user customized UDDI node.
A default UDDI node would be a suitable option for initial evaluation of UDDI and for development and test purposes. With a customized UDDI node, you have more control over the database management system used for the UDDI database, and the properties used to set up the UDDI database. With a user customized UDDI node, you create the UDDI database and datasource to your own specifications, and then use the uddiDeploy.jacl script to deploy the UDDI application.
The main difference between default and user customized, in the context of these set up tasks, refers to a number of vital UDDI properties. For a default set up these vital properties are automatically set to default values and are not changeable by the user. For a user customizable set up, the user is given an opportunity to set these vital properties, but once set they cannot be changed for this configuration.
If you are setting up a UDDI node for production use, refer to Database considerations for production use of the UDDI Registry for information about choosing a database type.
The main guidance for deploying UDDI, elsewhere in this information center, is written for a single server configuration. This basic guidance applies to all configurations, however the following sections provide additional guidance for other variations such as:

Network deployment
Moving from a single server to a network deployment configuration
Moving from a default to a customized node
Moving between database types
If you are installing into a standalone application server one can proceed to either Setting up a default UDDI node, or Setting up a customized UDDI node.
Important: Important
Note for DB2 users - Starting the WAS in which the UDDI Registry is deployed
On Unix and Linux platforms, before you start the WebSphere server that is hosting your UDDI DB2 application, run the db2profile script which is found in the home directory for your db2 userid, for example /home/db2inst1/sqllib/db2profile
Similarly when in a network deployment configuration and starting the server using the Deployment Manager, run the db2profile script before starting the relevant nodeagent.
The information above is true during initial set up and deployment of UDDI and also every time you start the application server or node agent. For this reason it is strongly recommended that you update the user profile for the user that will start the nodeagent and server to also execute the db2profile.
If running the profile manually type
. /home/db2inst1/sqllib/db2profile

Note: In the above example, notice that the '.' is followed by a single space character.
Deploying into a Network Deployment cell (but not a cluster)
The information in this section now applies to deploying into a cluster as well as a single server. For resources such as the JDBC provider and datasource, one can follow the guidelines for a non cluster configuration, however the resources may need updating on individual cluster members to correctly access the shared database for example.
It is important to note that the uddiDeploy.jacl script must be run with the Deployment Manager as the target.
If you are deploying into a network deployment cell one cannot create a default Cloudscape node using uddiDeploy.jacl. You may, however, manually create the default Cloudscape database (with a default profile) by following the instructions in Creating a Cloudscape database and adding the parameter 'DEFAULT' as the last argument.
You will not be able to use the default option on uddiRemove for a UDDI node that is deployed into an application server which is part of a Network Deployment cell. See Removing a UDDI Registry node for more information.
If you have a non default UDDI setup in a base application server, one can issue an addNode -includeapps command which will add the necessary definitions into the deployment manager.
Deploying into a cluster within a Network Deployment cell
The scripts uddiDeploy.jacl and uddiRemove.jacl can now be used in a cluster environment, so the information in this section can be ignored.
It is important to note that uddiDeploy.jacl and uddiRemove.jacl cannot be used in a cluster environment.
It is assumed a single database will be used for all members of the cluster.
You can follow the same guidelines for a non cluster set up in general for the resources such as the JDBC provider and datasource as described in this Information Center, but they may need updating on individual cluster members to correctly access the shared database for example.
The options that are available are:

Deploy UDDI into a standalone server, as described in this Information Center (using uddiDeploy), and then create a cluster using that server as a template for the other members.
If using an cluster that already exists, use the admin console or wsadmin for example (and not uddiDeploy.jacl), to deploy the uddi.ear across the cluster members, but follow the additional advice in the main instructions.

Changing from a base application server to a Network Deployment cell.
It is possible to move from a base application server to a network deployment cell using the standard addNode command. During the move, any applications may be lost unless you use the -includeapps option. This applies to all applications and not just UDDI applications. See the addNode command for details. This applies to a default or a customized UDDI node.
Moving from a default UDDI node to a user customized UDDI node.
After testing the UDDI deployment in a default UDDI node, one can move to a user customized node by recreating the database using the instructions in Setting up a customized UDDI node, but you must be aware that any data saved in the default node (policies, properties and user data) will be lost in the move.
Moving between Cloudscape, DB2 and Oracle databases.
If you decide to move between one type of database to another, the datasource of the old database will still have a JNDI name of datasources/uddids. You must either rename this JNDI name to something different, or delete the datasource before you define the new database, create the new datasource and initialize the database.

What to do next

You now have the choice of Setting up a default UDDI node orSetting up a customized UDDI node.

See also

Database considerations for production use of the UDDI Registry
Setting up a customized UDDI node
Setting up a default UDDI node
Creating a DB2 database for the UDDI Registry
Creating a Cloudscape database for the UDDI Registry
Creating an Oracle database for the UDDI Registry
Using a remote database for the UDDI Registry
UDDI Registry Installation Verification Program (IVP)