Cluster Configuration  Locate

This chapter contains general notes about the synchronized configuration of an Oracle Service Registry cluster and gives instructions on how to deploy Oracle Service Registry to a WebLogic Cluster (WebLogic specific configuration for use with cluster).

Cluster operation  Locate

Cluster operation is achieved by running multiple registries and joining their functionality with a load balancer (proxy).

Load balancing is used to distribute requests among registries to get the optimal load distribution. The load balancer should be configured to distribute requests among all physical endpoints of the registry nodes. If using an application server, refer to its documentation for details about configuring load balancing.

Figure 45. Oracle Service Registry in WebLogic Cluster

Oracle Service Registry in WebLogic Cluster

Clients to Oracle Service Registry access TCP ports on the balancer which forwards the connection to a running cluster node with an actual Oracle Service Registry. Each Oracle Service Registry has a connection to a common database so that each Oracle Service Registry has access to the latest data. This connection also serves as a distribution point for changed configurations and inter-node events.

When an Oracle Service Registry node fails (there are various reasons for this such as hardware problems, network connection problems or software failure), other nodes can work without it. The intelligent load balancer will detect this and further requests will not be directed there until the node starts to respond.

Every node has a Node ID - a string identifying the node. Each node should have a different ID. Breaking this rule will cause nodes with the same ID to miss some configuration changes and synchronization events.

Node ID can be specified by the administrator in the REGISTRY_HOME\app\uddi\conf\nodeid.xml file. If it is not specified before the initial start of Oracle Service Registry, it will be generated as a unique UUID string. It is possible to change it later, but node-local configurations under the old ID will be left in the database. Ensure that EAR/WAR file generated for deployment has either:

  1. Empty Node ID - so that each deployment of the file will generate a unique Node ID on first run and will retain it until deletion or redeployment of the EAR/WAR file. You can use the EAR/WAR file to deploy on all nodes.

  2. Specified Node ID - when you deploy the EAR/WAR file to a single node and generate another EAR/WAR file for others. You can choose meaningful names for Node ID this way.

You can set the Node ID in the nodeid.xml file before starting setup to generate EAR/WAR file. If you use generation of EAR/WAR file directly from installer the Node ID will be empty.


Latest configurations are identified by internal index sequencing. Time stamps of configurations as displayed in configuration management UI are not relevant as they may be unreliable in case of clock skew on a cluster node.

Cluster operation is affected by the interaction of connection security (HTTPS) and the load balancer. For security reasons, client access is done using the HTTPS protocol. This protocol requires that there is a valid and matching security certificate on the server side (possibly on the client side too if client authentication is required). There are generally two methods for achieving clustered operation via independent load balancer. If you deploy on an application server it may provide an integrated load balancer for you which may be easier to configure than an independent load balancer.

  1. Secure connection can take a place between a client and the load balancer. The load balacner is the end point for the secure connection which originated at the client. The load balancer will make an independent connection to some of the Oracle Service Registry nodes. This connection may be either in HTTP or HTTPS. The certificate which the client checks has to be placed on the load balancer. A connection between the load balancer and each Oracle Service Registry can be protected by HTTPS in which case the load balancer and the registries should know each others certificates.

    Figure 46. Security in cluster, method 1.

    Security in cluster, method 1.

  2. Secure connection can be passed by the load balancer and terminated at the cluster node. This case requires that the certificates on all the nodes be the same to provide the illusion of a single service. However the common name inside the certificate should specify the DNS name of the balancer.

    Figure 47. Security in cluster, method 2.

    Security in cluster, method 2.


Load balancer is not part of Oracle Service Registry product. You can use almost any HTTP/HTTPS load balancer that supports the described configurations.

Most of the Client - Oracle Service Registry interactions require an authentication token to be passed along the way. This token is encrypted by the Oracle Service Registry certificate. Therefore each Oracle Service Registry behind the balancer has to have the same certificate.

WEB interfaces of Oracle Service Registry (Registry Console) need to know the absolute HTTP addresses of themselves. This address in the cluster is the address of the load balancer and the possible context under which it is deployed. This address can be changed during setup.

Cluster installation  Locate

Cluster installation requires the setup of a load balancer and multiple registries. These steps are recommended on the Oracle Service Registry side when an application server is used:

  1. Install Oracle Service Registry.

    • Fill-in the hostname and ports of the load balancer.

  2. Port Oracle Service Registry via the Deploy option in the Oracle Service Registry Setup program (or directly in Installer program).

  3. Deploy the generated WAR or EAR to all cluster nodes via the application server.

