.NET developers tend not to worry about WSDL too much. We build a WCF service, decorate members as appropriate and, hey presto, WSDL is automatically generated.
However, recently I needed to consume a new web service provided by a third party. I created a spike to test it - adding a service reference and allowing SvcUtil to create proxy classes. All seemed well until the third party complained about the SOAP requests I was sending. This was because they had specified RPC binding in the WSDL rather than Document. The RPC style is older and less interoperable and caused the .NET DataContractSerlializer to send SOAP that, although valid according to the SOAP 1.1 spec, was not handled appropriately by the service.
After the third party changed their WSDL style to Document and confirmed that they could consume the requests I was sending I then discovered that the responses from the web service were not being deserialized in my .NET code.
Visual Studio doesn't offer much in the way of tooling for examining SOAP requests and responses.
Fiddler is an obvious choice - but it's not easy to have it display messages from a .NET WCF app.
You can configure your WCF app to emit a tracelog - but it's not always the most straightforward thing to decipher.
WebServiceStudio is a decent SOAP client which shows Requests / Responses and WSDL - it's useful where the in-built WcfTestClient cannot send complex types.
Lastly SoapUI is a widely used (Java based) tool. the interface isn't the most intuitive but crucially it can validate requests and responses against published WSDL - and it was this tool that allowed me to go back to the provider of the web service and point out that they weren't sending me responses as they should!
I won't mention that the supplier struggling to build the web service was a major communications company and that I effectively did all their system testing for them - nope, won't mention that at all...
However, recently I needed to consume a new web service provided by a third party. I created a spike to test it - adding a service reference and allowing SvcUtil to create proxy classes. All seemed well until the third party complained about the SOAP requests I was sending. This was because they had specified RPC binding in the WSDL rather than Document. The RPC style is older and less interoperable and caused the .NET DataContractSerlializer to send SOAP that, although valid according to the SOAP 1.1 spec, was not handled appropriately by the service.
After the third party changed their WSDL style to Document and confirmed that they could consume the requests I was sending I then discovered that the responses from the web service were not being deserialized in my .NET code.
Visual Studio doesn't offer much in the way of tooling for examining SOAP requests and responses.
Fiddler is an obvious choice - but it's not easy to have it display messages from a .NET WCF app.
You can configure your WCF app to emit a tracelog - but it's not always the most straightforward thing to decipher.
WebServiceStudio is a decent SOAP client which shows Requests / Responses and WSDL - it's useful where the in-built WcfTestClient cannot send complex types.
Lastly SoapUI is a widely used (Java based) tool. the interface isn't the most intuitive but crucially it can validate requests and responses against published WSDL - and it was this tool that allowed me to go back to the provider of the web service and point out that they weren't sending me responses as they should!
I won't mention that the supplier struggling to build the web service was a major communications company and that I effectively did all their system testing for them - nope, won't mention that at all...
Comments
Post a Comment