Demonstrating the usage of the XSLT mediator for transforming message content and using local registry and remote registry for storing configuration metadata.
This example uses the XSLT mediator to perform transformations, and the xslt transformations are specified as registry resources. The first resource 'xslt-key-req' is specified as a 'local' registry entry. 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.
In this example you will notice the new 'registry' definition. Synapse comes with a simple URL based registry implementation (SimpleURLRegistry). During initialization of the registry, the SimpleURLRegistry expects to find a property named 'root', which specifies a prefix for the registry keys used later. When the SimpleURLRegistry is used, this root is prefixed to the entry keys to form the complete URL of the resource being looked up. The registry caches a resource once requested, and stores it internally for a specified duration. Once this period expires, it will reload the meta information about the resource and reloads its cached copy if necessary, the next time the resource is requested.
Hence the second XSLT resource key 'transform/transform_back.xslt' concatenated with the 'root' of the SimpleURLRegistry 'file:repository/conf/sample/resources/' forms the complete URL of the resource as 'file:repository/conf/sample/resources/transform/transform_back.xslt' and caches its value for a period of 15000 ms.
Execute the custom quote client as follows and analyze the the Synapse debug log output.
The incoming message is transformed into a standard stock quote request by the XSLT mediator. The XSLT mediator uses Xalan-J to perform the transformations. It is possible to configure the underlying transformation engine using properties when necessary. The response from the SimpleStockQuoteService is converted back into the custom format as expected by the client during the out message processing.
During the response processing you could see the SimpleURLRegistry fetching the resource as shown by the log message below.
If you run the client again immediately (i.e within 15 seconds of the first request) you will not see the resource being reloaded by the registry as the cached value would be still valid.
However if you leave the system idle for 15 seconds or more and then retry the same request, you will now notice that the registry notices the cached resource has expired and will reload the meta information about the resource to check if the resource has changed and will require a fresh fetch from the source URL. If the meta data / version number indicates that a reload of the cached resource is not necessary (i.e. unless the resource itself actually changed) the updated meta information is used and the cache lease extended as appropriate.
Thus the SimpleURLRegistry allows resource to be cached, and updates are detected so that the configuration changes could be reloaded without restarting the Synapse instance.