Re: Calling web services from Cocoon
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
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
Gianugo Rabellino wrote: On Tue, 27 Jul 2004 14:57:08 +0200, Daniel Fagerstrom <[EMAIL PROTECTED]> 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 element, providing some status information (see SWT#reportResult()). Am I missing something? I have extended SWT so that you can post XML as well: . 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.: http://apache.org/cocoon/source/1.0";> http://services.xmethods.net:9090/soap text/xml; charset="utf-8" "" http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"; xmlns:xsd="http://www.w3.org/1999/XMLSchema";> http://schemas.xmlsoap.org/soap/encoding/";> England Japan and the output from SWT: http://apache.org/cocoon/source/1.0";> 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/";> 183.9227 success entire source overwritten post posted http://services.xmethods.net:9090/soap xml How does this differ from what you have in mind? /Daniel
RE: Calling web services from Cocoon
Gianugo Rabellino <[EMAIL PROTECTED]> writes: > > On Tue, 27 Jul 2004 14:57:08 +0200, Daniel Fagerstrom > <[EMAIL PROTECTED]> wrote: > SWT discussion > > 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? > Just to agree that I'd use a transformer approach as well and that if you're ok with flow it might also help: you could use a processPipelineTo call to dynamically go off and grab any XML you want for inclusion in the main pipeline.
Re: Calling web services from Cocoon
On Tue, 27 Jul 2004 14:57:08 +0200, Daniel Fagerstrom <[EMAIL PROTECTED]> 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 > >element, providing some status information (see SWT#reportResult()). > >Am I missing something? > > > I have extended SWT so that you can post XML as well: . 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
Gianugo Rabellino wrote: On Mon, 26 Jul 2004 16:12:30 +0200, Daniel Fagerstrom <[EMAIL PROTECTED]> 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 element, providing some status information (see SWT#reportResult()). Am I missing something? I have extended SWT so that you can post XML as well: . 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
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
On Mon, 26 Jul 2004 16:12:30 +0200, Daniel Fagerstrom <[EMAIL PROTECTED]> 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 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
Re: Calling web services from Cocoon
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
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