Oracle Service Registry uses many configuration files. They are stored in REGISTRY_HOME\app\uddi\conf and REGISTRY_HOME\work\uddi\bsc.jar\conf directories. Some of them may be changed during setup or with web interfaces.
Each such configuration file is an XML file containing tag config with some information about how the configuration file is used.
These attributes are generally recognized:
Table 2. Attributes of config tag
|local||true when the file is local to the cluster node||yes||false|
|updateDB||when true the file is stored in the database on Oracle Service Registry start||yes||false|
|history||when false configuration history is not logged||yes||true|
|savingPeriod||delay before changes in memory are written to file in milliseconds||yes||2000|
The most important attribute is name which is the identifier by which Oracle Service Registry tries to find the configuration. Some configuration files have attribute local set to true. That means that the configuration is only used by this Oracle Service Registry and other Registries in the cluster will not share it. Other nodes will have their own independent versions. These cluster nodes are distinguished by the Node ID which is specified inside nodeid.xml. If its value is empty, a unique ID will be generated at Oracle Service Registry startup.
The configuration files are always present in the directories, however their copy is in the database. If a configuration file is present in both database and file-system, the one in the database has priority. After the initial startup of Oracle Service Registry all configurations are put into the database. When Oracle Service Registry needs to change some configuration settings it does so in the both the database and file-system.
If a user or another program like Oracle Service Registry setup wants to edit the configuration file the priority of the configuration in database has to be overridden. This can be done in two ways:
By setting attribute updateDB to true in the top-level tag config in all configuration files where modifications have been done. Once Oracle Service Registry starts, the attribute will be automatically removed.
By setting attribute updateDBAll (see in table below) to true in tag dbconfig in database.xml Once Oracle Service Registry starts the attribute will be automatically cleared. There can be also time stamp in this attribute in format like 20070321133058 where digits denote year, month, day of month, hour, minute, and second in GMT time zone. Such time stamp is compared to time stamp in database. When config files have more recent time, they will be put in database on Oracle Service Registry start. When stamp in database is more recent, database version will be used. In both cases the attribute will be cleared.
Time stamp in updateDBAll is used by setup. Each time setup task is run it updates time stamp except for task that do not modify configuration files like drop database and backup. Purpose of the time stamp is to prevent overwritting current configuration with old one while redeploying same EAR/WAR file to application server.
When Oracle Service Registry operates in cluster mode the other means than the time stamp is used for synchronization. Clocks on cluster nodes are assumed to be not enough precise for that, but enough precise for redeployment and configuration changes. There is only one time stamp in database.xml, individual configuration files allow only true/false values in updateDB attribute.
The other important configuration setting for configurations is inside the database.xml file, in the dbconfig tag. The tag has following attributes:
Table 3. Attributes of dbconfig tag
|configRetainCount||number of latest configuration versions that are not deleted||yes||10|
|configRetainMinutes||age of configuration version before it can be deleted||yes||10|
|eventRetainMinutes||age of event information before it can be deleted||yes||5|
|updateDBAll||when true all configuration files will be stored in the database at Oracle Service Registry startup, can be also a time stamp||yes||false|
Oracle Service Registry setup automatically sets the updateDBAll attribute when its operation has been successful so that all changed configurations will be stored in the database at Oracle Service Registry startup. This is usually desirable behavior.
When Oracle Service Registry encounters an identical configuration in the database to the one that is being stored (e.g. when set updateDB or updateDBAll is encountered) then the store operation is ignored. This may be surprising as there would be no entry in the log of configurations, however the resulting state of the configurations is correct.
The database not only holds the current set of configurations but also their history in a log. You can monitor configuration changes, what the previous content was, or let Oracle Service Registry show you differences between versions. This configuration history log is purged every few minutes. Old configurations are not retained indefinitely. There are rules on how many older versions are left there and the age of a configuration before it can be deleted. The purpose of these rules is to avoid running out of space in the database and yet still have information about recent changes. Rules can be configured inside tag dbconfig in database.xml. Their defaults are in the table above. Default settings specify that there must be at least configRetainCount new versions of the configuration before it can be deleted automatically. Also, the configuration has to be older than configRetainMinutes before it can be deleted automatically. This allows the correction of most non-fatal configuration errors after an invalid change or to track which configuration change might have caused unexpected behavior.
To allow easy comparison of current and older configurations or try-then-rollback scenarios, the current set of configurations can be stored into a named collection of configurations. These collections are not deleted automatically. They allow you to store a configuration that works correctly and compare it with the current version if something breaks later. You can then activate the old one if needed or change the incorrect setting manually.
Backup tool in setup can store both file and database configurations. You can select which you want to backup.
Configurations in the database can be managed with the "Configuration Management" component of Oracle Service Registry Administration Console. You can find it under tab Manage, then Registry management sub-tab (default), then Configuration Management button.