ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "Synapse/UserGuide" by PaulFremantle
Date Mon, 12 Dec 2005 13:50:26 GMT
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/UserGuide

------------------------------------------------------------------------------
  
  bin\synapse synapse-repository 8080 [Win]
  
- }}}}
+ }}}
  
- == Deployment models == 
+ == Deployment models ==
  
  Synapse can intermediate in a number of different models:
   * Transparent mode
@@ -74, +74 @@

  
  A synapse deployment attaches to one or more transport listeners, and mediates messages
from those listeners. One of the key decisions is how to “attach” mediators to messages.
  
- == Rules ==
+ === Rules ===
  By default Synapse will execute all defined mediators against a given message, but this
can be affected by using simple rules. Synapse has two predefined rules: {{{<xpath>}}}
and {{{<regex>}}}. xpath evaluates and XPath expression against the message, while regex
matches a regular expression against one of the message headers (such as the {{{wsa:To}}}
address).
  
  Synapse also has two simple rules {{{<in>}}} and {{{<out>}}} which process only
request or response messages (as seen by the target service).
  
- == Stages ==
+ === Stages ===
  As a message goes through the Synapse engine, it can pass through multiple stages. Each
stage is a way of grouping and organizing mediators and rules. A stage simply gives the group
a name.
  
- == An example ==
+ === An example ===
  At this point an example would be useful.
  
  {{{
@@ -114, +114 @@

  
  Finally the last stage sends the message on. For responses, the messages come back through
the same stages. This time the message will not be redirected because the “to” address
on the response will not match xmethods.
  
- == User Mediators ==
+ === User Mediators ===
  
  Synapse allows users to extend the built in mediators and add their own. The mediators use
the Synapse API. The API has three interfaces. 
  
- === SynapseMessage ===
+ ==== SynapseMessage ====
  The primary interface is the SynapseMessage interface:
   
  {{{
@@ -144, +144 @@

  
  The purpose of this interface is to capture a message as it flows through the system. As
you will see the messages are represented using the SOAP infoset. Binary messages can be embedded
in the Envelope using the MTOM support built into Axis2's AXIOM object model. 
  
- === Mediator interface ===
+ ==== Mediator interface ====
  The second key interface for mediator writers is the Mediator interface:
  
  {{{
@@ -160, +160 @@

  
  The mediator can modify the SynapseMessage in any way it likes - adjusting the routing headers
or changing the message. If it returns false, that signals to the Synapse processing model
to stop processing further. For example, if the mediator is a security agent it may decide
that this message is dangerous and should not be processed further. This is generally the
exception as mediators are usually designed to co-operate to process the message onwards.
  
- === EnvironmentAware ===
+ ==== EnvironmentAware ====
  The final aspect of the API is the EnvironmentAware interface. If the mediator implements
this, then it will have the SynapseEnvironment injected into it:
  
  {{{
@@ -191, +191 @@

  }
  }}}
  
- == Mediator configuration ==
+ === Mediator configuration ===
  
  Mediators can be configured in a few ways, including as classes, using IoC containers such
as Spring, and as deployed Axis2 Services.
  
- === ClassMediator ===
+ ==== ClassMediator ====
   Firstly, they can be loaded as simple classes:
  
  {{{
@@ -204, +204 @@

  
  This will load a class named `org.apache.sample.MyLogger` and use it to mediate messages.

  
- === ServiceMediator ===
+ ==== ServiceMediator ====
  This will direct the message through a deployed Axis2 service which implements the mediate
interface:
  
  {{{
  <servicemediator name="optional-name" service="service-name"/>
  }}}
  
- === SpringMediator ===
+ ==== SpringMediator ====
  This model is supported by an optional extension, and requires that you have the `spring-core`,
`spring-context` and `spring-beans` libraries from the [http://www.springframework.org Spring
framework] website, as well as the `springmediator.jar` in your classpath.
  
  The Spring mediator model uses a spring assembly to configure an assembly of beans. The
bean assembly must produce at one bean which implements the mediator interface. 
@@ -244, +244 @@

  
  There is a corresponding {{{<out>}}} rule.
  
- == References ==
+ === References ===
  In order to make the configuration more re-usable, every rule, stage or mediator can be
named:
  {{{
  	<stage name=”thisname”>
@@ -271, +271 @@

  }}}
  Please note this is one area where we expect to do considerable work 
  
- == Never ==
+ === Never ===
  This is a stage where none of the children get executed. Its purpose is to allow you to
place rules and mediations and have them not executed but instead refer to them from one or
more other places.
  
  So the following may be deemed equivalent to the previous example
@@ -289, +289 @@

  }}}
  
  
- == Content based routing ==
+ === Content based routing ===
- We can further improve this example by adding some “content-based” routing. Using an
<xpath> rule we can make tests within the XML. For example, we could decide not to allow
stock ticker queries against certain companies whose share prices we were jealous of – MSFT
say :-).
+ We can further improve our example by adding some “content-based” routing. Using an
<xpath> rule we can make tests within the XML. For example, we could decide not to allow
stock ticker queries against certain companies whose share prices we were jealous of – MSFT
say :-).
  
  To do this we can add a rule:
  {{{

Mime
View raw message