SOAP Version 1.2

2.SOAP message exchange model

Basically, SOAP messages are a transmission method from the sender to the receiver, but as described in the previous example, SOAP messages are generally combined with the implementation mode, for example, request/response.

The implementation of SOAP can be optimized for the special features of special network systems. For exampleSection 6The HTTP binding described in is used to transmit the SOAP response message through the HTTP Response and use the same HTTP connection as the corresponding request.

2.1 SOAP Node

The SOAP node can be the initial SOAP sender, the final SOAP receiver, or the SOAP intermediary between the SOAP sender and the receiver at the same time. SOAP does not provide a routing mechanism. Therefore, SOAP needs to identify which SOAP messages generated by the SOAP sender should be sent to one end SOAP receiver through zero or multiple SOAP intermediaries.

The SOAP node that receives the SOAP message must be able to implement processing and generate necessary SOAP errors and SOAP responses. If appropriate, additional SOAP messages should be generated according to subsequent descriptions in this specification.

2.2 SOAP role and SOAP Node

When processing a SOAP message, the SOAP endpoint is notified that it should be processed by one or more SOAP processing roles identified by the SOAP actor name, the name of the SOAP actor is a URI. Each SOAP node must be processed by a specified role. This role is named"Http://www.w3.org/2001/06/soap-envelope/actor/next". At the same time, you can apply zero or multiple additional roles as needed. The SOAP node can implement processing using the role of an anonymous SOAP actor to make itself the final SOAP receiver. When a SOAP node processes a SOAP message, its SOAP role cannot be changed throughout the process. This is because this specification only involves how to process a single SOAP message without considering the status. Therefore, it makes no sense to allow the role to be converted when processing a single SOAP message.

