On 6/14/02 3:39 AM, "Per-Olof Norén" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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, anyway! >> >> 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. Cheers, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
