You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Paul Fremantle <pz...@gmail.com> on 2007/07/24 15:54:47 UTC
Synapse using SCA assembly model for configuration
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 :)
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by ant elder <an...@apache.org>.
See section 1.10 on page 63 of the assembly model spec -
http://www.oasis-opencsa.org/sca-assembly. Page 23 describes a Composite (or
page 82 for more concisely).
Either way would work - as you suggested with the synapse.xml being one big
composite, or support multiple individual composites packaged as
contributions in jar's or just as files on the file system or synapse
registry.
...ant
On 7/26/07, Paul Fremantle <pz...@gmail.com> wrote:
>
> 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 <pz...@gmail.com> 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 <an...@apache.org> 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)<http://helloworld#wsdl.interface%28HelloWorld%29>"
> > > />
> > > <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)<http://helloworld#wsdl.interface%28HelloWorld%29>"
> />
> > > <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 <pz...@gmail.com> 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 < antelder@apache.org> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 7/24/07, ant elder < antelder@apache.org> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> > > > paul@wso2.com
> > > >
> > > > "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
> > paul@wso2.com
> >
> > "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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <pz...@gmail.com> 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 <an...@apache.org> 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 <pz...@gmail.com> 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 <an...@apache.org> wrote:
> > > >
> > > >
> > > >
> > > > On 7/24/07, ant elder < antelder@apache.org> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> > > paul@wso2.com
> > >
> > > "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
> paul@wso2.com
>
> "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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <pz...@gmail.com> 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 <an...@apache.org> 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 <pz...@gmail.com> 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 <an...@apache.org> wrote:
> > > >
> > > >
> > > >
> > > > On 7/24/07, ant elder < antelder@apache.org> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> > > paul@wso2.com
> > >
> > > "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
> paul@wso2.com
>
> "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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <an...@apache.org> 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 <pz...@gmail.com> 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 <an...@apache.org> wrote:
> > >
> > >
> > >
> > > On 7/24/07, ant elder < antelder@apache.org> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> > paul@wso2.com
> >
> > "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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <an...@apache.org> 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 <pz...@gmail.com> 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 <an...@apache.org> wrote:
> > >
> > >
> > >
> > > On 7/24/07, ant elder < antelder@apache.org> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> > paul@wso2.com
> >
> > "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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by ant elder <an...@apache.org>.
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 <pz...@gmail.com> 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 <an...@apache.org> wrote:
> >
> >
> >
> > On 7/24/07, ant elder <an...@apache.org> wrote:
> > >
> > >
> > >
> > >
> > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
Re: Synapse using SCA assembly model for configuration
Posted by ant elder <an...@apache.org>.
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 <pz...@gmail.com> 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 <an...@apache.org> wrote:
> >
> >
> >
> > On 7/24/07, ant elder <an...@apache.org> wrote:
> > >
> > >
> > >
> > >
> > > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <an...@apache.org> wrote:
>
>
>
> On 7/24/07, ant elder <an...@apache.org> wrote:
> >
> >
> >
> >
> > On 7/24/07, Paul Fremantle < pzfreo@gmail.com> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by ant elder <an...@apache.org>.
On 7/24/07, ant elder <an...@apache.org> wrote:
>
>
>
> On 7/24/07, Paul Fremantle <pz...@gmail.com> 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
Re: Synapse using SCA assembly model for configuration
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I think it's a great opportunity for both Synapse and Tuscany. From Tuscany
side, the following features may be helpful.
1) We have the SCA assembly model defined as pure interfaces in Tuscany and
factories can be plugged in to provide different implementations.
2) We already have a module in Tuscany to consume the SCA assembly model by
the Spring runtime. Please see
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spring.
It's a good example for how the SCA assembly model can be consumed by other
runtimes.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <an...@apache.org>
To: <sy...@ws.apache.org>
Cc: <tu...@ws.apache.org>
Sent: Tuesday, July 24, 2007 1:32 PM
Subject: Re: Synapse using SCA assembly model for configuration
> On 7/24/07, Paul Fremantle <pz...@gmail.com> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by ant elder <an...@apache.org>.
On 7/24/07, Paul Fremantle <pz...@gmail.com> 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
Re: Synapse using SCA assembly model for configuration
Posted by Rajith Attapattu <ra...@gmail.com>.
Paul,
You sure want to do this? I hope Ant want kill me :)
Theoritically it makes sense, but the reality is that the tuscany code is
pretty complex. (atleast the last time I coded the JMS binding)
Judging by the spec I don't blame the code base as the complexity of the
spec naturally creeps in to the code base.
As a Tuscany comitter I shouldn't be saying this, but can we not experiment
with spring first?
Regards,
Rajith
On 7/24/07, Paul Fremantle <pz...@gmail.com> 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 :)
>
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: Synapse using SCA assembly model for configuration
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 26, 2007, at 2:54 AM, Paul Fremantle wrote:
> 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.
One of the published extension points in the spec is the ability to
add different implementations. That's what we're doing here - adding
an extension that supports the Synapse programming model. The big
advantage is that it would support the existing Synapse programming
model as is, without the need to change any of the Synapse components.
We could wire it up using SCA programming models e.g.
implementation.java but that would expose a lot of implementation
detail to users e.g.
<component name="StockQuoteSender">
<implementation.java
class="org.apache.synapse.mediators.builtin.SendMediator"/>
</component>
and IMO that's a bit ugly.
By using a Synapse specific implementation type we are able to get
the best from both technologies: the standardized assembly from SCA,
the existing mediation-oriented programming model from Synapse. IOW,
users would be able to define mediation flows, bindings, policies,
etc. using standard SCA assembly model and be able to reuse existing
Synapse Mediators or write their own using Synapse's mediation-
oriented programming model.
BTW, these extensions would only be used for mediation components,
and of course the samples are all about mediations so we'd see them
used a lot :-) Users could still use regular SCA implementation types
to wire up their more complex mediations. For example, if we were to
separate the discount calculation from the data selection we could do
something like:
<composite ...>
...
<component name="DiscountQuoteMediator">
<synapse:class class="samples.mediators.DiscountQuoteMediator"/>
<reference name="discountCalculator" target="DiscountCalculator"/>
</component>
<component name="DiscountCalculator">
<implementation.java class="samples.common.DiscountCalculator"/>
<property name="discountFactor">10</property>
<property name="bonusFor">5</property>
</component>
</composite>
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <jb...@apache.org> 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: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Jeremy Boynes <jb...@apache.org>.
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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
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 <jb...@apache.org> 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: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Jeremy Boynes <jb...@apache.org>.
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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Paul Fremantle <pz...@gmail.com>.
Mike
Thoughts inline:
> It certainly looks like a reasonable mapping.
Good
> SCA makes no assumption about the runtime at all - and the spec teams
> have always viewed the SCA model as being mappable to a whole range of
> runtimes, so this way of thinking about things is fine. Indeed, some of
> the work in the Eclipse tools project is done this way, where an SCA
> model is used to describe the solution in the tools and is then mapped
> to the configuration file format of a particular runtime. The runtime
> never sees the SCA metadata directly.
>
> Your idea is to do this mapping at runtime - I happen to prefer that way
> of doing things.
Well it would be done at runtime, but not at message passing time.
> One BIG question to ask is whether you want to support implementation
> artifacts with SCA annotations. SCA supports, for example, Java classes
> with annotations which configure them with a range of features - this is
> an alternative to providing the information in the SCA XML format.
> Doing this requires appropriate introspector code in the runtime. This
> can certainly come from Tuscany.
I hadn't really considered that. Synapse isn't really about deploying
Java components.... so I'm not sure if this would be appropriate.
> This direct mapping of SCA metadata into runtime entities is behind my
> contention that SCA does not add any layering. SCA is not about
> indirection, rather it is about having a consistent way of describing
> SOA configuration, which is mapped to the specifics of given component
> and runtime technologies.
Well I'll wait and see how it looks when we get it running! But
getting this working would be a long way to proving to me that you are
right.
> As for holding multiple inconsistent viewpoints at once - politicians
> seem to manage that as a way of life ;-)
We'll I guess I asked for that, but really - a little below the belt
comparing me with a politician.
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by Mike Edwards <mi...@gmail.com>.
Paul,
Great to hear from you! Some thoughts inline.
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
>
It certainly looks like a reasonable mapping.
> 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?
SCA makes no assumption about the runtime at all - and the spec teams
have always viewed the SCA model as being mappable to a whole range of
runtimes, so this way of thinking about things is fine. Indeed, some of
the work in the Eclipse tools project is done this way, where an SCA
model is used to describe the solution in the tools and is then mapped
to the configuration file format of a particular runtime. The runtime
never sees the SCA metadata directly.
Your idea is to do this mapping at runtime - I happen to prefer that way
of doing things.
One BIG question to ask is whether you want to support implementation
artifacts with SCA annotations. SCA supports, for example, Java classes
with annotations which configure them with a range of features - this is
an alternative to providing the information in the SCA XML format.
Doing this requires appropriate introspector code in the runtime. This
can certainly come from Tuscany.
>
> 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 :)
>
This direct mapping of SCA metadata into runtime entities is behind my
contention that SCA does not add any layering. SCA is not about
indirection, rather it is about having a consistent way of describing
SOA configuration, which is mapped to the specifics of given component
and runtime technologies. Only where it is the intention to extend the
runtime(s) involved (eg with support for new bindings) would there need
to be any consideration of layering - but then it is a question of how
the runtime itself is written - the ideal is no layering, but a simple
addition of function.
As for holding multiple inconsistent viewpoints at once - politicians
seem to manage that as a way of life ;-)
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Synapse using SCA assembly model for configuration
Posted by ant elder <an...@apache.org>.
On 7/24/07, Paul Fremantle <pz...@gmail.com> 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