WSO2 Registry Explained!

What is a Registry?

Registry in essence is a storage space in which data and configuration relating to a product can be persisted and referred from. The Registry uses a database for data persistence and it can be mounted to any type of Relational DB. Registry is a Carbon Kernel component hence all WSO2 products have a registry space built into the product.

Registry Spaces

Each registry can be divided into 3 spaces.

  1. Local Registry space

Local Registry space is specific to each WSO2 product and is not shared with other products in the deployment. Local registry stores artifacts that are local to that particular server.

  1. Config Registry space

Config Registry is shared between similar products in the cluster. For example all ESB nodes in the cluster would share a single Config Registry space. All product specific artifacts are stored inside this Registry.

  1. Governance Registry space

The governance registry space is a common space that is shared by all WSO2 products in the deployment. This registry space will store all artifacts that are common to all WSO2 products in the deployment. Governance Registry space should not be confused with the WSO2 Governance Registry.

Registry spaces are conceptual and all 3 spaces can mount to a single location. In the vanilla distribution of a WSO2 product, all these 3 spaces are pointed to the local H2 Database.

What is Registry mounting?

Registry mounting refers to a concept of linking the registry to a database. By Default the registry is mounted to the local H2 Database. It is possible to mount different Registry spaces of the same registry to different databases. For example the Local Registry space can be mounted to the H2 database whilst other spaces can be mounted to a remote database. In a production system it is recommend to mount the Config and Governance spaces of the Registry to a remote database.

Governance Registry Space != Governance Registry

Even though they sound similar, the Governance Registry space is not the same as WSO2 Governance Registry Product. Governance Registry simply refers to a registry space that is common to all WSO2 Products. Whereas the WSO2 Governance Registry product is a registry and a repository to store any type of data or metadata. It provides a rich set of features including SOA governance, lifecycle management, and a strong framework for governing anything.

What is remote Registry mounting

In a production deployment it is recommended to mount the Config and Governance space of the Registry to a remote database. This allows these registry spaces to be shared by the other products in the cluster or in the deployment. For example if you mount the Config space in a remote location all similar products in the cluster can use this remote location, where as if you mount the Governance space in a remote location all the WSO2 products in the deployment can use this remote Governance space.

How WSO2 Governance Registry comes into the picture

WSO2 governance registry can be used to manage the registry spaces of WSO2 products. This provides the capability to incorporate registry features to the registry spaces so that the registry can be managed better from a central point.

WSO2 Deployment synchronization on Windows environment

Deployment synchronization (dep-sync) is a feature that is shipped with most of the WSO2 products. This blog looks at how deployment synchronization can be achieved on carbon instances running on windows environment.

  1. Deployment synchronization requires SVNKit implementation from This library has to be downloaded separately since it is not shipped with the WSO2 distribution.
  2. Once this SVN kit is downloaded copy the svnClientBundle-1.0.0.jar to {carbon_home}\repository\components\dropins folder on all the instances that artifacts need to be synchronized.
  3. In the Manager node open the {carbon_home}\repository\conf\carbon.xml and enable the dep-sync configuration as given below
  1. In the worker nodes use the following configuration to enable dep-sync in the {carbon_home}\repository\conf\carbon.xml file.
  1. Enable clustering in all instances by setting the clustering value as true in the {carbon_home}\repository\conf\axis2\axis2.xml.
<clustering class="org.apache.axis2.clustering.tribes.TribesClusteringAgent" enable="true">

Once the clustering is enabled, set a domain name so that all instances in the cluster will have the same domain name. Domain can be set as shown below.

 <parameter name="domain">wso2.carbon.domain</parameter>

Mounting WSO2 instances on a MS SQL Database which is secured via Windows authentication

A multi instance deployment of WSO2 products would require the registry (config and governance) space to be mounted on an external database.  WSO2 Products can be mounted on many types of databases. Below instructions explain how WSO2 products can be mounted on a MS SQL database that is secured via Windows Authentication.

  1. download jTDS from the following link

  1. Extract the folder and copy the jtds-1.2.2.Jarfile to the {WSO2 Product}/components/lib folder
  1. The extracted folder also includes ntlmauth.dllfile in the \x64\SSOfolder copy the dll file to java bin folder(C:\Program Files\Java\jre7\bin)
  1. download and install the jdbc driver for mssql from the following location

  1. Once this is installed set the class path to the following location {JDBC driver Installation Path}\sqljdbc_4.0\enu\auth\x86
  1. Make sure that the IP and the port is enabled at the MSSQL side, this can be verified through telnet.
  1. Change the datasources.xml to the following configuration (Please change the DB name and the hostname accordingly)
  1. Start the ESB.