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