SOAP Transport Protocol

1. HTTP transport protocol

Hypertext Transfer Protocol (HyperText Transfer Protocol, abbreviation: HTTP), which is based on the request-response mode protocol, the client sends a request, the server gives a response and returns the request content. The method is as follows. The HTTP transport protocol commonly used is the GET and POST methods, and the following SOAP protocol is also commonly used in the GET and POST methods.

method	meaning
GET	Issues a "show" request to the specified resource. Using the GET method should only be used to read data, and should not be used for "side-effect" operations, such as in Web Applications. One of the reasons is that GET may be randomly accessed by web spiders, etc.
HEAD	Like the GET method, it sends a request to the server for a specified resource. It's just that the server will not return the text portion of the resource. Its advantage is that using this method, you can get the "information about the resource" (meta information or metadata) without having to transmit all the content
POST	Submit data to the specified resource and request the server for processing (such as submitting a form or uploading a file). Data is included in the request body. This request may create a new resource or modify an existing resource, or both
PUT	Upload its latest content to the specified resource location
DELETE	Request the server to delete the resource identified by the Request-URI
TRACE	Echo the request received by the server, mainly for testing or diagnosis
OPTIONS	This method causes the server to return all HTTP request methods supported by this resource. Use '*' to replace the resource name, and send an OPTIONS request to the web server to test whether the server function is working normally
CONNECT	Reserved in the HTTP/1.1 protocol for proxy servers that can change the connection to a pipeline. Typically used for connections to SSL-encrypted servers (via non-encrypted HTTP proxy servers)

======================================================================

2. SOAP transport protocol

SOAP (Simple Object Accrss Protocol, Simple Object Access Protocol) is a simple XML-based protocol. SOAP is a communication protocol for Web Services. It is based on XML language and XSD standards. It defines a set of encoding rules. How to define encoding rules Representing data as messages, and how to transmit SOAP messages over the HTTP protocol, consists of four parts:

(1) SOAP envelope (Envelope): defines a framework that describes what is in the message, including the content of the message, sender, receiver, processor, and how to process the message.

(2) SOAP Encoding Rules: Defines a serialization mechanism for exchanging instances of data types defined by applications. (3) SOAP RPC representation: Defines the protocol used to represent remote procedure calls and responses.

(4) SOAP Binding: Defines a convention that uses the underlying transport protocol to complete the exchange of SOAP envelopes between nodes.

After soap serializes the information in XML, it is packaged and transmitted in the form of http protocol, and the transmission method is still tcp or udp. It is easy to understand as a metaphor. Both tcp and udp are roads. For now, consider tcp as a general road, udp highway, soap and http are both cars, then soap and http can run on tcp and udp. It is said that soap can be transmitted through http, which actually means that soap is a car, and http is a truck loaded with cars. The information of soap is loaded into http, and then transported. Of course, the road to take is tcp or udp. It is not accurate to say that soap can be transmitted through the http protocol. The more accurate statement is: soap information can be packaged through the http protocol and then transmitted through tcp or udp.

//SOPA协议的基本结构
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
  ...
  ...
</soap:Header>
 
<soap:Body>
  ...
  ...
  <soap:Fault>
    ...
    ...
  </soap:Fault>
</soap:Body>
 
</soap:Envelope>

========================================================================

3. SOAP transport protocol
1. SOAP Envelope

SOAP Envelope is the root element of the XML document representing the message. It defines the framework for how messages are processed and by whom. XML content starts with SOAP Envelope. In SOAP, the XML namespace is used to distinguish SOAP identifiers from application-specific identifiers, and to limit the scope of elements of SOAP messages to a specific field. If a different namespace is used, the application will error out and discard this message. All elements in a SOAP message must be qualified by the first namespace.

SOAP 1.1规范如下：

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"

</soap-env:Envelope >

SOAP 1.2规范如下：

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

</soap:Envelope>

2. encodingStyle attribute

 The encodingStyle attribute of SOAP is used to define the data type used in the document. The encodingStyle attribute can appear in any SOAP element and will be applied to the content of the element and all child elements of the element. SOAP messages have no default encoding.

