Re: SOAP::Lite client and .NET server, array return

Gordon,

The patch I'm using works equally well with RPC/Encoded and
Doc/Literal (I haven't tested the other two combinations, but
then is anyone using them?)

Getting SOAP::Lite to work with Doc/Literal is more a matter of
encoding the arguments and formulating the final call correctly.

I haven't encountered the problem that the patch creates arrays
for multiple values.  I'm not sure what you mean by that -- if
the service returns several contiguous elements with the same
name, I would expect that to be mapped to an array.

- Eric

Gordon Henriksen <[email protected]> writes:
> Date:    Wed, 11 Sep 2002 23:47:24 -0400
> From:    Gordon Henriksen <[email protected]>
> Subject: Re: SOAP::Lite client and .NET server, array return
>
> The best resolution for the problem I initially had was to switch my web
> service to use SOAP RPC encoding, with the [SoapRpcMethod] C# method
> attribute.
>
> Unfortunately, I have to support a Java client as well, which is proving
> to be much more problematic. I've found that IBM's wsdl2java stub
> generator tool can be convinced to work with document/literal encoding
> fairly easily but is very nearly impossible to use with SOAP RPC
> encoding.
>
> So, the best resolution to my Perl interop problem was is in conflict
> with the only feasable resolution to my Java interop problems.
>
>     As an aside, is everyone else as unimpressed with Apache SOAP as I
> am? It is virtually
>     undocumented and completely unusable without the stub generator. I
> seek alternatives.
>
> The below patch would allow me to use my Perl client with the
> document/literal server, but has the undesireable--if not outright
> buggy--behavior of creating arrays for multiple values and creating
> scalars for single or nil values. Reminds me of a particular horror of
> Mason. Since I'm not exposing the SOAP::Lite interface directly to my
> developers, I can apply this patch and work around that bug for the time
> being.
>
>
> But is SOAP::Lite client interoperability with document/literal web
> services reasonable to expect in the near term from release code?
>
> If SOAP::Lite won't become compatible, I can double up the .NET web
> service to vend both interfaces, one for Java and one for Perl. However,
> I'd prefer not to have to support the two interfaces. If this patch will
> make document/literal encoding fly for my Perl client and compatible
> document/literal functionality will appear in release code in the near
> future, that satisfies me and I won't bother to double the interface.
>
>
> Additionally, are there any other problems I should be aware of in using
> SOAP::Lite with document/literal encoding?
>
> [... rest deleted...]

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.