SOAP 要点总结

1.The Basic Structure of SOAP

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- Header blocks go here -->
  </soap:Header>
  <soap:Body>
    <!-- Application data goes here -->
  </soap:Body>
</soap:Envelope>

 2.SOAP Namespaces

To avoid name collisions each of these elements should be identified by a unique namespace.


3.SOAP Headers

The SOAP specification defines rules by which header blocks must be processed in the message path. The message path is simply the route that a SOAP message takes from the initial sender to the ultimate receiver. It includes processing by any intermediaries. The SOAP rules specify which nodes must process particular header blocks and what should be done with header blocks after they've been processed.

The actor attribute to identify a function to be performed by a particular node.

The mustUnderstand attribute equal to "1", it's called a mandatory header block. SOAP nodes must be able to process any header block that is marked as mandatory if they play the role specified by the actor attribute of the header block.


4.The SOAP Body

The Body element contains either the application-specific data or a fault message.


5.SOAP Messaging Modes

A messaging mode is defined by its messaging style (RPC or Document) and its encoding style(Literal or Encoded).

The term "Literal" means that the XML document fragment can be validated against its XML schema

Although SOAP supports four modes of messaging (RPC/Literal, Document/ Literal, RPC/Encoded, and Document/Encoded) the BP permits the use of RPC/ Literal or Document/Literal only.

5.1 Document/Literal

In the Document/Literal mode of messaging, a SOAP Body element contains an XML document fragment, a well-formed XML element that contains arbitrary application data (text and other elements) that belongs to an XML schema and namespace separate from the SOAP message's.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:mi="http://www.Monson-Haefel.com/jwsbook/message-id"
 xmlns:proc="http://www.Monson-Haefel.com/jwsbook/processed-by">
  <soap:Header>
    <!-- Header blocks go here -->
  </soap:Header>
  <soap:Body>
    <po:purchaseOrder orderDate="2003-09-22"
     xmlns:po="http://www.Monson-Haefel.com/jwsbook/PO">

      <po:accountName>Amazon.com</po:accountName>
      <po:accountNumber>923</po:accountNumber>
      ...
      <po:book>
        <po:title>J2EE Web Services</po:title>
        <po:quantity>300</po:quantity>
        <po:wholesale-price>24.99</po:wholesale-price>
      </po:book>
    </po:purchaseOrder>
  </soap:Body>
</soap:Envelope>


5.2 RPC/Literal 
mode of messaging enables SOAP messages to model calls to procedures or 
method calls with parameters and return values. In RPC/Literal messaging, the 
contents of the Body are always formatted as a struct. An RPC request message 
contains the method name and the input parameters of the call. 
An RPC response message contains the return value and any output parameters (or 
a fault). 

An RPC/Literal SOAP Request Message

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote">
   <soap:Body>
      <mh:getBookPrice>
          <isbn>0321146182</isbn>
      </mh:getBookPrice>
   </soap:Body>
</soap:Envelope>

An RPC/Literal SOAP Response Message

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote" >
   <soap:Body>
      <mh:getBookPriceResponse>
          <result>24.99</result>
      </mh:getBookPriceResponse>
   </soap:Body>
</soap:Envelope>


6.SOAP Faults

SOAP fault messages are the mechanism by which SOAP applications report errors "upstream," to nodes earlier in the message path. It's the mission of this section to provide a full and detailed explanation of SOAP faults so that you can handle them appropriately in your own Web services.


The faultcode Element

Client:The Client fault code signifies that the node that sent the SOAP 
message caused the error.

Server:The Server fault code indicates that the node that received the SOAP 
message malfunctioned or was otherwise unable to process the SOAP message. 

VersionMismatch:A receiving node generates a VersionMismatch fault when it doesn't 
recognize the namespace of a SOAP message's Envelope element

MustUnderstand:When a node receives a SOAP message, it must examine the Header element 
to determine which header blocks, if any, are targeted at that node. If a header 
block is targeted at the current node (via the actor attribute) and 
sets the mustUnderstand attribute equal to "1", then the node 
is required to know how to process the header block. If the node doesn't 
recognize the header block, it must generate a fault with the 
MustUnderstand code.

The faultactor element indicates which node encountered the error and
generated the fault (the faulting node).


The faultstring element is mandatory. It should provide a human-readable description of the fault. Although the faultstring element is required, the text used to describe the fault is not standardized.

The detail element of a fault message must be included if the fault was caused by the contents of the Body element, but it must not be included if the error occurred while processing a header block.

7.SOAP over HTTP

7.1 Transmitting SOAP with HTTP POST Messages

A SOAP Request over HTTP

POST /jwsbook/BookQuote HTTP/1.1
Host: www.Monson-Haefel.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 295
SOAPAction=""

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote">
   <soap:Body>
      <mh:getBookPrice>
          <isbn>0321146182</isbn>
      </mh:getBookPrice>
   </soap:Body>
</soap:Envelope>

The HTTP POST message must contain a SOAPAction header field, but the value of this header field is not specified

A SOAP Reply over HTTP

HTTP/1.1 200 OK
Content-Type: text/xml; charset='utf-8'
Content-Length: 311

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote" >
   <soap:Body>
      <mh:getBookPriceResponse>
          <result>24.99</result>
      </mh:getBookPriceResponse>
   </soap:Body>
</soap:Envelope>

The reply to the SOAP message contains no SOAPAction header.


7.2 HTTP Response Codes

Success Codes

The 200-level HTTP success codes are used to indicate that a SOAP request was received or successfully processed. The 200 OK and 202 Accepted HTTP success codes are used in Web services.

200 OK When a SOAP operation generates a response SOAP message, the HTTP response code for successful processing is 200 OK. This response code indicates that the reply message is not a fault, that it does contain a normal SOAP response message.

202 Accepted This response code means that the request was processed successfully but that there is no SOAP response data. This type of SOAP operation is similar to a Java method that has a return type of void.

Error Codes

In general, HTTP uses the 400-level response codes to indicate that the client made some kind of error when transmitting the message.

404 Resource Not Found error when using a Web browser. The 404 error code signifies that the client attempted to access a Web page or some other resource that doesn't exist.

Web services uses a specific set of 400-level codes when the error is related to the contents of the SOAP message itself, rather than the HTTP request. HTTP also uses the 500-level response codes to indicate that the server suffered some type of failure that is not the client's fault.

400 Bad Request This error code is used to indicate that either the HTTP request or the XML in the SOAP message was not well formed.

405 Method Not Allowed If a Web service receives a SOAP message via any HTTP method other than HTTP POST, the service should return a 405 Method Not Allowed error to the sender.

415 Unsupported Media Type HTTP POST messages must include a Content-Type header with a value of text/xml. If it's any other value, the server must return a 415 Unsupported Media Type error.

500 Internal Server Error This code must be used when the response message in a Request/Response MEP is a SOAP fault.