|Table of Contents|
This sample demonstrates the dynamic behavior of the WSO2 ESB through the use of a Registry.
The ESB supports dynamic definitions for sequences, endpoints and resources. It defines a Synapse configuration which references a sequence definition specified as a registry key. The registry key resolves to the actual content of the sequence which is loaded dynamically by the ESB at runtime and cached appropriately as per its definition in the registry. Once the cache expires, ESB rechecks the meta information for the definition, reloads the sequence definition if necessary, and caches it again.
For a list of prerequisites, see the Prerequisites section in ESB Samples Setup.
Building the Sample
1. Start the ESB with sample 9 configuration using the instructions given in Starting Sample ESB Configurations.
2. A message should appear in the command or text Linux console stating the server started successfully.
3. The synapse configuration in the ESB used for message mediation in this sample is provided in
synapse_sample_9.xml as shown below:
<definitions xmlns="http://ws.apache.org/ns/synapse"> <registry provider="org.wso2.carbon.mediation.registry.ESBRegistry"> <parameter name="root">file:./repository/samples/resources/</parameter> <parameter name="cachableDuration">15000</parameter> </registry> <sequence key="sequence/dynamic_seq_1.xml"/> </definitions>
4. Deploy the back-end service 'SimpleStockQuoteService' and start the Axis2 server using the instructions given in section Starting Sample Back-End Services.
5. Now you have a running ESB instance and a back-end service deployed. In the next section, we will send a message to the back-end service through the ESB using a sample client.
Executing the Sample
The sample client used here is 'Stock Quote Client' which can operate in several modes. For instructions on this sample client and its operation modes, refer to Stock Quote Client.
1. Run the following ant command from
ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/
2. ESB fetches the definition of the sequence from the registry and executes its rules as shown in the logs.
[HttpServerWorker-1] DEBUG SequenceMediator - Sequence mediator <dynamic_sequence> :: mediate() ... [HttpServerWorker-1] INFO LogMediator - message = *** Test Message 1 ***
3. Execute the client immediately (within 15 seconds of the last execution) to see that the sequence is not reloaded.
4. Edit the sequence definition in
<ESB_HOME>/repository/samples/resources/sequence/dynamic_seq_1.xml (edit the log message to read as "Test Message 2") and execute the client again.
5. The new message will not yet be visible (if you execute this within 15 seconds of loading the resource for the first time).
6. Delay more than 15 seconds since the original caching of the sequence and execute again. The new sequence will be loaded and executed by the ESB as shown in the following log messages.
[HttpServerWorker-1] DEBUG SequenceMediator - Sequence mediator <dynamic_sequence> :: mediate() ... [HttpServerWorker-1] INFO LogMediator - message = *** Test Message 2 ***
The cache timeout could be tuned appropriately by configuring the URL registry to suit the environment and the needs.
Examples of message mediation in WSO2 ESB.