You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2004/07/26 16:12:30 UTC
Re: Calling web services from Cocoon
Hi Morley,
I answer at Cocoon-dev as others might be interested.
AFAIK there are no "current prefered method" for calling web-services. I
and my colleagues, use the extended SourceWritingTransformer (SWT) and
org.apache.excalibur.source.impl.HTTPClientSource that you can find in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24402, (I updated it
with new patches for the SWT and HTTPClientSource, you still need some
stuff from the earlier patch, though). It should be possible to use with
HTTPS if you connect https to o.a.e.source.impl.HTTPClientSourceFactory
in cocoon.xconf, but I have not tested it.
In some applications we have used the HTTPClientSource from flowscript
code instead of calling it from the SWT, it requires some more work but
gives better control of error handling (and also memory consumption for
very large soap requests).
My idea with extending the HTTPClientSource with SOAP (post)
functionallity was to gather all uses of the
o.a.jakarta.commons.HTTPClient in one component. Now similar things are
done in various SOAP and Web-proxy components. From a technical POV I
still think it is a good idea. There where however a number of other
problems that have done that I not have put the code in the Cocoon CVS
yet: I never succeeded in updating the avalon CVS, Excalibur have
sometimes been quite hard to compile, there where talk about deprecating
the Excalibur components, there where severe community problems in
Avalon, it have been moved from Ant to Maven and from CVS to Subversion.
Now, Excalibur has left Avalon and started a new top level project that
seem to be healthy, so I'll try to integrate the extended SWT and
HTTPClientSource as soon as I find some time for it ;)
I spent some time today trying to test the code with the samples that I
submitted in the bugzilla entry, but the web services that I call from
xmethods.net seemed to be down or at least very slow, anyone knowing
about any other good webservice test sites, preferably with WSDL
descriptions?
/Daniel
Morley Howell wrote:
> Daniel,
>
> I've been struggling for a few days to call a Web service from Cocoon 2.1.5,
> with little joy.
>
> I noticed various discussions on the wiki and the dev list about your source
> writing idea and some other options from Daniel Fagerstrom and Steve Punte.
> Do you know what the current preferred method is to call a Web service from
> Cocoon? Are any of them integrated into 2.1.5? Do any of them work over
> HTTPS (unlike the SOAP XSP logicsheet).
>
> Thanks for any help you can provide.
>
> Morley Howell
>
>
Re: Calling web services from Cocoon
Posted by Christian Mayrhuber <cm...@iicm.tu-graz.ac.at>.
Hi,
sorry for my late reply, I should have noted that I'm only subscribed to
dev-digest.
On Tuesday 27 July 2004 14:29, Daniel Fagerstrom wrote:
> Christian Mayrhuber wrote:
> >On Monday 26 July 2004 16:12, Daniel Fagerstrom wrote:
> >Business logic:
> >As java beans or as stubs trough webservices|ejb.
>
> Yes, something like http://wiki.apache.org/cocoon/FlowAndWebServices
> would be nice. We are mainly using document-style web services so we
> have not used the stub based approach.
Agreed.
>
> Are you using the HTTPClient from Jakarta commons?
I'm using the java xml rpc api (J2EE 1.4) with the axis-1.1 jars.
import javax.xml.rpc.*
There is a tutorial on the sun site:
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXRPC5.html
The DII client sample may come handy.
>
> >>I spent some time today trying to test the code with the samples that I
> >>submitted in the bugzilla entry, but the web services that I call from
> >>xmethods.net seemed to be down or at least very slow, anyone knowing
> >>about any other good webservice test sites, preferably with WSDL
> >>descriptions?
> >
> >http://www.amazon.com/gp/browse.html/104-6232418-6223133?node=3435361
> >You need to subscribe as developer, though.
>
> Thanks. I mainly need something that I can use for samples for Cocoon,
> so something that doesn't need subscription would be nice.
>
> /Daniel
You don't need a license for querying, just one for developing.
I'm rather sure that this sort of complicated license would have to be
included/mentioned in the samples.
Google offers webservices, too. It requires a license that allows for 1000
queries a day and restricts you in how to present your sample.
http://www.google.com/apis/
--
lg, Chris
Re: Calling web services from Cocoon
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Christian Mayrhuber wrote:
>On Monday 26 July 2004 16:12, Daniel Fagerstrom wrote:
>
>
>I'm currently writing a hand crafted stub for a remote object, that I can use
>in both Flowscript and my custom generator. (The remote side has no wsdl)
>If the remote site had a wsdl description you could use wsdl2java from the
>axis project to generate such stub's.
>Stub's are the way to go, because their usage pattern is identical for
>EJB business logic and foreign web services.
>
>My best experiance with cocoon has been so far with:
>Presentation layer:
>1. jxtemplate + cforms + flowscript + xslt/xslfo
>2. custom geneator|custom transformer + xslt/xslfo
>
>Business logic:
>As java beans or as stubs trough webservices|ejb.
>
Yes, something like http://wiki.apache.org/cocoon/FlowAndWebServices
would be nice. We are mainly using document-style web services so we
have not used the stub based approach.
Are you using the HTTPClient from Jakarta commons?
>
>
>
>>I spent some time today trying to test the code with the samples that I
>>submitted in the bugzilla entry, but the web services that I call from
>>xmethods.net seemed to be down or at least very slow, anyone knowing
>>about any other good webservice test sites, preferably with WSDL
>>descriptions?
>>
>>
>
>http://www.amazon.com/gp/browse.html/104-6232418-6223133?node=3435361
>You need to subscribe as developer, though.
>
>
Thanks. I mainly need something that I can use for samples for Cocoon,
so something that doesn't need subscription would be nice.
/Daniel
Re: Calling web services from Cocoon
Posted by Christian Mayrhuber <cm...@iicm.tu-graz.ac.at>.
On Monday 26 July 2004 16:12, Daniel Fagerstrom wrote:
> Hi Morley,
>
> I answer at Cocoon-dev as others might be interested.
>
> AFAIK there are no "current prefered method" for calling web-services. I
> and my colleagues, use the extended SourceWritingTransformer (SWT) and
> org.apache.excalibur.source.impl.HTTPClientSource that you can find in
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24402, (I updated it
> with new patches for the SWT and HTTPClientSource, you still need some
> stuff from the earlier patch, though). It should be possible to use with
> HTTPS if you connect https to o.a.e.source.impl.HTTPClientSourceFactory
> in cocoon.xconf, but I have not tested it.
>
> In some applications we have used the HTTPClientSource from flowscript
> code instead of calling it from the SWT, it requires some more work but
> gives better control of error handling (and also memory consumption for
> very large soap requests).
>
> My idea with extending the HTTPClientSource with SOAP (post)
> functionallity was to gather all uses of the
> o.a.jakarta.commons.HTTPClient in one component. Now similar things are
> done in various SOAP and Web-proxy components. From a technical POV I
> still think it is a good idea. There where however a number of other
> problems that have done that I not have put the code in the Cocoon CVS
> yet: I never succeeded in updating the avalon CVS, Excalibur have
> sometimes been quite hard to compile, there where talk about deprecating
> the Excalibur components, there where severe community problems in
> Avalon, it have been moved from Ant to Maven and from CVS to Subversion.
>
> Now, Excalibur has left Avalon and started a new top level project that
> seem to be healthy, so I'll try to integrate the extended SWT and
> HTTPClientSource as soon as I find some time for it ;)
I'm currently writing a hand crafted stub for a remote object, that I can use
in both Flowscript and my custom generator. (The remote side has no wsdl)
If the remote site had a wsdl description you could use wsdl2java from the
axis project to generate such stub's.
Stub's are the way to go, because their usage pattern is identical for
EJB business logic and foreign web services.
My best experiance with cocoon has been so far with:
Presentation layer:
1. jxtemplate + cforms + flowscript + xslt/xslfo
2. custom geneator|custom transformer + xslt/xslfo
Business logic:
As java beans or as stubs trough webservices|ejb.
>
> I spent some time today trying to test the code with the samples that I
> submitted in the bugzilla entry, but the web services that I call from
> xmethods.net seemed to be down or at least very slow, anyone knowing
> about any other good webservice test sites, preferably with WSDL
> descriptions?
http://www.amazon.com/gp/browse.html/104-6232418-6223133?node=3435361
You need to subscribe as developer, though.
--
lg, Chris
Re: Calling web services from Cocoon
Posted by Gianugo Rabellino <gi...@gmail.com>.
First of all, sorry for the delayed reply. I got stuck in urgent
issues and had to leave this aside.
> >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.
It does definitely belong to streams, I used a very bad wording. My
point is actually that a Source, in its current incarnation, is an
abstraction of a stream I/O where write operations are considered as
in "file" operations: whatever I write, can be read back later (which
is not the case with POST). This is, besides, exactly, what the HTTP
RFC considers as the difference between PUT and POST:
"The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations. In
contrast, the URI in a PUT request identifies the entity enclosed with
the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
If the server desires that the request be applied to a different URI"
Moreover, there is no use in considering a Source (as an interface)
where the implementation isn't swappable: I'm using a Source when I'm
in a position not to care where the final result will be written to or
read from. Can be a filesystem, an FTP/DAV server, a database or
whatever. With your "extension" the only source that can be used is
the HTTP one, so I see no need for an abstraction here. It seems, on
the contrary, a perfect candidate for a specific transformer.
> >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.
In practice, the difference is barely noticeable: a different
transformer and different wrapping tags. But conceptually I think
there is an important difference in using a more correct way (Cocoon
wise) of doing things. But, of course, IMHO.
--
Gianugo Rabellino
Re: Calling web services from Cocoon
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Gianugo Rabellino wrote:
>On Tue, 27 Jul 2004 14:57:08 +0200, Daniel Fagerstrom
><da...@nada.kth.se> 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
>compatibility?
>
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.:
<page>
<source:post xmlns:source="http://apache.org/cocoon/source/1.0">
<source:source>http://services.xmethods.net:9090/soap</source:source>
<source:header name="Content-Type">text/xml; charset="utf-8"</source:header>
<source:header name="SOAPAction">""</source:header>
<source:fragment>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<soap:Body>
<ns1:getRate xmlns:ns1="urn:xmethods-CurrencyExchange"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<country1 xsi:type="xsd:string">England</country1>
<country2 xsi:type="xsd:string">Japan</country2>
</ns1:getRate>
</soap:Body>
</soap:Envelope>
</source:fragment>
</source:post>
</page>
and the output from SWT:
<page>
<sourceResult xmlns:source="http://apache.org/cocoon/source/1.0">
<content>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Body>
<n:getRateResponse xmlns:n="urn:xmethods-CurrencyExchange">
<Result xsi:type="xsd:float">183.9227</Result>
</n:getRateResponse>
</soap:Body>
</soap:Envelope>
</content>
<execution>success</execution>
<message>entire source overwritten</message>
<behaviour>post</behaviour>
<action>posted</action>
<source>http://services.xmethods.net:9090/soap</source>
<serializer>xml</serializer>
</sourceResult>
</page>
How does this differ from what you have in mind?
/Daniel
Re: Calling web services from Cocoon
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Tue, 27 Jul 2004 14:57:08 +0200, Daniel Fagerstrom
<da...@nada.kth.se> 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.
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.
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
compatibility?
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.
Anyone else cares to comment?
--
Gianugo Rabellino
Re: Calling web services from Cocoon
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Gianugo Rabellino wrote:
>On Mon, 26 Jul 2004 16:12:30 +0200, Daniel Fagerstrom
><da...@nada.kth.se> wrote:
>
>
>>Hi Morley,
>>
>>I answer at Cocoon-dev as others might be interested.
>>
>>
>
>Yup, I am. We're currently facing the need of a tool that does "XML
>over HTTP" for some webserviceish things that aren't actually SOAP
>compliant (it's just RPC with XML in/XML out stuff).
>
>Just to add another wheel, we were thinking of a different solution:
>we're planning to build a WebServicesProxyTransformer that basically
>builds on the ideas of the WSPGenerator (take some XML, send it over
>the wire, insert the response) and SQL/DASLTransformer. A custom
>element wraps the XML to be sent to the "web service" and the result
>is inserted exactly at the same point in the XML stream. Then we
>realized that we were duplicating
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24391.
>
>
>
>>AFAIK there are no "current prefered method" for calling web-services. I
>>and my colleagues, use the extended SourceWritingTransformer (SWT)
>>
>>
>
>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/>.
The code can be found in:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24402. You need the
patch
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8966
which is a tar.gz, (is there any way to explain to Bugzilla that the
attachement is a tar.gz?), and the two update patches.
>
>So, is it time to grab this issue once and for all, providing a common solution?
>
>
>
Absolutely, I think it is a good idea to gather the client code in one
component (like the o.a.e.source.impl.HTTPClientSource in my code), so
that you can use it from web-proxy generators, transformers and
flowscripts depending on your needs. I am not sure if it is good enough
to call web services from the SWT as in my code or it would be better to
have a more specialized webservice and SOAP transformer. A general
problem with transformer based solutions is that you don't get that much
controll over errror handling for geting that it is better to use
flowscripts. I submitted an example of using the HTTPClientSource from
flowscript, that one of my colleauges wrote, to the Bugzilla entry.
/Daniel
Re: Calling web services from Cocoon
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Mon, 26 Jul 2004 16:12:30 +0200, Daniel Fagerstrom
<da...@nada.kth.se> wrote:
> Hi Morley,
>
> I answer at Cocoon-dev as others might be interested.
Yup, I am. We're currently facing the need of a tool that does "XML
over HTTP" for some webserviceish things that aren't actually SOAP
compliant (it's just RPC with XML in/XML out stuff).
Just to add another wheel, we were thinking of a different solution:
we're planning to build a WebServicesProxyTransformer that basically
builds on the ideas of the WSPGenerator (take some XML, send it over
the wire, insert the response) and SQL/DASLTransformer. A custom
element wraps the XML to be sent to the "web service" and the result
is inserted exactly at the same point in the XML stream. Then we
realized that we were duplicating
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24391.
> AFAIK there are no "current prefered method" for calling web-services. I
> and my colleagues, use the extended SourceWritingTransformer (SWT)
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?
So, is it time to grab this issue once and for all, providing a common solution?
--
Gianugo Rabellino