Mindreef - Debugging Interop Problems

Just because a Web service client and server both talk SOAP doesn't guarantee interoperability.

At Mindreef, we work with many different SOAP implementations. That's why we made sure SOAPscope™ is toolkit-independent. Some of us eschew toolkits, and code our own SOAP. Some prefer Java-based tools, and others use Microsoft .NET. Our student intern, Kevin, insists that Perl and SOAP::Lite are the only way to go. Unfortunately, mixing toolkits doesn't always work out the way you planned.

The Problem

Kevin recently ran some tests against one of our QA test servers -- a simple Web service that converts temperatures from Fahrenheit to Celsius. He whipped up a test client in Perl to invoke the service, which had been coded in C# with Microsoft ASP.NET.

Our QA manager ran her test client, and was pleased to respond, "Nope. It works for me."

Mindreef SOAPscope automatically logged both messages, so we fired up the message viewer for a first-hand lesson in interoperability.

What SOAPscope Saw

At first glance, Kevin was correct. SOAPscope Pseudocode View™ showed that the request sent 70, but -17 came back - certainly not the correct temperature conversion.

SOAPscope's unique "Debug Annotations" provided the first clue to what went wrong. Annotations allow the server developer to send debug information, along with the message response, to be logged in SOAPscope. In this case, the annotation provided the input value received after XML deserialization, along with the calculation result before serialization.

Here's why Kevin was receiving -17 as a result: although 70 was sent on the wire, the service actually received 0!

Debug, Understand, and Resend

Next we decided to compare the problematic and successful requests. Switching to SOAPscope XML View allowed us to debug the data.

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <ConvertTemperature xmlns="">
         <parameters>70</parameters>
      </ConvertTemperature>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body>
      <ConvertTemperature xmlns="http://Walkthrough/XmlWebServices/">
         <dFahrenheit>75</dFahrenheit>
      </ConvertTemperature>
   </soap:Body>
</soap:Envelope>

The first difference we noticed is that the SOAP::Lite request specifies an encodingStyle attribute in the SOAP envelope containing the encoding namespace. This indicates that the SOAP::Lite message is using an encoded style of invocation.

The next significant difference is within the Body of the request. SOAP::Lite uses a blank namespace for children of ConvertTemperature and wraps the input data in a element. But the ASP.NET client uses a specific namespace for and wraps the data in a element.

It looks like our SOAP::Lite client was sending the message in the wrong format. Kevin did two things to confirm this diagnosis. First, he used SOAPscope WSDL View to examine the service's WSDL. It clearly indicated a Document/Literal encoding. As a final confirmation, Kevin used SOAPscope's Resend feature. Within SOAPscope, he modified the message to Document/Literal format and resent it. Success!

Upon further investigation we learned that although our .NET service is defined as Document/Literal, SOAP:Lite by default does an RPC/Encoded invocation. ASP.NET did not reject the invalid request, but instead called our service implementation with an invalid parameter (0 instead of 70 in our example).

What Next?

Kevin found a way to make his SOAP::Lite client talk Document/Literal. And we found some great new features for the next release of SOAPscope.

Update: March 31, 2004