Working with the Registry

WSO2 ESB makes use of a registry to store various configurations and artifacts such as sequences and endpoints. Simply put, a registry is a content store and a metadata repository. Various SOA artifacts such as services, WSDLs and configuration files can be stored in a registry keyed by unique paths. A path is similar to a Unix file path. WSO2 ESB 2.1 introduced a feature to directly store endpoints and sequences to the registry with a user specified key value.

WSO2 ESB accesses the registry in two ways. In many cases it accesses the registry by directly calling the registry API from Carbon components. In some special situations it gains access to the registry through the underlying Apache Synapse configuration. It is important that Synapse configuration should always include a registry definition. That is, the ESB configuration should include the following registry definition.

<registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
   <parameter name="cachableDuration">15000</parameter>
</registry>

To improve performance, "org.wso2.carbon.mediation.registry.WSO2Registry" implementation has a caching mechanism and cache timout can be configure by changing parameter value of cachableDuration.

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.For remote registry configuration details, refer to Sharing Registry Space Among Multiple Products.
  

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.

The above registry instances are mounted to a single, top-level registry to provide a unified view. Mount points of the three registries are /_system/local, /_system/config and /_system/governance respectively. One can browse the contents of the registry used by the ESB from the WSO2 ESB management console. To learn how to browse the registry, see Managing the Registry.

See also Storing Various WSO2 Enterprise Service Bus Configurations.