Chapter 1 Configuring and Setting Up Service Registry

This chapter describes how to configure Service Registry after you install it and how to perform other administrative tasks.

This chapter contains the following sections:

• Configuring Service Registry

• Administering the Application Server Domain for Service Registry

• Configuring the Java Virtual Machine (JVM) for the Registry Domain

• Creating an Administrator for Service Registry

• Specifying Who Can Perform User Registration in Service Registry

• Enabling Versioning in Service Registry

• Disabling the Service Registry WSDL Cataloger

• Configuring the Service Registry Web Console

• Reinstalling Service Registry

• Administering the Java DB Database for Service Registry

Configuring Service Registry

This section describes the following tasks:

• To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation

• To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation

• To Edit Database Properties for the Oracle Database

• To Add Root Certificates to the Trusted Certificates in the Registry Domain

• Configuring an Oracle Database for Use with Service Registry

• Configuring Service Registry with a Non-Default Application Server Location

• Configuring Service Registry with Application Server 9.1

The Sun Java Enterprise System 5 Update 1 Installation Guide for UNIX describes how to perform post-install configuration of Service Registry using default property settings for the Registry. To use custom property settings, make a copy of the file ServiceRegistry-base/install/install.properties or ServiceRegistry-base/install/install.properties.template and edit it before you perform the configuration.

See Default Paths and File Names for the location of ServiceRegistry-base on your platform.

To configure the Registry, you can be logged in as root or become superuser, or you can be logged in as an non-root user.

For security reasons, it is recommended that you configure the Registry as a non-root user. For instructions, see To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

Before you configure Service Registry, you must first install and configure Sun Java System Application Server (“Application Server”). The configuration process for Service Registry installs the Registry into an Application Server domain.

It is recommended that you install Application Server in its default location. If you installed Application Server in a non-default location, follow the instructions in Configuring Service Registry with a Non-Default Application Server Location before you configure Service Registry.

The version of Application Server that is part of Java Enterprise System 5 Update 1 is Application Server 8.2. You can also install Service Registry on Application Server 9.1. See Configuring Service Registry with Application Server 9.1 for details.

The install.properties file contains a set of modifiable property settings. The properties that are listed in Table 1–1 and Table 1–2 are used by the configuration process. Each property name in Table 1–1 has the prefix registry.install. (terminating in a period). Some of these properties set non-default ports for the Application Server domain created for the Registry. Others set configuration properties described elsewhere in this manual.

You can configure multiple instances of Service Registry either as root or as a non-root user. If you do so, you must change the registry.install.dataHome property to be unique for each Registry instance. If you want to be able to run more than one instance at a time on the server, you must also change the eight port properties to be unique for each instance. For multiple non-root instances, you may want to change the value of registry.install.CACertDir to be unique for each instance.

Table 1–2 describes properties used to configure the database used by the Registry. By default, the Registry uses the Java DB database. You can, however, configure the Registry to use an Oracle database instead of the Java DB database. Some of the database property names do not begin with registry.install, so this table provides the full name of each property.

If you plan to use an Oracle database, you must perform some configuration tasks for the Oracle database before you configure Service Registry to use it. For details, see Configuring an Oracle Database for Use with Service Registry. In addition, you must edit the install.properties file as described in To Edit Database Properties for the Oracle Database.

To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation

Before You Begin

These instructions assume that you are logged in as root or have become superuser.

1. Change to the ServiceRegistry-base/install directory.

2. Copy the file install.properties to a secure location.

   Use a command like the following:

   cp install.properties $HOME/hidden_dir/sr.properties

3. Change the permissions on the properties file to make it writable.

   Use a command like the following:

   chmod 600 $HOME/hidden_dir/sr.properties

4. Edit the modifiable properties in the file.

   For example, it is recommended that you change all the passwords from the default values.

   If you will be using Oracle as the database instead of Java DB, follow the instructions in To Edit Database Properties for the Oracle Database to edit the database properties. (Make sure you have already followed the instructions in Configuring an Oracle Database for Use with Service Registry.)

5. Change the permissions back to the original read-only value.

   Use a command like the following:

   chmod 400 $HOME/hidden_dir/sr.properties

6. In the ServiceRegistry-base/install directory, run a command like the following (all on one line), specifying the location of the modified install.properties file.

   Ant-base/ant -f build-install.xml -Dinstall.properties=$HOME/hidden_dir/sr.properties configure

   The ant command requires the JAVA_HOME environment variable to be set. Ordinarily, you set this variable to the following value:

   /usr/jdk/entsys-j2se

   The Registry configuration process creates an Application Server domain at RegistryDomain-base/domains/${registry.install.DomainName}. The default domain name is registry. The configuration process then starts the domain, deploys the Registry, and leaves the domain running.

   The Registry configuration process installs the Registry database and server keystore in the directory RegistryDomain-base/3.0. This directory is not removed when the Registry is uninstalled, so that the database can be preserved for use in a future release. The administrator has control over when and whether to remove this directory.

   The RegistryDomain-base location is /var/opt/SUNWsrvc-registry on Solaris OS, /var/opt/sun/srvc-registry on Linux systems, and C:\Program Files\Sun\JavaES5\srvc-registry\data on Microsoft Windows systems.

   The Registry configuration process creates a directory named ServiceRegistry-base/install/cacerts for you to place added certificates that the Application Server domain should trust.

7. Review the output of the ant configure command for any errors.

   If there are no errors, you can now begin using the Web Console or the Admin Tool.

To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation

Before You Begin

These instructions assume that you are logged in as an ordinary user, not as root, and that someone logged in as root has installed Service Registry.

1. Change to the ServiceRegistry-base/install directory.

2. Copy the file install.properties.template to a location in your home directory and rename it.

   Use a command like the following:

   cp install.properties.template $HOME/sr.properties

