cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Axis SOAPHelper implementation anyone?
Date Fri, 14 Jun 2002 16:32:42 GMT
On 6/14/02 3:39 AM, "Per-Olof Norén" <> wrote:

> Hi Ovidiu!
> Glad to see that you are alive :)

Still hanging in here, thanks ;)

> Next up on our schedule is to construct our app
> using flow layer, with soap calls as backend :)

This sounds interesting, I'd like to hear some more about it.

> Ovidiu Predescu wrote:
>> On 6/13/02 4:51 AM, "Per-Olof Norén" <> wrote:
>> 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

I wasn't aware the Axis client library allows you to do this. Sounds neat,

>> 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 :)

OK, I get your point! I think your approach is good, I like it.

Could you send me a patch, or the complete files with your changes? I'd vote
+1 for this change, but I like to see your changes. I also agree that
pluggable SOAPHelper is overkill, only one solution should be used.

Ovidiu Predescu <> (Apache, GNU, Emacs...)

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

View raw message