Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

WSO2 Carbon-based products support The WSO2 Governance Registry supports the concept of federating the directory structure of the repository across multiple servers. ThereforeThus, the structure of collections does need not necessarily need to exist in be existent on a single instance of the server. You can mount/un-mount each remote registry instance using a configuration, which defines 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 registry instance. This can could use either the JDBC-based configuration model, the Atom-based configuration model or the WebService-based configuration model.

Table of Contents

JDBC-Based Remote Instance Configuration

Following is an example configuration of a remote instance:

Code Block
languagehtml/xml
<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>

Elements of the configuration are explained below.

urlThe URL of the remote instance.
idRemote instance idID.
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.
cacheIDThis 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.
Info
titleInfor

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

Atom-Based Remote Instance Configuration

Warning
titleNote

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

...

Code Block
languagehtml/xml
<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.

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

...

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 of databaseUser@databaseURL. For example, the cache id for a remote instance running with the default embedded H2 database should be be wso2carbon@jdbc:h2:repository/database/WSO2CARBON_DB.

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

WebService-Based Remote Instance Configuration

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

...

Elements of the configuration are explained below.

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

...

...

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

Mount Configurations
Anchor
Mount Configurations
Mount Configurations

Following is an example configuration of a mount.

Code Block
languagehtml/xml
<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.

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

...

Info
titleNote

It is recommended to refrain from mounting a target path under "/_system/governance" of a remote registry to path "/_system/config". Similarly, refrain 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".

Code Block
languagehtml/xml
<mount path="/_system/config" overwrite="true"> 
    <instanceId>instanceId</instanceId> 
    <targetPath>/_system/governance/mounting/config</targetPath> 
</mount> 
<mount path="/_system/configgovernance" overwrite="true"> 
    <instanceId>instanceId</instanceId> 
    <targetPath>/_system/governance/mounting/governance</targetPath> 
</mount>

Enable Clustering 
Anchor
Clustering
Clustering

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

Code Block
languagehtml/xml
<clustering class="org.wso2.apachecarbon.axis2core.clustering.tribeshazelcast.TribesClusteringAgentHazelcastClusteringAgent" enable="true">

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