synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <antel...@apache.org>
Subject Re: Synapse using SCA assembly model for configuration
Date Wed, 25 Jul 2007 11:08:12 GMT
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
>

Mime
View raw message