3. SOAP Header element

 The SOAP Header element should be the first direct child element of the SOAP Envelope and must use a valid namespace. Header can also contain 0 or more optional sub-elements. Sub-elements are called Header items. All Header items must be fully modified, that is, must consist of a namespace URI and a local name. No namespace is not allowed. The modified Header item exists.

The Header element is used to transport additional information along with the message, such as authentication or transaction information. The Header element can also contain certain attributes. SOAP defines three attributes in the default namespace: actor, mustUnderstand and encodingStyle. These attributes, defined in the SOAP header, inform the container how to process the SOAP message.

<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
xmlns:m="http://www.w3school.com.cn/transaction/"
soap:mustUnderstand="1">234</m:Trans>
</soap:Header>
 
...
</soap:Envelope>

3.1 actor attributes

SOAP messages can travel from a sender to a receiver by passing through different endpoints along the message path. Not all parts of the SOAP message are intended to be transmitted to the final endpoint of the SOAP message, and may also be transmitted to a specific endpoint. SOAP's actor attribute can be used to address the Header element to a specific endpoint.

//语法规则：soap:actor="URI"
//下面代码中有一个"Trans"元素的头部，值是234，此元素的"mustUnderstand"属性的值是"1"。
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
xmlns:m="http://www.w3school.com.cn/transaction/"
soap:actor="http://www.w3school.com.cn/appml/">
234
</m:Trans>
</soap:Header>
 
...
...
 
</soap:Envelope>

3.2 mustUnderstand attribute

SOAP's mustUnderstand attribute can be used to identify whether a header item is mandatory or optional for the recipient to process it. If "mustUnderstand="1" is added to a sub-element of the Header element, it indicates that the recipient processing this header must recognize this element. If the recipient cannot recognize this element, it must invalidated.

//语法：soap:mustUnderstand="0|1"
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
xmlns:m="http://www.w3school.com.cn/transaction/"
soap:mustUnderstand="1">
234
</m:Trans>
</soap:Header>
 
...
...
 
</soap:Envelope>

3.3 encodingStyle attribute

The encodingStyle attribute of SOAP is the same as in the Envelope element.

=========================================================================

4. SOAP Body element

  The Body block of a SOAP message can contain any of the following elements: RPC methods and their parameters; target application (message receiver) specific data; SOAP Fault reporting fault and status messages. All direct child elements of the Body element are called Body items, and Body items must be decorated by a namespace. The required SOAP Body element may contain the actual SOAP message intended to be delivered to the message's ultimate endpoint.

Direct child elements of the SOAP Body element may be namespace-qualified. SOAP defines an element inside the Body element in the default namespace ("http://www.w3.org/2001/12/soap-envelope"). That is, the Fault element of SOAP, which is used to indicate the error message.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Body>
   <m:GetPriceResponse xmlns:m="http://www.w3school.com.cn/prices">
      <m:Price>1.90</m:Price>
   </m:GetPriceResponse>
</soap:Body>
 
</soap:Envelope>

=========================================================================

5. SOAP Fault element

The SOAP Fault element is used to transmit error and status information in SOAP messages. If the SOAP message needs to include the SOAP Fault element, the SOAP Fault element must appear as a Body item, and it must appear at most once. SOAP Fault includes the following sub-elements: faultcode, faultstring, faultactor, detail.

child element	describe
<faultcode>	codes for fault identification
<faultstring>	A human-readable description of the fault
<faultactor>	Information about who caused the failure
<detail>	Persist application-specific error messages involving the Body element

The SOAP Fault element has the following sub-elements. The faultcode value defined below must be used in the faultcode element when describing the fault:

VersionMismatch	An invalid namespace was found for the SOAP Envelope element
MustUnderstand	A direct child element of the Header element (with a mustUnderstand attribute set to "1") could not be understood.
Client	The message was improperly composed, or contained incorrect information.
Server	The server has a problem and cannot proceed further.

=========================================================================

6. SOAP attachments

