synapse-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: Composite Services Architectural question
Date Thu, 17 Apr 2008 08:58:29 GMT
Hi Wayne,

We have done similar stuff using Synapse. So if you could send me a sample
request and the exact requirement including any other schemas of the
requests that has to be generated by synapse, (may be with sample services
or WSDL) I would be happy to give you the exact configuration for you to use
for the scenario. You may send the requests to me privately if you feel
uncomfortable in sharing these in public. My email address is ruwan AT wso2
DOT com.

Thanks,
Ruwan

On Thu, Apr 17, 2008 at 1:25 PM, Wayne Keenan <wayne.keenan@gmail.com>
wrote:

> Hi,
>
> Thanks for all your help, but the amount of configuration involved todo
> this
> is perhaps indicating my requirements are not a best fit for Synapse's
> intended use, no offence to Synapse.
> We have decided to find another mecanism to co-ordinate the service
> invocations, and I'm currently looking at Apache ODE.
> That is not to say we won't be using Synapse, quite the opposite, we will
> still be Synapse on the 'front line', todo: routing, failover, load
> balancing etc.
>
> Regards
> Wayne
>
>
> On Wed, Apr 16, 2008 at 3:42 PM, Ruwan Linton <ruwan.linton@gmail.com>
> wrote:
>
> > Hi Wayne,
> >
> > I was thinking you are using the message mediation but not a proxy. In
> > your
> > case the out sequence of the proxy will not be called because the
> message
> > does not go out on the normal path. So here is the workaround for that.
> >
> > You will need to put a dummy outSequence for the proxy because that is
> > required, but you need to append the ossj_fault_out to the end of the
> > proxy
> > in sequence execution. Since there is a clone mediator these linkages
> > should
> > happen at the two cloned targets. In effect you should modify the
> > ossj_fault_main and ossj_fault_comment_wrapper sequences and add the
> > following configuration point to the end of these sequences.
> >
> > <sequence key="ossj_fault_out"/>
> >
> > Modify the config as I proposed and let me know the results. I will
> guide
> > you for any other changes to get this done if you get any more issues on
> > this.
> >
> > Thanks,
> > Ruwan
> >
> > On Wed, Apr 16, 2008 at 7:33 PM, Wayne Keenan <wayne.keenan@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Help, I am being quite thick and was wonodering if someone could
> sanity
> > > check my config please, liberlay doused with printf debugging.
> > > My backend service (a RESTful POX service that accept the SOAP payload
> > as
> > > the 'callout' doesn't support POX) is called and a responds, but the
> > > processing stops at :  DEBUG SequenceMediator End : Sequence
> > > <ossj_fault_main>
> > >
> > > The out sequence 'ossj_fault_out' is never called and I am at a loss
> as
> > to
> > > why.   (The namings are an unfortunate clash, but its a FaultReporting
> > > interface)
> > >
> > > My config is below:
> > >
> > > <definitions xmlns="http://ws.apache.org/ns/synapse">
> > >
> > >
> > >    <!-- the SimpleURLRegistry allows access to a URL based registry
> > (e.g.
> > > file:/// or http://) -->
> > >    <registry
> > >        provider="org.apache.synapse.registry.url.SimpleURLRegistry">
> > >        <parameter name="root">
> > >
> > >
> > >
> >
> file:../../workspace/OS3_SOA_POC/src/test/config/Synapse/repository/conf/os3/resources/
> > >        </parameter>
> > >        <!-- the root property of the simple URL registry helps resolve
> a
> > > resource URL as root + key -->
> > >        <parameter name="cachableDuration">1000</parameter><!--
all
> > > resources loaded from the URL registry would be cached for this number
> > of
> > > milli seconds -->
> > >    </registry>
> > >
> > >    <!--  Entry point -->
> > >    <proxy name="JVTAlarmCreationSession" transports="https">
> > >        <publishWSDL
> > >
> > > key="OSSJ/wsdl/FaultManagement/v1-0/JVTAlarmCreationSession.wsdl" />
> > >        <target inSequence="ossj_fault_in" outSequence="ossj_fault_out"
> > />
> > >    </proxy>
> > >
> > >    <!--  handle incoming messages -->
> > >    <sequence name="ossj_fault_in" trace="enable">
> > >        <log level="full">
> > >            <property name="SECTION" value="inSequence" />
> > >        </log>
> > >        <clone>
> > >            <target sequence="ossj_fault_main" />
> > >            <target sequence="ossj_fault_comments_wrapper" />
> > >        </clone>
> > >    </sequence>
> > >
> > >    <!-- send response messages to client -->
> > >    <sequence name="ossj_fault_out" trace="enable">
> > >        <log level="full">
> > >            <property name="SECTION" value="ossj_fault_out" />
> > >        </log>
> > >        <xslt key="OSSJ/transform/AddWrapperTag.xslt" />
> > >        <aggregate>
> > >            <correlateOn expression="//wrapper" />
> > >            <onComplete>
> > >                <iterate preservePayload="true"
> > >
> > >
> > >
> >
> expression="/wrapper/*[local-name()='createAlarmByValueRequest']/*[local-name()='alarmValue']/*[local-name()='comments']/*[local-name()='item']">
> > >                    <log level="full">
> > >                        <property name="SECTION" value="iterate" />
> > >                    </log>
> > >                    <target sequence="final" />
> > >                </iterate>
> > >            </onComplete>
> > >        </aggregate>
> > >    </sequence>
> > >
> > >
> > >    <sequence name="ossj_fault_main" trace="enable">
> > >        <log level="full">
> > >            <property name="SECTION"
> > >                value="ossj_faults_main_precallout_prexslt" />
> > >        </log>
> > >
> > >        <xslt
> > >
> > >
> > >
> >
> key="OSSJ/transform/FaultManagement/v1-0/createAlarmByValueRequest_Main.xslt"
> > > />
> > >        <log level="full">
> > >            <property name="SECTION"
> > >                value="ossj_faults_main_precallout_postxslt" />
> > >        </log>
> > >        <callout serviceURL="http://localhost:8764/ars/create/">
> > >            <source
> > >                xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > >                xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > >                xpath="s11:Body/child::*[fn:position()=1] |
> > > s12:Body/child::*[fn:position()=1]" />
> > >            <target
> > >                xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > >                xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > >                xpath="s11:Body/child::*[fn:position()=1] |
> > > s12:Body/child::*[fn:position()=1]" />
> > >        </callout>
> > >        <log level="full">
> > >            <property name="SECTION"
> > >                value="ossj_faults_main_post_callout" />
> > >        </log>
> > >         <property name="RESPONSE" value="true" scope="axis2" />
> > >    </sequence>
> > >
> > >     <sequence name="ossj_fault_comments_wrapper" trace="enable">
> > >        <log level="full">
> > >            <property name="SECTION"
> > >                value="ossj_fault_comments_wrapper" />
> > >        </log>
> > >
> > >        <property name="RESPONSE" value="true" scope="axis2" />
> > >         <send/>
> > >    </sequence>
> > >
> > >    <sequence name="final" trace="enable">
> > >        <log level="full">
> > >            <property name="SECTION" value="final" />
> > >        </log>
> > >        <!--  xslt  -->
> > >        <send />
> > >    </sequence>
> > >
> > > </definitions>
> > >
> > >
> > > On Wed, Apr 16, 2008 at 11:06 AM, Wayne Keenan <wayne.keenan@gmail.com
> >
> > > wrote:
> > >
> > > > Thanks very much,  when I have something working I will make it less
> > > > specific to my needs and post an article, or create a Synapse
> sample.
> > > >
> > > > All the best,
> > > > Wayne
> > > >
> > > >
> > > > On Wed, Apr 16, 2008 at 9:31 AM, Ruwan Linton <
> ruwan.linton@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Wayne,
> > > > >
> > > > > According to your problem here is the optimized solution that I
> can
> > > see;
> > > > >
> > > > >   - Inside an in mediator Clone the message in to two messages and
> > > give
> > > > >   the messages to two sequences (lets say sequence A and B)
> > > > >   - Inside sequence A put a callout mediator after an XSLT
> mediator
> > to
> > > > >   transform the message to relevant format (or you can use a
> custom
> > > > > mediator
> > > > >   to do the callout), then set the property "RESPONSE" on the
> axis2
> > > > > level to
> > > > >   make it an outgoing message
> > > > >   - Inside sequence B set the property "RESPONSE" on the axis2
> level
> > > to
> > > > >   make it an outgoing message
> > > > >
> > > > >
> > > > >   - On the out mediator put a XSLT mediator to wrap the messages
> > into
> > > a
> > > > >   wrapping tag
> > > > >   - Then put an aggregate mediator to aggregate the parent message
> > and
> > > > >   the response from the callout using the wrapping element
> > > > >   - Now you will have a message with both the first incoming
> request
> > > and
> > > > >   the response from the callout mediator aggregated inside the
> > > wrapping
> > > > >   element you used in the transformation above
> > > > >   - Then use the iterate mediator to iterate over the child
> elements
> > > > >   make sure to use the preservePayload=true to preserve the whole
> > > > > payload on
> > > > >   the iterated (splitted) messages (this will provide number of
> > > > > identical
> > > > >   messages according to the number of child elements in the
> message)
> > > > >   - Now again use an XSLT mediator to include the required callout
> > > > >   response contents to the child elements to for the new messages.
> > > > >   - Then use the normal send mediator to invoke the service with
> > child
> > > > >   messages.
> > > > >
> > > > > following is an abstract config that has to be used, and you can
> > > replace
> > > > > all
> > > > > the XSLT mediators with script mediators with groovy, also you can
> > > write
> > > > > your own mediators to handle any of these actions if required.
> > > > >
> > > > > <defnitions>
> > > > > <in>
> > > > > <clone><target sequence="A"/><target sequence="B"/></clone>
> > > > > </in>
> > > > > <out>
> > > > > <xslt ... [to add the <wrapper> tag as a wrapping]/>
> > > > > <aggregate expression="//wrapper"/>
> > > > > <iterate expression="[child-element]"><target
> > > > > sequence="final"/></iterate>
> > > > > </out>
> > > > > <sequence name="A">
> > > > > <xslt />
> > > > > <callout/>
> > > > > <property name="RESPONSE" value="true" scope="axis2"/>
> > > > > </sequence>
> > > > > <sequence name="B">
> > > > > <property name="RESPONSE" value="true" scope="axis2"/>
> > > > > </sequence>
> > > > > <sequence name="final">
> > > > > <xslt />
> > > > > <send/>
> > > > > </sequence>
> > > > >
> > > > > Hope this will help you.
> > > > >
> > > > > If you want to block a particular message you can do so by
> > evaluating
> > > > > the
> > > > > following code over that message;
> > > > >
> > > > > OperationContext opCtx
> > > > >            = ((Axis2MessageContext)
> > > > > synCtx).getAxis2MessageContext().getOperationContext();
> > > > >        if (!continueParent && opCtx != null) {
> > > > >            opCtx.setProperty(Constants.RESPONSE_WRITTEN, "SKIP");
> > > > >        }
> > > > >
> > > > > Thanks,
> > > > > Ruwan
> > > > >
> > > > > On Wed, Apr 16, 2008 at 12:26 PM, Wayne Keenan <
> > wayne.keenan@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The incoming message to my proxy contains a parent record with
> > many
> > > > > child
> > > > > > records.
> > > > > > I need to send the parent record to an atomic create record
> > service
> > > > > and
> > > > > > with
> > > > > > the response from that atomic service I extract a key which
I
> then
> > > > > > subsequently need to use when sending the child records to
> further
> > > > > atomic
> > > > > > create services.
> > > > > >
> > > > > > What I can't not see is how to easily preserve the original
> > message
> > > > > AND
> > > > > > wait
> > > > > > for the 1st message to complete, e.g. a clone isn't viable as
> the
> > > > > > sequences
> > > > > > are triggered in parallel and I need to wait for the parent
ket
> > from
> > > > > the
> > > > > > 1st
> > > > > > create.
> > > > > >
> > > > > > Would one approach be to:
> > > > > >
> > > > > > 1. insert a generated unique message id on input, for use later
> in
> > > the
> > > > > > proxy
> > > > > > only
> > > > > > 2. clone the message, send the 1st to the create for the parent,
> > > > > keeping
> > > > > > the
> > > > > > 2nd untouched
> > > > > > 3. aggregate based on id created in #1
> > > > > > 4. take the unaltered child messages from the 2nd in #2 and
use
> > for
> > > > > the
> > > > > > child creates
> > > > > >
> > > > > > To me that seems inefficient (I will have approx. 6 'types'
of
> > child
> > > > > > records), so I'm wondering if mm overlooking something and/or
> > going
> > > > > > against
> > > > > > the grain.
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > > > Wayne
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 9:51 AM, Ruwan Linton <
> > > ruwan.linton@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Wayne,
> > > > > > >
> > > > > > > You should have a look at the callout mediator [1] and
also
> this
> > > [2]
> > > > > > case
> > > > > > > study, which covers some ground and do something similar.
Also
> > you
> > > > > can
> > > > > > use
> > > > > > > the SynapseEnvironment.createMessageContext() to get a
new
> > message
> > > > > > context
> > > > > > > created. You can use java inside groovy and hence this
call
> will
> > > be
> > > > > > > possible
> > > > > > > inside groovy as well.
> > > > > > >
> > > > > > > Hope this will help.
> > > > > > >
> > > > > > > [1] - http://synapse.apache.org/Synapse_Samples.html#Callout
> > > > > > > [2] - https://wso2.org/library/3325
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Ruwan
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 1:57 PM, Wayne Keenan <
> > > > > wayne.keenan@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I think I might be pushing/abusing mediators, by doing
more
> > that
> > > > > > message
> > > > > > > > manipulation, I'm trying to call endpoint from within
a
> > script,
> > > > > and
> > > > > > > would
> > > > > > > > be
> > > > > > > > grateful for some advice.
> > > > > > > >
> > > > > > > > Here is the setup:
> > > > > > > >
> > > > > > > > 1. Synapse
> > > > > > > >
> > > > > > > > a) publishing a predefined WSDL of 'composite' services.
> e.g.
> > > > > > > > createTroubleTicket.
> > > > > > > > b) a mediator chops up incoming SOAP Payload XML into
parent
> > > child
> > > > > > > records
> > > > > > > > c) the mediator calls (external) lower level atomic
services
> > > (e.g.
> > > > > > > create
> > > > > > > > record) for the parent
> > > > > > > > d) the mediator needs to either calculate child id
(e.g.
> > > > > sequential
> > > > > > > index)
> > > > > > > > or use the result of parent ids created at runtime
> > > > > > > > e) the mediator calls (external) lower level create
record
> for
> > > the
> > > > > > > > children
> > > > > > > >
> > > > > > > > 2. RESTful server for the (external) Atomic services
> > > > > > > > a). create record in a DB (not JPA, uses propritary
API to
> > > create
> > > > > 1
> > > > > > row
> > > > > > > in
> > > > > > > > an underlying DB)
> > > > > > > >
> > > > > > > >
> > > > > > > > I am writing a Groovy mediator to take the parent
and child
> > > > > records
> > > > > > and
> > > > > > > > then
> > > > > > > > call the atomic service endpoitns using somehtin glike:
> > > > > > > >
> > > > > > > >    def createEP = mc.getEndpoint("SOME_API_CREATE")
> > > > > > > >    createEP.send(newMc)
> > > > > > > >
> > > > > > > > I've basically got 1a,1b & 2a working, but for
1c-e  trying
> to
> > > > > create
> > > > > > > the
> > > > > > > > new MessaceContext ('newMc') is perhaps telling me
I should
> > not
> > > be
> > > > > > doing
> > > > > > > > this?
> > > > > > > >
> > > > > > > > I wanted to avoid 'programming in XML' via the declarative
> > > Synapse
> > > > > > > > mediators, but perhaps I will have to?
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > Wayne
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Ruwan Linton
> > > > > > > http://www.wso2.org - "Oxygenating the Web Services Platform"
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Ruwan Linton
> > > > > http://www.wso2.org - "Oxygenating the Web Services Platform"
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
>



-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message