备忘录：SOAP 1.1

 

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

http://www.matrix.org.cn/resource/article/44/44281_SOAP.html

1, SOAP consists of three parts:

• The SOAP envelope (see section 4) construct defines an overall framework for expressing what is in a message; who should deal with it, and whether it is optional or mandatory.
• The SOAP encoding rules (see section 5) defines a serialization mechanism that can be used to exchange instances of application-defined datatypes.
• The SOAP RPC representation (see section 7) defines a convention that can be used to represent remote procedure calls and responses.

2, A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. The namespace identifier for the elements and attributes defined in this section is "http://schemas.xmlsoap.org/soap/envelope/". A SOAP message contains the following:

• The Envelope is the top element of the XML document representing the message.
• The Header is a generic mechanism for adding features to a SOAP message in a decentralized manner without prior agreement between the communicating parties. SOAP defines a few attributes that can be used to indicate who should deal with a feature and whether it is optional or mandatory (see section 4.2)
• The Body is a container for mandatory information intended for the ultimate recipient of the message (see section 4.3). SOAP defines one element for the body, which is the Fault element used for reporting errors.

3, Below is an example of a type with both simple and complex members. It shows two levels of referencing. Note that the "href" attribute of the "Author" accessor element is a reference to the value whose "id" attribute matches. A similar construction appears for the "Address".

<e:Book>
   <title>My Life and Work</title>
   <author href="#Person-1"/>
</e:Book>
<e:Person id="Person-1">
   <name>Henry Ford</name>
   <address href="#Address-2"/>
</e:Person>
<e:Address id="Address-2">
   <email>mailto:[e-mail]</email>
   <web>http://www.henryford.com</web>
</e:Address>

The form above is appropriate when the "Person" value and the "Address" value are multi-reference. If these were instead both single-reference, they SHOULD be embedded, as follows:

<e:Book>
   <title>My Life and Work</title>
   <author>
       <name>Henry Ford</name>
       <address>
          <email>mailto:[e-mail]</email>
          <web>http://www.henryford.com</web>
       </address>
   </author>
</e:Book>

4, HTTP applications MUST use the media type "text/xml" according to RFC 2376 [3] when including SOAP entity bodies in HTTP messages.

5, SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request. (Must be present, but no restrictions are required.)

6, Using SOAP for RPC is orthogonal to the SOAP protocol binding. To make a method call, the following information is needed:

• The URI of the target object
• A method name
• An optional method signature
• The parameters to the method
• Optional header data

SOAP relies on the protocol binding to provide a mechanism for carrying the URI. For example, for HTTP the request URI indicates the resource that the invocation is being made against.

RPC method calls and responses are both carried in the SOAP Body element (see section 4.3) using the following representation:

• A method invocation is modelled as a struct.
• The method invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter. The struct is both named and typed identically to the method name.
• Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter. These appear in the same order as in the method signature.
• A method response is modelled as a struct.
• The method response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter. The first accessor is the return value followed by the parameters in the same order as in the method signature.
• Each parameter accessor has a name corresponding to the name of the parameter and type corresponding to the type of the parameter. The name of the return value accessor is not significant. Likewise, the name of the struct is not significant. However, a convention is to name it after the method name with the string "Response" appended.
• A method fault is encoded using the SOAP Fault element (see section 4.4). If a protocol binding adds additional rules for fault expression, those also MUST be followed.

7, Array: Partially Transmitted Arrays and Sparse Arrays