Sharing Registry Space across Multiple Product Instances

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

These three partitions are available on all the products based on WSO2 Carbon Platform, which allows to share resources and configuration replication. Two of these 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 Carbon-based 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.