These steps are recommended on the Oracle Service Registry side where multiple standalone instances of Oracle Service Registry are used:

  1. Install the first Oracle Service Registry.

    • Fill-in the hostname and ports of the load balancer.

  2. Setup SSL certificates as required in the first Oracle Service Registry.

  3. Install other Registries.

    • Do not create new databases, just connect to the database of first Oracle Service Registry.

    • Copy REGISTRY_HOME\conf\pstore.xml from the first registry to each Oracle Service Registry. This assures that each Oracle Service Registry will have the same identity with respect to authentication tokens.

    • Copy the configuration files in the REGISTRY_HOME\app\uddi\conf\ directory from the first Oracle Service Registry. This is requireded because some fields in the configuration files are coded by a key specified in application_core.xml. Failure to do so may result in error messages during startup and inconsistent configuration data in the database.

  4. Run the first installed Oracle Service Registry first so that its configuration files are stored in database first. The next time you can run the Registries in any order (including the first one).

Setting Up Security  Locate

If using a cluster of standalone registries, they must share the same private key for validating authentication tokens.

Sharing Token Key  Locate

If Oracle Service Registry is installed as a cluster of standalone registries, you must ensure that all cluster nodes share the same private key for checking authentication token validity. (By a standalone registry, we mean Oracle Service Registry that is not deployed to an application server. You do not need to do this if Oracle Service Registry is deployed to an application server). To set this up, choose one of the cluster nodes and copy its private key to all other nodes in the cluster by entering this command at a command prompt:

PStoreTool copy -alias authTokenIdentity -keyPassword SSL_CERTIFICATE_PASSWORD -config REGISTRY_HOME\conf\pstore.xml -config2 TARGET_REGISTRY_HOME\conf\pstore.xml

SSL_CERTIFICATE_PASSWORD is a ssl certificate password entered during the installation

TARGET_REGISTRY_HOME is the directory where a cluster node is installed.

WebLogic specific configuration for use with cluster  Locate

This section will guide you through an example setup of clustering with a WebLogic application server.

To deploy Oracle Service Registry to a WebLogic cluster follow these steps:

  1. Install WebLogic, then configure it by adding machines to the cluster. In our case, the cluster is named cluster and is running on The nodes in the WebLogic cluster are named:

    • kila (, running on, with an http port of 7101 and https port of 7102

    • fido (, running on, with an http port of 7101 and https port of 7102

  2. Generate the certificates of all cluster nodes: Let's create proper certificates for our two nodes. It will be done via the CertGen tool provided by WebLogic. Go to the directory %WEB_LOGIC_HOME%\weblogic81\server\lib. CertGen is located in weblogic.jar's utils package. Invoke it with the command:

    java -cp weblogic.jar utils.CertGen changeit kilacert kilakey export

    The output resembles the following:

    kilacert kilakey export 
            ...... Will generate certificate signed by CA from CertGenCA.der file
            ...... With Export Key Strength 
            ...... Common Name will have Host name
            ...... Issuer CA name is
            CN=CertGenCAB,OU=FOR TESTING ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US 

    Use the password changeit for starting the UDDI node servers. The output file with the certificate is kilacert, and kilakey is the output file containing the private key. Generate certificates for all remaining nodes from their CertGen tools. (In our case, the other node is

  3. Once you have certificates from all nodes (in our case files kilacert.der and fidocert.der), import them to pstore.xml using the PstoreTool. Also include CertGenCA.der (from the directory %WEB_LOGIC_HOME%\weblogic81\server\lib). The pstore.xml file is now ready. For more info about WebLogic certificates and SSL settings, please see Configuring SSL in BEA's WebLogic product documentation.

  4. Prepare a registry deployment package (REGISTRY_HOME\conf\porting\weblogic\registry.war) as described in Oracle WebLogic deployment details.

    In our case, the http port is 7101, the https port is 7102, and the application server context is wasp.

  5. Check that the paths for log4j.appender.eventLog.File, log4j.appender.errorLog.File, and registry.war\conf\log4j.config are valid on all cluster nodes.

  6. Deploy registry.war into all WebLogic cluster nodes

You must also prepare the package for the balancer which will only be deployed to the cluster manager server. To do so:

  1. Create a balancer directory, in, for example, REGISTRY_HOME. This directory is referenced in this section as PACKAGE_HOME.

  2. Create a subdirectory of PACKAGE_HOME named WEB-INF.

  3. In this subdirectory, create the file web.xml containing the following text. Under WebLogicCluster specify the names and ports of your cluster nodes separated by a pipe (|). In our case, the file looks like:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 

  4. In the WEB-INF subdirectory, create the file weblogic.xml containing the following text, where /wasp is the context of Oracle Service Registry deployed to this application server. Your text must be customized for your own installation.

    <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" 
  5. Create the directory %PACKAGE_HOME%\uddi\webdata.

  6. Unjar REGISTRY_HOME\app\uddi\bsc.jar and copy the content of the webroot subdirectory from the jar to %PACKAGE_HOME%\uddi\bsc\webdata

  7. Unjar REGISTRY_HOME\app\uddi\web.jar and copy the content of the webroot subdirectory from the jar to %PACKAGE_HOME%\uddi\webdata.

  8. Package the content of %PACKAGE_HOME% into the file balancer.war using jar or some other compression utility.

  9. Deploy balancer.war into the cluster manager server.