UserPreferences

SoapInOnePointAfter


The argument for SOAP

The benefits of SOAP being proposed so far include:

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?

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 benefit of OrthogonalExtensibility is that requestors or providers can add "out of band" information that won't be "stored" with an entry, for example.

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 [WWW]suggests a solution and SamRuby [WWW]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

CategoryArchitecture, CategoryApi