SOAP Technology and B2B Application Integrated SOAP Message Structure and Data Method
Chai Xi Road Chief System Architect April 24, 2001
Content: SOAP Message Framework SOAP ENCODINGSTYLE Attribute SOAP Headersoap Actor Property Soap Mustunderstand Properties Soap Body Using Soap Bodysoap Header and Soap Body Semantic Relationship Soap FaultsoAP Fault Code Reference Author
This article continues the SOAP technology and application overview, combined with application examples, explain the structure of the SOAP message, and describes how to use the SOAP message to describe RPC calls to how to use SOAP messages by detailing the SOAP ENVELOPE, SOAP HEADER, SOAP BOAP. With a complete and in-depth understanding of this series, it lays a structural basis for the articles of the coding rules in the SOAP message later.
SOAP provides a simple lightweight mechanism for using XML pairs of structured and type information in a loose, distributed environment. The basic unit carrier of transmitting information is SOAP message. Fundamentally, the SOAP message is a transmission method from the sender to the recipient, but as explained in the previous SOAP technology and application overview, 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, the SOAP response message is transmitted, requested and responded to the same connection with the HTTP response via HTTP Binding.
Of course, regardless of the SOAP is binding to which protocol is binding, it uses the same message to describe the framework format. This framework format is based on the SOAP Envelope (SOAP envelope), which contains SOAP header and soap body child elements. An XML document. SOAP Message Description Text is an XML Application. The reason why it is called a description, not known as a description, is because the SOAP specification defines a powerful extension mechanism for SOAP Header and SOAP Body, and the user can add a custom description format related to the application as needed. Soap specification Just define a skeleton description of the message.
All SOAP messages are encoded using XML format. 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 and can handle SOAP messages that do not contain SOAP namespaces, as if they contain the correct namespace.
SOAP defines two namespaces:
The namespace identifier of the SOAP envelope is http://schemas.xmlsoap.org/soap/envelope/ SOAP sequencing namespace ID http://schemas.xmlsoap.org/soap/encoding/
The SOAP message must not contain DTD, and the SOAP message must also not contain pi (Processing Instructions).
In addition to SOAP Mustunderstand Attribute and SOAP Actor Attribute, generally allowed attributes and attribute values to freely choose to describe in XML instances or description in XML Schema, of course, the premise is that they have the same effect. That is, the default value or fixed value is defined in semantic value definitions in the instance in the mode (Schema).
For example: Defining in Schema
Then define in XML instances
Defined with direct XML instances
SOAP message framework
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://schemas.xmlsoap.org/soap/envelope/. SOAP messages should include the following:
ENVELOPE is an universal mechanism for adding features of SOAP messages to SOAP messages in the case where the messages are not yet priorcted in conjunction between the messages in the loose environment. SOAP defines some of some of the properties to specify who can handle this feature and whether it is optional or forced to process. Body provides a container for those that must be processed for the final recipient of the message. In addition, SOAP defines a child element FAULT of Body for reporting an error.
The grammar rules of these XML elements are as follows:
Envelope
Element name envelope This element must appear in the SOAP message, typically the root element can include named space declaration and additional properties. If additional attributes (not the SOAP specification predefined attribute), you must use a namespace to modify. Similarly, the element can contain additional child elements, if the sub-elements must have named space modifications and must follow the SOAP body element, that is, the direct child elements of Envelope must be arranged at the foremost. HEADER
The element name is HEADER This element can appear in the SOAP message, but it is not necessary (that is, the information describing only the BODY element is used to complete 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. The Header entry they can contain the lower grade element, but these elements are not the header entry, but the contents of the Header entry. Body
The element name is 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 information that calls an error. The Boidy entry itself can contain the lower level element, but these elements are not a Body entry, but the content of the body entry.
Below is an example of a SOAP message, where envelope contains a Header element and a body element. The Header element has two header entries, and their namespace modifications are Unib2b, and two header entries have a child element. The body element has a Body entry that contains two sub-elements.
XMLns: soap-env = "http://schemas.xmlsoap.org/soap/envelop/" SOAP-ENV: EncodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"> 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 attribute in all its sub-elements, which is the same as the scope of the XML namespace definition. . For a SOAP message, there is no default encoding definition. The value of the SOAP ENCODINGSTYLE attribute is one or more or more ordered lists for identifying the order rules (description rules for the data type and data type instance) and the rules for identifying the rules of the SOAP message, which is sorted by detailed extent Large to small arrangement. Here are some examples of values: "http://schemas.xmlsoap.org/soap/encoding/" "http://schema.dealeasy.com/soap/encoding/ http://schema.dealeasy.com/soap/encoding/additional/" "" The marked rules defined in the SOAP specification is http://schemas.xmlsoap.org/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://schemas.xmlsoap.org/soap/encoding/ on syntactics indicate that all URIs all consistent with the SOAP coding rules defined in the SOAP specification. (Although potential stringent rules may be added, that is, http://schemas.xmlsoap.org/soap/encoding/ identified coding rules is a code base class) A null value of the URI ("") explicitly indicates that no coding style is declared for the elements contained. This can close any previous pre-declarations for the included elements. SOAP Header SOAP provides an expandable mechanism for modularize the description capabilities of SOAP messages in a dispersed network environment, while communication between communication does not require a complete pre-agreement. A typical exemplary example can be a HEADER entry, such as authentication, transaction management, and payment, of course, for more complex multi-step B2B, can be implemented by extending relatively complex Header entry, in front of the article SOAP technology and application overview There is a complete example in the middle. According to SOAP grammar, the Header element should be encoded as the first straight sub-set 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 Header entry is identified by a completely modified element name, and the so-called complete modified element name is composed of a namespace URI and a local name. All direct child elements of the SOAP header element must be completely modified. Any HEADER entry without namespace is not allowed. The SOAP ENCODINGSTYLE property can be used to specify the HEADER entry's encoding style, and the EncodingStyle property has been described in detail in front. SOAP MUSTERSTAND attributes and SOAP Actor properties can be used to indicate how to handle entries and who will handle entries. In SOAP HEADER, the setting of the SOAP header property is to make the receiver of the SOAP message understand how the message should be handled. 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 a header, which contains an element identification priority and a MUSTUNDERSTAND attribute and its value 1, and the value of Priority 7 indicates that the processing priority is 7. XMLns: unib2b = "Some-Uri" soap-env: Mustunderstand = "1"> Seduce SOAP Actor attribute 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. All parts of a SOAP message are called information that the final recipient needs to understand, wherein the part is one or more intermediate mesa needed in the path. He does not give it to other parties in the Header Element. That is, a recipient receives the Header element that needs to receive must not forward the header to the next application in the SOAP message path. The recipient can insert a similar Header element, but in this case, the contractual 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. URI: http://schemas.xmlsoap.org/soap/actor/next Indicates that the Header element is directly the next SOAP application that performs messages. This is consistent with the expression of Hop-by-Hop Scope Model with HTTP's connection header field. If the SOAP Actor property is omitted, the recipient of the message is the final recipient of the SOAP message. For an instance of a SOAP message (in the actual SOAP message), this property must appear to indicate the URI of the receiver of the message. The SOAP MUSTUNDERSTAND Property SOAP MUSTUNDERSTAND Global property is used to indicate that a header entry is forced to process or optionally the recipient processed. The recipient of the Header entry is defined by the SOAP Actor property. The value of the Mustunderstand property is "0" or "1". If there is no SOAP MUSTERSTAND attribute, it is "0" in semantically equivalent to the MustovernmentStand attribute. If the Header element has a SOAP Mustunderstand attribute of "1", the recipient of the Header entry either follows semantic (conveys the elements with complete modified elements) and correctly handles these semanties, or must claim to fail . That is to say, if the application finds that it is unable to identify a Header entry (there is no entry in your own processing logic), you must declare an error and respond to error messages. 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 attribute must be in an instance, which means that this property is enabled by setting the default value or fixed value of XML Schema. SOAP BODY The SOAP body element provides a simple mechanism for exchange information for the final recipient with the message (this information is required). 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 called a Body entry, while each Body entry should be encoded as a separate 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 property can be used to indicate the encoding rules used in the Body entry. SOAP only predefines a Body entry: use to report an error to the calling party: Fault. Use SOAP BODY The following is an example of a pair of SOAP calls / responses. In the call message, the body contains a Body entry RequestPurchaseOrder that describes the calling method, which contains two parameters ProductID and ProductPrice. In the response message, the body contains a Body entry ResponsePurchaseOrder to describe the return information of the response call, which contains OrderID, AuthenticatedId, ProductId, ProductNumber, Issuedate. RPC called SOAP message representation Post / ProductQuote HTTP / 1.1 Host: service.emarketplace.com.cn Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn SOAPACTION: "Some-Uri" XMLns: soap-env = "http://schemas.xmlsoap.org/soap/envelop/" SOAP-ENV: EncodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"> RPC response SOAP message representation HTTP / 1.1 200 ok Content-type: text / xml; charSet = "UTF-8" Content-Length: nnnn XMLns: soap-env = "http://schemas.xmlsoap.org/soap/envelop/" SOAP-ENV: EncodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"> Semantic relationship between SOAP HEADER and SOAP 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 semanticity 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 them without using the actor properties. SOAP FAULT The SOAP FAULT element is used to transmit errors and 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: The Faultcode Faultcode element is the need to identify the erroneous software in the mechanism of algorithms. FaultCode must appear in the SOAP Fault element, and the value of FaultCode must be a modulation name that belongs to the rear section. SOAP defines a collection of SOAP error codes to overwrite basic SOAP errors. Faultstring Faultstring Elements are misinterpretation for those who can read for those error codes, which is not set for program processing. The faultstring element is a bit similar to 'Reason-Phrase' defined in HTTP. FaultString must appear in the SOAP Fault element, and it should at least provide some information to explain the error type. The Faultactor Faultactor element is to describe who is in the message path that has caused the incorrect information. It is similar to the SOAP Actor attribute, 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 application of the non-final recipient of the 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. The Detail Detail element is a special error message for transmitting applications related to a 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 a Detail element does not appear in the 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 processed 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: 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. The SOAP ENCODINGSTYLE property can be used to indicate the encoding rules used in the Detail entry. Other Fault child elements can appear, they should provide namespace modifications. SOAP FAULT code When describing errors defined by this specification, the FaultCode element must use the value of the Faultode defined in this section. The namespace identifies of these Faultcode values are http://schemas.xmlsoap.org/soap/envelope/. The default SOAP FaultCode value is defined according to an extensible style that allows for a new SOAP Faultcode value to be defined after maintaining backward compatibility with a FaultCode value. This mechanism is very similar to the definition 1xx, 2xx, 3xx, etc. of the basic state class in HTTP. However, they are defined with XML modifications, not using integers. "." 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. E.g: Client.AuthenThent The Faultcode value collection defined in this document is: Name Meaning The VersionMismatch handler finds an illegal namespace in the SOAP Envelope element. A direct child element of the Mustunderstand Soap header element cannot be understood or he does not comply with the SOAP Mustunderstand attribute required by the processing object to take the value "1". Client Client Error Class is used to indicate the following error: the format of the message is incorrect or there is a lack of some appropriate information necessary for successful handling. For example, there may lack appropriate authentication and payment information in the message. Under normal circumstances, the message should not be retransmitted without modification. Referring to the description of the Fault Detail sub-elements. 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. Referring to the description of the Fault Detail sub-elements. Conclusion This article describes the message structure of the SOAP message and the XML syntax and specific application methods of each element of SOAP messages. I will describe how to describe specific data (data structure / data instance) in the SOAP element in the next article, and in detail The syntax of the SOAP coding rule describing the data. Reference Solve B2B e-commerce application interaction and integrated Interop Stack Series Technical Standard Specification UDDI Technical White Paper, Ariba Inc., IBM Corporation and Microsoft Corporation, 6 Sep 2000 Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000 SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000 Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000 XML Schema Part 0: Primer, W3C, 16 Mar 2001 SOAP development package Microsoft Soap Toolkit 2.0, RC0, Microsoft Corporation Apache SOAP 2.0, Apache.org About the Author
