Author: asankha
Date: Tue Jul 18 01:08:17 2006
New Revision: 423006
URL: http://svn.apache.org/viewvc?rev=423006&view=rev
Log:
add to svn from wiki
Added:
incubator/synapse/trunk/java/xdocs/Synapse_Configuration_Language.html
Added: incubator/synapse/trunk/java/xdocs/Synapse_Configuration_Language.html
URL:
http://svn.apache.org/viewvc/incubator/synapse/trunk/java/xdocs/Synapse_Configuration_Language.html?rev=423006&view=auto
==============================================================================
--- incubator/synapse/trunk/java/xdocs/Synapse_Configuration_Language.html
(added)
+++ incubator/synapse/trunk/java/xdocs/Synapse_Configuration_Language.html Tue
Jul 18 01:08:17 2006
@@ -0,0 +1,466 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <meta content="text/html; charset=ISO-8859-1"
+ http-equiv="content-type">
+ <title>Synapse Configuration Language</title>
+</head>
+<body>
+<h1>Synapse Configuration Language<br>
+</h1>
+<p>The Synapse configuration language is designed to support a
+processing model where messages come into Synapse, are processed via
+some number of mediators and then delivered to an endpoint somewhere.
+This design currently does not support the concept of "service
+mediation." It is also currently direction agnostic, but directionality
+can easily be added as a selection mechanism for mediators (see below
+for details). </p>
+<h2>Overall Structure</h2>
+<p>A Synapse configuration looks like the following at the top level: </p>
+<pre> <synapse><br> <definitions><br> (sequencedef |
endpointdef | literalpropertydef | extensiondef)+<br>
<definitions>?<br> <proxies><br> proxyservice+<br>
</proxies>?<br> <rules><br> mediator+<br> </rules><br>
</synapse><br>
+</pre>
+<h3>Definitions</h3>
+<p>The <definitions> section defines reusable elements that can
+be used from within the rules, and the <rules> section contains
+the sequence of mediators that every message passes through during
+mediation. </p>
+<h3>Proxy services</h3>
+<p>The <proxies> section defines Synapse Proxy services, which
+are real Axis2 services hosted on Synapse, which allows WSDL mediation
+as well as the ability to expose existing services on Synapse, with
+possibly different semantics, such as WS-Security, WS-RM and Transport
+switching etc. </p>
+<p>A proxyservice token represents a <proxy> element which is
+used to define a Synapse Proxy service. </p>
+<pre> <proxy name="string" [description="string"]
[transports="(http|https|jms)+|all"]><br> <target sequence="name" |
endpoint="name"/>? // default is main sequence<br> <wsdl
url="url">?<br> <schema url="url">*<br> <policy
url="url">*<br> <property name="string" value="string"/>*<br>
</proxy><br>
+</pre>
+<p>A proxy service is created and exposed on the specified transports
+through the underlying Axis2 instance, exposing service EPR's as per
+the standard Axis2 conventions. (Note: that currently Axis2 does not
+allow custom URI's to be set for services on some transports.) The
+Proxy service could be exposed over all enabled Axis2 transports such
+as http, https, JMS etc. or on a subset of these. Each service could
+define the target for received messages as a named sequence or a direct
+endpoint. If a target is not supplied, the default Synapse rules will
+apply for message mediation. Any supplied policies would apply as
+service level policies, and any properties could be passed into the
+proxy services' AxisService instance (e.g.
+the JMS destination etc) </p>
+<h4>Sequences</h4>
+<p>A sequencedef token represents a <sequence> element which is
+used to define a named sequence of mediators that can be invoked later
+by name as a sequence of mediators. </p>
+<pre> <sequence name="string"><br> mediator+<br> </sequence><br>
+</pre>
+<h4>Endpoints</h4>
+<p>An endpointdef token represents an <endpoint> element which is
+used to give a logical name to an endpoint address. If the address is
+not just a simple URL, then extensibility elements may be used to
+indicate the address (i.e. to compute the address at runtime). </p>
+<pre> <endpoint name="string" [address="url"]><br><br> ..
extensibility ..<br><br> <parameter name="OutflowSecurity"><br>
...<br> </parameter><br><br> <wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";..<br>
xmlns:wsrm="http://ws.apache.org/sandesha2/policy"; wsu:Id="RMPolicy"><br>
...<br> </Policy><br><br> .. extensibility ..<br><br>
</endpoint><br>
+</pre>
+<p>An Axis2 Parameter element within an endpoint definition with the
+name " OutflowSecurity"
+describes the Apache Rampart security configuration to be used for
+messages flowing to this endpoint. Please see Rampart/Axis2
+documentation for more details. </p>
+<p>A Policy element within an endpoint definition with an Id of
+"RMPolicy" describes the Apache Sandesha2 RM configuration (or any
+overrides against the default) to be used for messages flowing to this
+endpoint. Please see Sandesha2/Axis2 documentation for more details. </p>
+<h4>Extensions</h4>
+<p>An extensiondef token represents an extension element that extends
+the core Synapse configuration. An extension provider must create an
+ExtensionFactory
+implementation that defines the type of element that the factory
+handles. At runtime the configuration builder loads any extensions
+through the Java service provider model, and then passes any unknown
+elements to the extension factory finder which will return the
+registered factory, if any. Then the factory is requested to process
+the extension element and create the extension, and this could be set
+as a 'property' into the SynapseConfiguration
+object. The Spring configuration extension operates in this manner and
+creates the Spring application contexts and sets it to the
+configuration as a property. </p>
+<p>See 'Extensibility of Synapse' below for more details. </p>
+<p>Note: The supported extensions are loaded through the J2SE Service
+Provider model. (<a rel="nofollow"
+
href="http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider";><img
+ src="file:///wiki/modern/img/moin-www.png" alt="[WWW]" height="11"
+ width="11">
+http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider</a>)
+</p>
+<h4>Properties</h4>
+<p>The token literalpropertydef refers to a <set-property>
+element as follows: </p>
+<pre> <set-property name="string" value="string"/><br>
+</pre>
+<p>which is used to set a global property with a constant value. </p>
+<p>These properties are top level properties which are set globally for
+the entire system. Values of these properties can be retrieved via the
+extension XPath function called "synapse:get-property(prop-name)". </p>
+<h3>Mediators</h3>
+<p>A mediator token refers to any of the following tokens: </p>
+<pre>send | drop | log | makefault | transform | header | filter | switch |
class | validate | setproperty | sequenceref | in | out <br>
+</pre>
+<p>In addition to the above, Synapse will be able to load mediators via
+the J2SE Service Provider model. Mediator extensions must implement the
+MediatorFactory interface, similarly to the configuration extensions
+mentioned
+previously. </p>
+<h4>Send</h4>
+<p>The send token represents a <send> element. The <send>
+element is used to send messages out of Synapse to some endpoint, and
+stop further mediation of the message. The send mediator also copies
+any message context properties named "correlate/*" from the current
+message context to the reply message received on the execution of the
+send operation. This allows the reply messages to be correlated to the
+original messages in a flexible manner. Messages may be correlated by
+WS-A MessageID, or even simple custom text labels. See example 1 for
+more details. </p>
+<p>In the simplest case, the place to send the message to is implicit
+in the message (via a property of the message itself)- that is
+indicated by the following: </p>
+<pre> <send/><br>
+</pre>
+<p>If the message is to be sent to one or more endpoints, then the
+following is used: </p>
+<pre> <send><br> (endpointref | endpoint)+<br> </send><br>
+</pre>
+<p>where the endpointref token refers to the following: </p>
+<pre> <endpoint ref="name"/><br>
+</pre>
+<p>and the endpoint token refers to an anonymous endpoint defined
+inline: </p>
+<pre> <endpoint address="url"/><br>
+</pre>
+<p>If the message is to be sent to an endpoint selected by load
+balancing across a set of endpoints, then it is indicated by the
+following: </p>
+<pre> <send><br> <load-balance algorithm="uri"><br>
(endpointref | endpoint)+<br> </load-balance><br> </send><br>
+</pre>
+<p>Similarly, if the message is to be sent to an endpoint with failover
+semantics, then it is indicated by the following: </p>
+<pre> <send><br> <failover><br> (endpointref |
endpoint)+<br> </failover><br> </send><br>
+</pre>
+<p>Once the <send> mediator executes, further processing of the
+current message stops. </p>
+<p>Note: Synapse does not yet support the load balancing or failover
+semantics, and supports only a single endpoint reference. </p>
+<h4>Drop</h4>
+<p>The drop token refers to a <drop> element which is used to
+drop a message: </p>
+<pre> <drop/><br>
+</pre>
+<p>Once the <drop> mediator executes, further processing of the
+current message stops. </p>
+<h4>Log</h4>
+<p>The log token refers to a <log> element which may be used to
+log messages being mediated: </p>
+<pre> <log [level="string"] [seperator="string"]><br> <property
name="string" (value="literal" | expression="xpath")/>*<br> </log><br>
+</pre>
+<p>The optional level attribute selects a pre-defined subset of
+properties to be logged. e.g. simple = To, From, WSAction, SOAPAction,
+ReplyTo,
+MessageID and any properties </p>
+<ul>
+ <li style="list-style-type: none;">
+ <p>headers = All SOAP header blocks
+and any properties full = all attributes included in log level 'simple'
+and the SOAP envelope and any properties custom = Only properties
+specified to the Log mediator </p>
+ </li>
+</ul>
+<p>A seperator if defined will be used to seperate the attributes being
+logged. The default seperator is the ',' comma. </p>
+<h4>Transforms</h4>
+<h5>Faults</h5>
+<pre> <makefault [version="soap11|soap12"]><br> <code
(value="literal" | expression="xpath")/><br> <reason (value="literal" |
expression="xpath")><br> <node>?<br> <role>?<br>
<detail>?<br> </makefault><br>
+</pre>
+<p>The <makefault> mediator transforms the current message into a
+fault message, but does NOT send it. The <send> mediator needs to
+be invoked to send a fault message created this way. The fault message
+"to" header is set to the "faultTo" of the original message if such a
+header existed on the original message, else it is set it to the
+"replyTo" of the original message. </p>
+<h5>XSLT/XQuery</h5>
+<pre> <transform xslt|xquery="url" [source="xpath"]><br> <property
name="string" (value="literal" | expression="xpath")/>*<br>
</transform><br>
+</pre>
+<p>The <transform> mediator applies the specified XSLT or XQuery
+transformation to the given element. If the source element is not
+specified, it defaults to the soap body content. Optionally parameters
+(XSLT) or variables (XQuery) could be passed into the transformations
+through the <property> elements. </p>
+<p>Note: Synapse does not currently support XQuery transformations </p>
+<h5>Headers</h5>
+<pre> <header name="qname" (value="literal" | expression="xpath")
[action="set"]/><br> <header name="qname" action="remove"/><br>
+</pre>
+<p>The <header> mediator sets or removes a specified header from
+the current soap message. Currently the set header only supports simple
+valued headers. In the future we may extend this to have XML structured
+headers by embedding the XML content within the element itself. The
+optional action attribute specifies whether the mediator should set or
+remove the header. If omitted, it defaults to a set-header. </p>
+<h4>Selection</h4>
+<h5>Filters</h5>
+<pre> <filter (source="xpath" regex="string") | xpath="xpath"><br>
mediator+<br> </filter><br>
+</pre>
+<p>The <filter> mediator either test the given xpath expression
+as a boolean expression, or match the evaluation result of a source
+xpath expression against the given regular expression. If the test
+succeeds, the filter mediator will execute the enclosed mediators in
+sequence. </p>
+<h5>Switch</h5>
+<pre> <switch source="xpath"><br> <case regex="string"><br>
mediator+<br> </case>+<br> <default><br> mediator+<br>
</default>?<br> </switch><br>
+</pre>
+<p>The <switch> mediator will evaluate the given source xpath
+expression into its string value, and match it against the given
+regular expressions. If the specified cases does not match and a
+default case exists, it will be executed. </p>
+<h4>Validation</h4>
+<pre> <validate schema="url" [source="xpath"]><br> <on-fail><br>
mediator+<br> </on-fail><br> </validate><br>
+</pre>
+<p>The <validate> mediator validates the result of the evaluation
+of the source xpath expression, against the schema specified. If the
+source attribute is not specified, the validation is performed against
+the soap body content of the current message. If the validation fails,
+the on-fail sequence of mediators is executed. </p>
+<p>Note: As the validation mediator is strongly dependent on the Xerces
+2.8.0 parser, it is bundled with the Synapse extensions, so that the
+Synapse core will remain simple and lightweight. </p>
+<h4>Properties</h4>
+<pre> <set-property name="string" (value="literal" |
expression="xpath")/><br>
+</pre>
+<p>The setproperty token refers to a <set-property> element which
+is a mediator that has no direct impact on the message but rather on
+the message context flowing through Synapse. The properties thus set on
+the message context applies only to the current message and can be
+later retrieved through the synapse:get-property(prop-name) extension
+function. </p>
+<h4>Class Mediators</h4>
+<pre> <class name="class-name"><br> <property name="string"
(value="literal" | expression="xpath")/>*<br> </class> <br>
+</pre>
+<p>The class mediator creates an instance of the specified class and
+sets it as a mediator. The class must implement the
+org.apache.synapse.api.Mediator interface. If any properties are
+specified, the corresponding setter methods are invoked on the class.
+However, Synapse will only support String properties. </p>
+<h4>Reusing Sequences</h4>
+<pre> <sequence ref="name"/><br>
+</pre>
+<p>A sequenceref token refers to a <sequence> element which is
+used to invoke a named sequence of mediators. </p>
+<h3>Extensibility of Synapse</h3>
+<p>The Synapse configuration language could be easily extended, with
+configuration extensions as well as mediation extensions. The Spring
+mediator and Spring Configuration are such examples. </p>
+<h4>Spring Configuration</h4>
+<p>The <spring:config> element could be used to define a reusable
+Spring ApplicationContext (BeanFactory).
+This could be referred subsequently by Spring mediator instances which
+will use this context. </p>
+<pre> <spring:config name="string" src="file"/><br>
+</pre>
+<p>The name attribute specifies a unique name for the configuration,
+and the src attribute specifies the Spring configuration file. </p>
+<p>Note: the <spring:config> element belongs to the <a
+ rel="nofollow" href="http://ws.apache.org/ns/synapse/spring";><img
+ src="file:///wiki/modern/img/moin-www.png" alt="[WWW]" height="11"
+ width="11"> http://ws.apache.org/ns/synapse/spring</a> namespace. </p>
+<h4>Spring mediator</h4>
+<pre> <spring:spring bean="exampleBean1" (config="spring1" |
src="spring.xml)"/><br>
+</pre>
+<p>The <spring> element creates an instance of a mediator, which
+is managed by Spring. This Spring bean must implement the Mediator
+interface for it to act as a Mediator. If a config attribute is
+specified, the bean will refer to the Spring configuration with the
+given name as its bean factory. If a src attribute specifies the Spring
+configuration file, the required application context is created inline
+and will be used by the mediator instance. </p>
+<h2>Examples</h2>
+<p>The following illustrates the hypothetical example used to
+illustrate the new Synapse configuration language syntax. However,
+features such as load balancing and failover etc are still not
+available with Synapse. </p>
+<p>The sample configuration presented below applies in the following
+hypothetical scenario. Assume that two web service endpoints exists,
+where registration requests could be processed. Requests may fall into
+Gold and Silver categories, and a specialized endpoint exists to
+process the Gold requests. If the Gold endpoint cannot be reached for
+whatever reason, requests should be processed via the Silver endpoint
+(i.e. failover). </p>
+<p>Once message arrive at Synapse, the 'to' address is looked up and
+different mediation rules applied depending on it. For registration
+messages, first we need to validate the incoming message against a
+schema, and if the validation fails, a log entry should be made and a
+fault reply should be sent back. For valid messages, we determine its
+category and attempt to use the Gold endpoint, failing which the Silver
+endpoint is tried. For requests that does not fall into the Gold
+category the default silver endpoint is used always. </p>
+<pre> <synapse><br> <definitions><br> <sequence
name="registration_flow"><br> <validate
schema="http://registry/xsd/registration.xsd"; source="//regRequest"><br>
<on-fail><br> <set-property name="error-code" value="100"/><br>
<set-property name="error-reason" value="validation failed"/><br>
<sequence ref="fault_flow"/><br> </on-fail><br> </validate>
<br> <filter xpath="/[EMAIL PROTECTED]'GOLD']"><br> <send><br>
<failover><br> <endpoint ref="gold_registration"/><br> <endpoint
ref="silver_registration"/><br> </failover><br> </send><br>
<filter> <br> <send><br> <endpoint
ref="silver_registration"/><br> </send><br> <sequence><br> <br>
+ <sequence name="fault_flow"><br> <log level="simple"><br>
<property name="application"
value="synapse:get-property('reg-app')"/><br> </log><br> <makefault
version="soap11"><br> <code
value="synapse:get-property('error-code')"/><br> <reason
expression="synapse:get-property('error-reason')"><br> <makefault><br>
<send/><br> <sequence><br> <br>
+ <endpoint name="gold_registration"
address="http://gold/registration"/><br> <endpoint
name="silver_registration" address="http://silver/registration"/><br> <br>
+ <set-property name="reg_app" value="Registration Application"/> <br>
</definitions><br> <br>
+ <rules><br> <switch source="synapse:get-property('to')"><br>
<case regex="/registration"><br> <sequence
ref="registration_flow"/><br> </case><br> <case
regex="someother"><br> ...<br> </case><br> <default><br>
<drop/><br> </default><br> </rules><br> <br>
+ </synapse>
+<br></pre>
+<h3>Example 0. </h3>
+<pre><br><synapse xmlns="http://ws.apache.org/ns/synapse"><br> <br>
<definitions><br> <br> <sequence name="stockquote"><br>
<!-- set the To address to the real endpoint --><br> <header
name="To" value="http://ws.invesbot.com/stockquotes.asmx"/><br> <br>
<!-- check if the symbol is MSFT --><br> <filter
xpath="//*[wsx:symbol='MSFT']" xmlns:wsx="http://ws.invesbot.com/"><br>
<!-- if it is throw a fault --><br> <makefault><br>
<code value="tns:Receiver"
xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/><br>
<reason value="Isn't there a Windows API for that?"/><br>
</makefault><br> </filter><br> </sequence><br><br>
</definitions><br><br> <rules><br> <!-- now log the message
using log4j --><br> <log level="full"/><br> <br> <!--
Check if the URL matches the stockquote gateway/dumb case --><
br> <filter source="get-property('To')" regex=".*/StockQuote.*"><br>
<sequence ref="stockquote"/><br>
</filter><br> <br> <!-- check if the URL matches the virtual
url - either the proxy or ws-add case --><br> <filter
source="get-property('To')" regex="http://.*stockquotes.*"><br>
<sequence ref="stockquote"/><br> </filter><br> <br>
<!-- send the message on --><br> <send/><br>
</rules><br><br></synapse> <br>
+</pre>
+<p>The above configuration is available with the Synapse distribution
+and illustrates the usual Stock quote examples. The client code for
+these are available with the Synapse samples, and the README.txt of the
+samples defines these in detail. </p>
+<h3>Example 1. </h3>
+<synapse xmlns="http://ws.apache.org/ns/synapse"><br>
+ <br>
+ <definitions><br>
+<br>
+ <sequence name="customrequest"><br>
+ <!-- set the To address to the
+real endpoint --><br>
+ <header name="To"
+value="http://ws.invesbot.com/stockquotes.asmx"/><br>
+ <br>
+ <!-- set correlation field to
+custom label --><br>
+ <set-property
+name="correlate/label" value="customquote"/><br>
+ <br>
+ <!-- transform the custom
+quote into a standard quote requst --><br>
+ <transform
+xslt="file:synapse_repository/conf/sample/transform.xslt"/><br>
+ <br>
+ <!-- send message to real
+endpoint and stop --><br>
+ <send/><br>
+ </sequence><br>
+<br>
+ <sequence
+name="customresponse"><br>
+ <!-- transform the custom
+quote into a standard quote requst --><br>
+ <transform
+xslt="file:synapse_repository/conf/sample/transform_back.xslt"/><br>
+ <br>
+ <!-- now send the custom
+response back to the client and stop --><br>
+ <send/>
+ <br>
+ </sequence><br>
+ <br>
+ <sequence name="stockquote"><br>
+ <!-- set the To address to the
+real endpoint --><br>
+ <header name="To"
+value="http://ws.invesbot.com/stockquotes.asmx"/><br>
+ <br>
+ <!-- check if the symbol is
+MSFT --><br>
+ <filter
+xpath="//*[wsx:symbol='MSFT']"
+xmlns:wsx="http://www.webserviceX.NET/"><br>
+ <!-- if it is
+throw a fault --><br>
+ <makefault><br>
+
+ <code value="tns:Receiver"
+xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/><br>
+
+ <reason value="Isn't there a Windows API for that?"/><br>
+ </makefault><br>
+ </filter><br>
+ <br>
+ <send/><br>
+ </sequence><br>
+ <br>
+ <sequence name="standardrequest"><br>
+ <!-- now log the
+message using log4j --><br>
+ <log level="full"/><br>
+ <br>
+ <!-- Check if the URL
+matches the stockquote gateway/dumb case --><br>
+ <filter
+source="get-property('To')" regex=".*/StockQuote.*"><br>
+
+ <sequence ref="stockquote"/><br>
+ </filter><br>
+ <br>
+ <!-- check if the URL
+matches the virtual url - either the proxy or ws-add case --><br>
+ <filter
+source="get-property('To')" regex="http://stockquote.*"><br>
+
+ <sequence ref="stockquote"/><br>
+ </filter><br>
+
+ <br>
+ <!-- send the message
+on --><br>
+ <send/><br>
+ </sequence><br>
+<br>
+ </definitions><br>
+<br>
+ <rules><br>
+ <in><br>
+ <!-- is this a custom
+stock quote message? --><br>
+ <filter
+xpath="//m0:CheckPriceRequest"
+xmlns:m0="http://www.apache-synapse.org/test"><br>
+
+ <sequence ref="customrequest"/><br>
+ </filter><br>
+ <br>
+ <!-- else, proceed as
+usual with the standard processing rules --><br>
+ <sequence
+ref="standardrequest"/><br>
+ </in><br>
+ <br>
+ <out><br>
+ <!-- is this a custom
+stock quote reply? --><br>
+ <filter
+source="get-property('correlate/label')" regex="customquote"><br>
+
+ <sequence ref="customresponse"/><br>
+ </filter><br>
+<br>
+ <!-- just
+let the message flow through --><br>
+ <send/><br>
+ </out>
+ <br>
+ </rules><br>
+<br>
+</synapse> <br>
+<p>This example illustrates the correlation of incoming and outgoing
+messages and the use of the <in> and <out> mediators that
+simplify the mediation configuration. This example also shows how an
+XSLT transformation of a message may be performed on receipt or reply,
+and also how a SOAP fault message may be created when required. </p>
+<h3>Example 2. </h3>
+<pre><synapse xmlns="http://ws.apache.org/ns/synapse"><br> <br>
<definitions><br> <br> <!-- define global properties
--><br> <set-property name="version" value="0.1"/><br> <br>
<!-- define a reuseable endpoint definition and use it within config
--><br> <endpoint name="invesbot"
address="http://ws.invesbot.com/stockquotes.asmx"/><br><br> <sequence
name="customrequest"><br> <!-- is this a valid custom request ?
--><br> <validate
schema="file:synapse_repository/conf/sample/validate.xsd"><br>
<on-fail><br> <!-- if the request does not validate
againt schema throw a fault --><br> <makefault><br>
<code value="tns:Receiver"
xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/><br>
<reason value="Invalid custom quote request"/><br>
</makefault><br> <br> <!-- send the fault and stop
processing --><br> <
;send/><br> </on-fail><br>
</validate><br><br> <switch
source="//m0:CheckPriceRequest/m0:Code"
xmlns:m0="http://www.apache-synapse.org/test"><br>
<case regex="IBM"><br> <set-property
name="symbol" value="Great stock - IBM"/><br>
</case><br> <case regex="MSFT"><br>
<set-property name="symbol" value="Are you sure? - MSFT"/><br>
</case><br> <default><br>
<set-property name="symbol" expression="fn:concat('Normal Stock - ',
//m0:CheckPriceRequest/m0:Code)"
xmlns:m0="http://www.apache-synapse.org/test"/><br>
</default><br> </switch><br> <br>
<!-- set a dynamic (local) message property --><br>
<br> <br> <!-- set correlation field to custom label --><br>
<set-property name="correlate/label" value="customquote"/><br>
<br> <!-- transform the custom quote into a standard quote
requst --><br>
<transform
xslt="file:synapse_repository/conf/sample/transform.xslt"/><br> <br>
<log level="custom"><br> <property
name="Text" value="Sending quote request"/><br> <property
name="version" expression="get-property('version')"/><br>
<property name="symbol" expression="get-property('symbol')"/><br>
</log><br> <br> <!-- send message to real endpoint
referenced by name "invesbot" and stop --><br> <send><br>
<endpoint ref="invesbot"/><br> </send><br>
</sequence><br><br> <sequence name="customresponse"><br>
<!-- transform the custom quote into a standard quote requst --><br>
<transform
xslt="file:synapse_repository/conf/sample/transform_back.xslt"/><br>
<br> <!-- now send the custom response back to the client and
stop --><br> <send/> <br> </sequence><br>
<br> <sequence name="stockquote">
<br> <!-- set the To address to the real endpoint --><br>
<header name="To" value="http://ws.invesbot.com/stockquotes.asmx"/><br>
<br> <!-- check if the symbol is MSFT --><br> <filter
xpath="//*[wsx:symbol='MSFT']" xmlns:wsx="http://www.webserviceX.NET/"><br>
<!-- if it is throw a fault --><br> <makefault><br>
<code value="tns:Receiver"
xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/><br>
<reason value="Isn't there a Windows API for that?"/><br>
</makefault><br> </filter><br> <br>
<send/><br> </sequence><br> <br> <sequence
name="standardrequest"><br> <!-- now log the message using
log4j --><br> <log level="full"/><br> <br>
<!-- Check if the URL matches the stockquote gateway/dumb case
--><br> <filter source="get-property('To')"
regex=".*/StockQuote.*"><br> <sequence ref="st
ockquote"/><br> </filter><br> <br>
<!-- check if the URL matches the virtual url - either the proxy or ws-add
case --><br> <filter source="get-property('To')"
regex="http://stockquote.*"><br> <sequence
ref="stockquote"/><br> </filter><br>
<br> <!-- send the message on --><br>
<send/><br> </sequence><br><br> </definitions><br><br>
<rules><br> <in><br> <!-- is this a custom
stock quote message? --><br> <filter
xpath="//m0:CheckPriceRequest"
xmlns:m0="http://www.apache-synapse.org/test"><br>
<sequence ref="customrequest"/><br> </filter><br>
<br> <!-- else, proceed as usual with the standard
processing rules --><br> <sequence
ref="standardrequest"/><br> </in><br> <br>
<out><br> <!-- is this a custom stock quote reply?
--><br> <filter source="get-property('correlate/label')"
regex="custom
quote"><br> <sequence ref="customresponse"/><br>
</filter><br><br> <!-- just let the message
flow through --><br> <send/><br> </out>
<br> </rules><br><br></synapse> <br>
+</pre>
+<p>This example adds onto the example 2 shown above and shows how the
+validate mediator could be used to perform message validation. This
+also illustrates the use of custom properties with the log mediator,
+global properties and message context properties and how they may be
+queried via the synapse:get-property(name) XPath extension function.
+See the Synapse samples for more information on this example and to try
+it out for real with the given test client. You will need to place the
+Xerces 2.8.0 jars into your <JAVA_HOME>/lib/endorsed directory,
+and the synapse-extensions.jar into the <SYNAPSE>/lib folder for
+this excersice as the validation mediator extension is dependent on the
+Xerces parser. </p>
+<h3>Example 3. </h3>
+<pre><synapse xmlns="http://ws.apache.org/ns/synapse";
xmlns:spring="http://ws.apache.org/ns/synapse/spring">
+ <definitions><br> <spring:config name="springconfig"
src="./../../repository/conf/sample/springsample.xml"/><br>
</definitions><br>
+ <rules><br> <spring:spring bean="springtest"
config="springconfig"/><br> <spring:spring bean="springtest"
src="./../../repository/conf/sample/springsample.xml"/><br>
</rules><br></synapse><br>
+</pre>
+</body>
+</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
