Executing the Client

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.