I'm seeing some unexpected behavior in the return-values when calling the MS
.NET beta 1 endpoint on the XMethods Interop Lab.
The first thing is that the method call (1st sub-element of <Body>) doesn't
have the same namespace qualification that was sent in the request.
Second, and more important, is that the response doesn't seem to specify
types at all, which is particularly troublesome, since I have to jump
through lots of hoops in our implementation in order to round-trip the data,
potentially ignoring spec violations in the process.
Here's a simple example:
Request:
<SOAP-ENV:Envelope...>
<SOAP-ENV:Body>
<m:echoInteger xmlns:m="http://tempuri.org/">
<inputInteger xsi:type="xsd:int">313</inputInteger>
</m:echoInteger>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Response:
<soap:Envelope...>
<soap:Body>
<echoIntegerResult xmlns="http://tempuri.org/">
<result xmlns="">313</result>
</echoIntegerResult>
</soap:Body>
</soap:Envelope>
Here are the problems I had to work through, in order to get the data back
from the response:
1) <result> isn't namespace-qualified. I expected to get back <m:result>...
2) <result> doesn't specify a type at all. This is (so far) the biggest
stumbling block for interop between Frontier and .NET, and I had to work
around a lot of spec-checks on our client-side, in order to get the right
data out of the response.
3) The method-response (1st sub-element of <Body>) is <echoIntegerResult>
and not <echoIntegerResponse>. While I'm aware that this isn't a spec
violation, it does deviate from the other implementations I've been able to
interop with (4s4c, Frontier itself, and SOAP::Lite), and the spec
recommends (in this case) <echoIntegerResponse>, as opposed to
<echoIntegerResult>...
Am I just seeing symptoms that the .NET SOAP implementation is incomplete,
or is there something deeper that I'm missing?
For example, does the spec allow for non-typed return values? My reading of
Section 7 hasn't seemed to give me much clarity in this respect...
Thanks,
-Jake