Structure format of the SOAP protocol

What do you know about the Simple Object Access Protocol, namely the SOAP protocol? This article will explain the structure of this Protocol in detail. Hope to help you. First, let's take a look at the definition in this regard. SOAP: Simple Object Access Protocol)

Simple Object Access Protocol (SOAP) is a lightweight, simple, XML-based protocol designed to exchange structured and solidified information on the WEB. SOAP can be used in combination with many existing Internet protocols and formats, including hypertext transfer protocol HTTP), simple mail Transmission Protocol SMTP), and multi-purpose Internet Mail Extension protocol MIME ). It also supports calling RPC from the message system to the remote process) and a large number of applications.

SOAP consists of three parts:

SOAP encapsulation: it defines a framework that describes the content in a message, who should handle it, and whether it is optional or necessary.

SOAP encoding rules: it defines a serialization mechanism for exchanging instances of the data types defined by an application.

SOAPRPC indicates that it defines the protocol used to represent remote process calls and responses.

SOAP messages are basically unidirectional transmission from the sending end to the receiving end, but they are often combined to execute a mode similar to request/response. All SOAP messages are encoded in XML format. A soap message is an XML file that contains an essential SOAP encapsulation package, an optional SOAP header, and a required SOAP block.

Binding SOAP to HTTP provides the advantages of using SOAP styles, scattered flexibility, and HTTP's rich feature libraries. Transmitting SOAP over HTTP does not mean that SOAP will overwrite the existing HTTP semantics, but that the SOAP semantics on HTTP will naturally map to the HTTP semantics. When HTTP is used as the Protocol binding, RPC requests are mapped to HTTP requests, while RPC responses are mapped to HTTP responses. However, using SOAP on RPC is not limited to HTTP binding.

Message format

In the standardized message format environment, SOAP can do all its work. The message body is a MIME type in the form of "text/xml" and contains a SOAP envelope. This envelope is an XML file. The encapsulation includes optional headers) and mandatory packets ). The encapsulated packet is always used for final received messages, and the Header project can determine the target node for intermediate processing. Attachments, binary numbers, and other items can be attached to packets.

The SOAP Protocol provides a method for the client to specify which intermediate processing node must process the Header project. Because the header and the main content of the SOAP message are irrelevant, they can be used to add information to the message without affecting the processing of the message.

For example, the header can be used to provide digital signatures for requests contained in the message. In this case, the authentication/authorization server can process header items that are independent of packets that can strip information to verify the signature. Once verification is passed, the rest of the envelope will be passed to the SOAP server, which will process the message. In-depth study of the SOAP envelope helps to understand the location and purpose of the SOAP header and packet elements.

Analysis of SOAP envelope

The SOAP1.1 specification provides the following enclosure example: SOAP-ENV: mustUnderstand = 1 5DEF

In this example, the GetLastTradePrice request is sent to a storage location on the network.

Reference Service

The request carries an Order symbol and returns a floating point number in the SOAP response. The SOAP envelope is the top-level element of the XML document that represents the SOAP message. The XML namespace is used to distinguish the SOAP Identifier from the specific Identifier of the application. XML Namespaces are frequently used in the SOAP protocol to restrict the scope of the message elements to a specific field. Understanding the SOAP protocol namespace helps you familiarize yourself with the XML naming convention. If you do not understand a namespace, you can also think of it as a neighboring identifier. It associates a SOAP element with a specific location, either real or imagined, this helps uniquely identify the SOAP element.

Namespace

The first namespace in the preceding example references the SOAP mode that defines elements and attributes in a SOAP message. The second namespace refers to the SOAP encoding, that is, Section 5 data type discussed earlier. Because no additional generic element encoding is specified, this encoding applies to the entire document.

Header

In the SOAP envelope header example, the first element identified is a transaction) element with a namespace attribute and a mustUnderstand attribute with a value of 1. Since the mustUnderstand attribute value is set to 1, the server that receives the message must perform intermediate processing on the transaction node. You can explain this as follows: the server and the client have already reached an agreement on the semantics for managing the Header element processing, so the server knows exactly the content of the element to be processed, in this example, the content of the element is "5 ". If the server receiving the message does not understand the semantics of the transaction header, the server rejects the request and throws an error. The error element is a special part of the SOAP message and well-defined mechanism, used to send the error message back to the client.

Intermediate processing nodes like this are an example of SOAP scalability. The client contains such a node in a SOAP message to indicate the special processing needs before the message content can be processed. To ensure backward compatibility, you only need to set the mustUnderstand attribute to 0, which makes the operation optional. In addition to defining transaction nodes as shown in the preceding example, SOAP messages can also contain header items, which are used to specify nodes for identity authentication processing, encryption, permanent status, and business logic processing. The header helps to build the SOAP Protocol into a scalable mode package model. You only need to remember that header processing is completely unique in SOAP messages.

Packets

The SOAP packet in the above example contains an XML load. we can infer that RPC is not explained in detail for us. SOAP is not only a mode package model, but also a mysterious package model. There is no clear indication of what RPC is about to do. We can see several XML elements in the message, one of which is restricted by namespaces. It depends on the SOAP server's understanding of document semantics and correct processing. In fact, the server provides an architecture to handle XML load in a meaningful way. "Meaningful" means that the server calls the Remote Process on some background databases to receive the stock price for the stock-symbol element contained in the message. All these magic operations are behind SOAPRPC.