According to the SOAP1.1 specification, a SOAP message can contain a main SOAP envelope in XML format and a SOAP attachment in any data format such as ASCII or binary. If the SOAP message contains attachments, the SOAP message will be a MIME-encoded message containing the SOAP content and one or more attachments of other types. So SOAP messages are actually divided into the following two types:

    A. A message containing only XML content

    B. A MIME-encoded message containing the initial XML payload and any number of attachments. Attachments can be any other type of data.

=========================================================================

7. SOAP message binding

The payload of a web service is usually wrapped in a SOAP message, and the SOAP message structure is determined by the SOAP binding definition in the WSDL document. Different calling methods and encoding methods can be combined to produce multiple binding styles, and the application scenarios and corresponding SOAP message structures of each style are different. Without proper construction of the SOAP message, the service's payload cannot be exchanged correctly.

 SOAP Body provides a mechanism for message exchange, which is the actual load of SOAP messages and can contain any content. The SOAP message body (SOAP Body) encapsulates the operation by binding the service call method (RPC or Document), and serializes the parameters by binding the encoding method (Encoded or Literal). The binding style of the SOAP message is jointly set by the three attributes of style, use and encodingStyle. The style attribute specifies the calling method of the service, whether to use the RPC method or the Document method; the use attribute specifies the encoding method of the message, whether to use the Encoded method or the Literal method; and the encodingStyle attribute specifies specific encoding rules, such as specifying SOAP encoding rules, XML Schema Coding rules, etc., usually use XML Schema.

7.1 style attribute

        The style attribute describes how the service is invoked. The value is "rpc" or "document", and the default value is "document". Applies to child elements (and possibly grandchildren) of the SOAP Body element. This option is specified as a soap:binding element in the WSDL document (usually) or as a style attribute of soap:operation.

A.RPC: Using the client/server method (request/response), the request is sent to the server, and the server returns the result after executing the method. The advantage is that it is cross-language and cross-platform. The disadvantage is that it cannot be debugged at compile time and can only be checked at runtime.

SOAP messages are essentially a one-way transfer from sender to receiver, but SOAP is often combined to implement request/response mechanisms. For RPC to use SOAP, several rules must be followed. First, request and response messages must be encoded into struct types. Second, for each input parameter of an operation, there must be an element (or member of the input structure) with the same name as a parameter. Finally, for each output parameter, there must be an element (or member of the output structure) with a matching name.

style="rpc" indicates compliance with the SOAP standard, and encapsulates the request and return operations of the RPC call in the SOAP Body. The constraint on this type of message is that the name of the operation must be used as the name of the root element that encapsulates the payload of the request and response messages for the operation. For SOAP request messages, the name of the request operation is based on the wsdl:operation element in the WSDL document, which corresponds to the Web service method. For SOAP response messages, the name of the response operation is the name of the request operation appended with "Response". Each child element in the operation element represents a parameter, named according to the wsdl:part element in the WSDL document. The format of an RPC request/response message (namespace qualification omitted) is as follows:

RPC请求消息格式：

<SOAP信封>

<SOAP头部>

     ……

</SOAP头部>

    <SOAP消息体>

<请求操作名称>

          <参数名1>值</参数名1>

          <参数名2>值</参数名2>

             ......

        </请求操作名称>

</SOAP消息体>

</SOAP信封>

RPC响应消息格式：

<SOAP信封>

<SOAP头部>

  ……

</SOAP头部>

    <SOAP消息体>

       <响应操作名称>

          <参数名1>值</参数名1>

          <参数名2>值</参数名2>

              ......

        </响应操作名称>

    </SOAP消息体>

</SOAP信封>

B. Compared with RPC, the Document method does not map the remote method in the XML file, but a complete self-contained business document. When the server receives this document, it first performs preprocessing (such as vocabulary translation and mapping), and then constructs a return message. In the process of constructing the return message, it is often no longer a simple method call, but multiple objects cooperate to complete the processing of a transaction, and then return the result.

 The document is used to construct the message, and the content in the SOAP Body element is completely defined by the XML Schema in WSDL, so the XML Schema can be used to verify the content in the SOAP Body element. Sub-elements of the SOAP Body are specified as message parts in the wsdl:part element defined in the WSDL document, which points to the XML Schema element declaration. Usually a wsdl:message does not contain multiple wsdl:part elements, so the SOAP Body content is a real XML document, although WSDL itself does not prohibit the inclusion of multiple wsdl:part elements. The format of a Document request/response message (namespace qualification omitted) is as follows:

