Setting up the Registry Space

WSO2 Carbon is the base platform for all WSO2 products and its Registry kernel provides the basic registry and repository functionality. Products based on Carbon use the services provided by the Registry kernel to establish their own registry spaces utilized for storing data and persisting configuration. Here are some of the features provided by the WSO2 Registry interface:

• Provides the facility to organize resources into collections.
• Maintains multiple versions of resources.
• Manages social aspects such as rating of resources.
• AtomPub interfaces to publish, view and manage resources from remote or non-Java clients.

Registry partitions

The Registry space provided to each product contains three major partitions.

• Local Repository : Used to store configuration and runtime data that is local to the server. This partition is not to be shared with multiple servers and can be browsed under /_system/local in the registry browser.
• Configuration Repository : Used to store product-specific configuration. This partition can be shared across multiple instances of the same product. (eg: sharing ESB configuration across a ESB cluster) and can be browsed under /_system/config in the registry browser.
• Governance Repository : Used to store configuration and data that are shared across the whole platform. This typically includes services, service descriptions, endpoints or datasources and can be browsed under /_system/governance in the registry browser.

Setting up the partitions

Any WSO2 Carbon-based product has the following options when configuring and using a registry space: 

• Use the registry space shipped by default with the product.
  
• Use a remote registry instance/s for the registry partitions that can be shared across multiple WSO2 Carbon-based product instances. 

This guide explains the second option using WSO2 Governance Registry as the remote registry instance. Two of the three partitions can be shared across multiple product instances in a typical production environment. Therefore, we can identify four main deployment strategies for the three partitions as follows.

• All Partitions in a Single Server
• Config and Governance Partitions in a Remote Registry
• Governance Partition in a Remote Registry
• Config and Governance Partitions in Separate Nodes

In all of the above four sections, any of the WSO2 products can be mounted to a remote WSO2 Governance Registry (G-Reg) instance. Examples discussed here use JDBC based configuration model as that is the recommended approach for a production deployment setup.