Demonstrates how to define local registry entries, sequences and endpoints in a reusable manner so that they can be used for mediation by referencing them by names.
Execute the sample client as follows.
This example uses a sequence named 'main' that specifies the main mediation rules to be executed. Following through the mediation logs you will notice that the sequence named 'main' is executed on receiving the requests (The main sequence acts as the default entry point for messages received by Synapse). Then for the incoming message flow the 'in' mediator executes, and it calls the sequence named 'stockquote'.
As the 'stockquote' sequence executes, the log mediator dumps a simple text/string property, result of an XPath evaluation, that picks up the key named 'version', and a second result of an XPath evaluation that picks up a local message property set previously by the property mediator. The get-property() XPath extension function is able to read message properties local to the current message, local or remote registry entries, Axis2 message context properties as well as transport headers. The local entry definition for 'version' defines a simple text/string registry entry which is visible to all messages that pass through Synapse.
Responses from the Axis2 server will also get dispatched to the main sequence. But because they are responses the in mediator will not be executed on them. Only the out mediator will execute on these messages which simply sends them back to the client using a send mediator.