WebServices principle and research and development practice--Reading notes 1

Fourth Chapter

1. SOAP message structure

The SOAP message has a SOAP Envelope, an optional SOAP header, and an XML document consisting of a SOAP body.

(1), SOAP Envelope

SOPA Envelope is the top-level element of a SOAP message.

The syntax rules for SOPA envelope are as follows:

* The element name is envelope, which must appear in the SOAP message, usually the root element;

* This element can contain namespace declarations and additional attributes. If additional attributes are present, the namespace decoration must be used;

* This element can have additional child elements, must have a namespace decoration and must be followed by the SOAP Body element, that is, the immediate child element header and body of envelope must be arranged at the front.

(2), SOAP Header

The syntax rules for the SOPA header are as follows:

* The element name is header. The element can appear in a SOAP message, but it does not have to occur. If present, 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 the immediate child elements of the header element. All immediate child elements of the header must have namespace adornments;

* Header entries themselves can contain subordinate child elements, but these elements are not header entries, but the contents of the header entries,

* For SOAP header attributes that appear as non-header entries, the recipient of the SOAP message must be ignored.

(3), SOPA Body

The syntax rules for SOPA body are as follows:

* element name is body, the element must appear in the SOAP message, if there is a header element in the message, the BODY element must be arranged adjacent to the header element, if there is no header element in the message, the BODY element must be the first direct child of the SOAP envelope;

* This element can contain a series of body entries, which should be the immediate child elements of the BODY element. All direct child elements of the body must have namespace adornments. The SOAP fault element, if present, must be an entry for the body, which is used to indicate the message that the error was invoked.

* The BODY element itself can contain subordinate child elements, but these elements are not body entries, but the contents of the body entry.

(4), SOAP Fault

The SOAP fault element is used to transmit error and state information in a SOAP message. If a SOAP fault element exists in a SOAP message, it must appear as a body entry and appear at most once within the BODY element.

The SOAP fault element has the following child elements:

* FaultCode: Must appear in the SOAP fault element

* FaultString: This element is for which error codes provide a user-readable explanation of the error, which is not set for program processing.

* Faultactor: This element describes the initiator of the error in the message path. It is similar to the soap actor property, but it does not indicate the recipient of the header entry, but rather indicates the source of the error.

* Detail: This element is used to transmit error information about the application associated with the BODY element. All immediate child elements of the detail element are called detail entries, while each detail entry is a separate element in the detail element.

2. SOAP Message exchange Model

(1), the meaning of the SOAP node

A SOAP node represents a logical entity of a SOAP message path for message routing or processing. The SOAP node can be the sender, receiver, and message intermediary of the SOAP message.

In the SOAP message model, the intermediary is a SOAP node responsible for providing message exchange and protocol routing between the application sending the message and the receiving party. The intermediary node resides between the sending node and the receiving node and is responsible for processing some of the messages defined in the SOAP message header. There can be 0 or more soap intermediaries between the SOAP sender and the receiver, which provides a distributed processing mechanism for the SOAP receiver.

In general, there are two types of SOAP message intermediaries:

* Forward intermediary: This type of intermediary implements message processing by describing and constructing semantics and rules in the SOAP message header block of the forwarded message.

* Active Intermediary: This type of intermediary uses a set of features to modify externally bound messages for the receiver node, providing more message processing operations.

In the SOAP message exchange path, the distributed processing model is implemented in the SOAP message exchange by means of the soap intermediary. By using SOAP intermediaries, you can integrate various functions (such as forwarding, filtering, transactions, security, logging, smart routing, and so on) into a SOAP application.

(2), the role of SOAP nodes

The SOAP node that receives the SOAP message must be able to process and produce the necessary SOAP faults and SOAP responses in real time, and, if appropriate, generate additional SOAP messages based on subsequent descriptions of the SOAP specification.

The SOAP header entry contains the optional Env:actor property, which is used to position the entry to the appropriate SOAP node, and the SOAP header without the attribute implicitly navigates to an anonymous soap actor. This means that the anonymous role is the final soap recipient.

