synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: Synapse using SCA assembly model for configuration
Date Thu, 26 Jul 2007 09:52:10 GMT
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 <pzfreo@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 <antelder@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 <pzfreo@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

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Mime
View raw message