Search the web
Sign In
New User? Sign Up
soapbuilders
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
MS .NET beta 1 return values   Message List  
Reply | Forward Message #246 of 10820 |
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




Tue Mar 27, 2001 12:13 pm

jake@...
Send Email Send Email

Forward
Message #246 of 10820 |
Expand Messages Author Sort by Date

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...
Jake Savin
jake@...
Send Email
Mar 27, 2001
12:13 pm

Hi, Jake! ... It may not. Nothing is wrong here. ... It may not. This information may be obtained from other sources (as service description or element...
Paul Kulchenko
paulclinger@...
Send Email
Mar 27, 2001
2:40 pm

inline ... data back ... <m:result>... Section 5 states that when doing section 5 encoding you shouldn't namespace qualify child element, but that they are in...
keithba@...
Send Email
Mar 27, 2001
5:56 pm

... Technically it is, but the default namespace that it is in is "". If the xmlns="" was removed then it would be in the same namespace of tempuri. ... Adding...
Oisin Hurley
ohurley@...
Send Email
Mar 28, 2001
5:29 am
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help