This documentation is for WSO2 ESB version 4.5.0. View documentation for the latest release.

Storing Various WSO2 Enterprise Service Bus Configurations

Owned by Former user (Deleted)
Last updated: Jul 06, 2012Version comment
4 min read

WSO2 Governance Registry is an integral part of the WSO2 Enterprise Service Bus. It should be used carefully for the specific user requirements to achieve the maximum usability.

WSO2 Enterprise Service Bus uses WSO2 Governance Registry for storing configuration elements, resources like WSDL’s, policies, service metadata etc. WSO2 Enterprise Service Bus can run a WSO2 Governance Registry instance embedded into it or it can connect to a remotely running WSO2 Governance Registry using JDBC. To support transactions, we recommend using the Embedded Registry or JDBC Registry.

See also Registry.

Configuring WSO2 Governance Registry

To configure the registry integration, edit the registry.xml found in the <ESB_HOME>\conf directory.

Here are some of the important parts of the registry configuration.

  • <readOnly>false</readOnly>

If readOnly set to true, WSO2 Enterprise Service Bus will not write anything to the registry. In a clustered environment we set up only one registry as read/write and others as read only.

  • <registryRoot>/</registryRoot>

The root of the registry. All the values will be written and read relative to this path.

  • <dbConfig/>
<dbConfig name="wso2registry">
	<url>jdbc:h2:database/WSO2CARBON_DB</url>
	<userName>wso2carbon</userName>
	<password>wso2carbon</password>
	<driverName>org.h2.Driver</driverName>
	<maxActive>50</maxActive>
	<maxWait>60000</maxWait>
	<minIdle>5</minIdle>
	</dbConfig>

WSO2 Governance Registry uses a database for storing its configuration. The database can run within the WSO2 Enterprise Service Bus itself or it can be run remotely. The above URL is for the database that ships with the WSO2 Enterprise Service Bus. Users can run WSO2 Governance Registry separately and connect to it using the JDBC URL.

WSO2 Enterprise Service Bus has a built-in concept of registry. It uses it for two purposes:

  • Storing the static configuration of WSO2 Enterprise Service Bus.
  • Storing Dynamic configuration items.

Static Configurations

Every WSO2 Enterprise Service Bus instance has a configuration. The configuration is in XML format called Apache Synapse configuration language. WSO2 Enterprise Service Bus has various configuration elements.

All these configurations are represented by XML. WSO2 Enterprise Service Bus can use a flat file called "synapse.xml" which can contain all these elements to load its configuration.

Also WSO2 Enterprise Service Bus stores this synpase XML configuration in the registry. The registry configuration is not a single flat file like synapse.xml. It stores all the different types of configuration units separately. All this is hidden from the end user and he/she should not care where the actual configuration is stored.

How this File Based Configuration and Registry Based Configuration is Used

1. When WSO2 Enterprise Service Bus boots up for the first time it reads the configuration from the synapse.xml file in the <ESB_HOME>\conf directory.

2. Then it stores this configuration in the registry.

3. Subsequent start-ups of the WSO2 Enterprise Service Bus use the registry configuration.

4. When a user made a change to the configuration via the UI, for example, sequence editor, those changes are stored in the registry and they are not persisted to the synapse.xml unless specifically saved.

5. If user wants to save the configuration to the syanpse.xml file, he/she needs to go to the Apache Synapse configuration in the management console and click the "Save" button. If the user wants to start WSO2 Enterprise Service Bus from the configuration stored in the synapse.xml, he/she can do so by giving the --DuseSynapseXML command line argument at the startup of the WSO2 Enterprise Service Bus.

It is recommended to save the configuration to the synapse.xml time to time. Synapse.xml can be hand edited. If an erroneous configuration is saved in the registry, sometimes WSO2 Enterprise Service Bus refuses to start. For example, a WSDL file used for creating a Proxy Service may not be available or its file location may have changed. WSO2 Enterprise Service Bus will not start in such a case. But users can always edit the synapse.xml manually and recover from the error very easily. If the configuration is only saved to the registry, user may not have a way to edit the configuration stored there.

Dynamic Configurations

WSO2 Enterprise Service Bus has a concept of registry built into it. It exposes an API for plugging various registries. WSO2 Enterprise Service Bus is integrated to the WSO2 Enterprise Service Bus using this API.

To use this registry, user has to use the following configuration in Apache Synapse configuration.

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

WSO2 Enterprise Service Bus configuration allows to refer various configuration elements using a registry key. This key is referring a resource in the Registry. For example, user can store the XML of a sequence in the registry. Then refer it from the WSO2 Enterprise Service Bus using the registry key. For example, if your registry resource path is /test/sequence_1, your key should be /test/sequence_1.

<syn:sequence key="/test/sequence_1">

These resources are loaded only when they are requested by the message processing (when a request comes). After the resource is loaded it will be cached locally into the memory by the WSO2 Enterprise Service Bus. Subsequent requests will use this cached resource. Users can specify a caching duration for these resources: cachableDuration parameter. When the cache duration expires, WSO2 Enterprise Service Bus fetches these resources again from the registry.

The advantage of this approach is that users can change the sequences without restarting the WSO2 Enterprise Service Bus. If the WSO2 Enterprise Service Bus is clustered using a single registry, the user has to update only at one place.

Some of the configurations that can be stored in the registry are:

Storing XSLT files in a registry is needed if the user requires to cluster the WSO2 Enterprise Service Bus. Usually an ESB cluster is created by pointing several ESBs to use the configurations stored in a single registry. Also it is easier to manage the resources like XSLT if they are stored in the registry.

Also keeping the frequently changing items in the registry is a good practice. But there is a small performance overhead in loading the resources when the cache expires.

See the source article here.