Document请求消息格式：

<SOAP信封>

<SOAP头部>

     ……

</SOAP头部>

    <SOAP消息体>

        <输入消息>

   ….

 </输入消息>

….

</SOAP消息体>

</SOAP信封>

Document响应消息格式：

<SOAP信封>

<SOAP头部>

 ……

</SOAP头部>

    <SOAP消息体>

         <输出消息>

   ….

  </输出消息>

….

    </SOAP消息体>

</SOAP信封>

7.2 use attribute

 The use attribute describes how the message is serialized. The value is "encoded" or "literal", and the default value is "literal". If use="encoded", set the value of the encodingStyle attribute to specify the encoding rules. If use="literal", you don't need to set the value of the encodingStyle attribute, usually the default XML Schema is used. Applies to Web service method parameters (or return values) that appear at the next level. This option is specified as the use attribute of the soap:body, soap:header, soap:fault, and soap:headerfault elements in the WSDL document.

A. Encoded, SOAP encoding uses a subset of XML Schema to bind between XML documents and the data they represent. SOAP encoding also uses the href attribute to reference elements that occur multiple times in the document. The complete difference between SOAP encoding and XML Schema encoding is arrays. Section 5.4.2 of the SOAP specification specifies a special mechanism to represent programming language arrays in XML, using a special SOAP-ENC:Array type. In XML Schema, an array is represented by setting the minOccurs and maxOccurs attribute values ​​of the element. For example, the definition of an integer array using these two encoding methods is as follows:

<complexType name="ArrayOfInt"> 
  <complexContent> 
     <restriction base="SOAP-ENC:Array"> 
<sequence>
    <element name=”item” type=”xsd:int” minOccurs=”0” maxOccurs=”unbounded”/>
</sequence>
        <attribute ref=" SOAP-ENC:arrayType"  wsdl:arrayType="xsd:ArrayOfInt[]"/> 
      </restriction> 
  </complexContent> 
</complexType>  

=================================================

//XML Schema定义数组
<complexType name="ArrayOfInt">  
<sequence>
 <element name=”item” type=”xsd:int” minOccurs=”0” maxOccurs=”unbounded”/>
</sequence>
  </complexContent> 
</complexType>

B. Compared with Encoded, Literal uses XML Schema encoding instead of SOAP encoding; Literal encoding does not require data type attributes. The data is formatted verbatim according to the XML Schema definition specified in the WSDL document or imported into the WSDL document. The message format of the add method encoded in Literal mode is as follows:

<op:add xmlns:op=”http://act.buaa.edu.cn/add”>
<a>
<item>45</item>
<item>36</item>
</a>
 <b>
<item>235</item>
<item>67</item>
</b>
</op:bdd>

7.3 encodingStyle attribute

        The encodingStyle attribute in the WSDL specification is defined the same as the encodingStyle attribute in the SOAP specification. The value of the encodingStyle attribute is a list of URIs, separated by a single space, each URI represents a message encoding rule, they are sorted from strong to weak encoding constraints. The encodingStyle attribute is used to specify the encoding rules of the SOAP message, that is, the serialization format and type system. If use="encoded" and the value of the encodingStyle attribute is "http://schemas.xmlsoap.org/soap/encoding/", it means that the encoding in section 5 of the SOAP specification is used, which defines the programming language The basic mechanism by which types are mapped to XML. If use="literal" then use the externally provided type system, and you can also specify the Schema through the encodingStyle attribute, but usually XML Schema is used to encode SOAP messages.

    The reason for this is because the SOAP specification was written before the adoption of the XML Schema specification. Therefore, the original SOAP specification had to provide a way to indicate encoding type information. However, since the adoption of XML Schema, most languages ​​use their own mappings (or serialization rules) from XML Schema to programming language types, making SOAP encoding obsolete. Therefore, it is recommended not to use SOAP encoding, but to use Literal encoding, where the mapping is specified externally by an XML Schema document (usually in the form of a WSDL document).

