The full name of soap is Simple Object Access.
Protocol, that is, Simple Object Access Protocol. Simply put, soap is a wired protocol, similar to the IIOP of CORBA, orpc of DCOM, or remote method call of Java.
Java Remote Method
Protocol, jrmp ). You may wonder why we need another one since we already have so many wired protocols? As a matter of fact, isn't this exactly the problem discussed above? These questions
But soap is different from other wired protocols.
Let's analyze:
Soap is not just a pretty slogan. It is a technology that will penetrate deep into the future of distributed computing. People want soap to combine with other technologies, such as UDDI (Universal
Discovery description, and integration) and WSDL (Web Services Description
Language), with the support of the web service concept, changing the way commercial applications can communicate across the Web in the future. I cannot even fully express how to add soap to the developer's toolkit.
The importance of knowledge. This is a series of articles about soap, four in total. This is the first article to introduce some basic knowledge. We will start with the idea of soap.
I. Introduction to soap
As mentioned above, soap uses XML as the data encoding format. Using XML as the data encoding format is not original to soap. In fact, this is a natural choice. XML-RPC and ebXML also use XML. For more information, see "reference resources" at the end of this article ".
Consider the following Java interface:
| Listing 1 Public interface hello |
The customer program provides a name when calling the sayhelloto () method. It wants to receive a personalized "hello" Message from the server. Now, assume that RMI, CORBA, and
DCOM does not exist. Developers must be responsible for serializing method calls and send messages to remote machines. Almost everyone would say "This should use XML", I agree. Therefore, let's start from
Request format starts. Assume that you want to simulate a sayhelloto ("John") call. The request I intend to send is:
| Listing 2 <? XML version = "1.0"?> |
Here, I use the interface name as the root node. In addition, I also regard both the method name and parameter name as nodes. Next, we will send this request to the server. We do not create our own TCP/IP Elimination
HTTP. Therefore, the following steps encapsulate the request into the http post request format and then send it to the server. Actually create the HTTP
The detailed POST request process is described later in this article. Now, let's assume that it has been created. The server receives the request, decodes the XML, and then sends a response to the client program in XML format.
Assume that the response content is as follows:
| Listing 3 <? XML version = "1.0"?> |
The root node is still the interface name hello. But this time, the node name corresponding to the method is no longer sayhelloto, but the method name is added with the "response" string. Customer
The program knows which method it calls. To find out the returned value of the called method, it only needs to check the elements whose name is the method name plus the "response" string.
The above is the fundamental idea of soap. Listing 4 shows the results of the same request encoded in soap xml:
| Listing 4 <SOAP-ENV: Envelope |
It looks a little more complicated, right? In fact, it is similar to the request we wrote earlier, but it only slightly extends something. First, note that the soap document uses an envelope (root section
Point), a header area, a body area, neatly organized together. The header area is used to encapsulate data that is not directly related to the method itself and provide environment information, such as transactions.
ID and security information. The body area contains information about the method itself. In Listing 2, the XML we write only contains one body area.
Second, pay attention to listing
4. XML Namespaces are widely used. SOAP-ENV ing to namespace http://schemas.xmlsoap.org/soap/envelope
/, Xsi ing to http://www.w3.org/5o/xmlschema-instance, and xsd to http:
// Www.w3.org/5o/xmlschema. These three are the standard namespaces of all soap documents.
Finally, in Listing 4, the interface Name (that is, hello) is no longer
2. Instead, it references a namespace NSL. In addition, the parameter type information is sent to the server along with the parameter value. Note envelope
(Envelope) value of the encodingstyle attribute. This property value is set to http://schemas.xmlsoap.org/soap
/Encoding /. This value indicates the encoding method used by the server for encoding (I .e. serializing) methods. The server needs this information to properly remove the serializing method. For servers
The self-description capability of the soap document is quite complete.
The server responds to the preceding SOAP request as follows:
| Listing 5 <SOAP-ENV: Envelope |
Listing 5 and Listing
4. The request message is similar. In the above Code, the returned value (that is, the personalized "hello" message) is included in the body area. The format of the SOAP message document is flexible. For example, the encoding method is not fixed,
It is specified by the customer program. As long as it is the encoding method recognized by both the client program and server, it can be any legal XML document.
In addition, separating call environment information means that the method itself does not care about this type of information. In the current market, mainstream application servers follow this concept. Previously, I pointed out that environmental information can contain transaction and security information. In fact, the environment can cover almost everything. The following is an example of a SOAP message header with transaction information:
| Listing 6 <SOAP-ENV: Header> |
The namespace t maps to the URI related to the specific application. 5 indicates the ID of the transaction in which the method belongs. Pay attention to the application of the mustunderstand attribute of the SOAP envelope. This
Attribute (1) indicates that the server either understands and processes the transaction request as required, or cannot process the request. This is required by the SOAP specification.
Ii. Error Handling
Using soap does not mean that all requests are successful at any time. Errors may occur in many places. For example, the server may not be able to access a critical resource (such as a database), and thus cannot process requests smoothly.
Let's return to the "hello" instance and add a hypothetical constraint to it, that is, "it is illegal to say hello to others on Tuesday ." Therefore, even if the request sent to the server is valid on Tuesday, the server will return an error message to the client. The response content is as follows:
| Listing 7 <SOAP-ENV: envelope xmlns: SOAP-ENV =" |
Let's analyze the faultelement defined by http://schemas.xmlsoap.org/soap/envelope/namespace. The fault element is always
The direct sub-element of the Body element. All soap servers must always report all errors through this element. The fault element must contain the faultcode and
Faultstring element. No exception is allowed. Faultcode is a code that identifies a problem. The customer program uses faultcode for algorithm according to the requirements of soap specifications.
Processing. The SOAP specification defines a group of error codes for your use. On the other hand, faultstring is an error message for humans to read.
Listing
The 7 Code also contains a detail element. Because an error occurs in the SOAP message body area, the detail element must appear. As you will see later in this article, if the error
When processing the header area, the detail element should not appear. In listing
7. The application uses the detail element to provide a more detailed and natural explanation of the current error. That is, the application cannot say hello on Tuesday. Soap also provides another error code for specific applications, that is, semi-acceptable
The selected faultfactor element, but this element is not displayed in the error message above. This element is called semi-optional because if the error message is not sent by the server at the request's final processing point
An error message must contain this element. Soap makes no provisions on situations where the faultcode element should not appear.
In listing 7, the error originated from the method call itself. The application that processes the method causes this error. Now let's take a look at another type of error, which is caused by the failure of the server to process the request header information. For example, if all the hello messages must be generated in a transaction environment, the request is similar:
| Listing 8 <SOAP-ENV: Envelope |
The header area of the preceding message contains a transaction element, which specifies the transaction ID in which the method call must belong. Here I say "yes" because
The mustunderstand attribute is used for the transaction element. As mentioned above, the SOAP server either processes the request according to the attribute instructions or declares that the request cannot be processed. Assume that
The SOAP server cannot process it. It must return an error message. The response should be similar:
| Listing 9 <SOAP-ENV: envelope xmlns: SOAP-ENV =" |
The above code is similar to listing.
7. The error message displayed. However, it should be noted that the detail element no longer appears. As I pointed out earlier: the SOAP specification stipulates that if an error occurs when processing the header area, the error will occur.
The message should not contain the detail element. In fact, we can quickly determine whether an error occurs in the body area or header area based on whether the detail element exists.
Iii. Soap and HTTP
In the first example, I sent a custom XML request to the server through HTTP, but I did not detail what operations were involved in this operation. Now let's look back at the problem. How can I
Is a SOAP request (instead of a custom XML) sent to the server over HTTP? Soap naturally follows the HTTP Request/Response Message model. This model is provided in HTTP requests
SOAP request parameters: Provide the soap response parameters in the HTTP response. In fact, soap 1.0 specifically specifies HTTP as its transmission protocol. Soap
1.1 relaxed slightly. Although soap
1.1 can still use HTTP, but it can also use other protocols, such as SMTP. In this series of articles, I will only discuss the use of soap over HTTP.
Let's return the hello example. If we send a SOAP request to the server through HTTP, the code should be similar:
| Listing 10 Post http://www.SmartHello.com/HelloApplication HTTP/1.0
|
Listing 10 indicates that the SOAP request is basically the same as the Listing 4 request, but the Listing
Some http-specific code is added at the beginning of 10. The first line of code indicates that this is an HTTP
1.1 For standard post requests, the post target is http://www.smarthello.com/helloapplication. The following line indicates
Type. When an HTTP message contains a soap object, the content type must be text/XML. Content-Length indicates the length of the payload of the POST request.
The fourth line is unique to soap, and it is essential. The soapaction HTTP Request Header specifies the target of the soap HTTP request. Its value is the URI that identifies the target. Soap does not impose any restrictions on the URI format. In fact, this URI does not have to correspond to a specific actual location.
A possible application of soapaction is that the firewall checks the value of this request header to determine whether to allow requests to pass through the firewall.
Once the server processes the request, it returns a response to the customer. The response content is shown in listing 11 (assuming there is no error ):
| Listing 11 HTTP/1.0 200 OK
|
This soap response and Listing
5 shows the same, but added some HTTP-specific code. Because no error occurs, the response status of the first line of code is 200. In HTTP, the 200 response status code indicates"
Everything works ". If any error occurs when processing the SOAP message (header or body), the returned status code is 500. 500 status code in HTTP
"Internal server error ". In this case, the first line of code for the above soap response will be:
| HTTP 500 Internal Server Error |
Iv. HTTP extension framework
Many applications require more services than traditional HTTP Services. The result is that such applications expand the traditional HTTP protocol. However, such expansion is private to the application itself. HTTP extension framework
Try to establish a general HTTP extension mechanism to solve this problem. One of the extensions of the HTTP extension framework is the addition of a M-POST method, where M represents mandatory (mandatory
Mandatory ). If an HTTP request contains at least one mandatory extension statement, this request is called a mandatory request. The mandatory extension statement is introduced through the man or C-man header.
Line. The name of the mandatory request method must be prefixed with "M-". For example, the mandatory post method is called M-post.
Soap 1.0 requires the client program to first send an http post request to send a M-POST request only when the Server Returns Error 510. Soap
1.1 no longer imposes such restrictions on customers, that is, soap
1.1 allow the customer to start from sending any type of request. The following request is the one we have been discussing so far, but it is now in M-POST format:
| Listing 12 M-POST http://www.SmartHello.com/HelloApplication HTTP/1.1 |
For actual soap messages, listing 12 and Listing
10. But there are some differences in the Request Header, for example, what we are sending now is not a POST request, but a M-POST request. As described earlier, like the M-POST
In this example, a forcible request must have at least one forcible expansion statement. Here we have a: Man domain describes a mandatory end-to-end expansion statement, and maps the header prefix 01 to the namespace.
Http://schemas.xmlsoap.org/soap/envelope /. Note that this prefix is associated with the soapaction domain.
Once the server completes the request, it returns a response to the customer. For example, the response content class (assuming there is no error ):
| Listing 13 HTTP/1.0 200 OK |
Similarly, the response displayed by listing 13 is similar to the response to a common POST request (as shown in listing 11). The difference between the two lies in the ext domain.
In the process of using soap through HTTP, we are delighted to see that the actual SOAP message (the SOAP envelope and all content in it) remains unchanged, just as the message has not yet loaded the HTTP protocol.
The same is true during the discussion. According to this fact, it can be inferred that HTTP is not the only protocol that can cooperate with soap. For example, soap can be conveniently run with SMTP or other customized private protocols.
Line. The only requirement is that both the client and server understand the protocol.
5. Features of soap: simple
So far, we have discussed all aspects of soap definition, but there are many issues in the field that soap is not defined. The creators of the SOAP specification clearly excluded some closely related fields, such as constructing object models and many other established standards.
The cause of this phenomenon can be understood from the analysis of soap goals. In addition to scalability, another major design goal of soap is simplicity. To Keep soap simple, the creation of soap specifications
The Creator decided to define only what is absolutely necessary for creating a lightweight protocol. For example, soap does not define/specify any information about distributed garbage collection, type security, version control, and bidirectional HTTP
Communication, message box transportation, MPs, and object activation. The goal of soap is to become a simple protocol-a single open
The protocol that the sender can implement in any language for several days. With this in mind, it is actually a good thing that soap is not clearly defined in many aspects, because when constructing distributed systems, all existing technologies
You can easily use soap, even though the differences between different technologies are as obvious as those between the CORBA and DCOM.
■ Conclusion
In this article, I introduced some basic concepts of soap and some reasons for its design. However, compared with soap, this iceberg is only one part of it. To view information about
For more information about soap, see the SOAP specification link in the resource section. With the introduction of this series of articles, I will introduce all the knowledge you must know about the soap specifications here.
In the second part, I will introduce Apache's SOAP implementation. We will use this implementation to create a simple distributed application that uses soap as the wired protocol.
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
