Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Objective: Introduction to Dynamic Sequences with a Registry.

Table of Contents

Introduction

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 rechecsk the meta information for the definition, reloads the sequence definition if necessary, and caches it again.

Prerequisites

Refer to Prerequisites section in ESB Samples Setup page.

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 <ESB_HOME>/repository/samples/synapse_sample_9.xml as shown below:

Anchor
synapse_sample_9.xml
synapse_sample_9.xml

Code Block
linenumbers
languagehtml/xmltrue
<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>
Prerequisites
  • Start the Synapse configuration numbered 9: wso2esb-samples.sh -sn 9
  • Start the Axis2 server and deploy the SimpleStockQuoteService if not already done.

This example introduces the dynamic behavior of ESB through the use of a Registry. ESB supports dynamic definitions for sequences and endpoints and, as seen before, for resources. In this example, we define 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 would be loaded dynamically by ESB at runtime and cached appropriately as per its definition in the registry. Once the cache expires, ESB would recheck the meta information for the definition, reload the sequence definition if necessary, and recache it again.

Once ESB is started, execute the stock quote client as ant stockquote... You will notice that that ESB fetches the definition of the sequence from the registry and executes its rules as follows.

bash
Code Block
language

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. According to synapse_sample_9.xml specified above, the schema is made available under the "validate_schema" key. The Validate Mediator by default operates on the first child element of the SOAP body. You may specify an XPath expression using the source attribute to override this behavior. The Validate Mediator now uses the "validate_schema" resource to validate the incoming message. If the message validation fails, it invokes the "on-fail" sequence of mediators.

2. Run the following ant command from <ESB_HOME>/samples/axis2Client directory.

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

Code Block
[HttpServerWorker-1] DEBUG SequenceMediator - Sequence mediator <dynamic_sequence> :: mediate()
...
[HttpServerWorker-1] INFO  LogMediator - message = *** Test Message 1 ***

Now if you execute 3. Execute the client immediately (within 15 seconds of the last execution) , you will notice to see that the sequence was is not reloaded. If you edit .

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, you will notice that the .

5. The new message is will not yet be visible (if you execute this within 15 seconds of loading the resource for the first time) However, after .

6. Delay more than 15 seconds elapsed since the original caching of the sequence , you will notice that the and execute again. The new sequence is will be loaded and executed by the ESB from as shown in the following log messages.

...

The cache timeout could be tuned appropriately by configuring the URL registry to suite suit the environment and the needs.

...