The SOAP actor name is used to identify the SOAP node and is not associated with the semantics of routing or message exchange. A SOAP actor can be named as a URI to send a SOAP message to the appropriate SOAP node.

Note: When the MustUnderstand property of the SOAP header block that is anchored to a SOAP node is "1", the SOAP node pointed to must:

* Process the SOAP block according to the semantics passed by the outermost element name that is fully decorated in the entry;

* Failed to process SOAP messages at all.

3. Process of SOAP message processing

4. Application Mode of SOAP message

(1), Request/Response mode

When a business application is called, a request containing a business document is sent from the SOAP sender to the SOAP receiver, while the business application on the SOAP receiver will process the request and generate a response, which is returned to the soap sender who made the request.

(2), "Fire-and_forget" mode

In this mode, a SOAP message is emitted, and then the operation associated with the message is no longer processed, and the pattern is divided into two cases: one for a single recipient and one for multiple receivers.

* * "Fire-and-forget" mode for individual receivers

This pattern means that the sender expects to send a message to a single recipient that is not answered. The SOAP sender does not need to know any message state information, including whether the message has been sent, or whether the message has been received by the receiver, etc. The underlying transport protocol might implement a response mechanism, but state information describing whether the message was sent successfully does not return to the SOAP processor that sent the SOAP message.

* * "Fire-and-forget" mode for multiple receivers

This mode means that the sender expects to send a message to a group of recipients that is not answered.

The "Fire-and-forget" pattern for multiple receivers is an extension of the "fire-and-forget" pattern for a single recipient. In this mode, the same SOAP message needs to be sent to multiple soap receivers. The transmission of messages can be achieved using broadcast distribution techniques, provided that the underlying transport protocol layer supports this technology.

(3), other advanced message exchange Mode

* * Session Mode

In a session-based message exchange Mode, both sides of the session will make a lengthy session process that contains multiple message exchanges. Examples of such processes are complex supply chain management, dynamic scheduling of production schedules, or information remediation.

* * Asynchronous Message pattern

In asynchronous message mode, the sender asynchronously sends the message to the receiver and expects to get some response after some time. The sender assigns an identity to the request, and the request is annotated so that the recipient's response can be associated with the initial request, and the sender can assign an identity to the request to the other service, which is the recipient of the final response, which means The response is not necessarily sent back to the sender.

* * Multi-message Asynchronous Response mode

In the multi-message asynchronous response mode, the application sends a request message to the server asynchronously, and the return result from the request is returned in the form of multiple response messages after a period of time. This application pattern is often used in situations where the requested information cannot be fully provided at once and the system performance is ensured. For example, in the context of distributed web search applications.

* * Event Notification mode

In event notification mode, an application subscribes to an event source with a number of explicitly named event notifications. When a subscribed event occurs, if the notification is sent to the application that originally issued the subscription, then the subscription is called a single-party subscription, and if the notification is sent to another application, the subscription is called a third-part subscription.

(4), incremental parsing and processing mode

The incremental parsing and processing mode of SOAP messages requires the sender to have the ability to send incrementally, with the receiver having the ability to receive incrementally.

This approach is particularly effective for SOAP processors with limited memory, and is very effective for incremental-oriented real-time data transfer services.

If the SOAP body contains a large amount of data and is suitable for segmented processing in a specific application, the use of an incremental processing pattern through the SAX parser is very well-suited. If a SOAP request is streamed and incrementally processed in a stream, the corresponding response message can also be streamed to the original request sender. In such an application example, we should pay particular attention to the real-time and error-handling design of receiver application. If the header entry for the SOAP request throws an error, then the SOAP fault is inserted into the response message, and the processing of the request message is aborted at the same time.

(5), Cache mode

In cache (caching) mode, some applications are cached for efficiency reasons. Therefore, the caching mechanism needs to be set in the context of the response.

Caching mechanisms are often used as an optimization mechanism in distributed systems, which can be used to avoid repeated execution of the same computational operations, or to avoid the overhead of using a result set to repeatedly perform complex database accesses over a period of time. In addition, after the caching mechanism is applied, a copy of the data can be stored on a leaf node server to facilitate local service without having to repeatedly access the central repository. This not only speeds up access to information, but also reduces the use of network bandwidth and reduces the load on the central server.

