Registry Configuration Details

The WSO2 Governance Registry, is designed, having in mind the ability to tailor it according to various business requirements. As an implementation framework for Governance within an organization, its people, processes and services, the WSO2 Governance Registry gives an administrator the ability to choose from a wide variety of design-time (static) configuration options.

<staticConfiguration>
        <versioningProperties>true</versioningProperties>
        <versioningComments>true</versioningComments>
        <versioningTags>true</versioningTags>
        <versioningRatings>true</versioningRatings>
        <!-- Location you want to add service and default
            location will be /governance/services/ -->
        <servicePath>/governance/services</servicePath>
    </staticConfiguration>

The ability to track changes done to organizational resource, and optionally review and revert back to an older version, puts one of the most important pieces to the puzzle that most organizations are facing. The WSO2 Governance Registry takes you a step further by giving you the option to decide on what operations on a resource are versioned and what are not. This allows you to optimize data storage and also gain better performance while securing your business goals. Versioning is enabled for all operations on a resource by default, and, you can disable versioning of properties, comments, tags and ratings by changing the value of the corresponding parameter to false.

In addition to versioning the WSO2 Governance Registry also allows you to configure how you store various resources (mainly for services). You can change the default service path /governance/services to any valid path on the registry. If this location already exists, it will be re-used, or if not, it will be created for you.

Versioning resource per each change made can be an extremely expensive operation at runtime (especially if there are many resources that change). By default, the versionResourcesOnChange parameter is set to false, disabling versioning resources on change.

<versionResourcesOnChange>false</versionResourcesOnChange>

Read-Only and Read-Write Registry

The WSO2 Governance Registry can be used in two modes of operation:

• READ-ONLY
• READ-WRITE

The WSO2 Carbon Server has been designed with the provision of multiple instances of similar servers to make use of a single configuration base. An ideal example is a cluster of WSO2 Enterprise Service Buses (ESBs). Here, we can define one node as the master of the cluster which has the ability to read and write configuration data, while the others can only read. The single-writer multiple-reader deployment scenario solves concurrency problems. The registry.xml file can be used to define whether the embedded (or remote) instance of the Registry in-use is writeable or not. This is controlled by the readOnly parameter.

<readOnly>false</readOnly>

To run the registry in read-only mode set the readOnly element to true. Setting the read-only mode allows you to run an immutable instance of registry repository.

Registry Root

The WSO2 Governance Registry also supports the notion of using a single repository shared among multiple servers based on the WSO2 Carbon Server platform. This is analogous to different users sharing the same file system. Each server (like each user) will be given a chroot'ed environment to work upon, with its apparent root being a child of the root of the shared repository.

<registryRoot>/</registryRoot>

The registryRoot parameter can be used to define the apparent root of the running instance of the server. In the event of multiple servers running against a single repository, the WSO2 Carbon Server can be configured in three different ways. Without loss of generality, lets take two servers A and B, sharing the same repository.Then the three configuration options are as follows:

• A is B's sibling - A and B have the same registry root (/, or /myroot).
• A is B's parent - A has registry root / or /myroot while B has registry root /child or /myroot/child.
• A and B are isolated - A has registry root /a and B has registry root /b.

The three different configuration options facilitate a number of grid and clustered deployments.

Configuring root, you can specify the absolute path of the collection which you wish to use as the root of this registry instance.

Registry Caching

To enable registry caching, set the enableCache element to true. Once caching is enabled, repetitive read operations will be executed against the cache instead of the database. The default registry caching expiry time is 15 minutes.