========================================================================

8. SOAP message construction

The style and use attributes both have two values. Through different combinations of them, four binding styles can be generated, namely rpc-literal, rpc-encoded, document-literal and document-encoded. In order to enable the Document binding style to support the call of the RPC binding style, a wrapping (Wrapped) style is added, which only restricts the use of the Document style. In this way, two more binding styles are added, document-literal-wrapped and document-encoded-wrapped, and there are 6 binding styles in total. The following uses an additive service as an example to illustrate the SOAP message structure under different binding styles. The definition of the service is as follows:

It can be seen from the definition of the service that the operation name of the input operation is add, and there are two input parameters of type a and b. According to the WSDL specification, the operation name of the return operation should be addResponse, and there is an output parameter of integer type, which is assumed to be named return.

Serialization of operations requires namespace qualification. If it is an RPC call, the namespace is the namespace attribute value of soap:body; if it is a Document call, the namespace is the targetNamespace attribute value of the Schema referenced by the input message. Whether the serialization of parameters requires namespace qualification depends on the value of the elementFormDefault attribute when the Schema is defined. If the value is "qualified", it means that it needs to be qualified, and the namespace is the value of the targetNamespace attribute of the Schema; if the value is "unqualified", it means that it does not need to be qualified, and the default value is "unqualified". The serialized elements of the operation are sub-elements of the SOAP message body, and the serialized elements of each parameter are sub-elements of the operation element, and the order of arrangement is the same as the definition order of the parameters of the operation.   

    A. If use= "encoded", the value of encodingStyle is "http://schemas.xmlsoap.org/soap/encoding/", if use= "literal", use "http://www.w3.org/2001 /XMLSchema" encoding.

    B. If style=”rpc”, the type reference of the wsdl:part part uses the type attribute, and if style=”document” uses the element attribute.

8.1  rpc-literal binding style

<wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/"
   xmlns:ns="http://act.buaa.edu.cn/add" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://act.buaa.edu.cn/add">
<wsdl:message name=”addRequest”>
 <wsdl:part name=”a” type=”xsd:int”/>
    <wsdl:part name=”b” type=”xsd:int ”/>
</wsdl:message>
<wsdl:message name=”addReponse”>
    <wsdl:part name=”return” type=”xsd:int”/>
</wsdl:message>
<!--Just assume it's rpc-literal. -->
......

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
     <op: add  xmlns:op=“http://act.buaa.edu.cn/add”>
       <a>12</a>
<b>45</b>
     </op: add >
   </env:Body>
</env:Envelope>]

 Advantages: WSDL description and SOAP message basically meet the requirements of being as simple and understandable as possible; the operation name of the service appears in the Body of the SOAP message, so that the receiver can easily send the message to the implementation of the method; there is no type encoding , which improves throughput and reduces processing overhead.

    Disadvantages: In the RPC model, XML is only used to describe the information of the method, and the function of XML cannot be fully utilized to describe and verify a business document; the validity of this message cannot be simply checked using Schema, because only parameters a and b are The content defined in the Schema, and the rest of the env:body content (such as the add element) come from the WSDL definition; the type information of the parameter cannot be obtained directly from the message; the RPC style bundles the mode of the request/response message, making the connection between the service and the client Inter-coupling increases, and once the method changes, the client needs to make corresponding changes; compared with the asynchronous calling method, the service call in the RPC style is usually synchronous.

8.2 rpc-encoded binding style

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
       xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” >
  <env:Body>
     <op: add xmlns:op=“http://act.buaa.edu.cn/add”>
        < a  xsi:type=”xsd:int”>12</a>
<b  xsi:type=”xsd:int”>45</b>
     </op: add >
   </env:Body>
