Answers embed below in <RJS>
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Sam
Ruby/Raleigh/IBM@ To: [EMAIL PROTECTED]
IBMUS cc:
Subject: Re: AXIS/SOAP Interop Test
Summary
01/31/2002 10:57
AM
Please respond to
axis-dev
Rich Scheuerle Jr wrote:
>
> The number of red failures in the last run: 35
> The number of red failures in the jan 1 run: 41
Great work!
> Void (SoapX4 and TclSoap both return elements with no values)
Open question: should we accept these resposes?
We accept an response containing an empty envelope from eSOAP. We don't
accept the one from TclSOAP because it is explicitly marked as a an
xsd:int. We don't accept the response from SoapX4 because there is
whitespace between the begin tag and the end tag.
<RJS> +1 to accepting both </RJS>
> Hex Binary (4s4c and 4s4c2.0 both return soapenc:base64)
Open question: we do automatic conversions in other cases (example: vector
=>array). Should we consider doing the same thing here?
<RJS> It's not hard to do. What is the semantic difference between
xsd:hexBinary
and soapenc:base64 ?</RJS>
> Also there are more SOAP structArray problems. Without the wire dumps
> its hard to tell what is going on, but I suspect that SOAP is now sending
> the arrays across with a type=ArrayOfSOAPStruct instead of
> type=soapenc:Array.
What is currently sent by Apache SOAP is accepted by a large number of
other end points. In fact, with your fixes, we now accept
ArrayOfSOAPStruct in a response. Is there any reason that we shouldn't
accept the same thing in a request?
<RJS>
Long explanation...
Before a serializer is invoked, the Serialization Context
setTypeAttributes is invoked which sets the xsi:type attribute.
Before yesterday, array types were not physically registered in the
type mapping registry, so the call to setTypeAttributes() would ALWAYS
be passed a soapenc:Array qname as the type. The array serializer
then serializes the array using the SOAP 1.1 soapenc:Array format.
Now, array types are physically registered in the type mapping registry.
Thus the call to setTypeAttributes() could be something other than
soapenc:Array...i.e ArrayOfFoo. When the array serializer is
invoked, it serializes the array using the soapenc:Array format.
But if the xsi:type was set to ArrayOfFoo, the remote receiver will get
messed up because it will receive a mixture of formats. So
I changed the array serializer to force the xsi:type back to soapenc:Array,
which makes sense because our array serializer is currently designed to
produce just the soapenc:Array format.
You indicated yesterday that a change was made to Apache SOAP to
register array types. I am concerned that they will run across this same
problem...and from last night's test it appears that they did.
See SOAP echoStructArray for SOAP RMI. Also, the SOAP echoStructArray
call failed when calling Apache SOAP and Apache AXIS!
It would be nice to see the SOAP wire dumps for these cases.
</RJS>
> SOAP may need to apply the same fix that I did to the array serializer to
> force type=soapenc:Array.
Should this be forced? It seems to me that ArrayOfSOAPStruct is not only
legal, but more specific (in oo terms, a subtype). On the other hand,
forcing it to may increase interop. On the other other hand (whoops! hand
fault.), forcing it makes it impossible to generate a whole class of legal
SOAP messages.
<RJS>
Forcing it is the proper solution for now and for interop.
Long term we could change the array serializer to use an
"ArrayOfSOAPStruct"
format along with the soapenc:Array format if we choose.
But it looks like more services accept the soapenc:Array format.
Comments ???
</RJS>
- Sam Ruby
