cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Calling web services from Cocoon
Date Tue, 27 Jul 2004 15:38:30 GMT
Gianugo Rabellino wrote:

>On Tue, 27 Jul 2004 14:57:08 +0200, Daniel Fagerstrom
><> wrote:
>>>I was thinking about using SWT as well, but then I realized that SWT
>>>doesn't offer a way of inserting the resulting XML in the original
>>>stream: all it does is delete the XML inside the <source:write/>
>>>element, providing some status information (see SWT#reportResult()).
>>>Am I missing something?
>>I have extended SWT so that you can post XML as well: <source:post/>.
>Oh, I see. Well, I spent a few brain cycles on it, and I have to admit
>that I'm not convinced that the Source/SWT way is the way to go. The
>idea of a Source, to me, is that whatever I write to it can be read
>back at the same location: this happens with files and with HTTP as
>well (if you PUT and GET). POST is a different beast and it belongs to
>RPC rather than to streams.
I can agree with that the name Source doesn't describe the a POST very 
well, protocol would have been better (at least if you want to post and 
put things to it). An HTTP POST require an input and an output stream 
and that you have completed your writing to the output stream before you 
can read from the input stream, so I don't understand what you mean with 
that it doesn't belong to streams.

>Same issue goes for SWT. Apart from having quite a few discussions
>about it (as it "tees" the pipeline, which - design wise - is not a
>good idea for many of us), it wasn't quite conceived to do this job.
As you might remember I spent quite a lot of energy trying to convince 
the community about the need for selection based on results earlier in 
the pipeline, tee functionality and so on ;) Anyway, my current take is 
that transformers with side effects are ok for simple use cases, when I 
need more advanced control functionality I use flowscripts instead.

>Also, I haven't seen your implementation, but is it compatible with
>the "old" SWT output in terms of the resulting XML or will it break
It is backward compatible with SWT as it just extends it functionality. 
The source:post tag sets the METOD parameter in the source to POST, and 
writes the content of the source:fragment element to the output stream 
of the source and report the result from the input stream of the source 
to the source:sourceResult/source:content element.

>All in all, I'd rather favor the transformer approach ATM: it seems to
>me that it fits much better in the overall Cocoon architecture: you
>build your request inside the pipeline, pass it through a component
>which performs the POST and grab the result (something you can,
>besides, do a using a cocoon:// src to the WSProxyGenerator). But I'm
>open to change my mind.
I don't see how this differs from my approach.

I have a pipeline e.g. FileGenerator -> SWT -> XMLSerializer

the input to SWT is e.g.:

  <source:post xmlns:source="">
    <source:header name="Content-Type">text/xml; charset="utf-8"</source:header>
    <source:header name="SOAPAction">""</source:header>
      <soap:Envelope xmlns:soap=""
          <ns1:getRate xmlns:ns1="urn:xmethods-CurrencyExchange"
            <country1 xsi:type="xsd:string">England</country1>
            <country2 xsi:type="xsd:string">Japan</country2>

and the output from SWT:

  <sourceResult xmlns:source="">
      <soap:Envelope xmlns:soap=""
          <n:getRateResponse xmlns:n="urn:xmethods-CurrencyExchange">
            <Result xsi:type="xsd:float">183.9227</Result>
    <message>entire source overwritten</message>

How does this differ from what you have in mind?


View raw message