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 Paul On 7/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Jul 24, 2007, at 6:54 AM, Paul Fremantle wrote: > I recently read Dan's blog entry on the SCA assembly model: > http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/ > > That and some other discussions I've had made me think about maybe > offering the SCA assembly model to configure Synapse. So it seems to > me that you can draw a direct correlation between: > > Synapse Proxy and SCA Service > Synapse Endpoint and SCA reference > Synapse Mediator - a specific type of SCA Component > Synapse Property - SCA Property > > If we were to make the XMLConfigurationBuilder pluggable then we could > just use this as an alternative configuration language. We did talk > about this in the beginning of Synapse [we discussed having a LEX/YACC > style config language - which I would still LOVE if someone wants to > do that - it would make a great Computer Science project] > > Anyway back to SCA, it seems to me that this would be a pretty nice > alternative config model, using an independent third party language. > I'm guessing that there is plenty of Tuscany code could help us > implement this. Maybe we might do it jointly? > > So I'm imagining the existing runtime being *exactly* the same as > today, but being able to use a subset of the SCA Assembly model to > configure it. Maybe some of the SCA wizards on tusc-dev can jump in > and let me know if this is feasible? Quick answer is yes. This is actually exactly what we do in F3 - use SCDL to describe the configuration of our runtime. It works by parsing the XML into an in-memory definition, then walking that definition to create our components. We then use that runtime to parse the more complex SCA definitions for user contributions. I think it would be easy to adapt that to Synapse, keeping the initial parse part but replacing the generation step with one that created Synapse components using the existing runtime in the same way XMLConfigurationBuilder does. We have a SPI interface, Loader[1], for parsing SCDL XML so I think the main work here would be in generating Synapse components from the loaded model. I can help get that going by tackling the loader side so you'd have a model to work from - do you have a simple Synapse configuration we could start to work with? -- Jeremy [1] https://svn.codehaus.org/fabric3/modules/tags/fabric3-spi-0.1/src/ main/java/org/fabric3/spi/loader/Loader.java --------------------------------------------------------------------- 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]
