Jeremy I'm not clear why we need to add synapse specific XML fragments. If we have to do that then the benefit of using SCA looks much less to me. I guess I was hoping that we could at least configure basic synapse scenarios without deviating from published specs.
Paul On 7/25/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > 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] > > -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
