When doing the SOAP-interop work we did last year, we soapbuilders agreed (at least tacitly) that a SOAP server or client should be as liberal as possible in what it can interpret, and as specific as possible in what it sends.
The more I hear from people working with .NET, the more it seems apparent that it fails to follow the latter guideline — that it seems to rely on the WSDL to determine how to encode and decode SOAP messages, and that little room is left for variation in the message encoding. This, at the expense of interoperability with software that doesn’t (or can’t) support WSDL at the same level that .NET does.
Fundamentally, this is a problem with the SOAP specification itself: It’s too ambiguous. That’s why people want WSDL — they need more specificity for their SOAP messages.
More specificity in the SOAP protocol itself would have made it much easier to support in a wide variety of programming environments, without having to rely on WSDL.
WSDL, while it attempts to declare the specific message format, just hasn’t been up to the task, because the nature of dynamically-typed programming environments makes WSDL difficult, if not impossible, to support in those environments.