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" <[EMAIL PROTECTED]> wrote: > > >>Morrison, John wrote: >> >>>>From: Per-Olof Norén [mailto:[EMAIL PROTECTED]] >>>> >>>>Hi all, >>>> >>>>I have rewritten the SOAPHelper.java 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: >>>>http://user:[EMAIL PROTECTED]/endpoint >>>> >>>> >>>>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 :) regards, Per-Olof Norén > > Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
