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 Wed, 25 Jul 2007 11:25:14 GMT
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

---------------------------------------------------------------------
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