Introduction to soap
Soap (simpleobjectaccessprotocal, Simple Object Access Protocol) technology helps achieve interoperability between a large number of heterogeneous programs and platforms, so that existing applications can be accessed by a wide range of users. Soap combines the mature HTTP-based Web technology with the flexibility and scalability of XML.
Soap
Is to make existing applications more widely used by users. For this purpose, there is no soapapi or soap Object Request proxy (soaporb), and soap is
Suppose you will use as many existing technologies as possible. Several major CORBA vendors have promised to support the SOAP protocol in their ORB products. Microsoft also promises to support in future com versions
Soap. Developmentor has developed a reference implementation that allows any Java or Perl programmer on any platform to use soap. And IBM and sun
We have successively supported the SOAP protocol and cooperated with MS to develop soap specifications and applications. Currently, soap has become one of the W3C and IETF reference standards.
Description
The idea is "it is the first technology that has not invented any new technology ". It uses two widely used protocols: HTTP and XML. HTTP is used to implement RPC-style transmission of soap, while
XML is its encoding mode. Using several lines of code and an XML parser, the HTTP server (such as MS's IIS or Apache) immediately becomes the soap orbs. Because more than one
Half of web servers use IIS or Apache, and soap will benefit from the wide and reliable use of these two products. This does not mean that all SOAP requests must pass through the web service.
The traditional Web Server only distributes SOAP requests. Therefore, Web services such as IIS or Apache are sufficient for applications that establish soap performance, but they are not necessary.
.
Soap converts XML code into request and Response Parameter encoding modes and uses HTTP for transmission. This seems a bit abstract. Specifically, a soap method can be simple
As an HTTP request and response that follows the soap encoding rules. A soap terminal can be seen as an HTTP-based URL used to identify the target of a method call. Image
Similar to CORBA and IIOP, soap does not need to bind a specific object to a given terminal. Instead, the specific implementation program determines how to map the object terminal identifier to the server-side object.
Soap
A request is an httppost request. The Content-Type of the SOAP request must use text/XML. And it must contain a request-Uri. How does the server explain this?
The request-Uri is related to the implementation, but many implementations may use it to map to a class or an object. A soap request must also use the soapmethodnamehttp Header
The method to be called. To put it simply, the soapmethodname header is the application-related method name specified by the URI. It uses the # character as the separator to separate the method name from the URI:
Soapmethodname: urn: strings-com: istring # reverse
This header indicates that the method name is reverse and the range URI is urn: strings-com: istring. In soap, the name domain URI that specifies the method name range is functionally equivalent to the interface ID that specifies the method name range in DCOM or IIOP.
Simplified
Simply put, the HTTP body of a SOAP request is an XML document that contains the values of the [in] and [In, out] parameters in the method. These values are encoded as sub-elements of a significant call element.
This call element has the method name and Name Domain uri of the soapmethodnamehttp header. The Calling element must appear in the standard soap <envelope>
And <body> (the two elements will be discussed later ). The following is a simple soap Method Request:
Post/string_server/object17http/1.1
HOST: 209.110.197.2
Content-Type: text/XML
Content-Length: 152
Soapmethodname: urn: strings-com: istring # reverse
<Envelope>
<Body>
<M: reversexmlns: M = ''urn: strings-com: istring ''>
<Thestring> Hello, world </thestring>
</M: reverse>
</Body>
</Envelope>
The soapmethodname header must match the first child element in <body>; otherwise, the call is rejected. This allows the firewall administrator to effectively filter calls to a specific method without parsing XML.
The soap response format is similar to the request format. The response body contains the [out] and [In, out] parameters of the method. This method is encoded as a sub-element of a significant response element. The element name is the same as the name of the requested call element, but is connected with the response suffix. Below is the soap response to the previous SOAP request:
200okcontent-type: text/XML
Content-Length: 162
<Envelope>
<Body>
<M: reverseresponsexmlns: M = ''urn: strings-com: istring ''>
<Result> dlrow, olleh </result>
</M: reverseresponse>
</Body>
</Envelope>
The response element is named reverseresponse, which is the method name followed by the response suffix. Note that there is no soapmethodnamehttp header. This header is only required in the request message and not in the Response Message.
Section 2 core of the soap body
The XML feature of soap is to serialize data-type instances into XML encoding modes. For this purpose, soap does not require traditional RPC-style proxies. Instead, a soap method call contains at least two data types: request and response. Consider the following comidl code:
[UUID (DEADF00D-BEAD-BEAD-BEAD-BAABAABAABAA)]
Interfaceibank: iunknown {
Hresultwithdraw ([in] longaccount,
[Out] float * newbalance,
[In, out] float * Amount
[Out, retval] variant_bool * overdrawn );
}
Under any RPC protocol, the value of the account and amount parameters will appear in the request message, the value of the newbalance and overdrawn parameters, and the updated value of the amount parameter will appear in the Response Message.
Soap improves method requests and method responses to the first-class status. In soap, requests and responses are actually type instances. To understand a method such as ibank: How does withdraw map a SOAP request and response type, consider the following data types:
Structwithdraw {
Longaccount;
Floatamount;
};
All request parameters are packaged into a single structure type. The following data indicates packaging all response parameters to a single data type.
Structwithdrawresponse {
Floatnewbalance;
Floatamount;
Variant_booloverdrawn;
};
The following simple visual basic program is provided, which uses the previously defined ibank interface:
Dimbankasibank
Dimamountassingle
Dimnewbalassingle
Dimoverdrawnasboolean
Amount = 100
Setbank = GetObject ("Soap: http://bofsoap.com/am ")
Overdrawn = Bank. Withdraw (3512, amount, newbal)
Here, before sending a request message, the parameter is serialized as a request object. Response objects received by the same response message are deserialized as parameters. A similar change also occurs on the called server.
When
When a method is called through soap, the request object and response object are serialized into a known format. Each soap body is an XML document with a notable name
Is the root element of <envelope>. The tag name <envelope> is named by soapuri (URN: Schemas-xmlsoap-
Org: Soap. V1) to define the scope. All elements and attributes dedicated to soap are defined by this URI. Soapenvelope contains an optional
Followed by a required <body> element. The <body> element also has a significant root element, which is either
Evaluate an object or a response object. The following is an ibank: withdraw Request Encoding:
<Soap: envelopexmlns: Soap = ''urn: Schemas-xmlsoap-org: Soap. V1 ''>
<Soap: Body>
<Ibank: withdrawxmlns: ibank = ''urn: UUID: DEADF00D-BEAD-BEAD-BEAD-BAABAABAABAA''>
<Account> 3512 </account>
<Amount> 100 </amount>
</Ibank: withdraw>
</Soap: Body>
</Soap: envelope>
The following response message is encoded:
<Soap: envelopexmlns: Soap = ''urn: Schemas-xmlsoap-org: Soap. V1 ''>
<Soap: Body>
<Ibank: withdrawresponsexmlns: ibank = ''urn: UUID: DEADF00D-BEAD-BEAD-BEAD-BAABAABAABAA''>
<Newbalance> 0 </newbalance>
<Amount> 5 </amount>
<Overdrawn> true </overdrawn>
</Ibank: withdrawresponse>
</Soap: Body>
</Soap: envelope>
Note that the [In, out] parameter appears in two messages. After checking the format of the request and response object, you may have noticed that the serialization format is usually:
<T: typenamexmlns: t = ''namespaceuri ''>
<Fieldname1> field1value </fieldname1>
<Fieldname2> field2value </fieldname2>
......
</T: typename>
In
In the case of a request, the type is an implicit C-style structure, which consists of the [in] and [In, out] parameters in the corresponding method. For the response, the type is also an implicit C-style structure, which consists of the corresponding method
The [out] and [In, out] parameters in. This style of each field corresponds to a sub-element is sometimes called the formal element format (ENF ). Generally, soap only uses XML features for transmission.
A comment describing the information contained in the element content.
Like DCOM and IIOP, soap supports protocol header extensions. Optional To upload the information used by Protocol extensions. If the client's soap software contains the header information to be sent, the original request may be shown in 9. In this case, the header named causality will
Serialized together with the request. After receiving the request, the server software can view the header domain Uri and process the header extension it recognizes. This head extension is http://comstuff.comURI
Identify and expect the following object:
Structcausality {
Uuidid;
};
In this case, if the uri of the Header element cannot be identified, the Header element can be safely ignored.
However
You cannot safely ignore header elements in all soap bodies. If a specific SOAP header is critical for correct message processing, this Header element can be used with the soap attribute.
Mustunderstand = 'true' is marked as required. This attribute tells the recipient that the Header element must be identified and processed to ensure correct use. To force the front
The causality header is a required header. The message is written as follows:
<Soap: envelopexmlns: Soap = ''urn: Schemas-xmlsoap-org: Soap. V1 ''>
<Soap: Header>
<Causalitysoap: mustunderstand = ''true' xmlns = "http://comstuff.com">
<ID> 362099cc-aa46-bae2-5110-99aac9823bff </ID>
</Causality>
</Soap: Header>
</Soap: envelope>
Soap
When the software encounters a situation where it cannot identify a required Header element, it must reject the message and present an error. If the server finds an unrecognized Header element in a SOAP request, it must return
The error response does not send any call to the target object. If the client finds a required Header element that cannot be identified in a SOAP request, it must return a runtime error to the caller. In COM
This will map to an obvious hresult.
Section 3 soap Data Types
In a SOAP message, each element may be a soap structure element, root element, access element, or independent element. In soap, soap: envelope, soap: Body, and soap: header are unique components. Their basic relationships are described by the following XMLSCHEMA:
<Schematargetnamespace = ''urn: Schemas-xmlsoap-org: Soap. V1 ''>
<Elementname = ''envelope ''>
<Type>
<Elementname = ''head'' type = ''head'' 'minoccurs = ''0''/>
<Elementname = ''body'' type = ''body'' minoccurs = ''1'/>
</Type>
</Element>
</Schema>
Among the four types of soap elements, all except the structure elements are used as expression type instances or references to a type instance.
Root
An element is a significant element. It is a direct sub-element of soap: body or soap: header. Soap: the body has only one root element, which expresses call, response, or error pairs.
Image. This root element must be the first child element of the soap: body, and its Tag Name and domain name URI must be the same as the httpsoapmethodname header or
Soap: corresponds to fault. Soap: The Header element has multiple root elements, and each header extension associated with the message corresponds to one. These root elements must be soap: Header
Directly sub-elements. Their tag names and domain Uris indicate the types of extended data.
An access element is used as a domain, attribute, or data member of the expression type. A given type of domain has only one access element in its soap expression. The access element tag name corresponds to the type domain name. Consider the following Java class definitions:
Packagecom. bofsoap. ibank;
Publicclassadjustment {
Publicintaccount;
Publicfloatamount;
}
The serialized instance in a SOAP message is as follows:
<T: adjustmentxmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank ''>
<Account> 3514 </account>
<Amount> 100.0 </amount>
</T: adjustment>
In
In this example, the access elements account and amount are called simple access elements. For access elements that reference simple types, the element values are simply encoded as character data directly under the access element, such
. There are two technologies to encode the access elements of the reference combination type (that is, the access elements constructed by sub-access elements. The simplest way is to embed a structured value directly.
In the access element. Consider the following Java class definition:
Packagecom. bofsoap. ibank;
Publicclasstransfer {
Publicadjustmentfrom;
Publicadjustmentto;
}
If an embedded value is used to encode the access element, a serialized transfer object in soap is as follows:
<T: transferxmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank ''>
<From>
<Account> 3514 </account>
<Amount>-1, 100.0 </amount>
</From>
<To>
<Account> 3518 </account>
<Amount> 100.0 </amount>
</To>
</T: Transfer>
In
In this case, the value of the adjustment object is directly encoded under their access element. When considering the combination of access elements, several issues need to be explained. Consider the above transfer class first. Class
The from and to fields of are object references, which may be null. Soap uses the null attribute of xmlschemas to indicate null values or references. The following example shows a serialized
Transfer object. Its from field is null:
<T: transferxmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank''
Xmlns: XSD = ''http: // www.w3.org/5o/xmlschema/instance''>
<Fromxsd: null = ''true'/>
<To>
<Account> 3518 </account>
<Amount> 100.0 </amount>
</To>
</T: Transfer>
If the property does not exist, the implicit value of XSD: NULL is false. Whether the given element can be empty is controlled by the XMLSCHEMA definition. For example, the following XMLSCHEMA will only allow the from access element to be null:
<Typename = ''transfer ''>
<Elementname = ''from ''' type = ''adjustment ''' nullable = ''true'/>
<Elementname = ''to ''type = ''adjustment ''' nullable = ''false''/>
</Type>
Without the nullable attribute in the schema declaration of an element, it means that the element in an XML document cannot be empty. The exact format of the null access element is still being revised. For more information, see the latest SOAP specification.
And
Another problem related to the access element is the substitution caused by the type relationship. Because the previous adjustment class is not a final class, the from
And the to domain actually reference the instance of the inheritance type is possible. To support this type-compatible replacement, soap uses the XMLSCHEMA convention for the Type attribute specified by a domain name. The value of this type of attribute
Is a name that limits the specific types of elements. Consider the following adjustment extension class:
Packagecom. bofsoap. ibank;
Publicclassauditedadjustmentextendsadjustment {
Publicintauditlevel;
}
The following Java language is provided:
Transferxfer = newtransfer ();
Xfer. From = newauditedadjustment ();
Xfer. From. Account = 3514;
Xfer. From. Amount =-100;
Xfer. From. auditlevel = 3;
Xfer. To = newadjustment ();
Xfer. to. Account = 3518;
Xfer. From. Amount = 100;
The serialization form of the transfer object in soap is as follows:
<T: transferxmlns: XSD = ''http: // www.w3.org/5o/xmlschema''
Xmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank ''>
<Fromxsd: TYPE ='t: auditedadjustment ''>
<Account> 3514 </account>
<Amount>-1, 100.0 </amount>
<Auditlevel> 3 </auditlevel>
</From>
<To>
<Account> 3518 </account>
<Amount> 100.0 </amount>
</To>
</T: Transfer>
Here, the XSD: Type attribute references a type name defined by the domain name, which can be used by deserialization programs to instantiate the correct type of the object. Because the to access element references an instance of the expected type (rather than an alternative inheritance type), The XSD: Type attribute is not required.
The transfer class just avoided a key issue. What happens if the serialized transfer object is initialized in the following way:
Transferxfer = newtransfer ();
Xfer. From = newadjustment ();
Xfer. From. Account = 3514; xfer. From. Amount =-100;
Xfer. To = xfer. From;
Based on previous discussions, the serialization form of transfer objects in soap is as follows:
<T: transferxmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank ''>
<From>
<Account> 3514 </account>
<Amount>-1, 100.0 </amount>
</From>
<To>
<Account> 3514 </account>
<Amount>-1, 100.0 </amount>
</To>
</T: Transfer>
This
There are two problems. The first easy to understand problem is that the same information is sent twice, which leads to a larger message than the actually needed message. A more subtle but more important issue is the reverse order.
The column-based program cannot distinguish between two adjustment objects with the same value and a single adjustment object referenced in two places. The identity relationship between the two access elements is
Lost. If the message recipient has executed the following test on the result object, (xfer. To = xfer. From) no true is returned.
Voidprocesstransfer (transferxfer ){
If (xfer. To = xfer. From)
Handledoubleadjustment (xfer. );
Else
Handleadjustments (xfer. To, xfer. From );
}
Is
Supports serialization of types that must maintain identity relationships. Soap supports multi-reference access elements. Currently, the access element we access is a single-reference access element, that is, the element value is embedded under the access element.
And other access elements are allowed to reference that value (similar to the [unique] concept in NDR ). The multi-reference access element is always encoded as containing only known soap: href
Null element. Soap: The href attribute always contains a code snippet identifier, which corresponds to the instance referenced by the access element. If the to and from access elements have been encoded as multi-reference access elements
Serialized transfer object:
<T: transferxmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank ''>
<Fromsoap: href = ''# id1'/>
<Tosoap: href = ''# id1'/>
</T: Transfer>
This encoding assumes that an instance of the Type compatible with the adjustment class has been serialized elsewhere in envelope, and the instance has been marked with the soap: Id attribute, as shown below:
<T: adjustmentsoap: Id = ''id1' xmlns: t = ''urn: develop-com: Java: COM. bofsoap. ibank ''>
<Account> 3514 </account>
<Amount>-1, 100.0 </amount>
</T: adjustment>
Conclusion
I
HTTP issues still need to be further clarified. Soap supports (but does not need) the HTTP extension Framework Convention to specify the required HTTP header extension. These conventions have two main purposes. First, they
Any URI can be used to limit the range of a given HTTP header (similar to an XML domain name ). Second, these conventions allow the necessary headers to be separated from the optional headers (like
Soap: mustunderstand ). The following is an HTTP extension framework used to define the soapmethodname header as a required header extension:
M-POST/foobarhttp/1.1
HOST: 209.110.197.2
MAN: "urn: Schemas-xmlsoap-org: Soap. V1; NS = 42"
42-soapmethodname: urn: bobnsid: ifoo # doit
Man
Ing the soapuri header to the header with a prefix of 42, indicating that the server that does not recognize soap must return an HTTP Error. the status code is 501 (not implemented) or 510 (not expanded)
Exhibition ). The HTTP method must be a M-POST, indicating that it is currently a mandatory header extension. Soap is a typed serialization format. It happens to use HTTP as the request/response message transmission protocol.
Soap is designed to work closely with the emerging XMLSCHEMA specifications and support the COM, CORBA, Perl, TCL, and
Interoperability Between Java, C, Python, PHP, and other programs.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
