Soap using namespace features a special quality of ‘soap-envelope “for the process be extended in the title element to be determined. The most important properties of the mustUnderstand. By default, there is no safe elements in the head element of SOAP message recipients can be ignored if mustUnderstand is properties to “true” (or “1″ that the value will only be recognized in SOAP 1.1). It would be a good example in terms of safety signs that the message sender / applicant is certified. If for any reason the recipient can not be deported elements of the process, the error must be provided to the sender with an error code mustUnderstand.
Since the soap to be used in networks with various agents (soap “node”, as identified functions <node>) designed to also define the role of the special features of intermediate XML should be a specific topic and present element method can be used to indicates that the element should be forwarded to another node if it is not when processed.
The SOAP body contains the “payload” of the message, which is defined by the WSDL’s <Message> part. If there is an error that needs to be transmitted back to the sender, a single <Fault> element is used as a child of the <Body>.
The <Fault> is the standard element for error handling. When present, it is the only child element of the SOAP <Body>. The structure of a fault looks like:
<env:Fault xmlns:m="http://www.example.org/timeouts">
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>m:MessageTimeout</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en">Sender Timeout</env:Text>
</env:Reason>
<env:Detail>
<m:MaxTime>P5M</m:MaxTime>
</env:Detail>
</env:Fault>
Here, only the <Code> and <Reason> child elements are required, and the <Subcode> child of <Code> is also optional. The body of the Code/Value element is a fixed enumeration with the values:
VersionMismatch: this indicates that the node that “threw” the fault found an invalid element in the SOAP envelope, either an incorrect namespace, incorrect local name, or both.MustUnderstand: as discussed above, this code indicates that a header element with the attributemustUnderstand="true"could not be processed by the node throwing the fault. ANotUnderstoodheader block should be provided to detail all of the elements in the original message which were not understood.DataEncodingUnknown: the data encoding specified in the envelope’sencodingSytleattribute is not supported by the node throwing the fault.Sender: This is a “catch-all” code indicating that the message sent was not correctly formed or did not have the appropriate information to succeed.Receiver: Another “catch-all” code indicating that the message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself.
Subcodes, however, are not restricted and are application-defined; these will commonly be defined when the fault code is Sender or Receiver. The <Reason> element is there to provide a human-readable explanation of the fault. The optional <Detail> element is there to provide additional information about the fault, such as (in the example above) the timeout value. <Fault> also has optional children <Node> and <Role>, indicating which node threw the fault and the role that the node was operating in (see role attribute above) respectively.
