2. SOAP message exchange model
Fundamentally, the SOAP message is a transmission method from the sender to the recipient, but as explained in the previous example, the SOAP message is generally combined with the implementation mode, such as request / response.
The implementation of SOAP can be optimized for special features of special network systems. For example, HTTP Binding described in Section 6 transmits the SOAP response message via HTTP response to use the same HTTP connection with the corresponding request.
2.1 SOAP Node
The SOAP node can be an initial SOAP sender, which can be the final SOAP recipient, or also simultaneously as a SOAP agent of the SOAP sender and the recipient. SOAP does not provide a routing mechanism, so SOAP needs to identify SOAP messages generated by SOAP senders should be sent to a final SOAP recipient.
The SOAP node that receives the SOAP message must be able to implement processing, generate the necessary SOAP errors and SOAP responses, and if appropriate, additional SOAP messages should also be generated in accordance with the subsequent description of this specification.
2.2 SOAP role and SOAP node
When processed a SOAP message, the SOAP node will be informed that the SOAP role is identified by the SOAP Actor name by one or more SOAP processing roles. The name of the SOAP Actor is a URI. Each SOAP node must be processed in a specified role. This role is represented by the SOAP Actor named "http://www.w3.org/2001/06/soap-envelope/actor/next", You can apply an additional role represented by zero or more other SOAP Actors. The SOAP node can be processed by the role of anonymous SOAP Actor, making it a final SOAP recipient. When the SOAP node is processed with a SOAP message, the SOAP role whose SOAP role is not changed throughout the process. This is because this specification only involves how to handle a single SOAP message without considering the status, so whether the conversion role is not intended when processing a single SOAP message.
The SOAP Actor name is used to identify the SOAP node, and it is not associated with the semantics of the route or message exchange. For example, a SOAP Actor can be named as a URI used to send a SOAP message to the appropriate SOAP node. Instead, there are some names such as SOAP processing roles, these names, or direct and message routes (for example, http: //example.org/banking/anyaccountmgr), or route is not contacted (for example, when a message head is used To carry an instruction, this indication is used to inform any related software that the SOAP message is a long-term constant, which is a safe cache and reuse. In this SOAP message header, a URI can be used to identify all cache Managing Software "), using these SOAP processing roles through the name.
2.3 Positioning the SOAP Header entry
The SOAP HEADER entry contains an optional ENV: Actor property (see section 4.2.2) to locate them to the appropriate SOAP node. Soap header without this property implies to an anonymous SOAP Actor, which means they are processed as the final SOAP recipient. We use the value of the SOAP Actor property (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) matches the role of a SOAP node, or the SOAP entry does not have an actor property (including the SOAP Body entry) and the SOAP node has assume it to be anonymous SOAP processing role, then we will Say that the SOAP entry is pointed to a SOAP node.
2.4 Understand SOAP Header
We believe that over time, there will be a lot of SOAP Header function specification, and each SOAP node can contain one or more software necessary to process these extensions. If the SOAP node software is fully compatible and implements the semantics passing through the outermost element name of complete modification in the entry, we say that this SOAP Header is understood by a SOAP node. When positioned to a SOAP HEADER block of the SOAP node is "1", the SOAP node pointed to: or the semantics passing through the outermost element name of the entry to process the SOAP block, or more This does not deal with SOAP messages (see section 4.4)..
2.5 processing message
This section stated in the SOAP message processing rules. Unless otherwise specified, the processing must be semantically equal to the steps below, and must also be in order to give a given order. Note that there is no way to use such specifications, such as parallel, rollback or other technologies can be used in this specification, as long as all SOAP messages, SOAP FAULT, and application-level results, and those rules that directly perform the following rules. The result obtained is the same.
If one or more SOAP entries that are positioned to the SOAP node have env: Mustunderstand = "1" and there is no description, it produces a SOAP MUSTERSTAND error. If such an error is generated, further processing must be stopped. Processing the SOAP entry positioned to the SOAP node, if necessary, generate a SOAP error. When defining env: MUSTUNDERSTAND = "1", a SOAP node must handle SOAP blocks. If there is no definition, the SOAP node can handle or ignore the SOAP entry. If a SOAP entry is processed, this SOAP node must understand the SOAP entry and must be processed with the SOAP entry to explain the fully consistent style. For errors, whether it is, it must be consistent with the description of the SOAP entry. It is possible to handle the specific SOAP entry to control or determine the processing order of other SOAP entries. For example, a SOAP entry may create a SOAP Header entry to enforce other SOAP Header entries in the order of vocabulary. If there is no such SOAP entry, the order in which the processing is determined by the SOAP node. When processing a SOAP entry, the SOAP node can reference any of the information in SOAP envelope. For example, if necessary, a cache function can cache the entire SOAP message.
If the SOAP node is a SOAP intermediary, the results of the SOAP message (if no error is generated), you can request a SOAP message along the SOAP message path. Such relay transactions must include all SOAP Header entry from the SOAP message source in the same order, in addition to the SOAP Header entry to the SOAP intermediary, these entries must be removed (regardless of whether they are processed, these The SOAP entry will be removed). Additional SOAP Header entries can be inserted in any point in the SOAP message, so that the SOAP Herder entry that is inserted may not be able to distinguish between one or more entry of the original movement (actually retained them, but emphasized Need to reinterpret each SOAP node along the SOAP message path)
3. Relationship with XML
All SOAP messages are encoded using XML format (see [7] to get more XML information).
SOAP applications should include proper SOAP namespaces when generating all elements and properties defined by SOAP. The SOAP application must handle the SOAP namespace in the message received. It must discard messages that contain incorrect namespaces (see section 4.4), and can handle SOAP messages that do not contain SOAP namespaces, as if they contain the correct namespace.
SOAP defines the following namespaces (see [8] to get more information about XML namespace): SOAP envelope namespace identifier is "http://www.w3.org/2001/06/soap-envelope "The namespace identifier of SOAP is" http://www.w3.org/2001/06/soap-encoding "SOAP MUSTUNDERSTAND FAULT" http://www.w3.org/2001/06 / SOAP-FAULTS "SOAP UPGRADE namespace ID" http://www.w3.org/2001/06/soap-upgrade "
The mode documentation of these namespaces can be obtained by parsing these namespace identifiers.
The SOAP message must not contain DTD, and the SOAP message must also not contain pi (Processing Instructions). [7]
SOAP uses local non-limiting ID type ID attributes to specify unique identifiers of encoding elements, using the HREF attribute of local non-limiting URI-REFERENCE types to specify the value of the value of the encoding element to obtain XML Specification [7], XML Schema Specification [11] and XML Linking Language Specifications [9].
In addition to the SOAP Mustunderstand attribute (see section 4.2.3) and SOAP Actor attribute (see section 4.2.2), generally allowed attributes and attribute values to freely choose to describe in XML instances or in XML Schema, of course, the premise is them Has the same effect. That is, use the default or fixed value in the DTD or mode (Schema) defined in the definition of semantics.
4. SOAP envelope
The SOAP message is an XML document consisting of a mandatory SOAP Envelope, an optional SOAP Header and a forced SOAP body. The XML document as a SOAP message will be referenced in the rest of this specification. The naming space identifier of elements and attributes of this section is "http://www.w3.org/2001/06/soap-envelope". SOAP messages should include the following:
A SOAP envelope. ENVELOPE is a top-level element representing the XML document of the message. A SOAP HEADER. HEADER is intended to support the general mechanism of SOAP messages in the case of SOAP messages in the case where the communication party (may be a SOAP sender, SOAP recipient or one or more SOAP transmission intermediaries) . SOAP defines some of some properties to specify who can handle this feature and it is still forced. (See Section 4.2) A SOAP Body. Body provides a container for those forced by the final recipient of the message (see section 4.3). In addition, SOAP defines a child element FAULT of Body for reporting an error.
The grammar rules are as follows:
SOAP envelope
The element is called "envelope". This element must appear in the SOAP message. This element can include named space declaration and additional properties. If additional attributes appear, you must have a namespace modification. Similarly, the element can contain additional sub-elements, if there is, if there is, there must be named space modifications and must be followed by the SOAP Body element. SOAP HEADER (see section 4.2)
The element is called "header". This element can appear in the SOAP message. If there is, the element must be the first direct child element of the SOAP Envelope element. This element can contain a series of Header entries, which should be direct child elements of the Header element. All direct child elements of Header must have namespace modifications. SOAP Body (see section 4.3)
The element is named "body". This element must appear in the SOAP message and must be a direct child element of the SOAP Envelope element. If the message contains the header element, the body element must follow Header, the neighboring brother element of the Header element. If Header does not appear, it must be the first direct child element of Envelope. This element can contain a series of Body entries that should be direct child elements of the body element. All direct child elements of Body must have namespace modifications. SOAP defines the SOAP FAULT element that is used to indicate an error message. (See Section 4.4). 4.1.1 soap encodingstyle attribute
SOAP Global EncodingStyle properties are used to indicate which order rule used in the SOAP message. This attribute can appear in any element, and its scope includes the content of the element and all sub elements of the attributes in all its sub-elements, which is like the XML namespace defined scope. For a SOAP message, there is no default encoding definition.
The value of this property is one or more or more ordered list of rules for identifying sequencing rules and rules for identifying SOAP messages, which are arranged from large to small alignment in detail. Example 3 shows three examples of EncodingStyle properties:
EXAMPLE 3
Encodingstyle = "http://www.w3.org/2001/06/soap-encoding"
EncodingStyle = "http://example.org/encoding/restricted http://example.org/encoding/"
EncodingStyle = ""
EXAMPLE VALUES for the EncodingStyle Attribute
The description rule defined in Section 5 is "http://www.w3.org/2001/06/soap-encoding". The message should be specified using the SOAP ENCODINGSTYLE attribute if special order should be used. In addition, all URI sequences starting by "http://www.w3.org/2001/06/06/soap-encoding" on syntax indicate that all URIs all consistent with the SOAP coding rules defined in Section 5. (Although potential stringent rules may be added)
A null value of the URI ("") explicitly indicates that no coding style is declared for the elements contained. This can close any declarations for the included elements.
4.1.2 ENVELOPE version model
SOAP does not define a traditional version model based on the hostian version number. The SOAP message must contain an envelope element associated with the namespace "http://www.w3.org/2001/06/soap-envelop". If the SOAP application receives a SOAP message, the envelope element in this message is associated with a namespace different from "http://www.w3.org/2001/06/soap-envelop", the application must Depending on it is a version error and generates a VersionMismatch SOAP error. SOAP VERSIONMISMATCH error message must be modified using the envelope namespace of SOAP 1.1 "http://schemas.xmlsoap.org/soap/envelop/".
4.2 SOAP HEADER
SOAP provides a scalable mechanism to expand SOAP messages in dispersed modular environments, while communication between communication does not need to have pre-agreement. A typical exemplary example can be some Header entry such as authentication, transaction management, and payment.
The SOAP Header element should be encoded as the first straight subsite element of the SOAP Envelope XML document. Header's direct child elements are called Header entry.
The coding rules of the Header entry include: a SOAP Header entry is identified by a completely modified element name, and the so-called completely modified element name consists of a namespace URI and a local name. All direct child elements of the SOAP header element must be completely modified. The SOAP ENCODINGSTYLE property can be used to specify the HEADER entry encoding style (see section 4.1.1). The SOAP Actor property (see section 4.2.2) and SOAP MUSTERSTAND properties (see section 4.2.3) can be used to specify which SOAP node to process entries and how to handle entries.
4.2.1 Using Header Attributes
The SOAP Header attribute defined in this section determines how the receiver of the SOAP message should handle the message (see section 2). A SOAP application that generates the SOAP message should only use the SOAP Header property of the direct child elements of the SOAP Header element. For the SOAP Header attributes that are not directly sub-elements that are not as a SOAP header element, the recipient of SOAP messages must be ignored.
The following is an example of SOAP Header (Example 4), which contains an element identifier Transaction and a Mustunderstand property and its value 1, and the value of Transactin 5:
EXAMPLE 4
5
Example Header with a single header block
4.2.2 SOAP Actor attribute
Ednote: this section section to be reconciled in a future revision of the specification.
The SOAP message arrives at the final recipient from the generator, which will potentially walk through a series of SOAP intermediaries along the Message Path. SOAP intermediate is an application that accepts and forwards SOAP messages. All intermediate media is as identified by a URI as the final recipient.
Not all parts of a SOAP message are desired by the final recipient, some of which are required by one or more intermediates in the path. He does not give it to other parties in the Header element. That is, a recipient receives a Header element that it wants must not forward the header to the next application in the SOAP message path, because the contract relationship is between the first two. The recipient can insert a similar Header element, but in this case, the relationship is between the application and the recipient of the next header element.
The SOAP Actor global property can be used to indicate the recipient of the Header element. The value of the SOAP Actor property is a URI. This special URI "http://www.w3.org/2001/06/soap-envelope/actor/next" indicates that the Header element is a direct next to the SOAP application for messaging. This expression of Hop-by-Hop Scope Model with HTTP's connection header field.
If the SOAP Actor property is omitted, the recipient is the final recipient of the SOAP message.
This property must appear in an instance of the SOAP message, and cannot be defined to obtain the same effect in the related XML Schema (see Section 3 and Section 4.2.1). 4.2.3 SOAP MUSTUNDERSTAND Properties
Ednote: this section section to be reconciled in a future revision of the specification.
The SOAP MUSTUNDERSTAND global property is used to indicate that a header entry is forcibly or optionally the recipient processing. The receiving node of the HEADER entry is defined by the SOAP Actor property (see section 4.2.2). The value of the MUSTUNDERSTAND property can be "0" or "1". If there is no SOAP MUSTERSTAND attribute, it is optional "0" in semantically equivalent to the MustovernmentStand property, that is, this entry is optional.
If the Header entry has the value of the SOAP Mustunderstand attribute of "1", the receiving node of the Header entry must follow semantics (conveyed by a full modified element name) and correctly handle these semantics, or must claim to process messages Failure (see section 4.4).
The SOAP MUSTUNDERSTAND attribute is set to consider robust upgrades. All elements that are marked with a SOAP Mustunderstand property with a value of "1" must be considered to be the semantics of the superior element or the peer element of the element. The elements of this style should ensure that the modifications to semantics cannot be ignored by those elements that cannot fully understand the modified semantic, incorrectly ignored.
This property must be taken into effect in an instance without defining the same effect in the relevant XML Schema (see Section 3 and Section 4.2.1).
4.3 SOAP BODY
The SOAP Body element provides a simple mechanism for exchange forced information with the final recipient of the message. The typical application of the body element contains the sequence RPC call and error report.
The Body element should be a direct child element of the SOAP Envelope element on the code. If included a Header element, the body element must follow the Header element, for the direct next brother element of the Header element, otherwise the Body element must be the first straight sub-elements of the envelope element.
The direct child elements of all body elements are becoming a SOAP BODY entry, while each Body entry should be encoded as an independent element in the SOAP body element.
The coding rules of the Body entry include:
A Body entry is identified by a completely modified element name. The so-called completely modified element name is composed of a namespace URI and a local name. The direct sub-element of the SOAP body element can be a named space modification. The SOAP ENCODINGSTYLE attribute can be used to indicate the encoding rules used in the Body entry (see section 4.1.1).
SOAP defines a Body entry that reports an error-incorrect Fault entry (see section 4.4).
4.3.1 Relationship between SOAP HEADER and BODY
Header and Body are defined independent, but in fact, it is in fact. A body entry and a Header entry are: a body entry is in semantics with such a Header entry equivalent, the Header entry will be interpreted by the default participant (final recipient) while the value "1" SOAP Mustunderstand property tag . Default participants can specify the way Actor attributes (see section 4.2.2).
4.4 SOAP error
The SOAP FAULT element is used to transfer errors or status information in the SOAP message. If the SOAP message needs to include the SOAP FAULT element, it must appear as a body entry, and it must not appear once in the body element (at most once).
The SOAP FAULT element defines as the sub-elements: faultcode
The FaultCode element is the need to identify the wrong software to provide a mechanism to provide an algorithm. FaultCode must appear in the SOAP Fault element, while the value of FaultCode must be a modification (restriction) name as defined in Section 3 in [8]. SOAP defines a small set of SOAP error codes to overwrite basic SOAP errors (see section 4.4.1).
Faultstring
The FaultString element is a misinterpret that the error code provides a person who can read, it is not set to program. The FaultString element is a bit similar to 'REason-phrase' defined in HTTP (see [5], Section 6.1). FaultString must appear in the SOAP Fault element, and it should at least provide some information to explain the error type.
Faultactor
The Faultactor element is description information that causes this error in the SOAP message path (see section 2). It is similar to the SOAP Actor property (see section 4.2.2), but it is not used to indicate the recipient of the Header entry, but is used to indicate an error source. The value of the FaultActor property is a URI that identifies the source. The so-called application of the final recipient as a SOAP message must contain the FaultActor element in the SOAP FAULT element. The final recipient of the message can use the FaultActor element to explicitly indicate that it generates the error (see the Detail element below].
Detail
The DETAIL element is a special error message for transmitting applications related to the SOAP body element. If the content in the body element cannot be successfully processed, it must appear. It must not be used to transmit an error message belonging to the Header entry. The detailed error message that belongs to the Header entry must be transmitted in the header entry. If you need an example, see Section 4.4.2.
If the Detail element does not appear in the SOAP FAULT element, it indicates that the error is not related to the processing of the Body element. This can be used to distinguish whether the Body element is handled by the final recipient of SOAP in an error.
All direct sub-elements of the Detail element are called Detail entries, while each Detail entry is encoded as a separate element in the Detail element.
The encoding rules of the Detail entry are as follows (you can also refer to Example 10):
A Detail entry is identified by a completely modified element name, and the so-called full modified element name consists of a namespace URI and a local name. The direct child element of the Detail element can be a named space modification. SOAP ENCODINGSTYLE properties can be used to indicate encoding rules used in the Detail entry (see section 4.1.1).
4.4.1 SOAP error code
When describing errors defined by this specification, the FaultCode element must use the value of the Faultode defined in this section. The namespace identified by these faultcode values is "http://www.w3.org/2001/06/soap-envelope". The specification of the method defined outside the existing specification is recommended to use the namespace (but not required).
The default SOAP FaultCode value is defined according to an extensible style, which allows new SOAP Faultcode values to define new SOAP Faultcode values to maintain the backward compatible basis of the existing Faultcode value. This mechanism is very similar to the definition 1xx, 2xx, 3xx, etc. in HTTP, etc. (see Section 10 in [5]). However, they are defined with XML modifications (see section 3 in [8]) instead of using an integer. "." The symbol is the separator of the faultcode value, which is used to indicate "." The left is a more generalized error code than the right. EXAMPLE 5 shows this feature:
EXAMPLE 5
Client.AuthenThent
Example of an Authentication Fault Code
The faultcode value set in SOAP is collected in the following table.
The NameMemeningVersionMismatch handler finds an illegal namespace in the SOAP Envelope element. (See Section 4.1.2) Mustunderstandsoap HEADER Elements Cannot be understood or he does not comply with the SOAP Mustunderstand attribute required by the processing object to be "1". (See Section 4.2.3) Client Client Error Class For indication of the following error: The format of the message is incorrect or there is no other appropriate information that can be successfully handled in the message. For example, there may lack appropriate authentication and payment information in the message. Under normal circumstances, the message should not be retransmitted without modification. See Section 4.4 to see the description of the Fault Detail child element. Server Server Error Class is used to indicate the reason why messages cannot be processed, but those that belong to content are not to this category, which is mainly used to indicate errors that belong to processing. For example, the processing operation needs to include communication with one upstream handler, but the program does not respond. But the message may be successfully processed at the next point in time. See Section 4.4 to see the description of the Fault Detail child element.
4.4.2 Mustunderstand Error
When the SOAP node produces a MUSTUNDERSTAND error, it should provide the corresponding Header entry in the way they are generated in the way they are generated. In the generated error message, it should provide the Header entry to describe the details of the nameless names that cannot be understood (QNames, descriptions of XML Schema Data Types).
Each such header entry has a local name for misunderstood and a namespace called "http://www.w3.org/2001/06/soap-faults". Each block has a QNAME without modified properties, which is a QNAME of the Header entry that cannot be understood by an error.
For example, if the container of the initial message does not understand the two header elements ABC: Extension1 and DEF: Extension2 in Example 6, an error message is generated in Example 7.
EXAMPLE 6
Env: Mustunderstand = '1' /> Env: Mustunderstand = '1' /> . SOAP ENVELOPE THAT WILL CAUSE A SOAP MUSTUNDERSTAND FAULT IF EXTENSION1 or Extension2 Are Not Understood EXAMPLE 7 XMLns: f = 'http://www.w3.org/2001/06/soap-faults'> XMLns: DEF = 'http: //example.com/stuff' /> SOAP FAULT generated as a result of not understanding extension1 and extension2 in Example 6 Note that there is no need to name a space prefix returns a QNAME that matches the source header element namespace, if the prefix is mapped to an identical namespace name, the error node can use any prefix. It is noted that there is no guarantee that each Mustunderstand error contains all the QNAME's QNAME, the SOAP node can generate an error after the first header block generates only a single Header block error detail information. The SOAP node can also generate a mixed error that contains all the details of all the Mustunderstand issues.
