Dear Wiki user,

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

The following page has been changed by PaulFremantle:
http://wiki.apache.org/ws/Synapse/200509F2F

------------------------------------------------------------------------------
   * Configure a new endpoint
   * Configure a raw pass-thru mediation between a listener and endpoint
  
+ === Core Model ===
  
- ====XML==============
+ There is a rule: match -> mediation component approach
+ 
+ Suppose I want to log every message, and then run tranform mediation on the 
stockquote service.
+ 
+ rules
+ *                             ->      LogMediation, QoS markers
+ http://xmethods.net/stockquote        ->      StockXFormMediation, QoS markers
+ 
+ This could be used as a "composition" model, but that is not the primary aim. 
Primarily compositions happen statically 
+ inside a mediation. So for example, we may provide a BPELMediation that use 
BPEL syntax to compose sub-mediations. Alternatively, we may provide some 
logical composition components (chain, branch, tee) that can be combined to 
compose mediations.
+ 
+ However, there is some differences between using the rule model and the 
mediation composition mode:
+ 
+ 1.    The invocation of a Mediation component by the framework is a single 
thread - so multiple rule matches may operate on separate threads (e.g. above, 
the logging may happen on a different thread to the xform). 
+       
+ 2.    The QoS markers are only at the level of a rule. So mediation writers 
can do what they like inside a mediation. So if a mediation wants to launch a 
new AxisEngine to get the security handlers invoked it can.  
+ 
+ 3. The rule matching is inherently dynamic, whereas the mediations are more 
statically defined and deployed. (of course a mediation is just Java so it can 
do as much dynamic stuff as any other Java - reflection, classloading, etc). 
+ 
+ Rules can be added dynamically.
+ 
+ In fact because the system is inherently one-way, sometimes we will 
automatically add a new tule that matches an async response. 
+ 
+ === XML ===
+ We could write our own serialisation
+ 
  <sxl>
        <match xpath="wsa:To/address=http://dims.com/tricky"/>
        <mediation name="dims">
                <param name="finalendpoint" value="http://paul.com/easy"/>
        </mediation>
  </sxl>
+ 
+ 
+ or use Policy attachment 
  
  <wsp:PolicyAttachment>
        <AppliesTo>
@@ -85, +114 @@

        </Policy>
  </wsp:PolicyAttachment>
  
+ Another option would be to have an ASCII/LEX serialisation that transforms 
to/from the PolAttachment model above.
+ 

Reply via email to