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:
http://ws.apache.org/synapse/Synapse_Samples.html#Sample100
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>
</component>
</composite>
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
Synapse"/>
... instance level configuration as above ...
</component>
</composite>
@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"/>
<binding.ws uri="StockQuoteProxy"/>
<service>
<reference name="SimpleStockQuoteService"
promote="StockQuoteSender/target">
<interface.wsdl interface="SimpleStockQuoteServicePortType"/>
<binding.ws uri="http://localhost:9000/soap/
SimpleStockQuoteService"/>
</reference>
<component name="StockQuoteSender">
<synapse:send/>
</component>
</composite>
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">
<synapse:transform/>
<reference name="in" target="stockquoteScript/transformRequest"/>
<reference name="out" target="stockquoteScript/transformResponse"/>
</component>
<component name="stockquoteScript">
<synapse:js script="stockquoteTransform.js"/>
</component>
</composite>
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