5. SOAP encoding Type and rules

(1), SOAP type encoding rules

Introduce several terms:

* * "Value" is a string (string), a measurable object (number, date, enumeration) name, or a combination of several simple values. All values have a definite type.

* * "Simple value" is an irreducible value that does not contain any part that can be named. A specific string, certificate, or enumeration value can be treated as a simple value.

* * "Compound value" (compound value) is the aggregation of a value's relationship. Examples of composite values are specific purchase orders, inventory reports, street addresses, and so on.

* * Access identification, in a composite value, each of the relevant values can be distinguished by a role name, or can be distinguished by an ordinal, of course, you can use both. Arrays are also composite values. It can be seen as a composite value with multiple access identities of the same name, such as RDF.

* * "Array" is a composite value that differs only in order between its member values.

* * struct is a composite value that is differentiated between its member values by an access identifier, and the names of all access identities should be different.

* * Simple Type is a class of simple values. Examples of simple types include the String class, the integer class, the enumeration class, and so on.

* * "Compound type" (compound type) is a class of composite values. Examples of composite types include the abstract types of purchase orders, which have the same access identifier (ShipTo, TotalCost, and so on) as the purchase orders that derive from the type, and of course they have different values.

* * In a composite type, the access identifier is unique within the composite type, and if it cannot be distinguished from an access identity in another composite type, the access identifier name, plus the name of the compound type, becomes a unique identity, which is the local name. Whether the name is directly or indirectly based on a URI, if the access identifier is unique without the addition of the type name constraint, then the name becomes the "Global name".

* * If only one access identifier can reference a value, it is called a single reference. If it can be referenced by multiple access identifiers, whether in fact or potential, it is a multi-reference. Note that one of the possible values in a pattern is a single reference, while the other values are multiple references.

* * In syntax, an element can be "independent" or "embedded". An independent element appears as a top-level element in the sequence. The other elements are embedded elements.

The encoding rules for SOAP are as follows:

* * All values should be represented as elements (content). A multi-reference value must be represented as the content of an independent element.

* * For each element that contains one value, the type of the value indicates that at least one of the following conditions must be met: (1), the element instance containing the value contains a Xsi:type attribute, (2), An instance of an element containing the value is contained in an element with the Enc:arraytype attribute (which may be set to default), (3), and the element's name has an explicitly typed association, and the type has a pattern to determine.

* * A simple value should be represented as character data, that is, there are no child elements. Each simple value must have a type that can be listed in the Datatypes section of the XML Schema specification, or its source type can be listed in that section.

* * A composite value should be encoded as an element sequence, where each access identifier is represented by an embedded element, and their name is one by one corresponding. If the name of the access identifier is local to the type that contains it, its element name can be unmodified, while others should have a fully decorated element name.

* * A multiple-reference simple or compound value should be encoded as a standalone element that contains a local "id" attribute with an unrestricted name that is of the type defined in the XML specification. Each access identifier for the value is an empty element that has a local unmodified attribute "href", which is the "uri-reference" type defined in the XML Schema specification, "href" The value of the property is a URI fragment identity that refers to the corresponding independent element.

* * Strings and byte numbers are represented as multi-reference simple types, but there are special rules that make them more efficient to represent in general situations. The access identifier for a string or byte array can have a property of the ID type named "id" defined in the XML specification. If so, all other access identifiers for that value can be encoded as an empty element, which should contain a local "href" attribute with an unrestricted name that is of type "uri-reference" as defined in the XML Schema specification, "href" The value of the property is a URI fragment identity that refers to the corresponding independent element.

* * You can encode multiple references to a value, which appears to refer to several different values, but you can tell from the context that the meaning of the XML instance is constant.

* * Array is a composite value. The SOAP array is defined as the type is "Enc:array" or the type is derived from "Enc:array".

* * Null values and default values can be omitted from the access identity element. A null value can be specified in an Access identity element using a property xsi:null with a value of 1, or it can be another application-dependent property and value.

WebServices principle and research and development practice--Reading notes 1