incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Incubator Wiki] Update of "SynapseConfigurationLanguage" by Asankha Perera
Date Tue, 25 Apr 2006 12:50:49 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by Asankha Perera:

New page:
====== Synapse Configuration Language ======

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). 

===== Overall Structure =====

A Synapse configuration looks like the following at the top level:
      (sequencedef | endpointdef | literalpropertydef)+

===== Definitions =====

The <definitions> section defines reusable elements that can be used from inside the
rules and the <rules> section contains the sequence of mediators that every message
is processed through.

==== Sequences ====

A sequencedef token represents a <sequence> element which is used to define a sequence
of mediators that can be included later as a mediator.
  <sequence name="string">

==== Endpoints ====

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.
  <endpoint name="string" [address="url"]>
    .. extensibility ..

==== Properties ====

The token literalpropertydef refers to a <set-property> element as follows:
  <set-property name="string" value="string"/>
which is used to set a glboal property with a constant value.

These properties are top level properties which are set globally for the entire system. Values
of these properties can be retrieved via an extension XPath function called "synapse:get-property(prop-name)".

===== Mediators =====

A mediator token refers to any of the following tokens:
  send | drop | log | makefault | transform | edit | filter | switch | class | validate |
setproperty | sequenceref

==== Send ====

The send token represents a <send> element. The <send> element is used to send
messages out of Synapse to some endpoint. 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:

If the message is to be sent to one or more endpoints, then the following is used:
    (endpointref | endpoint)+
where the endpointref token refers to the following:
  <endpoint ref="name"/>
and the endpoint token refers to an anonymous endpoint defined inline:
  <endpoint address="url"/>

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:
    <load-balance algorithm="uri">
      (endpointref | endpoint)+

Similarly, if the message is to be sent to an endpoint with failover semantics, then it is
indicated by the following:
      (endpointref | endpoint)+

==== Drop ====

The drop token refers to a <drop> element which is used to drop a message:
Once the <drop> mediator is executed, the message processing is finished.

==== Log ====

The log token refers to a <log> element which is used to log the message:
  <log [level="string"]>
    <property name="string" (value="literal" | expression="xpath")/>*

The optional level attribute selects a pre-defined subset of properties to be logged. e.g.

==== Transforms ====

=== Faults ===

  <makefault [version="soap11|soap12"]>
    <code (value="literal" | expression="xpath")/>
    <reason (value="literal" | expression="xpath")>

=== XSLT/XQuery ===

  <transform xslt|xquery="url" [source="xpath"]>
    <property name="string" (value="literal" | expression="xpath")/>*

=== Headers ===

The edit token refers to any of the following elements: <remove-header> and <set-header>:
  <remove-header name="qname"/>
  <set-header name="qname" (value="literal" | expression="xpath")/>
Note that <set-header> currently only supports simple valued headers. In the future
we may extend this to have XML structured headers by embedding the XML content in the set-header
element itself.

==== Selection ====

=== Filters ===

  <filter (source="xpath" regex="string") | xpath="xpath">

=== Switch ===

  <switch source="xpath">
    <case regex="string">

==== Validation ====

  <validate schema="url" [source="xpath"]>

If the source attribute is not specified, the validation is performed against the soap envelope

==== Properties ====

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.
  <set-property name="string" (value="literal" | expression="xpath")/>

These properties are set on the message context of the message currently flowing through the
system. The value of property can be queried via the XPath extension function "synapse:get-property(prop-name)".

==== Class Mediators ====
  <class name="class-name">
    <property name="string" (value="literal" | expression="xpath")/>*

==== Reusing Sequences ====

A sequenceref token refers to a <sequence> element which is used to invoke a named sequence
of mediators:
  <sequence ref="name"/>

===== Examples =====

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).

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.

      <sequence name="registration_flow">
        <validate schema="http://registry/xsd/registration.xsd" source="//regRequest">
            <set-property name="error-code" value="100"/>
            <set-property name="error-reason" value="validation failed"/>
            <sequence ref="fault_flow"/>
        <filter xpath="/regRequest[@Category='GOLD']">
               <endpoint ref="gold_registration"/>
               <endpoint ref="silver_registration"/>
          <endpoint ref="silver_registration"/>
      <sequence name="fault_flow">
        <log level="simple">
          <property name="application" value="synapse:get-property('reg-app')"/>
        <makefault version="soap11">
          <code value="synapse:get-property('error-code')"/>
          <reason expression="synapse:get-property('error-reason')">
      <endpoint name="gold_registration" address="http://gold/registration"/>
      <endpoint name="silver_registration" address="http://silver/registration"/>
        <set-property name="reg_app" value="Registration Application"/>
      <switch source="synapse:get-property('to')">
        <case regex="/registration">
          <sequence ref="registration_flow"/>
        <case regex="someother">

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message