The argument for SOAP
The benefits of SOAP being proposed so far include:
SOAP envelopes provide OrthogonalExtensibility, particularly
SOAP envelopes may contain mustUnderstand attributes "to indicate whether a header entry is mandatory or optional for the recipient to process."
WSDL-enabled requestors or providers can transparently use SOAP.
See also SoapProfile.
Is it true also that WSDL-enabled requestors or providers can also transparently use XML web services that are not based on the SOAP 1.2 binding?
SamRuby describes a use-case for mustUnderstand in Unification: REST, SOAP, RSS, Blogger and further in RFP: Preview API.
The principal argument for "why not SOAP?" is that for simple requestors and providers, the SOAP envelope is "just template text that can be sent or received by any XML-aware software."
The counter-argument is that, if a vast majority of toolkits will be written thinking that the SOAP envelope is just template text, then requestors and providers will tend to silently accept SOAP headers with mustUnderstand attributes they don't recognize.
The benefit of OrthogonalExtensibility is that requestors or providers can add "out of band" information that won't be "stored" with an entry, for example.
XML alone also provides for a significant amount of similar OrthogonalExtensibility by allowing one to add the information in one's own namespace, and delete it as seen fit.
Other systems that aren't the owner of the namespace would not know to delete it.
SOAP after 1.0
Subtitle: SOAP optional in 1.0 for anyone that needs it.
The principle benefit of ubiquitous SOAP usage (that is, outside of favoring WSDL-enabled software) is the use of OrthogonalExtensibility, with mustUnderstand in particular. Given the proposed solution, "include SOAP envelopes in nee Echo 1.0", most requestors and providers are being recommended to ignore the SOAP envelopes thus negating the principle benefit.
JoeGregorio suggests a solution and SamRuby expands: an optional SOAP envelope.
If the usage of SOAP is optional, if requestors decide whether to use SOAP envelopes and providers respond in kind, then the principle of OrthogonalExtensibility can be implemented successfully today.
Requestors and providers can implement HTTP+XML requests that do not include SOAP envelopes. By definition, a request without a SOAP envelope states the requestor will not understand a SOAP response. A request with a SOAP envelope to a provider expecting only an Entry or Feed will generate an HTTP 5xx error on the unrecognized root element.
WSDL can distinguish between the two and make it known which type of web service one can direct requests to.
Original author: KenMacLeod