SOAP

What's wrong with SOAP ?

SOAP is not the only way to build services based software. SOAP has some good things going for it: standardization, service metadata, vendor acceptance and rich tooling. However, it's not without its issues, particularly when building very large systems that require a broad reach to consumers. It is no accident that Yahoo, Google and Amazon have chosen not to use SOAP to expose their programmable interfaces.
Representational State Transfer, or REST, is an architecture that doesn't suffer from the problems that SOAP does (although has issues of its own). You can create and consume REST based services using WCF, ASP.NET and LINQ to XML.

Challenges in the SOAP world ?

SOAP relies on XML messages being sent to a defined endpoint. The service at the endpoint then works out what to do with the message based on the action header that is part of the WS-Addressing standard. When we are talking about services that are part of heterogeneous environments these messages will be sent using HTTP. However, because of the nature of the payload (textual XML) they are always sent using the HTTP verb POST. They could, in theory, use other verbs but why bother, the intent of the message is in the action header not in the way it uses HTTP. HTTP is purely there as a transport, the message is independent of it. Web Service Description Language (WSDL) is an XML dialect used to describe the endpoint including all the operations available there and what messages they require and what messages they may send back. It all seems pretty reasonable, so what are the problems.

The application protocol is the sequence of valid operations that a service can perform. In SOAP, if I want to retrieve an image, I have to pack that binary payload into an XML message by either using base64 encoding or by using the MTOM standard. Then when I receive the message I have to decode it to be able to display it. This seems highly over-complicated if I know I am getting an image that I could simply display.