synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Synapse using SCA assembly model for configuration
Date Wed, 25 Jul 2007 16:00:56 GMT
On Jul 25, 2007, at 5:25 AM, Paul Fremantle wrote:

> Jeremy
> Thanks for the offer of help! If you want to take a look at a sample
> synapse.xml the simplest is probably sample 100:

Thanks. I took a look at a couple of the samples trying to figure out  
how to map them to SCA.

One simple option is to treat the entire Synapse instance as an SCA  
component. This would work in a similar way to the Spring integration  
where the actual configuration would still be done using Synapse but  
the resulting instance could be incorporated within SCA. Something like;

<composite xmlns:synapse="..." >
   <component name="SynapseInstance">
     <synapse:instance configuration="path to synapse.xml"/>
       <service> ... configure Synapse Proxy ... </service>
       <reference> ... configure Synapse Endpoint ... </reference>
       <property> ... configure Synapse Property ... </property>

This isn't quite what you were after but provides a stepping stone  
that would allow users' current configurations to easily be migrated.  
To start using SCA to configure the instance itself, we can change  
how the implementation is defined e.g.:

<composite xmlns:synapse="..." >
   <component name="SynapseInstance">
     <synapse:instance composite="name of composite that configures  
     ... instance level configuration as above ...

@composite would be the QName of an SCA composite that defined the  
configuration of the Synapse instance. Taking Sample 100 as an  
example, I'm thinking something like this:

<composite name="SynapseInstanceConfig" ...>
   <service name="StockQuoteProxy" promote="StockQuoteSender">
     <interface.wsdl interface="SimpleStockQuoteServicePortType"/>
     < uri="StockQuoteProxy"/>

   <reference name="SimpleStockQuoteService"  
     <interface.wsdl interface="SimpleStockQuoteServicePortType"/>
     < uri="http://localhost:9000/soap/ 

   <component name="StockQuoteSender">

The <synapse:send> implementation type would do the simple forwarding  
I believe <send/> does. To perform mediation, the user could replace  
that with a pre-defined type (e.g. for logging there could be a  
<synapse:log> implementation), or could use a generic mediator  
capable of driving the in/out transform pipelines, e.g. from Sample 500

<composite ...>
   ... service/reference config as above ...
   <component name="StockQuoteSender">
     <reference name="in" target="stockquoteScript/transformRequest"/>
     <reference name="out" target="stockquoteScript/transformResponse"/>

   <component name="stockquoteScript">
     <synapse:js script="stockquoteTransform.js"/>

To add this to Synapse, we'd have to add the model classes for the  
SCDL extension elements and parsers that can handle them - I can  
knock that up pretty quickly in a sandbox. What I don't really know  
is how to generate the SynapseConfiguration.


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

View raw message