The purpose of this document is to show by a set of examples of how the in-scope XP requirements map to SOAP/1.1. In particular, the examples focus on sections related to the sections "Data Encapsulation and Evolvability", "Intermediaries", "Data Representation", "Protocol Bindings", and "Convention for RPC"
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> ... </S:Header> <S:Body> ... </S:Body> </S:Envelope>
SOAP has a processing model that is defined in the SOAP/1.1 spec And it can generate a fault:
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/'> <S:Body> <S:Fault> <faultcode>S:Server</faultcode> <faultstring>S:Server</faultstring> <detail> <e:mydetails xmlns:e="http://detail"> cool error</e:mydetails> </detail> </S:Fault> </S:Body> </S:Envelope>
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/'> <S:Header> <he:headerentry xmlns:he="http://header-entry-ns"/> </S:Header> <S:Body> <b:bodyentry xmlns:b="http://body-entry-ns"/> </S:Body> </S:Envelope>And it can refer to data outside the envelope:
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/' S:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <S:Header> <he:headerentry xmlns:he="http://header-entry-ns"> <he:data href="http://www.w3.org"/> </he:headerentry> </S:Header> <S:Body> <b:bodyentry xmlns:b="http://body-entry-ns"> <b:data href="cid:1234frystyk@microsoft.com"/> </b:bodyentry> </S:Body> </S:Envelope>It can specify mandatory vs. optional using the mustUnderstand attribute:
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/' S:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <S:Header> <he:headerentry xmlns:he="http://header-entry-ns" S:mustUndestand="1"> <he:data href="http://www.w3.org"/> </he:headerentry> </S:Header> <S:Body> <b:bodyentry xmlns:b="http://body-entry-ns"> <b:data href="cid:1234frystyk@microsoft.com"/> </b:bodyentry> </S:Body> </S:Envelope>And it can indicate the intended recipient using the actor attribute:
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/' S:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <S:Header> <he:headerentry xmlns:he="http://header-entry-ns" S:actor="http://schemas.xmlsoap.org/soap/actor/next"> <he:data href="http://www.w3.org"/> </he:headerentry> </S:Header> <S:Body> <b:bodyentry xmlns:b="http://body-entry-ns"> <b:data href="cid:1234frystyk@microsoft.com"/> </b:bodyentry> </S:Body> </S:Envelope>
It identifies the envelope using XML NS
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> ... </S:Header> <S:Body> ... </S:Body> </S:Envelope>
and it generates a fault if this namespace identifier is not used.
HTTP which defines proxies, tunnels, and gateways, is a supported protocol binding.
POST http://www.my.com/some/endpoint HTTP/1.1 Host: www.my.com Content-Type: text/xml Content-Length: nnnn <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> ... </S:Header> <S:Body> ... </S:Body> </S:Envelope>And it defines processing intermediaries:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" S:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <S:Header> <a:authentication xmlns:a=... actor="intermediary a"> ... </a:authentication> <s:security xmlns:s=...actor="intermediary b"> ... </s:security> <t:transactions xmlns:t=... actor="intermediary c"> ... </t:transactions> <p:payment xmlns:p=... actor="destination"> ... </p:payment> </S:Header> <S:Body> <m:mybody> ... </m:mybody> </S:Body> </S:Envelope>Intermediaries can report faults using the faultActor element:
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/'> <S:Body> <S:Fault> <faultactor>http://www.soap.com/endpoint</faultactor> <faultcode>S:Server</faultcode> <faultstring>S:Server</faultstring> <detail> <e:mydetails xmlns:e="http://detail"> cool error</e:mydetails> </detail> </S:Fault> </S:Body> </S:Envelope>
SOAP provides a header/body separation which can be used by intermediaries to optimize processing as they know that all intermediary processing is in headers
The SOAP encoding model is orthogonal from the envelope design. In fact, many encodings are possible using the encodingStyle attribute which is part of the envelope schema.
<S:Envelope xmlns:S='http://schemas.xmlsoap.org/soap/envelope/' S:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <S:Header> <he:headerentry xmlns:he="http://header-entry-ns"> <he:data href="http://www.w3.org"/> </he:headerentry> </S:Header> <S:Body> <b:bodyentry xmlns:b="http://body-entry-ns"> <b:data href="cid:1234frystyk@microsoft.com"/> </b:bodyentry> </S:Body> </S:Envelope>
The SOAP encoding model is based on XML schema but in addition it defines arrays (which can nest) and links (both requirements for XP). These can be used to represent graphs - presentation from WWW9 talks about this. There are some examples illustrating the differences between RDF and SOAP
SOAP defines a protocol binding mechanism that allows for a variety of bindings including but not limited to:
The reason for the protocol binding is exactly that it should be possible to hook in different protocol bindings
SOAP provides a convention for representing RPC calls and responses