3. Open your copy of the file in a text editor and modify properties as needed.

   You must supply password values for the following properties, which are left empty in the template file:

   registry.install.AdministratorPassword=
   registry.install.ApplicationServerKeystorePassword=
   registry.install.RegistryServerKeystorePassword=

   If you will be using Oracle as the database instead of Java DB, follow the instructions in To Edit Database Properties for the Oracle Database to edit the database properties. (Make sure you have already followed the instructions in Configuring an Oracle Database for Use with Service Registry.)

4. Change the permissions on the file so that only you can read it.

   Use a command like the following:

   chmod 400 $HOME/sr.properties

5. In the ServiceRegistry-base/install directory, run a command like the following (all on one line), specifying the location of the modified file.

   Ant-base/ant -f build-install.xml -Dinstall.properties=$HOME/sr.properties configure

   Use a similar command to run any other configuration targets that you need.

   The Registry configuration process creates an Application Server domain at $HOME/srvc-registry/domains/${registry.install.DomainName}. The default domain name is registry.

   The Registry configuration process installs the Registry database and server keystore in the directory $HOME/srvc-registry/3.0.

   The Registry configuration process creates a directory named $HOME/srvc-registry/cacerts for you to place added certificates that the Application Server domain should trust.

6. Review the output of the ant configure command for any errors.

   If there are no errors, you can now begin using the Web Console or the Admin Tool.

To Edit Database Properties for the Oracle Database

Follow these steps if you will be using the Oracle database instead of Java DB. These steps assume that you have opened a copy of the install.properties or install.properties.template file in a text editor.

1. Change the values of the registry.install.RequireDatabaseAuthentication, registry.install.DatabaseUserID, and registry.install.DatabasePassword properties to match the values you provided for the Oracle user name and password in To Create a Database User:

   registry.install.RequireDatabaseAuthentication=true
   registry.install.DatabaseUserID=user-name
   registry.install.DatabasePassword=password
   

