I ran some tests per (2) in my previous note.
Here are interesting results for echoStructArray
Server SOAP Axis Sandbox Axis type="ArrayOfSOAPStruct"
------------------------------------------------------------
Axis FAIL OK FAIL'
Frontier FAIL OK FAIL'
Glue FAIL OK FAIL'
kSOAP FAIL OK FAIL''
SOAPRMI FAIL OK FAIL'''
Where:
FAIL indicates unknown failure...wire dumps not available
FAIL' indicates remote failure due to ArrayOfSOAPStruct not registered on
the server side.
FAIL'' failure because return did not have arrayType set...we should
change our array deserializer!
FAIL''' unknown remote failure
Observations:
a) The committed Axis code sends type="soapenc:Array" over the wire and is
more
interoperable because some of the remote services do not register
ArrayOfSOAPStruct.
b) Sending type="ArrayOfSOAPStruct" over the wire can cause the remote
server
to send back a response that we currently don't handle...for example
kSOAP's response.
-----------------------------------------------------------------------------------------
Work Items:
i) Sending type="ArrayOfSOAPStruct" over the wire may be 'more correct' but
is less
interoperable. So I think we should continue to send type="soapenc:Array"
over the
wire...but I will make a comment in the array serializer explainly the
pro's and con's.
ii) The array deserializer should be changed so that we could accept
returns like
kSOAP's above. This kind of return should be reflected in our TestDeser
tests.
iii) Change the array deserializer to use the specific type= information if
provided.
(See 3 below).
iv) Change our echoTest deploy.wsdd to include type mapping registration of
ArrayOfStruct.
Comments ?
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
R J Scheuerle
Jr/Austin/IBM@IBM To: [EMAIL PROTECTED]
US cc: [EMAIL PROTECTED]
Subject: Re: AXIS/SOAP Interop Test
Summary
02/06/2002 10:53
AM
Please respond to
axis-dev
Thanks Sam,
1) I'll change the echoTest deploy.wsdd to register the appropriate type
mappings for the arrays.
That should be done regardless.
2) I agree that sending the more specific type information is useful in the
overloaded method case.
So it may be more appropriate to serialize the specific type of the array.
If I have some time
I will run a test to see how many interop tests fail if we send the
specific array type.
3) Another question/comment :-). Previously axis only accepted arrays
with type="soapenc:Array", because
the specific array qnames were not registered. The type= information
provided no specific information about
the kind of array to instantiate. Thus the array deserializer is written
to always use the arrayType= attribute to figure
out the kind of array to instantiate. Clearly if we are going to
accept type="ns:ArrayOfFoo", the deserializer should use the
"ns:ArrayOfFoo" type to figure out the kind of
array to instantiate, and the runtime should not fail if arrayType= is
missing.
For example if "ns:Array" -->my. Base[] and "ns:Element" --> my.Derive
(assume Derive inherits from Base).
<name type="ns:Array" soapenc:arrayType="ns:Element[3]"> ....
Should be deserialized into an array of type my.Base[] with elements that
are my.Derive.
(Currently the array deserializer would create an array of my.Derive[].)
And if the following is specified:
<name type="ns:Array" soapenc:arrayType="xsd:anyType[3]"> ....
The deserializer deserialize into an array of type my.Base[] with
individual elements instantiated using the type= attributes of the
elements.
(I believe the current deserializer will either fail or build an Object[]
array.)
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
02/06/2002 09:54
AM
Please respond to
axis-dev
R J Scheuerle wrote:
>
> I have some questions...
>
> So a runtime could send an array using "style A":
>
> <name type="soapenc:Array" soapenc:arrayType="ns:foo[3]" >
>
> Or a runtime could send an array using "style B":
>
> <name type="ns:ArrayOfFoo" soapenc:arrayType="ns:foo[3]" >
>
> Apache SOAP is sending "style B"; I believe it used to send "style A".
> Apache Axis sends "style A".
Apache SOAP will simply send the last one that happens to be registered.
It used to be the case that only "style A" was registered. Now "style B"
has been added - at the end.
Instead of thinking of these two as styles, I have an analogy that you
might find helpful:
public class test {
public static void count(Object[] arg) {
System.out.println(arg.length);
}
public static void main(String args[]) {
count(new Object[] {"a", "b", "c"});
count(new String[] {"a", "b", "c"});
}
}
Note that the method named count accepts not only arrays of objects, but
also any subclasses of this type. ArrayOfFoo is more specific than Array.
------------------------------------------------------------------------------------------------
> A compliant runtime can receive an array of type "style A".
> In this case the deserializer is easily found because the type is
> "soapenc:Array".
It is not clear to me that a compliant runtime need accept arrays of type
"Style A", but in my opinion, they should. Be liberal in what you
accept...
> A compliant runtime can receive an array of type "style B".
> In this case, the runtime will attempt to find a deserializer of type
> "ns:ArrayOfFoo". In the case of Axis below, "ns:ArrayOfFoo" is not
> registered in the deploy.wsdd for samples.echo.TestClient.
>
> QUESTION 1: So should the behaviour be 1) fail as below or 2) if a
> deserializer is not found
> choose the array deserializer if the soapenc:arrayType attribute is
> present?
>
> My answer: I can make the change to implement (2) if I get some feedback
> from axis-dev.
I'd prefer (3) require that a specific deserializer be deployed for this
type. Modify the provide sample to demonstrate how this is done. That's
what was done in Apache SOAP.
In any case, I clearly don't care for option (1) above.
> QUESTION 2: Since the runtime can easily choose which style to send,
should
> we lean
> towards sending "style A" since it is more likely to be accepted by the
> remote runtime?
>
> My answer: We should send "style A"
I'm OK with that, but over time we may need to revisit this. My concern is
over things like operator overloading - when we get there we may need to
have the more specific information in order to correctly disambiguate the
choices.
- Sam Ruby
