Service Registry 3.1 Administration Guide

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

The Sun Java Enterprise System 5 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.

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.

The ServiceRegistry-base location is /opt/SUNWsrvc-registry on Solaris OS and /opt/sun/srvc-registry on Linux and HP-UX systems.


Note –

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 for a Non-Default Application Server Installation before you configure Service Registry.


The install.properties file contains a set of modifiable property settings. The properties that are listed in Table 1–1 are used by the configuration process. Each property name 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–1 Service Registry Configuration Properties

Property Name 

Description 

Default Property Value 

DomainName

Application Server domain name 

registry

ServerInstanceHost

The default hostname where Service Registry can be accessed 

localhost

ServerInstancePort

Application Server HTTP port for Service Registry 

6480

ServerInstanceSecurePort

Application Server HTTPS port for Service Registry  

6443

ServerJMSPort

Application Server Message Queue port for Service Registry 

6484

ServerIIOPPort

Application Server IIOP port for Service Registry 

6485

ServerIIOPSecurePort

Application Server IIOP secure port for Service Registry 

6486

ServerIIOPMutualAuthPort

Application Server IIOP mutual authentication port for Service Registry 

6487

AdministrationJMXPort

Application Server JMX port for Service Registry 

6488

AdministrationPort

Application Server Administrative Server port for Service Registry 

6489

AdministratorUserID

User name used to access Application Server Administrative Server 

admin

AdministratorPassword

Password used to access Application Server Administrative Server 

12345678 when you configure as root

None when you configure as a non-root user 

ApplicationServerKeystorePassword

Password used to access Application Server keystore 

12345678 when you configure as root

None when you configure as a non-root user 

RegistryServerKeystorePassword

Password used to access Service Registry keystore 

12345678 when you configure as root

None when you configure as a non-root user 

clientDatabase

Determines whether the Service Registry database runs in embedded or Network Server mode (true for Network Server mode)

false

RequireDatabaseAuthentication

Determines whether access to the Service Registry database requires user authentication 

false

DatabaseUserID

User ID for accessing the Service Registry database if user authentication is required 

APP

DatabasePassword

Password for accessing the Service Registry database if user authentication is required 

app123 when you configure as root

None when you configure as a non-root user 

backupDir

Directory to be used for Service Registry backups. Normally commented out; remove comment to specify an alternate location. 

RegistryDomain-base/3.0/backup when you configure as root

$HOME/srvc-registry/3.0/backup when you configure as a non-root user

dataHome

Directory where Service Registry data is stored 

RegistryDomain-base when you configure as root

$HOME/srvc-registry when you configure as a non-root user

CACertDir

Directory for added certificates that the Application Server domain should trust 

ServiceRegistry-base/install/cacerts when you configure as root

$HOME/srvc-registry/cacerts when you configure as a non-root user

ProcedureTo 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.

  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 the following command (all on one line), specifying the location of the modified install.properties file.

    Use a command like the following:

    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 and /var/opt/sun/srvc-registry on Linux and HP-UX 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.

ProcedureTo 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=
  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.

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 and HP-UX systems).


Note –

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 start and stop 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.

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–2 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.

Table 1–2 Service Registry Domain Default Ports

Port Value 

Description 

6480 

HTTP port 

6443 

HTTPS over SSL 

6484 

Message Queue port 

6485 

IIOP port 

6486 

IIOP SSL port 

6487 

IIOP Mutual Authentication port 

6488 

JMX port 

6489 

Application Server domain administration port 

ProcedureTo 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. The default is 12345678.

  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.

ProcedureTo 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.

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 (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.

    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.

ProcedureTo 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:

  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

    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.

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

Configuring Service Registry for a Non-Default Application Server Installation

The default location for installing Application Server is /opt/SUNWappserver/appserver on Solaris OS and /opt/sun/appserver on Linux and HP-UX systems. If you installed Application Server in a different location, you must edit a copy of the file install.properties before you configure Service Registry.

ProcedureTo Edit a Copy of the install.properties File

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

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

    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. 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. Save and close the file.

Next Steps

Continue with the instructions in Configuring Service Registry.

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

Service Registry requires the following in order to work correctly:

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.

ProcedureTo 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

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.

ProcedureTo 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 User’s Guide, or add yourself as a user by using the add user of the Admin Tool, described in add user.

  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

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.

ProcedureTo 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 of Registry Objects

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.

ProcedureTo 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 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.

ProcedureTo Disable the 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 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:

For information about using the Web Console, see the Service Registry 3.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.

ProcedureTo 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.

ProcedureTo 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:

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.

ProcedureTo 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.

ProcedureTo 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.

ProcedureTo 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.

Reinstalling Service Registry

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

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.

ProcedureTo 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.

ProcedureTo 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

The Registry uses the Java DB database. 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–3 shows these settings.

Table 1–3 Default Property Settings for Java DB

Property Setting 

Description 

registry.install.clientDatabase=false

Enables embedded mode 

registry.install.RequireDatabaseAuthentication=false

Does not require database authentication 

registry.install.DatabaseUserID=APP

Sets user ID to APP (not used)

registry.install.DatabasePassword=app123

Sets password to app123 (not used)

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

ProcedureTo 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.

ProcedureTo 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

ProcedureTo 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:

ProcedureTo 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.