</env:Envelope>

 The only difference from the rpc-literal binding style is that the parameter part of the request message is encoded differently. Each parameter in the message has a type code (such as <a xsi:type="int">12</a>), and the data type of the parameter can be known directly from the message. But these types of messages reduce the throughput and performance of message processing. Especially in the case of big data, the performance overhead is obvious.

 The rpc-encoded binding style is mainly used in cases of overloading, data graphics and polymorphism. WSDL allows overloaded operations, but when the number of parameters is the same, rpc-literal does not support such overloading because the Literal encoding method has no type information and cannot locate the method. The standard way of data graphics is to use the href tag, which is rpc-encoded in style. The SOAP message generated by polymorphism must contain type encoding information, so that the receiving terminal can know which extension of the parent class it is receiving.

8.3  document/literal binding style

<wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/"
xmlns:ns="http://act.buaa.edu.cn/add" targetNamespace=" http://act.buaa.edu.cn/add ">
<wsdl :types>
<xs:schema elementFormDefault="qualified" targetNamespace="http://act.buaa.edu.cn/add" xmlns:xs="http://www.w3.org/2001/XMLSchema" >  
       <xs:element name="a"  type="xs:int " />
       <xs:element name="b"  type="xs:int " />
       <xs:element name="return"  type="xs:int " />
</xs :schema>
</wsdl :types>
<wsdl:message name=”addRequest”>
     <wsdl:part  name=”parameter1” element=”ns:a”/>
<wsdl:part  name=”parameter2” element=”ns:b”/>
</wsdl:message>
<wsdl:message name=”addReponse”>
     <wsdl:part name=”parameter” element=”ns:return”/>
</wsdl:message>
<!--Just assume it's  document-literal. -->
……

================================================================
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:op=“http://act.buaa.edu.cn/add”>
<env:Body>
    <op:a>12</op:a>
<op:b>45</op:b>
</env:Body>
</env:Envelope>

The parameter element of the request message has namespace qualification added, because the input message is defined in the Schema of the WSDL document, and the elementFormDefault="qualified" of the Schema. That is to say, the parameter element must be qualified with the namespace "http://act.buaa.edu.cn/add" of the Schema.

 Advantages: There is no operation and type encoding information, which reduces the data volume of the message and improves the message processing performance; each content in env:Body is defined in the Schema, and any XML checker can be used to check the validity of the message.

 Disadvantages: WSDL documents become more complicated, which is only a very small disadvantage, because WSDL is not intended to be read by humans; the names of service operations are not provided in SOAP messages, and some specific program codes may be used when distributing messages. become complicated, and sometimes impossible. If HTTP is used as the underlying transport protocol, you can use the SOAPAction attribute to bind the name of the operation to solve the problem of message distribution. Although HTTP is used to transmit SOAP messages in most cases, this method binds the underlying transport protocol and limits the use of other transport protocols.

8.4  document /encoded binding style

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance”
       xmlns:op=“http://act.buaa.edu.cn/add”>
   <env:Body>
       <op:a  xsi:type=”xsd:int”>12</op:a>
<op:b  xsi:type=”xsd:int”>45</op:b>
   </env:Body>
</env:Envelope>

 The only difference from the document-literal binding style is that the parameter part of the request message is encoded differently. Type encodings were introduced, reducing the throughput and performance of message processing. This style of binding is not supported by most web service implementation platforms.

8.5   document-literal-wrapped binding style

<wsdl:definitions  xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/"
xmlns:ns="http://act.buaa.edu.cn/add"  targetNamespace=" http://act.buaa.edu.cn/add ">
<wsdl :types>
<xs:schema elementFormDefault="qualified" targetNamespace="http://act.buaa.edu.cn/xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" >  
       <xs:element name="add">
          <xs:complexType>
            <xs:sequence>
               <xs:element name="a"  type="xs:int " />
               <xs:element name="b"  type="xs:int " />
            </xs:sequence>
          </xs:complexType>
       </xs:element>
       <xs:element name="addResponse">
          <xs:complexType>
            <xs:sequence>
               <xs:element name="return"  type="xs:int " />
            </xs:sequence>
         </xs:complexType>
       </xs:element>
