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 and referred to by a key, which is a path similar to a UNIX file path.

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. Therefore, it is important that the ESB configuration always include a registry definition as follows:

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

When a message comes through the ESB, if the configuration for processing that message has a reference to a registry resource, the ESB gets the information from the registry and then caches it for use with subsequent requests. This caching of registry data improves performance of message processing, but it also means that if the resource has changed in the registry, those changes will not be reflected while the cached data is being used. The cachableDuration parameter controls how long the cached data is used. After the cachable duration expires, the ESB will pull the data from the registry again when the registry resource is needed to process a message. You can increase the cachableDuration value to improve the speed of message processing or decrease it to ensure registry resource changes are available sooner.

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 for storing data and persisting configuration. The registry space provided to each product contains three major partitions:

• Local repository: Stores configuration and runtime data that is local to the server. This partition is not shared with multiple servers and can be browsed under /_system/local in the registry browser.
• Configuration repository: Stores product-specific configurations. This partition can be shared across multiple instances of the same product, such as sharing ESB configuration across a ESB cluster, and can be browsed under /_system/config in the registry browser.
• Governance repository: Stores configurations and data that are shared across the whole platform. This space typically includes services, service descriptions, endpoints, and datasources, and it 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. You 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.