Could someone please explain to me how the sca contributions thing works? Is it part of the spec?
Paul On 7/25/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > Not quite. In my suggestion if you wanted sca then the synapse.xml > would look like: > > <composite xmlns="...sca namespace> > > </composite> > > > But maybe I don't understand the contribution model well enough. > > Paul > > On 7/25/07, ant elder <[EMAIL PROTECTED]> wrote: > > Maybe we should step back a bit and get more of a common understanding of > > what the sca support would look like. > > > > From that suggestion it sounds like there'd be one synapse.xml file holding > > all the config (as there is today) and within that would be the xml using > > the sca namespace to define the SCA services, references and components etc. > > Eg, something like a synapse.xml file containing: > > > > <definitions xmlns="http://ws.apache.org/ns/synapse"; > > xmlns:sca=" > > http://www.osoa.org/xmlns/sca/1.0";> > > > > <sca:service name="HelloWorldService"> > > <sca:interface.wsdl > > interface="http://helloworld#wsdl.interface(HelloWorld) " > > /> > > <sca:binding.ws uri="HelloWorldService"/> > > </sca:service> > > > > ... > > > > </definitions> > > > > Is that what you mean? > > > > I was thinking the SCA definitions would be separate, so there'd be > > something like an sca-contributions folder within the existing Synapse > > repository and in there you'd put individual sca composte files or sca > > contribution jars. Eg something like a helloworld.composite file containing: > > > > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; > > name="helloworld"> > > > > <service name="HelloWorldProxy" promote="HelloWorldMediator" > > > <interface.wsdl > > interface="http://helloworld#wsdl.interface(HelloWorld)" /> > > <binding.ws /> > > </service> > > > > <component name="HelloWorldMediator"> > > <implementation.mediator.../> > > </component> > > > > <reference name="HelloWorldEndpoint" promote="HelloWorldMediator" > > > <binding.ws uri="http://remote/helloservice"; /> > > </reference> > > > > </composite> > > > > ...ant > > > > > > On 7/25/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > > Well actually I had a different idea. > > > > > > At the moment the Mediator reading is pluggable - based on the > > > namespace, but the core reading of Synapse.XML is fixed. What if we > > > restructured so that we key the XMLConfigurationBuilder off of the XML > > > namespace of the document element in synapse.xml? That way we could > > > make the XML parsing pluggable. We could do it in the same way as we > > > do for Mediators. In other words we could have a JAR file that > > > registers itself as the reader for a given NS. > > > > > > What do you think? > > > > > > Paul > > > > > > On 7/25/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 7/24/07, ant elder < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On 7/24/07, Paul Fremantle < [EMAIL PROTECTED]> 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? > > > > > > > > > > > > Paul > > > > > > > > > > > > PS If someone is looking at > > > > > > http://www.infoq.com/news/2007/07/scaproblem and > > > > wondering where this > > > > > > is coming from I offer a few thoughts. Firstly, I'm always open to > > > > > > being proved wrong! Secondly, this would not be adding any layers of > > > > > > indirection... I'm mapping directly from SCA concepts into the > > Synapse > > > > > > runtime with this idea. Finally, I see nothing wrong with holding > > > > > > several inconsistent viewpoints at the same time :) > > > > > > > > > > > > > > > Great idea. This is definitely feasible, and also i think it would be > > > > really useful - so good for Synapse and good for Tuscany. You're right, > > we > > > > do have plenty of code in Tuscany that we can use, a big part of recent > > > > Tuscany releases has been around modularizing the code base to make > > exactly > > > > this type of thing easy to do. So I'd like take you up on the suggestion > > to > > > > do this jointly, as it turns out, i can even spend a bit of time helping > > > > make this happen. Let me go pull some things together and I'll post more > > > > about it tomorrow. > > > > > > > > > > ...ant > > > > > > > > > > > > > > > > > > Had a quick look at how sca support could be plugged into the existing > > > > Synapse runtime, not sure how to hook in to the existing initialization > > code > > > > without some code changes to Synapse. One option would be to add a new > > Axis2 > > > > module that is initialized after the existing Synapse module. That could > > > > then pick up the SynapseEnvironment and SynapseConfiguration objects > > from > > > > the AxisConfiguration and add the Synapse config as required based on > > the > > > > sca contributions. This seems like an easy and harmless way to at least > > get > > > > started which would have minimal disruption. What do you guys think, any > > > > other suggestions? > > > > > > > > ...ant > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > 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 > -- 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]