2. Put comment characters (#) in front of the lines that define properties for Java DB, so that they look like the following:

   #registry.install.clientDatabase=false
   #registry.install.databaseHost=localhost
   #registry.install.databasePort=1527
   #registry.db.dialect=org.freebxml.omar.server.repository.hibernate.DerbyDialect
   #registry.install.jdbcClassName=org.apache.derby.jdbc.EmbeddedDriver
   #registry.install.dbURL=jdbc:derby:$omar.home/data/registry/soar;create=true
   #registry.install.dbTransactionIsolation=TRANSACTION_READ_UNCOMMITTED
   #registry.database.supportsOrderBy=true

3. Remove the comment characters from the lines that define properties for the Oracle database, so that they look like the following.

   ---

   Note –

   Each property definition must appear on one line. The registry.install.dbURL and registry.install.dbURLFixed appear on two lines below so that they fit on the page.

   ---

   registry.install.clientDatabase=true
   registry.install.databaseHost=localhost
   registry.install.databasePort=1521
   registry.install.nonJavaDB=true
   registry.install.jdbcClassName=oracle.jdbc.driver.OracleDriver
   registry.install.jdbcDataSourceName=oracle.jdbc.pool.OracleDataSource
   registry.install.dbURL=jdbc:oracle:thin:@${registry.install.databaseHost}:
   ${registry.install.databasePort}:soar
   registry.install.dbURLFixed=jdbc\\:oracle\\:thin\\:@${registry.install.databaseHost}\\:
   ${registry.install.databasePort}\\:soar
   registry.db.installScript=database.sql
   registry.db.cleanupScript=cleanup.sql
   libs.db.jar=../lib/ojdbc14.jar
   registry.db.dialect=net.sf.hibernate.dialect.Oracle9Dialect
   registry.install.dbTransactionIsolation=TRANSACTION_READ_COMMITTED

   ---

   Note –

   The values of the registry.install.dbURL and registry.install.dbURLFixed properties assume that you gave the Oracle database the name soar when you followed the instructions in Configuring an Oracle Database for Use with Service Registry.

   ---

4. Add the following property definition to the file:

   registry.database.supportsOrderBy=false

   You must set this property in order for Service Registry to work correctly with an Oracle database. If you do not set this property, some queries will fail.

5. If the Oracle database is not installed on the same machine as Service Registry, change the value of the registry.install.databaseHost property from localhost to the IP address or hostname of the system where the Oracle database is installed (for example, 111.222.33.44 or mysys.mydomain.mycompany.com).

To Add Root Certificates to the Trusted Certificates in the Registry Domain

This task extends the list of trusted certificates in the Application Server registry domain.

Perform this task only if you use a third-party certificate and the root Certificate Authority (CA) certificate for the third party is not already in the Application Server truststore. Do not perform this task if you use only registry-issued certificates.

To determine whether the CA certificate you need is already available, you can use the list.cacerts target of the build-install.xml file:

Ant-base/ant -f build-install.xml -Dinstall.properties=props-file list.cacerts

where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

1. Download any root certificates that you want to support.

   Sites that provide root certificates include the following:

   • http://www.entrust.net/developer/

   • http://www.geotrust.com/resources/root_certificates/

   • http://www.thawte.com/roots/

   • http://www.verisign.com/support/roots.html

2. If necessary, use the unzip command to extract .cer files from the downloaded archive.

   ---

   Note –

   Some files have the suffix .der.

   ---

3. Copy the .cer files to the directory specified by the registry.install.CACertDir property in your copy of the install.properties file.

   This value is normally ServiceRegistry-base/install/cacerts if you configured as root, or $HOME/srvc-registry/cacerts if you configured as a non-root user.

4. Change to the directory ServiceRegistry-base/install.

5. Run the following command (all on one line):

   Ant-base/ant -f build-install.xml -Dinstall.properties=props-file install.cacerts

6. This command installs any certificates found in the directory specified by the registry.install.CACertDir property into the Application Server domain truststore.

   You can use the list.cacerts target again to make sure that the certificates have been installed correctly.

7. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Configuring an Oracle Database for Use with Service Registry

In order to use Service Registry with an Oracle database instead of the default Java DB database, you must install and configure the Oracle database for use with Service Registry. This manual does not describe how to install an Oracle database; consult the Oracle documentation for this information.

Once Oracle is installed, the required configuration tasks are as follows:

• Download and install the Oracle JDBC JAR file

• Create a database, defining a non-default number of cursors

• Create a user for the database

• Edit the tnsnames.ora file to allow multiple clients to connect over the network

These tasks are described in the following sections:

• To Obtain the Oracle JDBC JAR File

• To Create a Database

• To Create a Database User

• To Edit the tnsnames.ora File

After these tasks are completed, configure Service Registry as described in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation. This configuration must include the task described in To Edit Database Properties for the Oracle Database.

To Obtain the Oracle JDBC JAR File

1. Download the ojdbc14.jar file from the Oracle OTN network.

2. Copy this file into the ServiceRegistry-base/lib directory.

   For example, on Solaris OS, the command would look something like this:

   cp ojdbc14.jar /opt/SUNWsrvc-registry/lib

3. Change to the ServiceRegistry-base/install directory.

4. Run the following command:

   Ant-base/ant -f build-install.xml -Dinstall.properties=props-file configure.extern

To Create a Database

To create an Oracle database, use the Oracle Database Configuration Assistant utility.

1. Start the utility using the dbca command:

   dbca

2. On the Welcome screen, click Next.

3. On the Step 1 screen (Operations), select the Create a Database radio button and click Next.

4. On the Step 2 screen (Database Templates), select the General Purpose radio button and click Next.

5. On the Step 3 screen (Database Identification), specify a Global Database Name and a System Identifier (SID) for the database and click Next.

   For the Global Database name, specify soar followed by a domain name, as in soar.mydomain.mycompany.com.

   For the SID, specify soar.

6. On the Step 4 screen (Management Options), accept the default settings and click Next.

   The Configure the Database with Enterprise Manager checkbox is selected, and the Use Database Control for Database Management radio button is selected.

7. On the Step 5 screen (Database Credentials), select the Use the Same Password for All Accounts radio button, type a password of your choice in the text fields, and click Next.

8. On the Step 6 screen (Storage Options), accept the default settings and click Next.

   The File System radio button is selected.

9. On the Step 7 screen (Database File Locations), accept the default settings and click Next.

   The Use Database File Locations from Template radio button is selected.

10. On the Step 8 screen (Recovery Configuration), accept the default settings and click Next.

    The Specify Flash Recovery Area checkbox is selected, and default values are filled in for the two fields.

11. On the Step 9 screen (Database Content), accept the default settings and click Next.

    The Sample Schemas checkbox is not selected.

12. On the Step 10 screen (Initialization Parameters), select the Character Sets tab.

13. Select the radio button labeled “Choose from the list of character sets”, then select UTF8 from the menu.

14. At the bottom of the Step 10 screen, select the All Initialization Parameters radio button.

15. In the All Initialization parameters dialog, scroll to the open_cursors parameter.

16. Change the value to 3000 and click Close.

17. Click Next.

18. On the Step 11 screen (Database Storage), click Next.

19. On the Step 12 screen (Creation Options), accept the default selection of Create Database and click Finish.

To Create a Database User

To create a database user, use the sqlplus utility.

1. Become superuser by issuing the following command:

   su - oracle

2. Start the sqlplus utility:

   sqlplus /nolog

3. At the prompt, connect to the database:

   sqlplus>connect / as sysdba

4. Create a user and specify the password for the user:

   sqlplus>create user user-name identified by password;

   The password value must be at least six characters.

   For example, to specify a user named APP and a password of app123, you would use the following command:

   sqlplus>create user APP identified by app123;

5. Grant privileges to the user you created:

   sqlplus>grant connect, resource, dba to APP;

6. Exit the utility:

   exit

To Edit the tnsnames.ora File

To allow multiple clients to connect to the database over a network, edit the file tnsnames.ora.

1. Go to the directory Oracle-base/product/10.1.0/db_1/network/admin/.

2. Open the file tnsnames.ora in a text editor.

3. At the end of the file, append the following:

   SOAR =
     (DESCRIPTION =
       (ADDRESS = (PROTOCOL = TCP)(HOST = host.domain)(PORT = 1521))
       (CONNECT_DATA =
         (SERVER = SHARED)
         (SERVICE_NAME = soar)
       )
     )

   For host.domain, substitute the full domain name of the system where the database is installed.

Configuring Service Registry with a Non-Default Application Server Location

The default location for installing Application Server is Appserver-base, as described in Default Paths and File Names. If you installed Application Server in a different location, you must edit a copy of the file install.properties before you configure Service Registry.

To Edit a Copy of the install.properties File

1. Change to the ServiceRegistry-base/install directory.

2. Copy the file install.properties.template to a secure location and rename it.

   Use a command like the following:

   cp install.properties.template $HOME/hidden_dir/sr.properties

3. Change the permissions on the properties file to make it writable.

   Use a command like the following:

   chmod 600 $HOME/hidden_dir/sr.properties

4. Open the file in a text editor.

5. Find the commented-out definition of the property appserver.root.dir.

6. Remove the comment character (#) and replace the property definition with the actual location of Application Server.

7. Edit the file to specify the required passwords.

8. Save and close the file.

Next Steps

Continue with the instructions in Configuring Service Registry.

Configuring Service Registry with Application Server 9.1

The version of Application Server in Java ES 5 Update 1 is 8.2. It is possible, however, to install Service Registry on Application Server 9.1.

To Configure Service Registry with Application Server 9.1

1. If an Application Server 8.2 domain for the Registry is running, stop the domain:

   1. Change to the Service Registry install directory.

      cd ServiceRegistry-base/install

   2. Run the following command:

      Ant-base/ant -f build-install.xml -Dinstall.properties=props-file appserver.domain.stop

2. Install Application Server 9.1 in a location of your choice.

3. Deploy Service Registry on Application Server 9.1:

   Ant-base/ant -f build-install.xml -Dinstall.properties=props-file appserver.deploy.as9

4. Run the Application Server upgrade utility. Use the following command (Appserver-base is the location where you installed Application Server 9.1):

   Appserver-base/bin/asupgrade

   For the Source Domain Directory, specify RegistryDomain-base/domains/registry. For example, on a Linux system you would specify /var/opt/sun/srvc-registry/domains/registry.

   For the Target Domains Root Directory, specify RegistryDomain-base without registry. For example, on Linux you would specify /var/opt/sun/srvc-registry/domains/. The upgraded domain will also be named registry.

   ---

   Note –

   This step instructs you to create an Application Server 9.1 domain for the Registry in the same location as the previous domain (the term for this is an in-place upgrade). If you specify a different location for the Target Domains Root Directory (the term for this is a side-by-side upgrade), you must perform the task To Create a New Certificate Realm after you complete the current task.

   ---

5. Start the Application Server domain for the Registry.

   Ant-base/ant -f build-install.xml -Dinstall.properties=props-file appserver.domain.start

Next Steps

If you performed a side-by-side upgrade instead of an in-place upgrade, as described in Step 4, you must now perform the task To Create a New Certificate Realm.

For the Application Server 9.1 documentation, go to http://docs.sun.com/coll/1343.4.

To Create a New Certificate Realm

1. Change to the Appserver-base/bin directory.

2. Run the following command to remove any existing certificate realm (there should not be one):

   ./asadmin delete-auth-realm --host localhost --port 6489 certificate

3. Run the following command (all on one line) to create a new certificate realm:

   ./asadmin create-auth-realm --terse=false --echo=true --interactive=true --user admin --host localhost --port 6489 --classname com.sun.enterprise.security.auth.realm.certificate.CertificateRealm --property assign-groups=have.client.cert certificate

4. Stop and restart the Application Server domain, as described in To Stop and Restart the Application Server Domain for the Registry.

Administering the Application Server Domain for Service Registry

The configuration process for Service Registry by default creates an Application Server domain named registry, to which the Service Registry web application is deployed. This domain is in the RegistryDomain-base/domains/registry directory.

This location is different from the default location for Application Server domains, /var/opt/SUNWappserver/domains (Solaris OS) or /var/opt/sun/appserver/domains (Linux systems).

It is recommended that you not run any applications other than Service Registry in the registry domain.

To administer the registry domain, you can use the Application Server Administration Console (“Admin Console”). You can use the Admin Console to stop and restart the domain, view the server log, and perform other administrative tasks. See To Use the Application Server Admin Console for details.

You can also examine the server log directly. The log is in the file RegistryDomain-base/domains/registry/logs/server.log.

In addition to the Admin Console, you can use the asadmin command to administer the registry domain. Because the domain is not in the default location, you must specify the --domaindir option when you use asadmin commands that provide that option. The argument to the --domaindir option is RegistryDomain-base/domains. For some commands, you must also specify the option --port 6489, because the registry domain uses a non-default port. The asadmin command is in the Appserver-base/bin directory.

If you want to use the --passwordfile option of asadmin commands, you need a file with a copy of the administrator password for the Registry domain. To create such a file, use the generate.password.file target of the build-install.xml file. The file is RegistryDomain-base/3.0/data/security/pw.txt.

The registry domain uses a set of non-default ports so as not to cause conflicts with the default Application Server domain, domain1. These Service Registry port values are registered with the Internet Assigned Numbers Authority (IANA). Table 1–3 lists and describes these ports. For more information, see Ports in the Application Server in Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

To Use the Application Server Admin Console

1. In a web browser, go to the URL https://hostname:6489/.

   hostname is the system on which Application Server and Service Registry are running.

2. Accept the certificate that is offered.

   A login page appears.

3. On the login page, type admin in the User Name field.

   If you changed the default value of the registry.install.AdministratorUserID property when you configured the Registry, type the value you specified.

4. Type the Application Server administrator password in the Password field. Use the value that you specified for the registry.install.AdministratorPassword property when you configured the Registry.

5. Click Log In.

See Also

For details on using the Admin Console, refer to the online help for the Admin Console or to the Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

Changing the Service Registry Logging Level

To change the logging level for Service Registry, follow the instructions in the Admin Console online help. The property to specify in the Additional Properties area is org.freebxml.omar.

To change the logging for particular Service Registry subcomponents, refer to the following file: RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes/log4j.properties. You can specify any of the subcomponent names listed in this file. Do not include the string log4j.logger. For example, you can log server calls by specifying org.freebxml.omar.server.

To Stop and Restart the Application Server Domain for the Registry

The configuration process for the Registry starts the Application Server domain in which the registry is deployed. After you perform certain administrative tasks, you need to stop and restart the domain. Examples of such tasks are Configuring the Java Virtual Machine (JVM) for the Registry Domain and Creating an Administrator for Service Registry.

The Admin Console informs you if you need to restart the domain. You can use the Admin Console to perform this task. If you are using the asadmin command, you can use Ant tasks to stop and start the domain.

1. Change to the Service Registry install directory.

   cd ServiceRegistry-base/install

2. Run the following command:

   Ant-base/ant -f build-install.xml -Dinstall.properties=props-file appserver.domain.bounce

   where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

   The appserver.domain.bounce target stops the domain and then restarts it.

   The build-install.xml file also contains separate Ant targets for stopping and starting the Registry domain. To stop the domain, use the Ant target appserver.domain.stop. To start the domain, use the Ant target appserver.domain.start.

Configuring the Java Virtual Machine (JVM) for the Registry Domain

Service Registry requires the following in order to work correctly:

• The Registry must be able to access external web sites

• The Application Server domain for the Registry must have enough memory available to it

Any registry object can have an ExternalLink object, which specifies an external URL associated with that registry object. Any Service object can have a ServiceBinding, which can also point to an external URL. In order for users to create ExternalLink and ServiceBinding objects, Service Registry must be able to validate the URL, and this task requires access to external web sites. If the Registry is deployed behind a firewall, you need to set a proxy configuration that allows this access.

Proxy configuration requires you to specify a web proxy host and port as Java Virtual Machine (JVM) options of the Application Server domain where Service Registry is deployed.

It is also possible for the Registry to run out of memory. To prevent this problem from occurring, configure a JVM option to increase the memory available to the Application Server domain for the Registry.

Perform the following task to configure JVM options for the Registry.

To Configure JVM Options for the Registry Domain

1. Log in to the Application Server Admin Console as described in To Use the Application Server Admin Console.

2. Expand the Configurations node.

3. Expand the server node, server-config (Admin Config).

4. Click JVM Settings.

5. Click the JVM Options tab.

6. Click Add JVM Option.

7. In the text field, type the following (all on one line):

   -Dhttp.proxyHost=hostname.domainname -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=localhost

   The port value is usually 8080. If the port is different in your location, specify the correct value.

8. Click Add JVM Option again.

9. In the text field, type the following (all on one line):

   -XX:MaxPermSize=128m

10. Click Save.

11. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Creating an Administrator for Service Registry

The Service Registry administration tool enables some tasks that only a user who is registered as an administrator can perform. In addition, an administrator might be called upon to implement life cycle changes (for example, approvals) to objects other users submit.

An administrator can also change the default access control policy (ACP). However, writing an ACP is currently a manual process that requires knowledge of OASIS eXtensible Access Control Markup Language (XACML). For details, refer to Chapter 9, “Access Control Information Model,” of ebXML RIM 3.0, especially the examples in Sections 9.7.6 through 9.7.8. See Before You Read This Book for information on how to find the ebXML RIM 3.0 specification.

To Create an Administrator

To register yourself as an administrator, follow these steps:

1. Either perform user registration as described in Creating a User Account in Service Registry 3.1 Update 1 User’s Guide, or add yourself as a user by using the add user of the Admin Tool, described in add user Command.

2. If you used the Web Console to register, obtain the unique identifier of your User object as follows:

   1. Use the Web Console to perform a Basic Query, with the Object Type set to User.

   2. Click the Details link to view the User object the Registry created for you.

   3. Write down the Unique Identifier field value, or copy and paste it into a file.

   If you used the add user command, use the users command to get a list of users, then copy the identifier value for your user name.

3. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

4. Open the file omar.properties in a text editor.

5. Find the definition of the property omar.security.authorization.registryAdministrators.

6. Edit the property definition by adding a vertical bar (|), followed by the unique identifier string that you copied in Step 2.

   The property definition must all be on one line and must not contain spaces. After you finish, it will look something like this (all on one line):

   omar.security.authorization.registryAdministrators=
   urn:freebxml:registry:predefinedusers:registryoperator|
   urn:uuid:77f5c196-79de-4286-8483-8d80def3583b

7. Save and close the omar.properties file.

8. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Next Steps

To create additional administrators, you do not have to edit the omar.properties file. You can use either the Admin Tool or the Web Console to add users, and you can use the Web Console to classify the users as administrators.

Specifying Who Can Perform User Registration in Service Registry

By default, anyone who can access the Service Registry URL is permitted to perform user registration by using the User Registration Wizard. Any registered user can publish content to the Registry.

By defining the property omar.security.selfRegistration.acl in the file omar.properties, you can restrict this capability so that only specified people can perform user registration.

After you complete this task, the only people who can register by using the Wizard will be those who have the first and last names specified by the property definition. Other people who try to register will see an error message when they click the Next button after filling out the User Authentication Details form in Step 3 of the User Registration Wizard. The error message says User registration failed. After the message is a line that reports a UserNotFoundException.

If the omar.security.selfRegistration.acl property is not present in omar.properties, or if it is defined as the empty string, any registered user can publish content to the registry.

To Restrict User Registration

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file omar.properties in a text editor.

3. Add a definition of the following property:

   omar.security.selfRegistration.acl

   You can place this property definition anywhere in the file. A logical place for the property definition is in an area where other properties with the prefix omar.security are defined.

   Define the property value as a comma-separated list of first and last names of people who are authorized to perform user registration, as in the following example:

   omar.security.selfRegistration.acl=Vijay Patel, Jane Doe,

4. Save and close the omar.properties file.

5. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Enabling Versioning in Service Registry

By default, versioning of registry objects is disabled. If versioning is enabled, a new version of an object is created whenever any of the object's attributes is changed. Enabling versioning is an administrative task.

To Enable Versioning of Registry Objects

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file omar.properties in a text editor.

3. Find the definition of the property omar.server.lcm.VersionManager.versionableClassList.

   By default, this property has no value:

   omar.server.lcm.VersionManager.versionableClassList=

4. Specify any objects for which you want the Registry to create new versions when the objects are modified. Separate the objects with a vertical bar (|).

   For example:

   omar.server.lcm.VersionManager.versionableClassList=Service|Organization

   Use the commented-out copy of the property setting in the file as an example.

5. Save and close the omar.properties file.

6. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Disabling the Service Registry WSDL Cataloger

By default, when a WSDL file is published to the Registry as an ExtrinsicObject object, the Registry creates metadata for the object using the capability defined by the ebXML Registry Profile for Web Services. It is possible to disable this capability.

To Disable the Service Registry WSDL Cataloger

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file omar.properties in a text editor.

3. Find the definition of the property omar.server.cms.classMap.urn\:oasis\:names\:tc\:ebxml-regrep\:profiles\:ws\:wsdl\:cataloging\:Service\:default.

4. Comment out this property definition by placing a pound sign (#) before the definition.

5. Save and close the omar.properties file.

6. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Configuring the Service Registry Web Console

As an administrator, you can customize some aspects of the Web Console display by editing configuration files.

This section describes the following tasks:

• Adding Predefined Queries

• Changing the Default Query

• Hiding Classification Schemes

• Configuring the Search Results Display

• Configuring the Dependency Resolution Depth for the Export Feature

For information about using the Web Console, see the Service Registry 3.1 Update 1 User’s Guide.

Adding Predefined Queries

Service Registry includes several predefined queries, which appear in the Web Console Search form in the Select Predefined Query drop-down list. As an administrator, you can add new queries to the drop-down list that are specific to your installation of the Registry.

To Add a Predefined Query

1. Use the Web Console to publish an AdhocQuery object to the Registry.

   The name and description you specify for the query will appear in the drop-down list of predefined queries. In the SQL statement for the query, specify placeholders for user-supplied data by enclosing them in pairs of single quotes, as follows:

   select * from registryobject where id = ''$lid''

2. Write down the unique identifiers of the AdhocQuery object and of any placeholders in the SQL statement, or copy and paste them into a file.

3. Change to the directory RegistryDomain-base/3.0/jaxr-ebxml.

4. Open the file registry-browser-config.xml in a text editor.

   Make a copy of the original file so that you can back out your changes if you need to.

5. Add an entry to the registry-browser-config.xml file, using the following format. Specify a Parameter element for each placeholder in the SQL statement.

   <Query>
     <AdhocQueryRef id="unique-identifier"/>
     <Parameter parameterName="$placeholder-name" datatype="string">
       <rim:Name>
         <rim:LocalizedString xml:lang="en" charset="UTF-8" 
           value="parameter-name-in-en-locale"/>
         <rim:LocalizedString xml:lang="fr" charset="UTF-8" 
           value="parameter-name-in-fr-locale"/>
       </rim:Name>
       <rim:Description>
         <rim:LocalizedString xml:lang="en" charset="UTF-8" 
           value="parameter-description-in-en-locale"/>
         <rim:LocalizedString xml:lang="fr" charset="UTF-8" 
           value="parameter-description-in-fr-locale"/>
       </rim:Description>
     </Parameter>
     ...
   </Query>

   The unique-identifier is the unique identifier of the AdhocQuery object.

   The parameterName attribute value for each parameter must come from a placeholder in the SQL statement for the query.

   The datatype attribute can have any of the following values:

   • string: The parameter appears as a text field in the Search form.

   • taxonomyElement: The parameter appears as a drop-down list in the Search form. If you specify a taxonomyElement data type, the Name and Description elements must be followed by a SlotList element that looks like this:

     <rim:SlotList>
       <rim:Slot name="domain">
         <rim:ValueList>
           <rim:Value>
           classification-scheme-or-concept-id
           </rim:Value>
         </rim:ValueList>
       </rim:Slot>
     </rim:SlotList>

     The classification-scheme-or-concept-id is the unique identifier of the classification scheme or concept whose concepts (or subconcepts) must appear in the drop-down list. You must publish the classification scheme if it does not already exist in the registry.

     The slot name must be "domain".

   • boolean: The parameter appears as a checkbox in the Search form.

   If the datatype is string or boolean, you can also add a defaultValue attribute to the Parameter element to specify a default value to appear in the Search form.

   Specify localized string values for each parameter name and description for any locales you support. The parameter-name in the current locale appears as the label of the parameter in the Search form.

   Use the existing entries in the registry-browser-config.xml file as a reference.

6. Save and close the registry-browser-config.xml file.

7. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Changing the Default Query

The query that appears as the default in the Select Predefined Query drop-down list is Basic Query, which allows users to search for registry objects by name, description, and classification.

As an administrator, you can change this default to a query that is appropriate to your installation. For example, you might want the default query to be a new predefined query that you added to the Registry, as described in Adding Predefined Queries. To make this change, edit a property in a configuration file.

To Change the Default Query

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file jaxr-ebxml.properties in a text editor.

3. Find the definition of the property jaxr-ebxml.thin.defaultQueryPanel. By default, this property is commented out:

   #jaxr-ebxml.thin.defaultQueryPanel=

4. Remove the comment character (#).

5. Set the value of the property by specifying the logical identifier of the query that will be the default, as in the following example:

   jaxr-ebxml.thin.defaultQueryPanel=urn:oasis:names:tc:ebxml-regrep:query:MyQuery

6. Save and close the jaxr-ebxml.properties file.

7. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Hiding Classification Schemes

A tree structure of classification schemes appears in the following areas of the Web Console:

• The ClassificationScheme/Concept Selector window that appears when you click Select Classification Node in the Search menu area or when you need to choose a concept for some kinds of registry objects

• The Explore menu area

As an administrator, you can hide classification schemes from view if you do not want the classification schemes to be available to users of Service Registry. To hide classification schemes, define a property in a configuration file.

To Hide Classification Schemes

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file jaxr-ebxml.properties in a text editor.

3. Set the property jaxr-ebxml.registryBrowser.ConceptsTreeModel.hiddenSchemesList by using the following syntax. All of the property definition must be on one line and must not contain spaces.

   jaxr-ebxml.registryBrowser.ConceptsTreeModel.hiddenSchemesList=
   class-scheme-id1|class-scheme-id2|...

   Specify the logical identifier of each classification scheme that is to be hidden. If you specify more than one identifier, separate the identifiers with a vertical bar (|), as in the following example:

   jaxr-ebxml.registryBrowser.ConceptsTreeModel.hiddenSchemesList=
   urn:oasis:names:tc:ebxml-regrep:classificationScheme:StatusType|
   urn:oasis:names:tc:ebxml-regrep:profile:ws:classificationScheme:BindingType

4. Save and close the jaxr-ebxml.properties file.

5. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Configuring the Search Results Display

By default, the Web Console displays 25 search results at a time for each query. If the search returns more than 25 results, users can display additional pages of results. As an administrator, you can modify the number of search results that appears on each page.

By default, the Web Console displays certain columns in the search results area. For each object, it displays the object type, name, description, version, and version comment. For some object types, a non-default display is configured. For example, for a ServiceBinding object, the display includes the endpoint instead of the version information. As an administrator, you can add configuration information to display non-default data for object types of your choice.

To perform each of these tasks, you edit a configuration file.

To Configure the Number of Rows in the Search Results Display

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file jaxr-ebxml.properties in a text editor.

3. Find the definition of the property omar.client.thinbrowser.numSearchResults:

   omar.client.thinbrowser.numSearchResults=25

4. Change the value 25 to the value you prefer.

5. Save and close the jaxr-ebxml.properties file.

6. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

To Configure the Columns in the Search Results Area

You can configure columns in the Search Results area for object types. The columns display the attributes of the objects.

1. Change to the directory RegistryDomain-base/3.0/jaxr-ebxml.

2. Open the file registry-browser-config.xml in a text editor.

3. Add an entry to the registry-browser-config.xml file, or edit an existing one. Use the following format.

   This example configures a non-default display for Service objects.

   <ObjectTypeConfig 
       className="org.freebxml.omar.client.xml.registry.infomodel.ServiceImpl" 
       id="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Service">
     <SearchResultsConfig>
       <SearchResultsColumn columnClass="java.lang.Object" 
         columnHeader="Object Type" columnWidth="25" editable="false" 
         method="getObjectType"/>
       <SearchResultsColumn columnClass="java.lang.Object" 
         columnHeader="Name" columnWidth="25" editable="true" method="getName"/>
       <SearchResultsColumn columnClass="java.lang.Object" 
         columnHeader="Description" columnWidth="30" editable="true" 
         method="getDescription"/>
       <SearchResultsColumn columnClass="java.lang.Object" 
         columnHeader="Status" columnWidth="15" method="getStatusAsString"/>
       <SearchResultsColumn columnClass="java.lang.Object" 
         columnHeader="Version" columnWidth="5" method="getVersionName"/>
     </SearchResultsConfig>
   </ObjectTypeConfig>

   The registry-browser-config.xml file provides syntax for the ObjectTypeConfig element. Use the elements that are already in the file as examples. These elements configure the default display for registry objects as well as non-default displays for ExternalLink, ExtrinsicObject, and ServiceBinding objects.

   The maximum number of columns that you can configure is 30.

   For the SearchResultsColumn element:

   • The columnClass attribute value is always java.lang.Object.

   • The columnHeader attribute value is a key to a message in the Web Console resource bundle files. These files are contained in the directory registryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes/org/freebxml/omar/client/ui/thin/. For example, if you type Object Type for the columnHeader value, the Web Console's backing beans use the WebResourceBundle class to look up a message with that key. If the WebResourceBundle fails to find the message, it converts the key to lowercase and tries again. If this fails again, it sets the message value to"???"+key+"???" and logs a warning message about the missing resource bundle entry. So, to add new localized columnHeader values, you must enter new message keys into the ResourceBundle files contained in this directory.

   • The columnWidth attribute is not used by the Web Console.

   • The editable attribute is not used by the Web Console.

   • For the most part, you can deduce the method names for the method attribute from the class attributes in the ebXML Registry Information Model Version 3.0 specification (see Before You Read This Book for details). The getStatusAsString method can be found in the RegistryObjectImpl implementation class. (This release of Service Registry does not include API documentation, however.)

   You can have no more than one ObjectTypeConfig element for each omar.client.xml.registry.infomodel class name.

4. Save and close the registry-browser-config.xml file.

5. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

6. To verify the reconfiguration, use the Search or Explore menu of the Web Console to display the objects whose columns you changed.

Configuring the Dependency Resolution Depth for the Export Feature

The Export Repository Content to Zip File feature of the Search menu area allows you to export the repository items associated with ExtrinsicObject objects to a zip file. Repository items such as WSDL files can import other WSDL files, so the Dependency Resolution Depth combo box allows users to specify how many levels of dependency should be searched in order to export the required files. By default, the menu allows users to specify zero, 1, 2, 3, or all levels of dependency, and the default level is zero. A level of zero specifies that only the requested objects should be exported, not the files they depend upon.

Sometimes the dependency tree for a particular file is deep and complex. If all dependencies are returned for every export request, the resulting file set can be very large and can contain unwanted files. Also, traversing the entire dependency tree is resource-intensive, leading to a potential performance degradation. Therefore, you may wish to limit the number of levels searched. You may also want to specify a default level other than zero.

As an administrator, you can set properties to configure the number of levels and the default level with values appropriate for your installation.

To Configure the Dependency Resolution Depth

1. Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/classes.

2. Open the file jaxr-ebxml.properties in a text editor.

3. Find the commented-out definition of the property omar.client.thinbrowser.compressContent.maxDepthLevel:

   #omar.client.thinbrowser.compressContent.maxDepthLevel=6

4. Remove the comment character and specify the value you prefer. The default is 4, meaning that the levels 0, 1, 2, and 3 appear in the menu, along with All Levels.

5. Find the commented-out definition of the property omar.client.thinbrowser.compressContent.defaultDepthLevel:

   #omar.client.thinbrowser.compressContent.defaultDepthLevel=-1

6. Remove the comment character and specify the value you prefer. A level of –1 specifies that All Levels should be the default.

7. Save and close the jaxr-ebxml.properties file.

8. Follow the instructions in To Stop and Restart the Application Server Domain for the Registry.

Reinstalling Service Registry

If you need to uninstall and reinstall Service Registry, perform the following tasks before you reinstall:

• If the Registry database contains data that you want to preserve, back up the database as described in Administering the Java DB Database for Service Registry.

• Stop the Application Server domain for the Registry, then delete the domain. If you do not delete the domain, post-install configuration of the reinstalled Registry will fail.

If you need to reinstall the Service Registry database (for example, if the database becomes corrupted), follow the instructions in To Reinstall the Service Registry Database. You do not need to uninstall the database before you reinstall it.

To Stop and Delete the Application Server Domain for the Registry

1. Change to the ServiceRegistry-base/install directory.

2. Run the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.domain.delete

   where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

   This target stops the domain and then deletes it.

To Reinstall the Service Registry Database

This task deletes the existing database contents, including the registered users, and recreates the default database.

1. Change to the ServiceRegistry-base/install directory.

2. Run the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file install.db

3. Run the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.domain.stop export.registryOperatorCert install.cacerts appserver.domain.start

Administering the Java DB Database for Service Registry

This section describes the following tasks:

• To Require Database Authentication

• To Perform an Offline Backup of the Database

• To Switch From Embedded Mode to Network Server Mode

• To Perform an Online Backup of the Database

Service Registry uses the Java DB database by default. Java DB is a commercial release of the Apache Software Foundation's open source relational database project. The Apache project is called Derby.

By default, the database is located in the directory RegistryDomain-base/3.0/data/registry/soar/. Database backups are placed in the directory RegistryDomain-base/3.0/backup/, with a subdirectory name that contains the date of the backup (for example, 20060419-004759).

By default, the Java DB database runs in embedded mode. This means that it runs in the same JVM as Service Registry, and it can accept a connection from only one client, Service Registry. No remote connections are possible. When Java DB runs in embedded mode, you can back up the database only when it is not running (an offline backup). For instructions, see To Perform an Offline Backup of the Database.

If you need to be able to back up the database while the registry domain is running (an online backup), you must run the Java DB database in Network Server mode. For instructions, see To Switch From Embedded Mode to Network Server Mode and To Perform an Online Backup of the Database.

When it runs in Network Server mode, Java DB can accept multiple client connections in a familiar client/server configuration. For example, both Service Registry and a SQL client could concurrently communicate with Java DB. When Java DB runs in Network Server mode, it uses a database port whose default value is 1527. Clients such as Service Registry use this port to communicate with the database.

When Java DB runs in Network Server mode, Service Registry runs in Network Client mode.

A database that runs in Network Server mode must be password protected so that only authenticated clients can use it. You can also protect the database this way when it runs in embedded mode, but it is not essential to do so.

By default, the properties in the file ServiceRegistry-base/install/install.properties are set so that Java DB runs in embedded mode. Table 1–4 shows these settings.

For more details on Java DB, consult the Java DB documentation under the Reference tab at the Java DB web site .

To Require Database Authentication

By default, database authentication is not required. It is possible to require authentication when the database is running in embedded mode, and it is necessary to require authentication when the database is running in Network Server mode.

1. Change to the Service Registry install directory:

   cd ServiceRegistry-base/install

2. Open your copy of the install.properties file in a text editor.

3. Change the setting of the registry.install.RequireDatabaseAuthentication property from false to true.

4. Edit the setting of the registry.install.DatabaseUserID property.

   For embedded mode, this value can be either APP or empty:

   registry.install.DatabaseUserID=APP

   registry.install.DatabaseUserID=

   For Network Server mode, this value must be APP.

5. Edit the setting of the registry.install.DatabasePassword property.

   The password must contain at least 6 characters. The default value is app123.

6. Save and close the file.

7. Stop and restart the Application Server domain for the Registry. To do so, execute the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.domain.bounce

   where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

To Perform an Offline Backup of the Database

If the database is running in embedded mode, you must perform an offline backup.

1. Change to the Service Registry install directory:

   cd ServiceRegistry-base/install

2. Execute the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.domain.stop

   where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

3. Execute the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file backup.db

4. Restart the domain by executing the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.domain.start

To Switch From Embedded Mode to Network Server Mode

To switch from embedded mode (the default) to Network Server mode, change the setting of the registry.install.clientDatabase property from false to true, and require database authentication.

After editing the property, recreate the database resources, then stop and restart the Application Server.

1. Change to the Service Registry install directory:

   cd ServiceRegistry-base/install

2. Open your copy of the install.properties file in a text editor.

3. Change the setting of the property registry.install.clientDatabase from false to true.

4. Change the setting of the registry.install.RequireDatabaseAuthentication property from false to true.

5. Edit the setting of the registry.install.DatabaseUserID property, if necessary.

   For Network Server mode, this value must be APP.

6. Edit the setting of the registry.install.DatabasePassword property.

   Any length is valid. The default value is app123.

7. Save and close the file.

8. Recreate the database connection pool and its associated resource. To do so, execute the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.jdbcResource.update

   where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.

9. Stop and restart the Application Server domain for the Registry. To do so, execute the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file appserver.domain.bounce

10. Start the Java DB database. To do so, execute the following command:

    asadmin start-database --dbhome database-directory

    By default, this command places the database and its log file in the current directory. Use the --dbhome option to specify the location of your database (normally, this is RegistryDomain-base/3.0/data/registry/soar).

Next Steps

If the database is running in Network Server mode, you can perform an online backup of the database.

Later, if you want to return to embedded mode, follow the same steps, with the following exceptions:

• Change the setting of the registry.install.clientDatabase property from true to false.

• If you want to stop requiring database authentication, change the setting of the registry.install.RequireDatabaseAuthentication property from true to false.

• If you want to continue requiring database authentication, change the user ID and password if you wish. The registry.install.DatabaseUserID value must be either APP or empty. The registry.install.DatabasePassword value can be any length.

• Do not execute step 10. You do not need to start the database separately.

To Perform an Online Backup of the Database

1. Change to the Service Registry install directory:

   cd ServiceRegistry-base/install

2. Verify that the property registry.install.clientDatabase in your copy of the install.properties file is set to true.

3. Execute the following command (all on one line):

   Ant-base/ant -f build-install.xml Dinstall.properties=props-file backup.db

   where props-file is the path name of the copy of install.properties file that you edited in To Configure Service Registry as Root Using Custom Properties After a Configure Later Installation or To Configure Service Registry as a Non-Root User Using Custom Properties After a Configure Later Installation.