This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Remote Registry Instance Configuration

WSO2 Carbon-based products support federating the directory structure of the repository across multiple servers. Therefore, the structure of collections does not necessarily need to exist in a single instance of the server. You can mount/un-mount each remote registry instance using a configuration, which defines how to connect to it. The Remote Registry API is used to communicate between such remote instances.

In order to mount an external registry, you have to define the remote registry instance. This can use the JDBC-based configuration model, the Atom-based configuration model or the WebService-based configuration model.

JDBC-Based Remote Instance Configuration

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>
</remoteInstance>

Elements of the configuration are explained below.

urlThe URL of the remote instance.
idRemote instance id.
dbConfigThe database configuration to use, which should not be the currentDBConfig.
readOnlyWhether the instance is read-only.
enableCacheWhether caching is enabled for this instance.
registryRootThe root of the registry instance.

Infor

For specific configuration details on mounting a remote WSO2 Governance Registry (G-Reg) instance using the JDBC-based configuration model, refer to Sharing Registry Space Among Multiple Products.

Atom-Based Remote Instance Configuration

Note

The Atom-based remote instance configuration is not recommended for use in a production deployment as it does not support transactions.

Following is an example configuration of a remote instance.

<remoteInstance url="https://host:port/registry">
   <id>instanceId</id>
   <username>username</username>
   <password>password</password>
</remoteInstance>

Elements of the configuration are explained below.

urlThe URL of the remote instance.
idRemote instance id.
usernameUsername of the remote registry login.
passwordPassword of the remote registry login.
cacheIdThe identifier used in computing cache keys.

You can attach more than one remote instance to a given WSO2 product by adding relevant configuration details. Provide each remote instance 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:

The cache id is an optional parameter. Use it 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 should be wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB.

Note

You cannot mount the same server as a remote instance to itself.

WebService-Based Remote Instance Configuration

Note

The WebService-based configuration is not recommended for use in a production deployment as it does not support transactions.

Following 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>

Elements of the configuration are explained below.

urlThe URL of the remote instance.
idRemote instance id.
usernameUsername of the remote registry login.
passwordPassword of the remote registry login.
typeSet the type to ws.
cacheIdThe identifier used in computing cache keys.

You can attach more than one remote instance to a given WSO2 product by adding the relevant configuration details as seen above. Provide each remote instance 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:

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 will be, wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB.

Note

You cannot mount the same server as a remote instance to itself.

Mount Configurations

Following is an example configuration of a mount.

<mount path="/_system/config" overwrite="true|false|virtual">
   <instanceId>instanceId</instanceId>
   <targetPath>/_system/nodes</targetPath> 
</mount>

Elements of the configuration are explained below.

pathThe path to which the mount will be added to.
overwriteOptional. Defines whether an existing collection at the given path will be overwritten or not.
instanceIdRemote instance id.
targetPathThe path on the remote registry.

Once you have defined a remote instance, a collection on the remote registry can be mounted to the local instance.

 

Note

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/governance/mounting/config</targetPath> 
</mount> 
<mount path="/_system/config" overwrite="true"> 
   <instanceId>instanceId</instanceId> 
   <targetPath>/_system/governance/mounting/governance</targetPath> 
</mount>

Enable Clustering 

To enable clustering for a node, the enable attribute of the configuration in $GREG_HOME/repository/conf/axis2/axis2.xml file should be set to true as follows:

<clustering class="org.apache.axis2.clustering.tribes.TribesClusteringAgent" enable="true">

This configuration is responsible for the initialization of a node in the cluster and getting it to join the cluster.Â