SOAP actor names are used to identify SOAP nodes and are not associated with the semantics of routing or message exchange. For example, a SOAP actor can be named as a URI used to send a SOAP message to an appropriate SOAP node. On the contrary, there are also some SOAP processing role names that are either directly associated with message routing (e.g., http://example.org/banking/anyAccountMgr) or not associated with routing (e.g, when a message header is used to carry an indication, it is used to inform any related software that the SOAP message remains unchanged for a long time and can be safely cached and reused, in this SOAP message header, a URI can be used to identify "All Cache Management Software"). It is also appropriate to use these SOAP processing roles by name.

2.3 Locate SOAP Header entries

The SOAP header entry contains the optional env: actor attributes (seeSection 4.2.2) To locate them to the appropriate SOAP node. The SOAP Header without this attribute implicitly locates an anonymous SOAP actor, which means they are processed as the final SOAP receiver. We use the value of the SOAP actor attribute (implicitly or directly specified) as the SOAP actor of the corresponding SOAP entry (SOAP Header entry or SOAP Body entry.

If the SOAP actor (if any) in a SOAP entry matches the role of a SOAP node, or the SOAP entry does not have the actor attribute (including the SOAP Body entry) this SOAP node is already assumed to be an anonymous SOAP processing role. In this case, we will say that the SOAP entry is directed to a SOAP node.

2.4 Understanding SOAP Header

We believe that over time, there will be a large number of SOAP Header function specifications, and each SOAP node can contain one or more software necessary to process these extensions. If the software of the SOAP node is fully compatible and implements the semantics transmitted by the outermost element name fully modified in the entry, we say that the SOAP Header is understood by a SOAP node.

When the mustUnderstand attribute of the SOAP Header block located at a SOAP node is "1", the pointed SOAP node must: you can also process the SOAP Block Based on the semantics passed by the fully modified outermost layer element name in the entry, or simply fail to process the SOAP message (seeSection 4.4)..

2.5 Process messages

This section describes the SOAP message processing rules. Unless otherwise specified, the processing must be semantically equivalent to performing the following steps separately and in the given order. Note that, in any case, this specification does not block the use of technologies such as parallel, rollback, or other technologies that can improve flexibility in processing, as long as all SOAP messages, SOAP fault, and application-level results are the same as those obtained by directly executing the following rules.

1. If one or more SOAP entries located at the SOAP node have env: mustUnderstand = "1" and are not understood by the node, a SOAP mustUnderstand error is generated. If such an error occurs, you must stop further processing.

2. Process the SOAP entries located at the SOAP node. If necessary, a SOAP error is generated. When defining env: mustUnderstand = "1", a SOAP node must process the SOAP block. If not defined, the SOAP node can process or ignore this SOAP entry. If a SOAP entry is processed, in any case, the SOAP node must understand the SOAP entry and process it in a style that exactly matches the description of the SOAP entry. Errors must be consistent with the description of SOAP entries. Processing special SOAP entries may control or determine the processing sequence of other SOAP entries. For example, a SOAP entry may create a SOAP Header entry to force other SOAP Header entries to be executed in the word order. Without such a SOAP entry, the processing order is determined by the SOAP node. When processing a SOAP entry, the SOAP node can reference any information in the SOAP envelope. For example, if needed, a cache function can cache the entire SOAP message.

If the SOAP node is a SOAP intermediary, the SOAP message style and processing result (if no error is generated) can be further delivered along the SOAP message path. This type of transmission must include all SOAP Header entries and SOAP Body entries from the SOAP message source in the same order, except those SOAP Header entries pointing to the SOAP mediation, these entries must be removed (whether or not they are processed, these SOAP entries will be removed ). The added SOAP Header entries can be inserted at any point of the SOAP message, in this way, the inserted SOAP Herder entries may not be distinguished from one or more newly removed entries (in fact, they will be retained, but stressed the need to re-interpret each SOAP node along the SOAP message path)

3. Relationship with XML

All SOAP messages are encoded in XML format (see[7]For more XML Information ).

A soap application should contain an appropriate SOAP namespace when generating all elements and attributes defined by SOAP. The SOAP application must be able to process the SOAP namespace in the received message. It must discard those namespaces that contain incorrect namespaces (seeSection 4.4And can process SOAP messages that do not contain the SOAP namespace, as if they contain the correct namespace.

SOAP defines the following namespaces (see[8]To get more information about the XML namespace ):

• The namespace ID of the SOAP envelope is"Http://www.w3.org/2001/06/soap-envelope"

• The namespace in the SOAP Collation is identified"Http://www.w3.org/2001/06/soap-encoding"

• The namespace ID of SOAP mustUnderstand fault is"Http://www.w3.org/2001/06/soap-faults"

• The namespace ID of SOAP upgrade is"Http://www.w3.org/2001/06/soap-upgrade"

The schema documents of these namespaces can be obtained by parsing these namespaces identifiers.

The SOAP message must not contain the DTD, and the soap message must not contain the PI (Processing Instructions ).[7]

SOAP uses a local unrestricted ID type id attribute to specify the unique identifier of the encoding element, use the href attribute of the local unrestricted uri-reference type to specify the application of the value of the encoding element to obtain the XML specification.[7]XML Schema Specification[11]And XML Linking Language specifications[9].

In addition to the SOAP mustUnderstand attributes (seeSection 4.2.3And SOAP actor attributes (seeSection 4.2.2). Generally, attributes and attribute values are allowed to be freely described in an XML instance or in an XML Schema. The premise is that they have the same effect. That is to say, using the default value or fixed value definition in a dtd or schema is semantically equivalent to the definition in an instance.

4. SOAP envelope

A soap message is an XML document consisting of a forced SOAP Envelope, an optional SOAP Header, and a forced SOAP Body. This XML document, as a SOAP message, will be referenced in the rest of this specification. The namespace ID of the elements and attributes in this section is"Http://www.w3.org/2001/06/soap-envelope". SOAP messages should include the following parts:

• A soap envelope. Envelope is the top-level element of the XML document that represents the message.

• A soap Header. The Header is used to support communication in a loose environment (it may be a SOAP sender, a SOAP receiver, or a transmission intermediary of one or more SOAP) added a general mechanism for SOAP messages when no pre-agreement is reached between them. SOAP defines few attributes to indicate who can handle the feature and whether it is optional or mandatory. (SeeSection 4.2)

• A soap Body. The Body provides a container for the mandatory information that the final receiver of the message wants (seeSection 4.3). In addition, SOAP defines a sub-element Fault of the Body for reporting errors.

The syntax rules are as follows:

1. SOAP