You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by ru...@apache.org on 2008/01/28 12:05:55 UTC
svn commit: r615849 [4/11] - in /webservices/synapse/trunk/java/src/site: ./
resources/ resources/css/ resources/download/ xdoc/ xdoc/1_0/ xdoc/1_1/
xdoc/download/ xdoc/download/1.0/ xdoc/download/1.1.1/ xdoc/download/1.1/
Propchange: webservices/synapse/trunk/java/src/site/xdoc/1_0/samples.xml
------------------------------------------------------------------------------
svn:executable = *
Added: webservices/synapse/trunk/java/src/site/xdoc/1_0/samples_setup.xml
URL: http://svn.apache.org/viewvc/webservices/synapse/trunk/java/src/site/xdoc/1_0/samples_setup.xml?rev=615849&view=auto
==============================================================================
--- webservices/synapse/trunk/java/src/site/xdoc/1_0/samples_setup.xml (added)
+++ webservices/synapse/trunk/java/src/site/xdoc/1_0/samples_setup.xml Mon Jan 28 03:05:41 2008
@@ -0,0 +1,518 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"/>
+ <title>
+ Apache Synapse Samples
+ </title>
+ <meta name="generator" content="Amaya 9.54, see http://www.w3.org/Amaya/"/>
+ <style type="text/css" xml:space="preserve">
+ .command {
+ border: 1px dashed #3c78b5;
+ text-align: left;
+ background-color: #f0f0f0;
+ padding: 3px;
+ font-size: 11px;
+ font-family: Courier;
+ margin: 10px;
+ line-height: 13px;
+ }
+ .consoleOutput {
+ border: 1px dashed #3c78b5;
+ font-size: 11px;
+ font-family: Courier;
+ margin: 10px;
+ line-height: 13px;
+ background-color: #f0f0f0;
+ border-bottom: 1px dashed #3c78b5;
+ padding: 3px;
+ border-style: solid;
+ }
+ .info {
+ border-style: solid;
+ border-width: 1px;
+ border-color: #090;
+ background-color: #dfd;
+ text-align:left;
+ margin-top: 5px;
+ margin-bottom: 5px;
+ }
+ li {
+ font-family: Verdana, arial, sans-serif;
+ font-size: 11px;
+ line-height: 16px;
+ color: #000000;
+ font-weight: normal;
+ }
+ p {
+ font-family: Verdana, arial, sans-serif;
+ font-size: 11px;
+ line-height: 16px;
+ color: #000000;
+ font-weight: normal;
+ }
+ pre {
+ padding: 0px;
+ margin-top: 5px;
+ margin-left: 15px;
+ margin-bottom: 5px;
+ margin-right: 5px;
+ text-align: left;
+ background-color: #f0f0f0;
+ padding: 3px;
+ border: 1px dashed #3c78b5;
+ font-size: 11px;
+ font-family: Courier;
+ margin: 10px;
+ line-height: 13px;
+ }
+ h1 {
+ font-size: 24px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ color: #003366;
+ border-bottom: 1px solid #3c78b5;
+ padding: 2px;
+ margin: 36px 0px 4px 0px;
+ }
+ h2 {
+ font-size: 18px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ border-bottom: 1px solid #3c78b5;
+ padding: 2px;
+ margin: 27px 0px 4px 0px;
+ }
+ h3 {
+ font-size: 14px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ padding: 2px;
+ margin: 21px 0px 4px 0px;
+ }
+ h4 {
+ font-size: 12px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ padding: 2px;
+ margin: 18px 0px 4px 0px;
+ }</style>
+ </head>
+ <body>
+ <h1>
+ Overview
+ </h1>
+ <p/>
+ <p>
+ Synapse ships with a set of working examples that demonstrates some of the
+ basic features and capabilities of Synapse. A set of sample clients and
+ services are provided in addition to the sample configurations, and
+ scripts are provided to execute the sample scenarions as explained below.
+ </p>
+ <h4>
+ Pre-requisites
+ </h4>
+ <p>
+ You will need a Java development kit / JRE version 1.4 or later and Apache
+ Ant 1.5 or later at a minimum to try out the samples. Ant can be
+ downloaded from http://ant.apache.org. The JMS examples could be executed
+ against an ActiveMQ installation by default (or another JMS provider with
+ configuration) and any https examples would require a JDK version 1.5 or
+ later.
+ </p>
+ <p/>
+ <p>
+ Note*: The samples and the documentation assumes that you are running
+ Synapse in DEBUG mode. You could switch from the default INFO log messages
+ to DEBUG log messages by changing the line
+ "log4j.category.org.apache.synapse=INFO" as
+ "log4j.category.org.apache.synapse=DEBUG" in the lib/log4j.properties
+ file.
+ </p>
+ <h2>
+ Understanding the samples
+ </h2>
+ <p/>
+ <p>
+ The above diagram depicts the interactions between the clients, Synapse
+ and services at a high level. The Clients are able to send SOAP/REST or
+ POX messages over transports such as http/s or JMS with WS-Addressing,
+ WS-Security or WS-Reliable messaging. They could send binary optimized
+ content using MTOM or SwA or binary or plain text JMS messages. After
+ mediation through Synapse, the requests are passed over to the sample
+ services. The sample clients and services are explained below.
+ </p>
+ <p/>
+ <h2>
+ Using the sample clients
+ </h2>
+ <p/>
+ <p>
+ The sample clients could be executed from the samples/axis2Client
+ directory through the provided ant script. Simply executing 'ant' displays
+ the available clients and some of the sample options used to configure
+ them. The sample clients available are listed below:
+ </p>
+ <h3>
+ 1. Stock quote client
+ </h3>
+ <p/>
+ <p>
+ This is a simple SOAP client that could send stock quote requests, and
+ receive and display the last sale price for a stock symbol.
+ </p>
+<pre xml:space="preserve">ant stockquote [-Dsymbol=IBM|MSFT|SUN|..]
+ [-Dmode=quote | customquote | fullquote | placeorder | marketactivity]
+ [-Daddurl=http://localhost:9000/soap/SimpleStockQuoteService]
+ [-Dtrpurl=http://localhost:8080] [-Dprxurl=http://localhost:8080]
+ [-Dpolicy=../../repository/conf/sample/resources/policy/policy_1.xml]</pre>
+
+ <p>
+ The client is able to operate in the following modes, and send the
+ payloads listed below as SOAP messages:
+ </p>
+ <ul>
+ <li>
+ </li>
+ <li>
+ quote - send a quote request for a single stock as follows. The response
+ contains the last sales price for the stock which would be displayed
+<pre xml:space="preserve"><m:getQuote xmlns:m="http://services.samples/xsd">
+ <m:request>
+ <m:symbol>IBM</m:symbol>
+ </m:request>
+</m:getQuote></pre>
+ </li>
+ <li>
+ </li>
+ <li>
+ customquote - send a quote request in a custom format. Synapse would
+ transform this custom request into the standard stock quote request
+ format and send it to the service. Upon receipt of the response, it
+ would be transformed again to a custom response format and returned to
+ the client, which will then display the last sales price.
+<pre xml:space="preserve"><m0:checkPriceRequest xmlns:m0="http://www.apache-synapse.org/test">
+ <m0:Code>symbol</m0:Code>
+</m0:checkPriceRequest></pre>
+ </li>
+ <li>
+ </li>
+ <li>
+ fullquote - get quote reports for the stock over a number of days (i.e.
+ last 100 days of the year).
+<pre xml:space="preserve"><m:getFullQuote xmlns:m="http://services.samples/xsd">
+ <m:request>
+ <m:symbol>IBM</m:symbol>
+ </m:request>
+</m:getFullQuote></pre>
+ </li>
+ <li>
+ </li>
+ <li>
+ placeorder - place an order for stocks using a one way request
+<pre xml:space="preserve"><m:placeOrder xmlns:m="http://services.samples/xsd">
+ <m:order>
+ <m:price>3.141593E0</m:price>
+ <m:quantity>4</m:quantity>
+ <m:symbol>IBM</m:symbol>
+ </m:order>
+</m:placeOrder></pre>
+ </li>
+ <li>
+ </li>
+ <li>
+ marketactivity - get a market activity report for the day (i.e. quotes
+ for multiple symbols)
+<pre xml:space="preserve"><m:getMarketActivity xmlns:m="http://services.samples/xsd">
+ <m:request>
+ <m:symbol>IBM</m:symbol>
+ ...
+ <m:symbol>MSFT</m:symbol>
+ </m:request>
+</m:getMarketActivity></pre>
+ </li>
+ <li>
+ </li>
+ </ul>
+ <p>
+ Note : See samples/axis2Client/src/samples/common/StockQuoteHandler.java
+ for sample responses expected by the clients.
+ </p>
+ <h4>
+ Smart client mode:
+ </h4>
+ <p>
+ The 'addurl' property sets the WS-Addressing EPR, and the 'trpurl' sets a
+ transport URL for a message. Thus by specifying both of these properties,
+ the client could operate in the 'smart client' mode, where the addressing
+ EPR could specify the ultimate receiver, while the transport URL set to
+ Synapse would ensure that any necessary mediation takes place before the
+ message is delivered to the ultimate reciver.
+ </p>
+<pre xml:space="preserve">e.g: ant stockquote -Daddurl=<addressingEPR> -Dtrpurl=<synapse></pre>
+ <h4>
+ Gateway / Dumb client mode:
+ </h4>
+ <p>
+ By specifying only a transport URL, the client operates in the 'dumb
+ client' mode, where it sends the message to Synapse and depends on the
+ Synapse rules for proper mediation and routing of the message to the
+ ultimate destination.
+ </p>
+<pre xml:space="preserve">e.g: ant stockquote -Dtrpurl=<synapse></pre>
+ <h4>
+ Proxy client mode:
+ </h4>
+ <p>
+ In this mode, the client uses the 'prxurl' as a http proxy to send the
+ request. Thus by setting the 'prxurl' to Synapse, the client could ensure
+ that the message would reach Synapse for mediation. The client could
+ optionally set a WS-Addressing EPR if required.
+ </p>
+<pre xml:space="preserve">e.g: ant stockquote -Dprxurl=<synapse> [-Daddurl=<addressingEPR>]</pre>
+
+ <p/>
+ <p>
+ Specifying a policy
+ </p>
+ <p>
+ By specifying a WS-Policy using the 'policy' property, QoS aspects such as
+ WS-Security could be enforced on the request. The policy could specify
+ details such as timestamps, signatures and encryption. See Apache Axis2
+ and Apache Rampart documentation for more information.
+ </p>
+ <p/>
+ <h3>
+ 2. Generic JMS client
+ </h3>
+ <p/>
+ <p>
+ The JMS client is able to send plain text, plain binary content or POX
+ content by directly publishing a JMS message to the specified destination.
+ The JMS destination name should be specified with the 'jms_dest' property.
+ The 'jms_type' property could specify 'text', 'binary' or 'pox' to specify
+ the type of message payload.
+ </p>
+ <p/>
+ <p>
+ The plain text payload for a 'text' message could be specified through the
+ 'payload' property. For binary messages, the 'payload' property would
+ contain the path to the binary file. For POX messages, the 'payload'
+ property would hold a stock symbol name to be used within the POX request
+ for stock order placement request.
+ </p>
+ <p>
+ e.g:
+ </p>
+<pre xml:space="preserve">ant jmsclient -Djms_type=text -Djms_dest=dynamicQueues/JMSTextProxy -Djms_payload="24.34 100 IBM"
+ant jmsclient -Djms_type=pox -Djms_dest=dynamicQueues/JMSPoxProxy -Djms_payload=MSFT
+ant jmsclient -Djms_type=binary -Djms_dest=dynamicQueues/JMSFileUploadProxy
+ -Djms_payload=./../../repository/conf/sample/resources/mtom/asf-logo.gif</pre>
+ <p>
+ Note: The JMS client assumes the existence of a default ActiveMQ (4.1.0 or
+ above) installation on the local machine.
+ </p>
+ <p/>
+ <h3>
+ 3. MTOM / SwA client
+ </h3>
+ <p/>
+ <p>
+ The MTOM / SwA client is able to send a binary image file as a MTOM or SwA
+ optimized message, and receive the same file again through the response
+ and save it as a temporary file. The 'opt_mode' could specify 'mtom' or
+ 'swa' respectively for the above mentioned optimizations. Optionally the
+ path to a custom file could be specified through the 'opt_file' property,
+ and the destination address could be changed through the 'opt_url'
+ property if required.
+ </p>
+<pre xml:space="preserve">e.g. ant optimizeclient -Dopt_mode=[mtom | swa]</pre>
+
+ <p/>
+ <h2>
+ Starting the sample services
+ </h2>
+ <p/>
+ <p>
+ The sample services ship with a pre-configured Axis2 server and
+ demonstrates in-only and in-out SOAP/REST or POX messaging over http/s and
+ JMS transports, using WS-Addressing, WS-Security and WS-Reliable Messaging
+ and handling of binary content using MTOM and SwA.
+ </p>
+ <p>
+ The sample services can be found in the samples/axis2Server/src directory
+ and could be built and deployed using ant from within each service
+ directory
+ </p>
+<pre xml:space="preserve">user@host:/tmp/synapse-1.0/samples/axis2Server/src/SimpleStockQuoteService$ ant
+Buildfile: build.xml
+...
+build-service:
+ ....
+ [jar] Building jar: /tmp/synapse-1.0/samples/axis2Server/repository/services/SimpleStockQuoteService.aar
+
+BUILD SUCCESSFUL
+Total time: 3 seconds</pre>
+ <p/>
+ <p>
+ To start the Axis2 server, go to the samples/axis2Server directory and
+ execute the axis2server.sh or axis2server.bat script. This starts the
+ Axis2 server with the http transport listener on port 9000 and https on
+ 9002 respectively. To enable JMS transport, you will need to setup and
+ start a JMS provider. An ActiveMQ 4.0.1 or later JMS server on the local
+ machine is supported by default, and could be easily enabled by
+ uncommenting the JMS transport from the repository/conf/axis2.xml
+ </p>
+ <p/>
+ <p>
+ Sample services
+ </p>
+ <h3>
+ 1. SimpleStockQuoteService
+ </h3>
+ <p>
+ This service has four operations, getQuote (in-out), getFullQuote(in-out),
+ getMarketActivity(in-out) and placeOrder (in-only). The getQuote operation
+ will generate a sample stock quote for a given symbol. The getFullQuote
+ operation will generate a history of stock quotes for the symbol for a
+ number of days, and the getMarketActivity operation returns stock quotes
+ for a list of given symbols. The placeOrder operation will accept a one
+ way message for an order.
+ </p>
+ <h3>
+ 2. SecureStockQuoteService
+ </h3>
+ <p>
+ This service is a clone of the SimpleStockQuoteService, but has
+ WS-Security enabled and an attached security policy for signing and
+ encryption of messages.
+ </p>
+ <h3>
+ 3. MTOMSwASampleService
+ </h3>
+ <p>
+ This service has three operations uploadFileUsingMTOM(in-out),
+ uploadFileUsingSwA(in-out) and oneWayUploadUsingMTOM(in-only) and
+ demonstrates the use of MTOM and SwA. The uploadFileUsingMTOM and
+ uploadFileUsingSwA operations accept a binary image from the SOAP request
+ as MTOM and SwA, and returns this image back again as the response; while
+ the oneWayUploadUsingMTOM saves the request message to disk.
+ </p>
+ <p/>
+ <p>
+ Starting sample Synapse configurations
+ </p>
+ <p>
+ To start Synapse with the sample default configuration, execute the
+ synapse.bat or synapse.sh script found in the /bin directory. This starts
+ up an instance of Synapse using the Synapse and Axis2 configuration files
+ located in the repository/conf directory. The repository/conf/samples
+ directory contains the sample configurations available as synapse_sample_<n>.xml
+ files. To start a specific sample configuration of Synapse, use the
+ '-sample <n>' switch as follows:
+ </p>
+<pre xml:space="preserve">synapse.bat -sample <n>
+synapse.sh -sample <n></pre>
+ <p/>
+ <h2>
+ Setting up JMS
+ </h2>
+ <p/>
+ <p>
+ The samples used in this guide assumes the existence of a local ActiveMQ
+ (4.1.0 or higher) installation properly installed and started up. You also
+ need to copy the following client JAR files into the Synapse 'lib' folder
+ to support ActiveMQ. These files are found in the 'lib' directory of the
+ ActiveMQ installation.
+ </p>
+ <p/>
+ <ul>
+ <li>
+ </li>
+ <li>
+ activeio-core-3.0.0-incubator.jar
+ </li>
+ <li>
+ </li>
+ <li>
+ activemq-core-4.1.0-incubator.jar
+ </li>
+ <li>
+ </li>
+ <li>
+ geronimo-j2ee-management_1.0_spec-1.0.jar
+ </li>
+ <li>
+ </li>
+ </ul>
+ <p/>
+ <p>
+ To enable the JMS transport, you need to uncomment the JMS transport
+ listener configuration. If you are using a JMS provider other than
+ ActiveMQ this configuration should be updated to reflect your environment.
+ Once uncommented, the default configuration should be as follows. To
+ enable JMS for synapse, the repository/conf/axis2.xml must be updated,
+ while to enable JMS support for the sample Axis2 server the
+ samples/axis2Server/repository/conf/axis2.xml file must be updated.
+ </p>
+<pre xml:space="preserve"> <!--Uncomment this and configure as appropriate for JMS transport support, after setting up your JMS environment (e.g. ActiveMQ)-->
+ <transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
+ <parameter name="myTopicConnectionFactory" locked="false">
+ <parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
+ <parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter>
+ <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">TopicConnectionFactory</parameter>
+ </parameter>
+
+ <parameter name="myQueueConnectionFactory" locked="false">
+ <parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
+ <parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter>
+ <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
+ </parameter>
+
+ <parameter name="default" locked="false">
+ <parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
+ <parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter>
+ <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
+ </parameter>
+ </transportReceiver></pre>
+ <p/>
+ <h2 id="script">
+ Configuring Synapse for Script Mediator support
+ </h2>
+ <p/>
+ <p>
+ The Synapse Script Mediator is a Synapse extension, and thus all
+ pre-requisites are not bundled by default with the Synapse distribution.
+ Before you use some script mediators you may need to manually add the
+ required jar files to the Synapse lib directory, and optionally perform
+ other installation tasks as may be required by the individual scripting
+ language. This is detailed in the following sections.
+ </p>
+ <h4>
+ JavaScript support
+ </h4>
+ <p>
+ The JavaScript/E4X support is enabled by default and comes ready-to-use
+ with the Synapse distribution.
+ </p>
+ <h4>
+ Ruby support
+ </h4>
+ <p>
+ For Ruby support you need to download the 'jruby-complete.jar' from the
+ Maven repository for JRuby, and copy it into the 'lib' folder of Synapse .
+ The JRuby JAR can be downloaded from <a
+ href="http://repo1.maven.org/maven2/org/jruby/jruby-complete/">here</a>.
+ </p>
+ <p/>
+ </body>
+</html>
\ No newline at end of file
Propchange: webservices/synapse/trunk/java/src/site/xdoc/1_0/samples_setup.xml
------------------------------------------------------------------------------
svn:executable = *
Added: webservices/synapse/trunk/java/src/site/xdoc/1_1/configuration.xml
URL: http://svn.apache.org/viewvc/webservices/synapse/trunk/java/src/site/xdoc/1_1/configuration.xml?rev=615849&view=auto
==============================================================================
--- webservices/synapse/trunk/java/src/site/xdoc/1_1/configuration.xml (added)
+++ webservices/synapse/trunk/java/src/site/xdoc/1_1/configuration.xml Mon Jan 28 03:05:41 2008
@@ -0,0 +1,1511 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta content="text/html; charset=iso-8859-1" http-equiv="content-type"/>
+ <title>
+ Synapse Configuration Language
+ </title>
+ <style type="text/css" xml:space="preserve">
+ .command {
+ border: 1px dashed #3c78b5;
+ text-align: left;
+ background-color: #f0f0f0;
+ padding: 3px;
+ font-size: 11px;
+ font-family: Courier;
+ margin: 10px;
+ line-height: 13px;
+ }
+ .consoleOutput {
+ border: 1px dashed #3c78b5;
+ font-size: 11px;
+ font-family: Courier;
+ margin: 10px;
+ line-height: 13px;
+ background-color: #f0f0f0;
+ border-bottom: 1px dashed #3c78b5;
+ padding: 3px;
+ border-style: solid;
+ }
+ .info {
+ border-style: solid;
+ border-width: 1px;
+ border-color: #090;
+ background-color: #dfd;
+ text-align:left;
+ margin-top: 5px;
+ margin-bottom: 5px;
+ }
+ li {
+ font-family: Verdana, arial, sans-serif;
+ font-size: 11px;
+ line-height: 16px;
+ color: #000000;
+ font-weight: normal;
+ }
+ p {
+ font-family: Verdana, arial, sans-serif;
+ font-size: 11px;
+ line-height: 16px;
+ color: #000000;
+ font-weight: normal;
+ }
+ pre {
+ padding: 0px;
+ margin-top: 5px;
+ margin-left: 15px;
+ margin-bottom: 5px;
+ margin-right: 5px;
+ text-align: left;
+ background-color: #f0f0f0;
+ padding: 3px;
+ border: 1px dashed #3c78b5;
+ font-size: 11px;
+ font-family: Courier;
+ margin: 10px;
+ line-height: 13px;
+ }
+ h1 {
+ font-size: 24px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ color: #003366;
+ border-bottom: 1px solid #3c78b5;
+ padding: 2px;
+ margin: 36px 0px 4px 0px;
+ }
+ h2 {
+ font-size: 18px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ border-bottom: 1px solid #3c78b5;
+ padding: 2px;
+ margin: 27px 0px 4px 0px;
+ }
+ h3 {
+ font-size: 14px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ padding: 2px;
+ margin: 21px 0px 4px 0px;
+ }
+ h4 {
+ font-size: 12px;
+ line-height: normal;
+ font-weight: bold;
+ background-color: #f0f0f0;
+ padding: 2px;
+ margin: 18px 0px 4px 0px;
+ }</style>
+ </head>
+ <body>
+ <h1>
+ Synapse Configuration Language
+ </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. It is currently
+ direction agnostic, but directionality can easily be added as a selection
+ mechanism for mediators (see below for details).
+ </p>
+ <h3>
+ Overall Structure
+ </h3>
+ <p>
+ A Synapse configuration looks like the following at the top level:
+ </p>
+<pre xml:space="preserve"> <definitions>
+ <<a href="#registry">registry</a> provider="string">...</registry>?
+ <<a href="#localEntry">localEntry</a> key="string">...</localEntry>?
+ <<a href="#sequence">sequence</a> name="string">...</sequence>?
+ <<a href="#endpoint">endpoint</a> name="string">...</endpoint>?
+ <<a href="#proxy">proxy</a> name="string" ...>...</proxy>?
+ <<a href="#task">task</a> name="string" ...>...</task>?
+ <a href="#mediator">mediator</a>*
+ </definitions></pre>
+ <p/>
+ <p>
+ The Synapse configuration is held in a single XML file called the
+ 'synapse.xml' and this may refer to other configuration fragments and
+ resources - which may be held in an external Registry or Repository. The
+ Synapse release ships with a simple URL based registry implementation that
+ could use a file system, web server etc. as the registry/repository
+ backend. When using the file system, the contents could be held in a
+ version controlled directory so that changes could be controlled and moved
+ from Dev, QA, Staging to Production. The Synapse engine and the simple URL
+ registry implementation support caching and dynamic refreshing of some
+ configuration elements [sequences & endpoints] and resources such as
+ XSLT's, Scripts, XSDs etc. Synapse can be easily integrated with an
+ external registry by implementing the
+ 'org.apache.synapse.registry.Registry' interface.
+ </p>
+ <p/>
+ <p>
+ A Synapse configuration refers to resources stored on an external Registry
+ via 'keys'. The 'localEntry' elements in a configuration provides the
+ capability to define a new resource or configuration fragment; or to
+ override any existing resource available under a registry with a local
+ replacement. An example would be to use a localEntry to override the
+ production endpoint definition for development time. Local entries could
+ direct to an external URL for the resource content, or provide the text or
+ XML content inline.
+ </p>
+ <p/>
+ <p>
+ Synapse accepts messages for mediation via the exposed/enabled transports.
+ These are configured via the 'axis2.xml' configuration file. By default
+ the http, https and VFS transports are enabled. Using the JMS and Mail
+ transports requires that these be enabled and configured for your
+ environment via the axis2.xml file. Once a proxy service is defined, it
+ could be configured to listen for messages on one or more of the enabled
+ transports. A proxy service then listens for messages over the selected
+ transports by exposing a virtual service. A proxy service maybe a SOAP or
+ POX service over http/s or SOAP, POX or Plain Text service for other
+ transports such as JMS and VFS - e.g. CSV content being its payload. Thus
+ Synapse is able to switch between these message formats and transports, as
+ well as introduce or terminate QoS aspects such as WS-Security/RM through
+ proxy services.
+ </p>
+ <p/>
+ <p>
+ Sequences define an ordered execution of a set of 'Mediators', where each
+ 'Mediator' gets full access to the current message flowing through the
+ system. Synapse ships with a common set of mediators that can handle most
+ of the common tasks such as - logging, content based routing,
+ transformations using XSLT/XQuery, validation, BSF scripting language
+ based or Java class based mediation, database reporting or lookup,
+ caching, throttling, cloning, splitting and aggregation etc. Writing a
+ custom mediator in Java is easy and the supplementary documentation
+ provides more details. The 'Class' and 'POJO' mediators allows one to
+ plugin a Java class easily into the Synapse engine with minimal effort.
+ </p>
+ <p/>
+ <p>
+ Typically proxy services associates mediation sequences for processing
+ incoming and outgoing messages. A Synapse configuration holds two special
+ sequences called the 'main' and 'fault' sequences. The 'main' sequence
+ executes for any message that is not received by any particular proxy
+ service. When using the http/s transports - this refers to the concept of
+ 'Message Mediation' where Synapse may be configured as a transparent proxy
+ to its clients. In this scenario, Synapse could receive all messages on
+ the wire and mediate them as necessary and send them to the final
+ destinations. The 'fault' sequence executes whenever Synapse itself
+ encounters an error while processing a message - or when a fault handler
+ has not been defined to handle exceptions. Typically a fault sequence
+ would log the failed message and any other context information.
+ </p>
+ <p/>
+ <p>
+ Endpoints define aspects to be considered when sending a message out from
+ Synapse. Endpoints also allow load balancing, fail-over and timeout
+ scenarios to be handled - or to introduce WS-Security, Addressing or RM
+ for messages sent to an endpoint. An endpoint maybe defined as an Address
+ or using a WSDL definition.
+ </p>
+ <p/>
+ <h2>
+ <a name="registry" id="registry">Registry</a>
+ </h2>
+ <p>
+ The <registry> element is used to define a remote registry which are
+ referenced from within the configuration. The registry provider specifies
+ an implementation class for the registry used, and optionally a number of
+ configuration parameters may be specified to configure the connection to
+ the registry.
+ </p>
+<pre xml:space="preserve"> <registry provider="string"/>
+ <parameter name="string">text | xml</parameter>*
+ </registry></pre>
+ <p>
+ Registry entries loaded from a remote registry are cached within Synapse
+ as dictated by the registry, and reloaded after the cache periods expires.
+ Hence it is possible to define configuration elements such as (dynamic)
+ sequences and endpoints, as well as resources such as XSLT's or XSDs off
+ the registry, and update the configuration as these change dynamically
+ over time.
+ </p>
+ <p/>
+ <h3>
+ <a name="localEntry" id="localEntry">Local Entry</a>
+ </h3>
+ <p>
+ The <localEntry> element is used to declare registry entries that
+ are local to the Synapse instance, as shown below
+ </p>
+<pre xml:space="preserve"> <localEntry key="string" [src="url"]>text | xml</localEntry></pre>
+ <p>
+ These entries are top level entries which are set globally for the entire
+ system. Values of these entries can be retrieved via the extension XPath
+ function "synapse:get-property(prop-name)".
+ </p>
+ <p>
+ An entry can be static text specified as inline text or static XML
+ specified as an inline XML fragment or specified as a URL (using the src
+ attribute). These local entries can override any existing entries with the
+ same keys of the remote registry.
+ </p>
+ <p/>
+ <h2>
+ <a name="sequence" id="sequence">Sequences</a>
+ </h2>
+ <p>
+ A <sequence> element is used to define a sequence of mediators that
+ can be invoked later by name.
+ </p>
+<pre xml:space="preserve"> <sequence name="string" [onError="string"] [key="string"] [trace="enable"]>
+ mediator*
+ </sequence></pre>
+ <p>
+ If the configuration defines a sequence named "main" then it is considered
+ as the main mediation sequence of Synapse. If such a sequence is not
+ defined locally, and a registry has been specified, the registry is looked
+ up for a key named "main" to find the main mediation sequence. Synapse
+ also supports the specification of mediators directly within the <definitions>
+ tag, and if any mediators are present, will be considered to constitute
+ the main sequence. In the absence of a main sequence, the Synapse runtime
+ will create a default main sequence that consists of an implicit send
+ mediator.
+ </p>
+ <p>
+ Synapse considers a sequence named "fault", or in its absence a registry
+ entry with a key "fault" as its general fault handler sequence. If Synapse
+ encounters an erroneous situation while processing a message through a
+ sequence, it executes the defined error handling sequence for the current
+ context - which may be specified as the 'onError' sequence for a sequence
+ mediator. If a fault sequence is not specified or cannot be found through
+ the registry, Synapse will create a default fault sequence that will
+ perform a default logging of the message at the log level 'full'.
+ </p>
+ <p>
+ If an optional error handler sequence name is specified on any sequence
+ through the attribute 'onError', an exception on this sequence will invoke
+ the sequence specified by this key.
+ </p>
+ <p>
+ A Dynamic Sequence may be defined by specifying a key reference to a
+ registry entry. As the remote registry entry changes, the sequence will
+ dynamically be updated according to the specified cache duration and
+ expiration. If tracing is enabled on a sequence, all messages being
+ processed through the sequence would write tracing information through
+ each mediation step to the trace.log file configured via the
+ log4j.properties configuration. Setting the trace log level to TRACE would
+ additionally dump the message at each mediation.
+ </p>
+ <p/>
+ <h2>
+ <a name="endpoint" id="endpoint">Endpoints</a>
+ </h2>
+ <p>
+ An <endpoint> element defines a destination for an outgoing message.
+ An endpoint may be specified as an address endpoint, WSDL based endpoint,
+ a load balanced endpoint or a fail-over endpoint as follows:
+ </p>
+<pre xml:space="preserve"><endpoint [name="string"] [key="string"][trace="enable"]>
+ <a href="#address-endpoint">address-endpoint</a> | <a href="#wsdl-endpoint">wsdl-endpoint</a> | <a href="#load-balanced-endpoint">load-balanced-endpoint</a> | <a href="#fail-over-endpoint">fail-over-endpoint</a>
+</endpoint> </pre>
+ <p>
+ All above endpoint types can have a name attribute. Such named endpoints
+ can be refered by other endpoints, which only contain the key attribute.
+ For example if there is an endpoint named as "foo", following endpoint can
+ be used in any place, where "foo" has to be used. A tracing enabled
+ endpoint would generate trace information into the trace log for each
+ message that passes through.
+ </p>
+<pre xml:space="preserve"><endpoint key="foo"/></pre>
+ <h4>
+ <a name="address-endpoint" id="address-endpoint">Address Endpoint</a>
+ </h4>
+ <p>
+ Address endpoint is an endpoint defined by specifying the EPR and other
+ attributes of the endpoint directly in the configuration.The 'uri'
+ attribute of the address element contains the EPR of the target endpoint.
+ Message format for the endpoint and the method to optimize attachments can
+ be specified in the format and optimize attributes respectively. Reliable
+ messaging and security policies for the endpoint can be specified in the
+ policy attribute of the enableRM and enableSec elements respectively.
+ WS-Addressing can be engaged for the messaging going to the endpoint by
+ the enableAddressing element. suspendDurationOnFailure attribute specifies
+ the time duration in seconds to suspend this endpoint, if it is detected
+ as failed. If this attribute is not specified, endpoint will never be
+ recovered after a failure.
+ </p>
+ <p/>
+ <p>
+ Address endpoints can timeout the responses if they failed to arrive
+ Synapse in predefined time duration. This is done by the timeout elements.
+ duration element inside the timeout element contains duration for the
+ timeout in seconds. action element specifies the action to be performed
+ once a timeout occurs. Allowed actions are discard and fault. If discard
+ is specified, responses arriving after the timeout will be discarded
+ without further processing. If fault is specified as the action, fault
+ sequence applicable for the endpoint will be activated as soon as the
+ timeout occurs and responses will not be processed after that.
+ </p>
+<pre xml:space="preserve"><address uri="endpoint-address" format="soap11|soap12|pox" [optimize="mtom|swa"]>
+ <enableRM [policy="key"]/>?
+ <enableSec [policy="key"]/>?
+ <enableAddressing/>?
+ <suspendDurationOnFailure>suspend-duration</suspendDurationOnFailure>?
+ <timeout>
+ <duration>timeout-duration</duration>
+ <action>discard|fault</action>
+ </timeout>?
+</address></pre>
+ <h4>
+ <a name="wsdl-endpoint" id="wsdl-endpoint">WSDL Endpoint</a>
+ </h4>
+ <p>
+ WSDL endpoint is an endpoint based on a WSDL document. It can extract the
+ target EPR from a given WSDL. The WSDL document can be specified either as
+ a URI or as an inlined definition within the configuration. The service
+ and port name containing the target EPR has to be specified in service and
+ port attributes respectively. enableRM, enableSec, enableAddressing,
+ suspendDurationOnFailure and timeout elements are same as for the Address
+ endpoint.
+ </p>
+<pre xml:space="preserve"><wsdl [uri="wsdl-uri"] service="qname" port/endpoint="qname">
+ <wsdl:definition>...</wsdl:definition>?
+ <wsdl20:description>...</wsdl20:description>?
+ <enableRM [policy="key"]/>?
+ <enableSec [policy="key"]/>?
+ <enableAddressing/>?
+ <suspendDurationOnFailure>suspend-duration</suspendDurationOnFailure>?
+ <timeout>
+ <duration>timeout-duration</duration>
+ <action>discard|fault</action>
+ </timeout>?
+</wsdl></pre>
+ <h4>
+ <a name="load-balanced-endpoint" id="load-balanced-endpoint">Load
+ balanced Endpoint</a>
+ </h4>
+ <p>
+ A Load balanced endpoint distributes the messages (load) arriving at it
+ among a set of listed endpoints by evaluating the load balancing policy
+ and any other relevant parameters. Policy attribute of the load balance
+ element specifies the load balance policy (algorithm) to be used for
+ selecting the target endpoint. Currently only the roundRobin policy is
+ supported. failover attribute determines if the next endpoint should be
+ selected once the currently selected endpoint has failed. Default is true.
+ The set of endpoints among which the load is distributed can be listed
+ under the loadBalance element. Those endpoints can belong to any endpoint
+ type mentioned in this document. For example, failover endpoints can be
+ listed inside the load balance endpoint to load balance between failover
+ groups.
+ </p>
+ <p/>
+ <p>
+ The optional session element makes the endpoint a session affinity based
+ load balancing endpoint. If it is specified, sessions are bound to
+ endpoints in the first message and all successive messages for those
+ sessions are directed to their associated endpoints. http sessions are
+ supported currently, which identifies sessions based on http cookies.
+ failover attribute mentioned above is not applicable for session affinity
+ based endpoints and it is always set to false. If it is required to have
+ failover behavior in session affinity based load balance endpoints, list
+ failover endpoints as the target endpoints.
+ </p>
+<pre xml:space="preserve"><session type="http"/>?
+<loadBalance [policy="roundRobin"] [failover="true|false"]>
+ <endpoint .../>+
+</loadBalance></pre>
+ <h4>
+ <a name="fail-over-endpoint" id="fail-over-endpoint">Failover Endpoint</a>
+ </h4>
+ <p>
+ Failover endpoints send messages to the listed endpoints with the
+ following failover behavior. At the start, first listed endpoint is
+ selected as the primary and all other endpoints are treated as backups.
+ Incoming messages are always sent only to the primary endpoint. If the
+ primary endpoint fails, next active endpoint is selected as the primary
+ and failed endpoint is marked as inactive. Thus it sends messages
+ successfully as long as there is at least one active endpoint among the
+ listed endpoints.
+ </p>
+<pre xml:space="preserve"><failover>
+ <endpoint .../>+
+</failover></pre>
+ <h2>
+ <a name="proxy" id="proxy">Proxy service</a>
+ </h2>
+ <p>
+ A <proxy> element is used to define a Synapse Proxy service.
+ </p>
+<pre xml:space="preserve"> <proxy name="string" [transports="(http |https |jms )+|all"]>
+ <description>...</description>?
+ <target [inSequence="name"] [outSequence="name"] [faultSequence="name"] [endpoint="name"]>
+ <inSequence>...</inSequence>?
+ <outSequence>...</outSequence>?
+ <faultSequence>...</faultSequence>?
+ <endpoint>...</endpoint>?
+ </target>?
+ <publishWSDL key="string" uri="string">
+ <description>...</description> | <definitions>...</definitions>
+ <publishWSDL>?
+ <enableSec/>? // These two tags will removed after the recognition of the Security and RM can be done by looking at policy
+ <enableRM/>?
+ <policy key="string">...</policy>? // optional service level policies
+ // (e.g. WS-Security and/or WS-RM policies)
+ <parameter name="string"> // optional service parameters
+ string | xml // (e.g. transport.jms.ConnectionFactory)
+ </parameter>
+ </proxy></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 - based on the service name. (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. Target inSequence or endpoint is required for the proxy
+ configuration, and a target outSequence defines how responses should be
+ handled. Any supplied WS-Policies would apply as service level policies,
+ and any service parameters could be passed into the proxy services'
+ AxisService instance using the parameter elements (e.g. the JMS
+ destination etc). If the proxy service should enable WS-Reliable Messaging
+ or Security, the appropriate modules could be engaged, and specified
+ policies will apply.
+ </p>
+ <p>
+ A Dynamic Proxy may be defined by specifying the properties of the proxy
+ as dynamic entries by refering them with the key. (For example one could
+ specify the inSequence or endpoint with the remote key, without defining
+ it in the local configuration) As the remote registry entry changes, the
+ properties of the proxy will dynamically be updated accordingly. (Note:
+ proxy service definition itself can not be specified to be dynamic; i.e
+ <proxy key="string"/> is wrong)
+ </p>
+ <p/>
+ <p>
+ Transport specific parameters
+ </p>
+ <table border="1" style="width: 100%">
+ <caption/>
+ <tbody>
+ <tr>
+ <td>
+ Transport
+ </td>
+ <td>
+ Require
+ </td>
+ <td>
+ Parameter
+ </td>
+ <td>
+ Description
+ </td>
+ </tr>
+ <tr>
+ <td>
+ JMS
+ </td>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.jms.ConnectionFactory
+ </td>
+ <td>
+ The JMS connection factory definition (from axis2.xml) to be used to
+ listen for messages for this service
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.jms.Destination
+ </td>
+ <td>
+ The JMS Destination name (Defaults to a Queue with the service name)
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.jms.ReplyDestination
+ </td>
+ <td>
+ The Destination where a reply would be posted
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td/>
+ <td/>
+ <td/>
+ </tr>
+ <tr>
+ <td>
+ VFS
+ </td>
+ <td>
+ Required
+ </td>
+ <td>
+ transport.vfs.FileURI
+ </td>
+ <td>
+ The primary File (or Directory) URI in the vfs* transport format,
+ for this service
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Required
+ </td>
+ <td>
+ transport.vfs.ContentType
+ </td>
+ <td>
+ The content type for messages for this service
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.FileNamePattern
+ </td>
+ <td>
+ A file name regex pattern to match files against a directory
+ specified by the FileURI
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.PollInterval
+ </td>
+ <td>
+ The poll interval (in seconds)
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.ActionAfterProcess
+ </td>
+ <td>
+ DELETE or MOVE
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.MoveAfterProcess
+ </td>
+ <td>
+ The directory to move files after processing (i.e. all files process
+ successfully)
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.ActionAfterErrors
+ </td>
+ <td>
+ DELETE or MOVE
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.MoveAfterErrors
+ </td>
+ <td>
+ The directory to move files after errors (i.e. some of the files
+ succeed but some fail)
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.ActionAfterFailure
+ </td>
+ <td>
+ DELETE or MOVE
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.MoveAfterFailure
+ </td>
+ <td>
+ The directory to move after failure (i.e. all files fail)
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td/>
+ <td/>
+ <td/>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.ReplyFileURI
+ </td>
+ <td>
+ Reply file URI
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td>
+ Optional
+ </td>
+ <td>
+ transport.vfs.ReplyFileName
+ </td>
+ <td>
+ Reply file name (defaults to response.xml)
+ </td>
+ </tr>
+ <tr>
+ <td/>
+ <td/>
+ <td/>
+ <td/>
+ </tr>
+ </tbody>
+ </table>
+ <p>
+ *VFS Transport URI examples
+ </p>
+ <p>
+ file:///directory/filename.ext
+ </p>
+ <p>
+ file:////somehost/someshare/afile.txt
+ </p>
+ <p>
+ jar:../lib/classes.jar!/META-INF/manifest.mf
+ </p>
+ <p>
+ jar:zip:outer.zip!/nested.jar!/somedir
+ </p>
+ <p>
+ ftp://myusername:mypassword@somehost/pub/downloads/somefile.tgz[?vfs.passive=true]</p>
+ <h2>
+ <a name="task" id="task">Tasks</a>
+ </h2>
+ <p>
+ A <task> element is used to define a Synapse Startup Task.
+ </p>
+<pre xml:space="preserve"> <task class="org.my.synapse.Task" name="string">
+ <property name="stringProp" value="String"/>
+ <property name="xmlProp">
+ <somexml>config</somexml>
+ </property>
+ <trigger ([[count="10"]? interval="1000"] | [cron="0 * 1 * * ?"] | [once=(true | false)])/>
+ </task></pre>
+ <p>
+ A task is created and scheduled to run at the specified time intervals or
+ as specified by the cron expression. The Task class specifies the actual
+ task implementation class (which must implement
+ org.apache.synapse.startup.Task interface) to be executed at the specified
+ interval/s, and name specifies an identifier for the scheduled task.
+ Fields in the task class can be set using properties provided as string
+ literals or as XML fragments. (For example; if the task implementation
+ class has a field named "version" with a corresponding setter method, the
+ configuration value which will be assigned to this field before running
+ the task can be specified using a property with the name version)
+ </p>
+ <p>
+ There are three different trigger mechanisms to schedule tasks. A simple
+ trigger is specified specifying a 'count' and an 'interval', implying that
+ the task will run a 'count' number of times at specified intervals. A
+ trigger may also be specified as a cron trigger using a cron expression. A
+ one-time trigger is specified using the 'once' attribute as true in the
+ definition and could be specified as true in which case this task will be
+ executed only once just after the initialization of Synapse
+ </p>
+ <p/>
+ <h2>
+ <a name="mediator" id="mediator">Mediators</a>
+ </h2>
+ <p>
+ A mediator token refers to any of the following tokens:
+ </p>
+<pre xml:space="preserve"><a href="#send">send</a> | <a href="#drop">drop</a> | <a href="#log">log</a> | <a href="#property">property</a> | <a href="#sequence_ref">sequence</a> | <a href="#validate">validate</a> | <a href="#makefault">makefault</a> | <a href="#xslt">xslt</a> | <a href="#header">header</a> | <a href="#filter">filter</a> | <a href="#switch">switch</a> | <a href="#in">in</a> | <a href="#out">out</a> | <a href="#dblookup">dblookup</a> | <a href="#dbreport">dbreport</a> | <a href="#RMSequence">RMSequence</a> | <a href="#throttle">throttle</a> | <a href="#xquery">xquery</a> | <a href="#cache">cache</a> | <a href="#clone">clone</a> | <a href="#iterate">iterate</a> | <a href="#aggregate">aggregate</a> | <a href="#class">class</a> | <a href="#pojoCommand">pojoCommand</a> | <a href="#script">script</a> | <a href="#spring">spring</a> </pre>
+ <p>
+ In addition to the above, Synapse will be able to load custom mediators
+ via the J2SE Service Provider model. Mediator extensions must implement
+ the MediatorFactory interface.
+ </p>
+ <h3>
+ Core Mediators
+ </h3>
+ <h4>
+ <a name="send" id="send">Send</a>
+ </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 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. Also see the property mediator.
+ </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 xml:space="preserve"> <send/></pre>
+ <p>
+ If the message is to be sent to one or more endpoints, then the following
+ is used:
+ </p>
+<pre xml:space="preserve"> <send>
+ (endpointref | endpoint)+
+ </send></pre>
+ <p>
+ where the endpointref token refers to the following:
+ </p>
+<pre xml:space="preserve"> <endpoint key="name"/></pre>
+ <p>
+ and the endpoint token refers to an anonymous endpoint defined.
+ </p>
+ <p/>
+ <h4>
+ <a name="drop" id="drop">Drop</a>
+ </h4>
+ <p>
+ The drop token refers to a <drop> element which is used to drop a
+ message:
+ </p>
+<pre xml:space="preserve"> <drop/></pre>
+ <p>
+ Once the <drop> mediator executes, further processing of the current
+ message stops.
+ </p>
+ <p/>
+ <h4>
+ <a name="log" id="log">Log</a>
+ </h4>
+ <p>
+ The log token refers to a <log> element which may be used to log
+ messages being mediated:
+ </p>
+<pre xml:space="preserve"> <log [level="string"] [separator="string"]>
+ <property name="string" (value="literal" | expression="xpath")/>*
+ </log></pre>
+ <p>
+ The optional level attribute selects a pre-defined subset of properties to
+ be logged.
+ </p>
+ <p>
+ e.g.
+ </p>
+ <ul>
+ <li>
+ simple = To, From, WSAction, SOAPAction, ReplyTo, MessageID and any
+ properties
+ </li>
+ <li>
+ headers = All SOAP header blocks and any properties
+ </li>
+ <li>
+ full = all attributes included in log level 'simple' and the SOAP
+ envelope and any properties
+ </li>
+ <li>
+ custom = Only properties specified to the Log mediator
+ </li>
+ </ul>
+ <p>
+ A separator if defined will be used to separate the attributes being
+ logged. The default separator is the ',' comma.
+ </p>
+ <p/>
+ <h4>
+ <a name="property" id="property">Property</a>
+ </h4>
+<pre xml:space="preserve"> <property name="string" [action=set|remove] (value="literal" | expression="xpath") [scope=transport|axis2|axis2-client]/></pre>
+ <p>
+ The property token refers to a <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 which does not
+ specify the action 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. If a scope is
+ specified for a property, the property could be set as a transport header
+ property or an (underlying) Axis2 message context property, or as a Axis2
+ client option or as an Axis2 message context property. If a scope is not
+ specified, it will default to the Synapse message context scope. Using the
+ property element with action specified as "remove" you can remove the
+ message context properties if available.
+ </p>
+ <p>
+ There are some well-defined properties that you can get/set:
+ </p>
+ <ul>
+ <li>
+ RESPONSE - 'true' means the message is marked as a response message
+ </li>
+ <li>
+ OUT_ONLY - 'true' means the message is marked as an out-only message
+ that does not expect a response
+ </li>
+ <li>
+ ERROR_CODE - this is set to any error message code encountered
+ </li>
+ <li>
+ ERROR_MESSAGE - this is set to any error message text encountered
+ </li>
+ <li>
+ ERROR_DETAIL - this is set to any error message detail text encountered
+ </li>
+ </ul>
+ <p>
+ There are also some Axis2 and module properties that are useful to set
+ (with scope="axis2"):
+ </p>
+ <ul>
+ <li>
+ Sandesha2RMSpecVersion - can be '1.0' or '1.1'
+ </li>
+ <li>
+ Sandesha2SequenceKey - can be an identifier specifying an Sandesha
+ internal sequence key, and
+ </li>
+ <li>
+ Sandesha2LastMessage - 'true' will make this the last message and
+ terminate the sequence
+ </li>
+ </ul>
+ <p/>
+ <h4>
+ <a name="sequence_ref" id="sequence_ref">Sequence</a>
+ </h4>
+<pre xml:space="preserve"> <sequence key="name"/></pre>
+ <p>
+ A sequence ref token refers to a <sequence> element which is used to
+ invoke a named sequence of mediators.
+ </p>
+ <p/>
+ <h4>
+ <a name="validate" id="validate">Validate</a>
+ </h4>
+<pre xml:space="preserve"> <validate [source="xpath"]>
+ <property name="validation-feature-id" value="true|false"/>*
+ <schema key="string"/>+
+ <on-fail>
+ mediator+
+ </on-fail>
+ </validate></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 first
+ child of the SOAP body of the current message. If the validation fails,
+ the on-fail sequence of mediators is executed. Properties could be used to
+ turn on/off some of the underlying features of the validator (See
+ http://xerces.apache.org/xerces2-j/features.html)
+ </p>
+ <p/>
+ <h3>
+ Transformation Mediators
+ </h3>
+ <h4>
+ <a name="makefault" id="makefault">Makefault</a>
+ </h4>
+<pre xml:space="preserve"> <makefault [version="soap11|soap12"]>
+ <code (value="literal" | expression="xpath")/>
+ <reason (value="literal" | expression="xpath")>
+ <node>?
+ <role>?
+ <detail>?
+ </makefault></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.
+ </p>
+ <p/>
+ <h4>
+ <a name="xslt" id="xslt">XSLT</a>
+ </h4>
+<pre xml:space="preserve"> <xslt key="string" [source="xpath"]>
+ <property name="string" (value="literal" | expression="xpath")/>*
+ <feature name="string" value="true| false" />
+ </xslt></pre>
+ <p>
+ The <xslt> mediator applies the specified XSLT transformation to the
+ given element. If the source element is not specified, it defaults to the
+ first child of the soap body. Optionally parameters (XSLT) could be passed
+ into the transformations through the <property> elements.The <feature>
+ defines a any feature which should be set to the TransformerFactory by
+ explicitly. The feature
+ 'http://ws.apache.org/ns/synapse/transform/feature/dom' turns on DOM based
+ transformations instead of serializing elements into Byte streams and/or
+ temporary files. However, this may not prove to be stable for all
+ scenarios - especially for large message transformation.
+ </p>
+ <p/>
+ <h4>
+ <a name="header" id="header">Header</a>
+ </h4>
+<pre xml:space="preserve"> <header name="qname" (value="literal" | expression="xpath") [action="set"]/>
+ <header name="qname" action="remove"/></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>
+ <p/>
+ <h3>
+ Selection Mediators
+ </h3>
+ <h4>
+ <a name="filter" id="filter">Filter</a>
+ </h4>
+<pre xml:space="preserve"> <filter (source="xpath" regex="string") | xpath="xpath">
+ mediator+
+ </filter></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>
+ <p/>
+ <h4>
+ <a name="switch" id="switch">Switch</a>
+ </h4>
+<pre xml:space="preserve"> <switch source="xpath">
+ <case regex="string">
+ mediator+
+ </case>+
+ <default>
+ mediator+
+ </default>?
+ </switch></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>
+ <a name="in" id="in"/>
+ <h4>
+ <a name="out" id="out">In / Out</a>
+ </h4>
+<pre xml:space="preserve"><in><br/> mediator+
+</in><br/></pre>
+<pre xml:space="preserve"><out>
+ mediator+
+</out></pre>
+ <p>
+ <br/>
+ </p>
+ <p>
+ The In and Out mediators will execute the child mediators over the current
+ message if the message matches the direction of the mediator. Hence all
+ incoming messages would pass through the "<in>" mediators and vice
+ versa.
+ </p>
+ <p/>
+ <h3>
+ Database Mediators
+ </h3>
+ <h4>
+ <a name="dblookup" id="dblookup">DB-lookup</a>
+ </h4>
+<pre xml:space="preserve"><dblookup>
+ <connection>
+ <pool>
+ (
+ <driver/>
+ <url/>
+ <user/>
+ <password/>
+ |
+ <dsName/>
+ <icClass/>
+ <url/>
+ <user/>
+ <password/>
+ )
+ <property name="name" value="value"/>*
+ </pool>
+ </connection>
+ <statement>
+ <sql>select something from table where something_else = ?</sql>
+ <parameter [value="" | expression=""] type="int|string"/>*
+ <result name="string" column="int|string"/>*
+ </statement>+
+</dblookup></pre>
+ <p/>
+ <p>
+ The dblookup mediator is capable of executing an arbitrary SQL select
+ statement, and then set some resulting values as local message properties
+ on the message context. The DB connection used maybe looked up from an
+ external DataSource or specified in-line, in which case an Apache DBCP
+ connection pool is established and used. Apache DBCP connection pools
+ support the following properties:
+ </p>
+ <ul>
+ <li>
+ autocommit = true | false
+ </li>
+ <li>
+ isolation = Connection.TRANSACTION_NONE |
+ Connection.TRANSACTION_READ_COMMITTED |
+ Connection.TRANSACTION_READ_UNCOMMITTED |
+ Connection.TRANSACTION_REPEATABLE_READ |
+ Connection.TRANSACTION_SERIALIZABLE
+ </li>
+ <li>
+ initialsize = int
+ </li>
+ <li>
+ maxactive = int
+ </li>
+ <li>
+ maxidle = int
+ </li>
+ <li>
+ maxopenstatements = int
+ </li>
+ <li>
+ maxwait = long
+ </li>
+ <li>
+ minidle = int
+ </li>
+ <li>
+ poolstatements = true | false
+ </li>
+ <li>
+ testonborrow = true | false
+ </li>
+ <li>
+ testonreturn = true | false
+ </li>
+ <li>
+ testwhileidle = true | false
+ </li>
+ <li>
+ validationquery = String
+ </li>
+ </ul>
+ <p>
+ More than one statement may be specified, and the SQL statement may
+ specify parameters which could be specified as values or expressions. The
+ types of parameters could be any valid SQL types. Only the first row of a
+ result set will be considered and any others are ignored. The single <result>
+ element contains the 'name' and the column' attributes. The 'name'
+ attribute defines the name under which the result is stored in the Synapse
+ message context, and the column attribute specifies a column number or
+ name .
+ </p>
+ <h4>
+ <a name="dbreport" id="dbreport">DB-report</a>
+ </h4>
+<pre xml:space="preserve"><dbreport>
+ <connection>
+ <pool>
+ (
+ <driver/>
+ <url/>
+ <user/>
+ <password/>
+ |
+ <dsName/>
+ <icClass/>
+ <url/>
+ <user/>
+ <password/>
+ )
+ <property name="name" value="value"/>*
+ </pool>
+ </connection>
+ <statement>
+ <sql>insert into something values(?, ?, ?, ?)</sql>
+ <parameter [value="" | expression=""] type="int|string"/>*
+ </statement>+
+</dblreport></pre>
+ <p/>
+ <p>
+ The dbreport mediator is very similar to the dblookup mediator, but writes
+ information to a Database, using the specified insert SQL statement.
+ </p>
+ <p/>
+ <h3>
+ Advanced Mediators
+ </h3>
+ <h4>
+ <a name="RMSequence" id="RMSequence">RMSequence</a>
+ </h4>
+<pre xml:space="preserve"> <RMSequence (correlation="xpath" [last-message="xpath"]) | single="true" [version="1.0|1.1"]/></pre>
+ <p>
+ The <RMSequence> mediator can be used to create a sequence of
+ messages to communicate via WS-Reliable Messaging with an WS-RM enabled
+ endpoint (<enableRM>). The simple use case of this mediator is to
+ specify a single="true" property, because this means that only one message
+ is involved in the same sequence. However if multiple messages should be
+ sent in the same sequence, the correlation property should be used with a
+ XPath expression that selects an unique element value from the incoming
+ message. With the result of the XPath expression, Synapse can group
+ messages together that belong to the same sequence. To close the sequence
+ neatly, for the last message of the sequence also an XPath expression
+ should be specified. With the version attribute the WS-RM specification
+ version to be used can be specified, 1.0 or 1.1.
+ </p>
+ <p/>
+ <h4>
+ <a name="throttle" id="throttle">Throttle</a>
+ </h4>
+<pre xml:space="preserve"><throttle [onReject="string"] [onAccept="string"] [id="string"]>
+ <policy key="string"/> | <policy>..</policy>
+ <onReject>..</onReject>
+ <onAccept>..</onAccept>
+</throttle></pre>
+ <p/>
+ <p>
+ The Throttle mediator can be used for rate limiting as well as concurrency
+ based limiting. A WS-Policy dictates the throttling configuration and may
+ be specified inline or loaded from the registry. The Throttle mediator
+ could be added in the request path for rate limiting and concurrent access
+ limitation. When using for concurrent access limitation, the same throttle
+ mediator ID must be triggered on the response flow so that completed
+ responses are deducted from the available limit. The acceptance or
+ rejection sequence is executed depending on the evaluation of the
+ throttling policy against the current message.
+ </p>
+ <h4>
+ <a name="xquery" id="xquery">XQuery</a>
+ </h4>
+<pre xml:space="preserve"><xquery [key="string"] [target="xpath"]>
+ <variable name="string" type="string" [key="string"] [expression="xpath"]/>?
+</xquery> </pre>
+ <p/>
+ <p>
+ The XQuery mediator can be used to perform an XQuery transformation. The
+ 'variable' elements define a variable that could be bound to the dynamic
+ context of the XQuery engine in order to access those variables through
+ the XQuery script . The name of the variable corresponds to the name of
+ variable declaration in the XQuery script. The 'type' of the variable must
+ be a valid type defined by the JSR-000225 (XQJ API). The supported types
+ are:
+ </p>
+ <ul>
+ <li>
+ XQItemType.XQBASETYPE_INT -> INT
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_INTEGER -> INTEGER
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_BOOLEAN -> BOOLEAN
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_BYTE - > BYTE
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_DOUBLE -> DOUBLE
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_SHORT -> SHORT
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_LONG -> LONG
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_FLOAT -> FLOAT
+ </li>
+ <li>
+ XQItemType.XQBASETYPE_STRING -> STRING
+ </li>
+ <li>
+ XQItemType.XQITEMKIND_DOCUMENT -> DOCUMENT
+ </li>
+ <li>
+ XQItemType.XQITEMKIND_DOCUMENT_ELEMENT -> DOCUMENT_ELEMENT
+ </li>
+ <li>
+ XQItemType.XQITEMKIND_ELEMENT -> ELEMENT
+ </li>
+ </ul>
+ <p>
+ The expressions will be evaluated against the current SOAP envelope.
+ </p>
+ <h4>
+ <a name="cache" id="cache">Cache</a>
+ </h4>
+<pre xml:space="preserve"> <cache (id="string")? hashGenerator="class" scope="string" timeout="milliseconds">
+ <onCacheHit (sequence="key")?>
+ (mediator)+
+ </onCacheHit>
+ <implementation type=(memory | disk) maxSize="int"/>
+ </cache></pre>
+ <p>
+ The <cache> mediator will evaluate the hash value of the incoming
+ message as described in the hash generator implementation (which should be
+ a class implementing the org.wso2.caching.digest.DigestGenerator
+ interface) and looks in a cache for a matching response. If the generated
+ hash value has been found in the cache then the cache mediator will
+ execute the onCacheHit sequence which can be specified inline or refered
+ to the registry.
+ </p>
+ <h4>
+ <a name="clone" id="clone">Clone</a>
+ </h4>
+<pre xml:space="preserve"> <clone continueParent=(true | false)>
+ <target to="uri" [soapAction="qname"] sequence="sequence_ref" endpoint="endpoint_ref">
+ <sequence>
+ (mediator)+
+ </sequence>
+ <endpoint>
+ endpoint
+ </endpoint>
+ </target>
+ </clone></pre>
+ <p>
+ The <clone> mediator closely resembles the Message Splitter EIP and
+ will split the message into number of identical messages all of which are
+ identical with the cloning message and processed parallelly using either
+ the specified sequence or endpoint (or both). Cloning message (parent) can
+ be continued or dropped depending on the boolean value of the
+ continueParent attribute which defaults to false and drops the parent when
+ false. This drop is not a general drop, rather stop the message processing
+ but does not closes the transport channel, leaving the ability of one or a
+ set of cloned message responses to be sent back to the caller
+ </p>
+ <h4>
+ <a name="iterate" id="iterate">Iterate</a>
+ </h4>
+<pre xml:space="preserve"> <iterate continueParent=(true | false) preservePayload=(true | false) (attachPath="xpath")? expression="xpath">
+ <target to="uri" [soapAction="qname"] sequence="sequence_ref" endpoint="endpoint_ref">
+ <sequence>
+ (mediator)+
+ </sequence>
+ <endpoint>
+ endpoint
+ </endpoint>
+ </target>
+ </iterate></pre>
+ <p>
+ The <iterate> mediator implements another EIP and will split the
+ message in to number of different messages derived from the parent message
+ by finding the matching elements of the XPATH expression specified in the
+ configuration. New messages will be created for each and every matching
+ element and processed parallelly using either the specified sequence or
+ endpoint or both. Parent message can be continued or dropped in the same
+ way as in the clone mediator. Iterate parent drop also is a channel
+ blocking drop as per in the clone mediator.
+ </p>
+ <h4>
+ <a name="aggregate" id="aggregate">Aggregate</a>
+ </h4>
+<pre xml:space="preserve"> <aggregate>
+ <corelateOn expression="xpath"/>
+ <completeCondition timeout="time-in-seconds">
+ <messageCount min="int-min" max="int-max"/>
+ </completeCondition>
+ <onComplete expression="xpath" sequence="sequence-ref">
+ (mediator +)?
+ </onComplete>
+ <invalidate sequence="sequence-ref" timeout="time-in-seconds">
+ (mediator +)?
+ </invalidate>
+ </aggregate></pre>
+ <p>
+ The <aggregate> mediator implements the Message Aggregator EIP and
+ will aggregate the messages splitted using either the clone or iterate
+ mediators. At the same time it can aggregate messages on the presence of
+ matching elements specified by the corelateOn XPATH expression. Aggregate
+ will collect the messages coming in to that until the messages on the
+ aggregation satisfies the complete condition. On completion of the
+ aggregation it will execute the aggregated message using the onComplete
+ sequence. Aggregated message will be created by combining the messages
+ participating in the aggregation using the onComplete XPATH expression. If
+ a particular aggregation fails to complete in a pre configured time, then
+ that particular aggregation will be invalidated using the invalidate
+ sequence.
+ </p>
+ <h3>
+ Extension mediators
+ </h3>
+ <h4>
+ <a name="class" id="class">Class</a>
+ </h4>
+<pre xml:space="preserve"> <class name="class-name">
+ <property name="string" value="literal">
+ (either literal or XML child)
+ </property>
+ </class> </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,
+ once, during initialization.
+ </p>
+ <p/>
+ <h4>
+ <a name="pojoCommand" id="pojoCommand">POJOCommand</a>
+ </h4>
+<pre xml:space="preserve"> <pojoCommand name="class-name">
+ <property name="string" value="literal">
+ (either literal or XML child)
+ </property>
+ <property name="string" expression="xpath"/>
+ </pojoCommand> </pre>
+ <p>
+ The <pojoCommand> mediator creates an instance of the specified
+ command class (which may implement the org.apache.synapse.Command
+ interface or should have a public void method named "execute"). If any
+ properties are specified, the corresponding setter methods are invoked on
+ the class and called the execute method of the command executed.
+ </p>
+ <p/>
+ <h3>
+ <a name="script" id="script">Scripting language mediators</a>
+ </h3>
+ <p/>
+ <p>
+ Synapse supports Mediators implemented in a variety of scripting languages
+ such as JavaScript, Python or Ruby. There are two ways of defining script
+ mediators, either with the script program statements stored in a separate
+ file which is referenced via the local or remote registry entry, or with
+ the script program statements embedded in-line within the Synapse
+ configuration. A script mediator using a script off the registry (local or
+ remote) is defined as follows:
+ </p>
+<pre xml:space="preserve"> <script key="string" language="string" [function="script-function-name"]/></pre>
+ <p>
+ The property key is the registry key to load the script. The language
+ attribute specifies the scripting language of the script code (e.g. "js"
+ for Javascript, "rb" for ruby, "groovy" for Groovy, "py" for Python..).
+ The function is an optional attribute defining the name of the script
+ function to invoke, if not specified it defaults to a function named
+ 'mediate'. The function is passed a single parameter - which is the
+ Synapse MessageContext. The function may return a boolean, if it does not,
+ then true is assumed, and the script mediator returns this value. An
+ inline script mediator has the script source embedded in the configuration
+ as follows:
+ </p>
+<pre xml:space="preserve"> <script language="string">...script source code...<script/></pre>
+ <p>
+ The execution context environment of the script has access to the Synapse
+ MessageContext predefined in a script variable named 'mc' . An example of
+ an inline mediator using JavaScript/E4X which returns false if the SOAP
+ message body contains an element named 'symbol' which has a value of 'IBM'
+ would be:
+ </p>
+<pre xml:space="preserve"> <script language="js">mc.getPayloadXML()..symbol != "IBM";<script/></pre>
+ <p>
+ Synapse uses the Apache <a href="http://jakarta.apache.org/bsf/">Bean
+ Scripting Framework</a> for the scripting language support, any
+ script language supported by BSF may be used to implement a Synapse
+ Mediator.
+ </p>
+ <p>
+ Implementing a Mediator with a script language can have advantages over
+ using the built in Synapse Mediator types or implementing a custom Java
+ class Mediator. Script Mediators have all the flexibility of a class
+ Mediator with access to the Synapse MessageContext and SynapseEnvironment
+ APIs, and the ease of use and dynamic nature of scripting languages allows
+ rapid development and prototyping of custom mediators. An additional
+ benefit of some scripting languages is that they have very simple and
+ elegant XML manipulation capabilities, for example JavaScript E4X or Ruby
+ REXML, so this makes them well suited for use in the Synapse mediation
+ environment. For both types of script mediator definition the
+ MessageContext passed into the script has additional methods over the
+ standard Synapse MessageContext to enable working with the XML in a way
+ natural to the scripting language. For example when using JavaScript
+ getPayloadXML and setPayloadXML, E4X XML objects, and when using Ruby,
+ REXML documents.
+ </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 is such an example.
+ </p>
+ <h4>
+ Spring Configuration
+ </h4>
+ <p>
+ A Spring configuration could be created as a localEntry or remote registry
+ entry providing a URL or a key reference to a Registry. The configuration
+ is then created on first use or as necessary (as per registry lookup
+ semantics) by the mediators which reference this configuration.
+ </p>
+<pre xml:space="preserve"> <localEntry key="string"/>
+ <localEntry key="string" src="url"/></pre>
+ <p>
+ The name attribute specifies a unique name for the configuration, and the
+ src, key or inlined XML references to the Spring configuration
+ </p>
+ <p/>
+ <h4>
+ <a name="spring" id="spring">Spring mediator</a>
+ </h4>
+<pre xml:space="preserve"> <spring:spring bean="exampleBean1" key="string"/></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. The key will reference the Spring
+ ApplicationContext/Configuration used for the bean
+ </p>
+ </body>
+</html>
\ No newline at end of file
Propchange: webservices/synapse/trunk/java/src/site/xdoc/1_1/configuration.xml
------------------------------------------------------------------------------
svn:executable = *
Added: webservices/synapse/trunk/java/src/site/xdoc/1_1/content.xml
URL: http://svn.apache.org/viewvc/webservices/synapse/trunk/java/src/site/xdoc/1_1/content.xml?rev=615849&view=auto
==============================================================================
--- webservices/synapse/trunk/java/src/site/xdoc/1_1/content.xml (added)
+++ webservices/synapse/trunk/java/src/site/xdoc/1_1/content.xml Mon Jan 28 03:05:41 2008
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!--
+ ~ Licensed to the Apache Software Foundation (ASF) under one
+ ~ or more contributor license agreements. See the NOTICE file
+ ~ distributed with this work for additional information
+ ~ regarding copyright ownership. The ASF licenses this file
+ ~ to you under the Apache License, Version 2.0 (the
+ ~ "License"); you may not use this file except in compliance
+ ~ with the License. You may obtain a copy of the License at
+ ~
+ ~ http://www.apache.org/licenses/LICENSE-2.0
+ ~
+ ~ Unless required by applicable law or agreed to in writing,
+ ~ software distributed under the License is distributed on an
+ ~ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~ KIND, either express or implied. See the License for the
+ ~ specific language governing permissions and limitations
+ ~ under the License.
+ -->
+
+<document>
+
+ <properties>
+ <title>The lightweight ESB - Version 1.0</title>
+ </properties>
+
+<body>
+
+<section name="Apache Synapse - the lightweight ESB">
+ <p>
+ Apache Synapse is a simple, lightweight and high performance Enterprise Service Bus (ESB) from Apache. Based on a small asynchronous core, Apache Synapse has excellent support for XML and Web services - as well as binary and text formats. The Synapse engine is configured with a simple XML format and comes with a set of useful transports and mediators. We recommend you start by reading the QuickStart and then trying out the samples.
+ </p>
+ <p>For more information, see:</p>
+
+ <ul>
+ <li><a href="./quickstart.html">Quick Start Guide</a></li>
+ <li><a href="./configuration.html">The Synapse Configuration Language</a></li>
+ <li><a href="./samples.html">A Quick start with Synapse Samples</a></li>
+ <li><a href="./extending.html">Extending Synapse</a></li>
+ <li>The WS Wiki <a href="http://wiki.apache.org/ws/Synapse">http://wiki.apache.org/ws/Synapse</a></li>
+ </ul>
+</section>
+
+<section name="Status">
+ <p>Synapse graduated from the Apache Incubator on the 2nd of January 2007, and has been
+ officially accepted as a sub-project of the Apache Web Services project</p>
+
+ <p>This release of Synapse is <a href="http://synapse.apache.org/download/1.1/download.cgi">1.1</a>. Its key features are </p>
+
+ <ul>
+ <li><p>Proxy services - facilitating transport, interface (WSDL/Schema/Policy), message format (SOAP/POX), QoS (WS-Security/RM) and optimization switching (MTOM/SwA)</p></li>
+ <li><p>Non-blocking http/s transports based on Apache <a target="_blank" href="http://hc.apache.org/httpcomponents-core/index.html">HttpCore</a> for ultrafast execution and support for thousands of connections</p></li>
+ <li><p>Built in Registry/Repository, facilitating dynamic updating and reloading of the configuration and associated resources (e.g. XSLTs, XSD, JS, ..)</p></li>
+ <li><p>Easily extended via custom Java class/Spring mediators, or BSF Scripting languages (Javascript, Ruby etc)</p></li>
+ <li><p>Load-balancing/Fail-over and Throttling support</p></li>
+ <li><p>WS-Security, WS-Reliable Messaging & Throttling configurable via WS-Policies</p></li>
+ <li><p>JMS message support for binary, plain text and XML and SOAP payloads</p></li>
+ <li><p>Lightweight, XML and Web services centric messaging model</p></li>
+ <li><p>Configurations serialized into a file system for versioning/backup and restoration</p></li>
+ <li><p>Support for Error handling and timeouts, and recovery</p></li>
+ <li><p>Many samples and a built-in Axis2 server to try out and experiment with samples (Samples includes WS-Security, JMS POX/Text messages, Script mediation and many more samples which can be run out of the box) </p></li>
+ <li><p>Enhanced documentation</p></li>
+ </ul>
+</section>
+</body>
+</document>
Propchange: webservices/synapse/trunk/java/src/site/xdoc/1_1/content.xml
------------------------------------------------------------------------------
svn:executable = *
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org