Page Comparison

WSO2 Carbon-based products support the concept of 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 through 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

• url - The URL of the remote instance.
• id - Remote instance id.
• dbConfig - The database configuration to use. 

• readOnly - Whether the instance is read-only.
• enableCache - Whether caching is enabled for this instance.
• registryRoot - The root of the registry instance.

Below is 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.

Atom-Based Remote Instance Configuration

• 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 Following is an example configuration of a remote instance.

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

...

Elements of the configuration are explained below.

You can attach more than one remote instance can be attached to a given WSO2 product by adding the relevant configuration details as seen above. Each Provide 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 . 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 will should be wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB.

WebService-Based Remote Instance Configuration

• 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 Following is an example configuration of a remote instance.

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

...

Elements of the configuration are explained below.

You can attach more than one remote instance can be attached to a given WSO2 product by adding the relevant configuration details as seen above. Each Provide 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 will be, wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB.

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- Optional. Defines whether an existing collection at the given path will be overwritten or not.
• instanceId - Remote instance id.
• targetPath - The path on the remote registry.

Here Following is an example configuration of a mount.

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

Elements of the configuration are explained below.

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

<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 should 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 this node it to join the cluster. 

...

...