</xs :schema>
</wsdl :types>
<wsdl:message name=”addRequest”>
    <wsdl:part  name=”parameter” element=”ns:add”/>
</wsdl:message>
<wsdl:message name=”addReponse”>
    <wsdl:part name=”parameter” element=”ns:addResponse”/>
</wsdl:message>
<!--Just assume it's  document-literal-wrapped. -->
……
=====================================================================
<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
     <op: add  xmlns:op=“http://act.buaa.edu.cn/add”>
       <op:a>12</op:a>
<op:b>45</op:b>
     </op: add >
  </env:Body>
</env:Envelope>

At this time, the name of the first element in the SOAP Body is not the name of the operation, but the name of the element in the Schema. The name of the element in the schema can be the same as the operation name, or it can be different. If taken the same is a clever way to put the operation name into the SOAP message.

  Although this SOAP message looks exactly the same as the rpc-literal's SOAP message (if namespace qualification is not taken into account), there are subtle differences between the two messages. In rpc-literal SOAP messages, the <op:add> root element under <env:Body> is the name of the operation. In document-literal-wrapped SOAP messages, the <op:add> element is the name of an element referenced by a component of a single input message.

 The document-literal-wrapped style stipulates that both the input message and the output message of the Document binding operation have only one wsdl:part part; this part uses the element attribute to refer to an element; the element is a complex type and has no attributes; the name of the element and the operation's The names must be the same.

 Advantages: The packaging behavior absorbs an important advantage of the RPC style, that is, the SOAP message body in the RPC style can be directly named by the service operation name associated with it, and at the same time abandons the shortcomings of the RPC style; it can use the WSDL document type part The Schema document directly verifies the SOAP message body; as long as a clear data structure is defined in the Schema, there is great flexibility in how to construct the SOAP message body; since the business data is self-contained, it is obvious that the document model is more conducive to asynchronous processing.

 Disadvantage: WSDL is more complicated, but this is still a very small disadvantage. This increases the complexity of service calls, especially at the API level. For program developers, writing client code based on wrapped document binding style services may become a very challenging task. There must be a service operation name in the XML wrapper element of the SOAP message body, so the wrapper version does not support overloaded service operations. In fact, there can only be one service operation for a given element name.

8.6  document-encoded-wrapped binding style

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” >
  <env:Body>
     <op: add  xmlns:op=“http://act.buaa.edu.cn/add”>
        <op:a  xsi:type=”xsd:int”>12</op:a>
<op:b  xsi:type=”xsd:int”>45</op:b>
     </op: add >
   </env:Body>
</env:Envelope>

The only difference from the document-literal-wrapped binding style is that the parameter part of the request message is encoded differently. Type encodings were introduced, reducing the throughput and performance of message processing.

========================================================================

9. SOAP  attachments

In practical applications, it is necessary to send SOAP messages together with various attachments (such as images, pictures, xml documents, etc.). Attachment data is usually in a special binary format. The SOAP with Attachments specification specifies referencing MIME parts using the "MIME multipart/related" media type and URI scheme. Not all Web service toolkits provide SOAP attachment support. Microsoft proposes another DIME-based attachment solution

9.1 SOAP message package

The SOAP message package with attachments is as follows. The SOAP message package contains the main SOAP message in XML format and other entities in any data format (such as gif, jpg, xml, etc.) that are not defined in the SOAP envelope but related to the message.

SOAP message packages are constructed using MIME's Multipart/related media types, and each part is embedded within a MIME boundary (defined in the Context-Type header). Each MIME part has header information such as Context-Type, which specifies the type of data embedded in this MIME part), Content Transfer-encoding (specifies the encoding used for this MIME part), Content-ID or Content-Location (as a MIME anywhere in the package that references these identifiers). The root part of the MIME message contains the SOAP envelope, and the Content-Type is set to text/xml.

9.2 SOAP References to Attachments

Both the SOAP header and the body of the SOAP message can refer to other entities in the message packet. According to the SOAP 1.1 encoding rules, SOAP's "href" attribute can be used to refer to any resource. Any resource can be referenced using Content-ID or Content-Location. If Content-ID is used as the identifier, then the schema attribute (such as href) must use the URL schema CID. If Content-Location is used as an identifier, it must be resolved according to the rules specified in the SOAP with Attachments specification, where the resolution is based on one of the following elements:

