This sample demonstrates the functionality of local registry entry definitions, reusable endpoints and sequences.
For a list of prerequisites, see the Prerequisites section in ESB Samples Setup.
Building the Sample
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
synapse_sample_3.xml as shown below:
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
This example uses a sequence named "main" that specifies the main mediation rules to be executed. This is equivalent to directly specifying the mediators of the main sequence within the <
definitions> tags. This sample scenario is a recommended approach for non-trivial configurations.
1. 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. Run the following ant command from
<ESB_HOME>/samples/axis2Client directory to trigger a sample message to the back-end service.
2. Note the mediation logs in the ESB start-up console that the sequence named "main" is executed. Then, for the incoming message flow, theexecutes and it calls the sequence named "stockquote."
As the "stockquote" sequence executes, 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 ESB.