Complete SOAP Message Parsing

SOAP messages can be XML files, which must contain SOAP Envelope (encapsulation) and SOAPBody (body), while SOAP Header (Header) is optional.
A soap message contains the following items:
· Envelope is the top-level element of an XML file, representing the file as a SOAP message.
· The Header provides a mechanism to add certain elements (feature) about a SOAP message to a SOAP message without having to establish a contract with the business partner in advance. SOAP defines some attributes used to specify "who" in the Header to process this function, and whether it is optional or mandatory.
· Body is the container for the receiver to receive messages. SOAP defines an element for BoO, that is, the Fault element, to report errors.

(1) SOAP Envelope
The SOAP Envelope message must contain the Envelope element and namespace lattp: // schemas.xmlsoap.org/soap/envelope/. if a SOAP application receives a message, the SOAP Envelope element of the message uses a different namespace than the preceding one, and the application regards it as a version error and ignores the message. If the message is used. H \ 'I' TP request/response communication protocol, the application must respond to a SOAP VersionMismatch error code message (using "http://schemas.xmlsoap.org/soap/envelope/?namespace ).
(2) SOAP Header
A flexible mechanism is provided for communication between groups to expand messages in a decentralized but standard manner without prior agreement. You can add entries in SOAP. Header to achieve this expansion, such as authentication, transaction management, and payment. The Header element is the first direct child element of the SOAP encapsulation element. All direct child elements of the Header element are called entries. The encoding rules of entries are as follows:
An entry has its complete element name (including the Name Domain URi and local name ). The direct sub-element of the SOAP Header must have a name restriction.
The SOAP encodingStyle attribute can be used to indicate the encoding format used by the entry.
The. SOAP mustLJnderstand and SOAPactor attributes can be used to indicate how to process this entry and who will process it.
(3) SOAP Body
SOAP: The Body provides a simple mechanism for exchanging information with the final receiver of a message, which must be processed. A typical application of the Body element is a series of RPC calls and error reports. The Body element is a direct sub-element of the SOAP Envelope element in the code. If the Body element contains the Header element, the Body element must follow the Header element directly and be the next sibling element directly. Otherwise, the Body element must be the first direct child element of the Envelope element. The direct sub-element of all Body elements is called the Body entry. At the same time, each Body entry is an independent element in the SOAP Body element.
SOAP only predefines one Body entry: Fault is used to report errors to the caller. The SOAP Fault element is used to transmit error and status information in a SOAP message. If a SOAP message needs to contain the SOAP Fault element, the SOAP Fault element must appear as a Body entry and only once in the Body element.
The SOAP Fault element defines the following child elements:
. Faultcode. The faultcode element meets the needs of software that uses algorithm mechanisms to identify errors. The faultcode element must appear in the SOAP Fault element, and its value must belong to a modifier defined later. SOAP defines a small set of SOAP error codes to overwrite basic SOAP errors.
. Faultstring. The faultstring element provides an explanation of the error code, which is not set for program processing. The faultstring element is somewhat similar to the "Reason. Phrase" defined in HTTP ". The faultstring element must appear in the SOAP Fault Element and provide information about error types.
. Faultactor. The value of faultactor is a URi that specifies the node in the message path that causes an error. It is similar to the SOAP actor attribute, but it is not used to indicate the receiver of the Header entry, but to indicate the error source. The value of the faultactor element is a uRI that identifies the source. An application that is not the final receiver of a SOAP message must include the faultactor element in the SOAP Fault element, and the final receiver of the message can use the faultactor element to explicitly indicate that it has generated the error.
· Detail. The detail element is used to transmit special error messages of applications related to the Body element. If the content in the Body element cannot be processed successfully, the detail element must appear. The detail element cannot be used for transmission. The error message of the Header entry. The detailed error information of the Header entry must be transmitted in the Header entry.
If no detail element exists in the Fault element, the error is irrelevant to the processing of the Body element. This can be used to identify whether the Body element has been processed in case of an error. All direct child elements of the detail element are called detail entries, and each detail entry is encoded as an independent element in the detail element.
(4) Transmission of SOAP messages
SOAP messages are transmitted in one way from the sender to the receiver, and are often implemented in the form of requests/responses. For example, HTTP binding transfers a SOAP Response Message as an HTTP Response and returns a request using the same connection. No matter which Protocol the SOAP is bound to, the SOAP message can be processed by an intermediate node outside the end node.
A soap application that receives SOAP messages follows these steps:
. Identify all parts of the SOAP message required by the application;
· Check whether the application supports all necessary parts of the message identified in step 1 and process it. If not, the message is discarded. If the processing result is not affected, the processor may ignore the optional part identified in step 1. If the SOAP application is not the final destination of the message, delete all the parts identified in step 1 before the message is forwarded.
To correctly process a message or a part of the message, the SOAP processor needs to understand the exchange methods used (unidirectional, request/response, and multi-path transmission) in this way, the receiver's task, the use of RPC (if any), the data representation method or encoding, and other necessary semantics. Although attributes (such as SOAP Encoding Style) can be used to describe certain aspects of a message, this specification does not force all receivers to have the same attributes and take the same attribute values. That is, the SOAP messages of the Interaction parties do not necessarily follow the same format settings, but only need to exchange information in a format that both parties can understand.
All SOAP messages are encoded in XML format. In a message generated by a SOAP application, all elements and attributes defined by SOAP must contain the correct name. The SOAP application must be able to process the SOAP names in the messages it receives, and also process SOAP messages without SOAP names, just as they have correct names.