Absolute URI Reference - The absolute URI is specified in the Content-Location and "href" attributes of the SOAP Envelope. Relative URI reference - a base (base) URI is specified in the Content-Location of the main header of the MIME message, and all relative URLs are referenced using this base URL. Relative URI without a base URI - Content-Location of the main header The base URI is not specified in , but the base URL of the message is used, and all relative URLs are referenced using this base URL.

Usually it is up to the SOAP processor to decide if the URI needs to be parsed. Also, the message package may have attachments that are not referenced by URIs in the SOAP Envelope.

9.3 HTTP Binding

If the HTTP binding is used by SOAP to send attachments, the HTTP header needs to be modified to include the Content-Type information from the SOAP MIME packet header. No other header information from the MIME packet header is included in the HTTP header. Apache ignores header information such as Content-Transfer-Encoding and MIME Version. All MIME parts contain SOAP envelope parts and other attachments that make up the HTTP body. For SMTP bindings, on the other hand, all multipart MIME headers are stored as part of the SMTP header. Thus, SOAP processors and applications should be aware of the incompatibilities of these headers with different kinds of SOAP bindings.

9.4  WSDL support

WSDL supports describing Web services with attachments.

<binding name="DocManagementService_Binding"  ... />
  <operation  name="SubmitArrayOfDocuments">
    <soap:operation soapAction="http://www.DocManagementService.com/SubmitArrayOfData"/>
    <input>
      <mime:multipartRelated>
          <mime:part>
            <soap:body
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    namespace="urn:DocManagement-service"
    parts="SubmitArrayOfDocuments_inType1 SubmitArrayOfDocuments_inType2"
    use="encoded"/>
          </mime:part>
          <mime:part>
            <mime:content part="SubmitArrayOfDocuments_inType3" type="*/*"/>
          </mime:part>
    </mime:multipartRelated>
    </input>
    <output>
      <soap:body
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    namespace="urn:DocManagement-service" 
    use="encoded"/>
    </output>
  </operation>
</binding>

The input and output elements of the binding element are extended and contain MIME:multipart-related with different MIME parts, one for the SOAP body and the other for the attachment. Each MIME part with attachments can also specify its content type.

========================================================================

SOAP protocol example

SOAP 1.2 request and response example. Placeholders shown need to be replaced with actual values.

//SOAP 1.2 请求
POST /WebServices/WeatherWS.asmx HTTP/1.1
Host: ws.webxml.com.cn
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <getWeather xmlns="http://WebXml.com.cn/">
      <theCityCode>string</theCityCode>
      <theUserID>string</theUserID>
    </getWeather>
  </soap12:Body>
</soap12:Envelope>


//SOAP 1.2 响应
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <getWeatherResponse xmlns="http://WebXml.com.cn/">
      <getWeatherResult>
        <string>string</string>
        <string>string</string>
      </getWeatherResult>
    </getWeatherResponse>
  </soap12:Body>
</soap12:Envelope>

 Example HTTP GET request and response. Placeholders shown need to be replaced with actual values.

GET /WebServices/WeatherWS.asmx/getWeather?theCityCode=string&theUserID=string HTTP/1.1
Host: ws.webxml.com.cn
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfString xmlns="http://WebXml.com.cn/">
  <string>string</string>
  <string>string</string>
</ArrayOfString>

 Example HTTP POST request and response. Placeholders shown need to be replaced with actual values.

POST /WebServices/WeatherWS.asmx/getWeather HTTP/1.1
Host: ws.webxml.com.cn
Content-Type: application/x-www-form-urlencoded
Content-Length: length

theCityCode=string&theUserID=string
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfString xmlns="http://WebXml.com.cn/">
  <string>string</string>
  <string>string</string>
</ArrayOfString>

 reference article

​​​​​​SOAP protocol analysis_tuowsh's blog-CSDN blog​​​​​​​​

 WeatherWS Web Service