ESB 11 WSO2 ESB Tutorial: Introduction to Static and Dynamic Registry Resources, and Using XSLT Transformations.

ESB 11

WSO2 ESB Tutorial:
Introduction to Static and
Dynamic Registry Resources,
and Using XSLT
Transformations

Index

1. Introduction
2. EI configuration Example
3. Running Example
4. Conclusion

1. Introduction

XSLT mediator is a useful component to transform a message to other format. It is used for example when we are interconnecting two external applications that use different message format. On the other hand we will study this time how to store configuration metadata into local registry and remote registry. On the example the XSLT transformations are specified as a registry resource.

2. EI configuration Example

This is the configuration for the EI:

The XSLT are identified as registry resources. Local entries do not place the resource on the registry, but simply make it available to the local configuration. If a local entry is defined with a key that already exists in the remote registry, the local entry will get higher precedence over the remote resource. Remote means that we can have Governance Registry configured in another host. On this way registry space can be shared among multiple product. The following picture shows a remote Governance Registry configuration:

Synapse uses a simple URL based registry implementation (SimpleURLRegistry): org.apache.synapse.registry.url.SimpleURLRegistry
WSO2 has implemented this other one:
org.wso2.carbon.mediation.registry.ESBRegistry

The parameters of the registry are:

• root=  which specifies a prefix for the registry keys used later. This root is prefixed to the entry keys to form the complete URL of the resource being looked up.
• cachableDuration= The resource is going to be stored locally for a specified duration. After that time the resource is reloaded and cache refreshed. Because of the cache, it is not needed to restart Synapse (EI) if there is a change on a resource.

XML transforms the request to a standard stock quote request. And the response from the SimpleStockQuoteService is converted back into the custom format as expected by the client during the out message processing.

• This is the flow: Request -> transform.xslt -> Request after transform

• This is the flow: Response -> transform_back.xslt -> Response after transform_back

3. Running Example

To test the example you can use SOAPUI with the requests from point 2. This is an example of how the request would look like in SOAPUI:

The first time the response is processed by the EI the class ESBRegistry load in memory the resource: transform/transform_back.xslt

That resource is going to last 15000 ms in memory as a cash. After that time and if the resource is requested again the cache reload it. If the resource is in memory when a new response is in process the cache is not going to be reloaded. If the resource has been modified the cache is refreshed.

4. Conclusion

To summarise, the static resource is the one loaded with the Local Entry, and the dynamic is the one that refers to the root value in the registry configuration. Something important to remember is the fact that the middleware interconnect different applications and because of that maybe every one use a different format of the messages. The solution to interconnect both applications is with the Message Translator pattern that WSO2 implements with the XSLT mediator.