cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per-Olof Norén <>
Subject Re: Axis SOAPHelper implementation anyone?
Date Fri, 14 Jun 2002 10:39:07 GMT
Hi Ovidiu!
Glad to see that you are alive :)
Next up on our schedule is to construct our app
using flow layer, with soap calls as backend :)

My comments and explanations are "inline" below

Ovidiu Predescu wrote:
> On 6/13/02 4:51 AM, "Per-Olof Norén" <> wrote:
>>Morrison, John wrote:
>>>>From: Per-Olof Norén []
>>>>Hi all,
>>>>I have rewritten the to use axis instead of HttpClient
>>>>in order to connect to .NET webservices. The change has been
>>>>verified by 
>>>>running google api search and the stock-ticker examples as
>>>>well as .NET 
>>>>services. Also support for basic authenticated connections is is
>>>>supported in the standard url format:
>>>>I´d gladly donate this code, though i need a little help packaging it.
>>>>The file itself is no problem, cvs diff as usual.
>>>>What I can see to be somewhat of a problem is that axis is not part
>>>>of the distribution by default.
>>>Axis *used* to be part of the distro and I can't see any problems putting
>>>it back.
>>Do we need a vote on this?
> How does the Axis client library work? With SOAPHelper, the logicsheet
> constructs the whole message, so there's no need to generate any client
> stub. The SOAPHelper class creates only the HTTP connection and streams the
> message onto it, nothing else.

What we did was to replace the http client code, feeding the content to 
axis own envelope builder. Didn´t change a thing in the stylesheets, 
until yesterday when we, after reading John Morrisons reply , made 
SOAPHelper an interface implemented by HttpClientSOAPHelper and 
AxisSOAPHelper. Also soaphelper is now a component defined and 
configured with in cocoon.roles and cocoon.xkonf. this made the 
SOAPHelper pluggable in which implementation to use.

So I´d guess that our change simply lets axis to do the http connection 
its own way instead of hand-crafting headers as would have been the case 
with http client.
see below for more precise explanation of headers

> As for .Net compatibility, it would be interesting to know what kind of
> problems you encountered with the existing code. I don't see any problem
> coming from the SOAPHelper, other than incompatible message format generated
> by the logicsheet, or bad HTTP protocol communication.

On our case, the service we are accessing requires basic authenticated 
calls. After investigating the http client, it  showed that one had to 
parse the url and set the headers by hand
We wanted to support the url format for specifying the credentials.
<soap:call url="http://user:pass@domain/service" method="..."/>

You could say that we "overworked" our solution, but we figured
the easiest way to handle the soap concerned http calls was to actually
let the code from axis (which is focused on just that) to do it.
This would let us be able to wait for their changes when the soap 
standerd changes. I´m not aware of any particular reasons for not using 
axis, but if there is, please let me know.

As for compability there were no particular reasons but lack of support 
for authentication.

Peronally I think that using the approach we´ve currently implemented 
with pluggable SOAPHelpers is overkill. Furthermore I consider url 
parsing and http connection authentication to be the concern of the 
underlaying code ie HttpClient OR Axis depending on which to choose.
I´d vote for Axis implementation, since Axis whole purpose is to handle 
soap requests and responses.

Please correct me if I´m wrong or missinformed :)

Per-Olof Norén

> Regards,

To unsubscribe, e-mail:
For additional commands, email:

View raw message