Remote Instance and Mount Configuration Details
The WSO2 Governance Registry supports the concept of federating the directory structure of the repository across multiple servers. Thus, the structure of collections need not necessarily be existent on a single instance of the server. Each remote instance can be mounted and un-mounted by the simple addition of a configuration describing how to connect to it. The WSO2 Governance Registry's Remote Registry API is used to communicate between such remote instances.
The configurations in this page are all found in the registry.xml file which is located in the <PRODUCT_HOME>/repository/conf
 folder.
In order to mount an external registry, you have to define the remote instance. This could use either the JDBC-based configuration, the Atom-based configuration model or the WebService-based configuration model.
JDBC-based Remote Instance Configuration
url
- The URL of the remote instance.id
- Remote instance id.dbConfig
- The database configuration to use.ÂThis database configuration should not be the currentDBConfig.
readOnly
- Whether the instance is read-only.registryRoot
- The root of the registry instance.- enableCache -Â Whether caching is enabled for this instance.
- cacheId - This is the cache id of the remote instance. Here the cache id should be in the format of $database_username@$database_url, where $database_username is the username of the remote instance database and $database_url is the remote instance database URL.
The following is an example configuration of a remote instance.
<remoteInstance url="https://host:port/registry"> <id>instanceId</id> <dbConfig>h2-db</dbConfig> <readOnly>false</readOnly> <registryRoot>/</registryRoot> <enableCache>true</enableCache> <cacheId>wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB</cacheId> </remoteInstance>
Atom-based Remote Instance Configuration
The Atom-based remote instance configuration does not support transactions and is therefore not a recommended approach for use in a Production deployment.
url
- The URL of the remote instance.id
- Remote instance id.username
- Username of the remote registry login.password
- Password of the remote registry login.cacheId
- The identifier used in computing cache keys.
Below is an example configuration of a remote instance.
<remoteInstance url="https://host:port/registry"> <id>instanceId</id> <username>username</username> <password>password</password> </remoteInstance>
More than one remote instance can be attached to a given WSO2 Governance Registry by adding the relevant configuration details as seen above. Each remote instance must be given an identifier along with valid credentials that have sufficient privileges to perform the desired registry operations (requires at least read-privileges to the registry along with permission to log-in to the server). The URL of the remote instance can be deduced as follows:
Let the URL of the destination server be https://localhost:9443/services
. Then the URL of the remote instance will be https://localhost:9443/registry
. Let the URL of the destination server be https://10.20.30.40:9445/webcontext/services
. Then the URL of the remote instance will be https://10.20.30.40:9445/webcontext/registry
.
The cache id is an optional parameter and should be used only if multi-node replicated caching is enabled. The cache id should be in the format of databaseUser@databaseURL
. For example, the cache id for a remote instance running with the default embedded H2 database would be, wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB
.
You cannot mount the same server as a remote instance to itself.
WebService-based Remote Instance Configuration
The WebService-based remote instance configuration does not support transactions and is therefore not a recommended approach for use in a Production deployment.
url
 - The URL of the remote instance.id
 - Remote instance id.username
 - Username of the remote registry login.password
 - Password of the remote registry login.type
 - Set the type to ws.cacheId
 - The identifier used in computing cache keys.
Below is an example configuration of a remote instance.
<remoteInstance url="https://host:port/registry"> <id>instanceId</id> <username>username</username> <password>password</password> <type>ws</type> </remoteInstance>
More than one remote instance can be attached to a given WSO2 Governance Registry by adding the relevant configuration details as seen above. Each remote instance must be given an identifier along with valid credentials that have sufficient privileges to perform the desired registry operations (requires at least read-privileges to the registry along with permission to log-in to the server). The URL of the remote instance can be deduced as follows:
Let the URL of the destination server be https://localhost:9443/services
. Then the URL of the remote instance will be https://localhost:9443/registry
. Let the URL of the destination server be https://10.20.30.40:9445/webcontext/services
. Then the URL of the remote instance will be https://10.20.30.40:9445/webcontext/registry
.
The cache id is an optional parameter and should be used only if multi-node replicated caching is enabled. The cache id should be in the format of databaseUser@databaseURL
. For example, the cache id for a remote instance running with the default embedded H2 database would be, wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB
.
You cannot mount the same server as a remote instance to itself.
Mount Configurations
Once a remote instance has been defined a collection on the remote registry can be mounted to the local instance.
path
- The path to which the mount will be added to.overwrite
- Whether an existing collection at the given path would be overwritten or not.
The element overwrite is optional.
instanceId
- Remote instance id.targetPath
- The path on the remote registry.
Here is an example configuration of a mount.
<mount path="/_system/config" overwrite="true|false|virtual"> <instanceId>instanceId</instanceId> <targetPath>/_system/nodes</targetPath> </mount>
It is recommended to refrain from mounting a target path under "/_system/governance" of a remote registry to path "/_system/config". Similarly, refrain from mounting a target path under "/_system/config" of a remote registry to path "/_system/governance". Such configurations can produce unpredictable results.
For example, with the following mounting configurations, "/_system/governance" will be mounted to the correct path, which is "/_system/governance/mounting/governance" but "/_system/config" will be mounted to "/_system/governance/mounting/governance/mounting/config".
<mount path="/_system/config" overwrite="true"> <instanceId>instanceId</instanceId> <targetPath>/_system/config</targetPath> </mount> <mount path="/_system/governance" overwrite="true"> <instanceId>instanceId</instanceId> <targetPath>/_system/governance</targetPath> </mount>
Enable ClusteringÂ
To enable clustering for a node, the enable
attribute of given below configuration at $GREG_HOME/repository/conf/axis2/axis2.xml
 should be set to true
. Â
<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="true">
This configuration is responsible for the initialization of a node in the cluster and getting this node to join the cluster.Â
Â