Object Simple Object Access Protocol-cnxml standard Tutorials <br>
2000-9-25 Author: He Hangjun <br>
<br>
SOAP is a lightweight protocol for exchanging information in a non centralized, distributed environment. It is an xml-based protocol that consists of three parts: the envelope (envelope) defines the message content and the framework of the processing, a set of coding rules to express an instance of the application-defined data type, and a contract to express a remote procedure call and response. "<br>
--SOAP 1.1 Specification <br>
<br>
Section one introduction to SOAP <br>
<br>
SOAP (Simple Object access protocal) technology helps to 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 flexibility and scalability of a sophisticated HTTP based Web technology with XML. <br>
<br>
One of the main goals of soap is to make existing applications available to a wider range of users. For this purpose, there is no SOAP API or SOAP object request proxy (Soap ORB), and soap is a technique that assumes that you will use as many existing technologies as possible. Several major CORBA vendors have pledged to support the SOAP protocol in their ORB products. Microsoft is also committed to supporting SOAP in future COM versions. DevelopMentor has developed a reference implementation that allows soap to be used by any Java or Perl programmer on any platform. And IBM and Sun have also supported the SOAP protocol, working with MS to develop SOAP specifications and applications. Soap has now become one of the reference standards for both the consortium and the IETF. <br>
<br>
The philosophy of soap is "it is the first technology that has not invented any new technology". It employs two protocols that have been widely used: HTTP and XML. HTTP is used to implement the RPC-style transport of soap, and XML is its encoding pattern. With a few lines of code and an XML parser, HTTP servers (such as MS IIS or Apache) immediately become soap orbs. Because more than half of the Web servers currently use IIS or Apache, SOAP will benefit from the extensive and reliable use of both products. This does not mean that all SOAP requests must be routed through a Web server, and that traditional Web servers are just one way of assigning soap requests. Therefore, Web services such as IIS or Apache are sufficient for the application of SOAP performance, but are by no means necessary. <br>
<br>
SOAP encodes the use code of XML into the request and Response parameter encoding mode and transmits it using HTTP. It seems a little abstract. Specifically, a SOAP method can be simply seen as an HTTP request and response that follows a SOAP encoding rule. A SOAP terminal can be viewed as an HTTP based URL that identifies the target of a method invocation. Like CORBA/IIOP, SOAP does not require a specific object to be bound to a given terminal, but rather a specific implementation program to determine how to map object terminal identifiers to server-side objects. <br>
<br>
A SOAP request is an HTTP POST request. The content-type of the SOAP request must be text/xml. And it must contain a request-uri. How the server interprets the request-uri is related to implementation, but it may be used in many implementations to map to a class or an object. A SOAP request must also use the Soapmethodname HTTP header to indicate the method to be invoked. Simply put, the Soapmethodname header is the name of the method associated with the application of the specified scope of the URI, which separates the method name from the URI using the # character as a delimiter:<br>
<br>
Soapmethodname:urn:strings-com:istring#reverse <br>
<br>
This header indicates that the method name is reverse and the range URI is urn:strings-com:istring. In soap, a name domain URI that prescribes a range of method names is functionally equivalent to an interface ID that prescribes a range of method names in DCOM or IIOP. <br>
<br>
Simply put, the HTTP body of a SOAP request is an XML document that contains the values of [in] and [in,out] parameters in the method. These values are encoded into a distinct child element of the calling element, which has the method name and name Domain URI of the Soapmethodname HTTP header. The calling element must appear within the standard SOAP <Envelope> and <Body> elements (more about these two elements later). The following is one of the simplest SOAP method requests:<br>
<br>
post/string_server/object17 http/1.1<br>
Host:209.110.197.2<br>
Content-type:text/xml<br>
Content-length:152<br>
Soapmethodname:urn:strings-com:istring#reverse <br>
<Envelope><br>
<Body><br>
<m:reverse xmlns:m= ' urn:strings-com:istring ' ><br>
<thestring>hello, world</thestring><br>
</m:reverse><br>
</Body><br>
</Envelope><br>
The Soapmethodname header must match the first child element under <Body>, otherwise the call will be rejected. This allows the firewall administrator to effectively filter calls to a specific method without parsing the XML. <br>
<br>
The format of the SOAP response is similar to the request format. The response body contains the [out] and [in,out] Parameters of the method, which is encoded as a child element of a significant response element. The name of this element is the same as the name of the requested invocation element, but is concatenated with the response suffix. The following is a SOAP response to the previous SOAP request:<br>
<br>
OK Content-type:text/xml <br>
content-length:162 <br>
<Envelope> <br>
<Body> <br>
<m:reverseresponse xmlns:m= ' urn:strings-com:istring ' ><br>
<result>dlrow,olleh</result><br>
</m:reverseResponse><br>
</Body><br>
</Envelope> <br>
The response element here is named Reverseresponse, which is the method name followed by the response suffix. Note that there is no Soapmethodname HTTP header here. This header is only required in the request message and is not required in the response message. <br>
<br>
Section II the core of the SOAP body <br>
<br>
The XML attribute of soap is an encoding pattern that serializes an instance of a data type into XML. For this purpose, SOAP does not require the use of traditional RPC-style proxies. Instead, a SOAP method call contains at least two data types: request and response. Consider the following COM IDL code:<br>
<br>
<br>
[UUID (Deadf00d-bead-bead-bead-baabaabaabaa)]<br>
Interface Ibank:iunknown {<br>
HRESULT withdraw ([in] long account, <br>
[out] Float *newbalance,<br>
[In, out] float *amount<br>
[Out, retval] Variant_bool *overdrawn);<br>
}<br>
Under any RPC protocol, the value of the account and amount parameters will appear in the request message, the value of the newbalance, overdrawn parameters, and the updated value of the amount parameter will appear in the response message. <br>
<br>
SOAP promotes method requests and method responses to a state-of-the-art state. In soap, an instance of the actual type of request and response. To understand how a method, such as Ibank::withdraw, maps a SOAP request and response type, consider the following data types:<br>
<br>
struct Withdraw {<br>
Long account;<br>
Float amount;<br>
};<br>
<br>
All request parameters are then packaged into a single structure type. The same data below indicates that all response parameters are packaged to a single data type. <br>
<br>
struct Withdrawresponse {<br>
Float newbalance;<br>
Float amount;<br>
Variant_bool overdrawn;<br>
};<br>
The following simple Visual Basic program is given, which uses the previously defined IBank interface:<br>
<br>
Dim Bank as Ibank<br>
Dim Amount as Single<br>
Dim Newbal as Single<br>
Dim overdrawn as Boolean<br>
Amount = 100<br>
Set Bank = GetObject ("soap:http://bofsoap.com/am") <br>
overdrawn = Bank.withdraw (3512, amount, Newbal) <br>
<br>
<br>
Here, before sending the request message, the parameter is serialized as a request object. The response object that is also received by the response message is deserialized as a parameter. A similar transition is also occurring on the server side of the call. <br>
<br>
When a method is invoked through SOAP, the request object and the response object are serialized into a known format. Each SOAP body is an XML document that has a significant root element called <Envelope>. The tag name <Envelope> delimited by the soap Uri (URN:SCHEMAS-XMLSOAP-ORG:SOAP.V1), all SOAP-specific elements and attributes are scoped by this URI. The SOAP envelope contains an optional <Header> element, followed by a required <Body> element. The <Body> element also has a significant root element, which is either a request object or a response object. The following is a Ibank::withdraw request encoding:<br>
<br>
<soap:envelope xmlns:soap= ' urn:schemas-xmlsoap-org:soap.v1 ' ><br>
<soap:Body><br>
<ibank:withdraw xmlns:ibank= ' Urn:uuid:deadf00d-bead-bead-bead-baabaabaabaa ' ><br>
<account>3512</account><br>
<amount>100</amount><br>
</IBank:withdraw><br>
</soap:Body><br>
</soap:Envelope><br>
The following response message is encoded as: <br>
<soap:envelope xmlns:soap= ' urn:schemas-xmlsoap-org:soap.v1 ' ><br>
<soap:Body><br>
<ibank:withdrawresponse xmlns:ibank= ' Urn:uuid:deadf00d-bead-bead-bead-baabaabaabaa ' ><br>
<newBalance>0</newBalance><br>
<amount>5</amount> <br>
<overdrawn>true</overdrawn><br>
</IBank:withdrawResponse><br>
</soap:Body><br>
</soap:Envelope><br>
Note that the [in, out] parameter appears in two messages. After checking the format of the request and response objects, you may have noticed that the serialization format is usually: <br>
<br>
<t:typename xmlns:t= ' NamespaceURI ' ><br>
<fieldname1>field1value</fieldname1><br>
<fieldname2>field2value</fieldname2><br>
......<br>
</t:typename> <br>
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. In response, the type is also an implicit C-style structure, which consists of the [out] and [in, out] parameters in the corresponding method. The style of each field corresponding to a child element is sometimes called the element formal format (ENF). In general, SOAP conveys only the annotations that describe the information contained in the element's content using XML attributes. <br>
<br>
Like DCOM and IIOP, SOAP supports protocol header extensions. SOAP uses optional <Header> elements to carry information that is used by the protocol extension. If the client's SOAP software contains the header information to be sent, the original request may be as shown in Figure 9. In this case, the header of the named causality will be serialized along with the request. Upon receipt of the request, the server-side software can look up the name Domain URI and handle the header extensions it recognizes. This header extension is identified by the http://comstuff.com URI and expects an object such as the following:<br>
<br>
struct Causality {<br>
UUID ID; <br>
}; <br>
In this case, if the URI of the header element cannot be recognized, the header element can be safely ignored. <br>
<br>
But you can't safely ignore all the header elements in the SOAP body. If a particular SOAP header is critical for handling messages correctly, this header element can be marked as necessary with the SOAP attribute mustunderstand= ' true '. This property tells the recipient that the header element must be recognized and processed to ensure proper use. In order to force the front causality head to become a necessary head, the message will be written in the following form:<br>
<br>
<soap:envelope xmlns:soap= ' urn:schemas-xmlsoap-org:soap.v1 ' ><br>
<soap:Header><br>
<causality soap:mustunderstand= ' true ' xmlns= ' http://comstuff.com ' ><br>
<id>362099cc-aa46-bae2-5110-99aac9823bff</id><br>
</causality> <br>
</soap:Header><br>
</soap:Envelope><br>
When the SOAP software encounters an unrecognized header element condition, it must reject the message and present an error. If the server discovers an unrecognized required header element in a SOAP request, it must return an error response and do not send any calls to the target object. If the client discovers an unrecognized required header element in a SOAP request, it must return a run-time error to the caller. In the case of COM, this will be mapped to an explicit HRESULT. <br>
<br>
<br>
Section III SOAP data types <br>
<br>
In a SOAP message, each element may be a SOAP structure element, a root element, an access element, or an independent element. In soap, Soap:envelope, Soap:body, and Soap:header are the only constituent elements. Their basic relationships are described by the following XML Schema: <br>
<br>
<schema targetnamespace= ' urn:schemas-xmlsoap-org:soap.v1 ' ><br>
<element name= ' Envelope ' ><br>
<type><br>
<element name= ' header ' type= ' header ' minoccurs= ' 0 '/><br>
<element name= ' body ' type= ' body ' minoccurs= ' 1 '/><br>
</type><br>
</element><br>
</schema><br>
In four types of SOAP elements, in addition to structural elements, they are used as instances of an expression type or as references to an instance of a type. <br>
<br>
The root element is a significant element, and it is a direct child element of Soap:body or Soap:header. Where Soap:body has only one root element, which expresses a call, response, or Error object. This root element must be the first child element of Soap:body, and its tag name and domain name URI must correspond to the HTTP Soapmethodname header or Soap:fault in the case of an error message. The Soap:header element has multiple root elements, one for each header extension associated with the message. These root elements must be direct child elements of the soap:header, and their tag names and name Domain URIs represent types that currently have extended data. <br>
<br>
The access element is used as the domain, property, or data member of the expression type. A given type of domain will have only one access element in its soap expression. The tag name of the access element corresponds to the domain name of the type. Consider the following Java class definitions:<br>
<br>
Package Com.bofsoap.IBank; <br>
public class Adjustment {<br>
public int Account;<br>
Public float Amount;<br>
}<br>
The instance that is serialized in a SOAP message is shown below:<br>
<br>
<t:adjustment xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank ' ><br>
<account>3514</account><br>
<amount>100.0</amount><br>
</t:adjustment><br>
In this example, the Access element account and amount are referred to as simple access elements. For an access element that refers to a simple type, the element value is simply encoded as the character data directly under the access element, as shown above. For access elements that reference a combination type (that is, access elements that are constructed by themselves using child-access elements), there are two techniques for encoding the access elements. The simplest approach is to embed the structured values directly under the access element. Consider the following Java class definition:<br>
<br>
Package com.bofsoap.ibank;<br>
public class transfer {<br>
Public Adjustment from;<br>
public adjustment to; <br>
}<br>
If you encode access elements with an embedded value, a serialized transfer object in SOAP is shown below:<br>
<br>
<t:transfer xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank ' ><br>
<from><br>
<account>3514</account><br>
<amount>-100.0</amount><br>
</from><br>
<to><br>
<account>3518</account><br>
<amount>100.0</amount><br>
</to><br>
</t:transfer><br>
In this case, the values of the adjustment objects are encoded directly under their access elements. Several issues need to be explained when considering combining access elements. First consider the transfer class above. The From and to fields of a class are object references, which may be empty. SOAP represents a null value or reference with an XML Schemas null attribute. The following example represents a serialized transfer object whose From field is empty:<br>
<br>
<t:transfer xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank ' <br>
Xmlns:xsd= ' Http://www.w3.org/1999/XMLSchema/instance ' ><br>
<from xsd:null= ' true '/><br>
<to><br>
<account>3518</account><br>
<amount>100.0</amount> <br>
</to> <br>
</t:transfer><br>
The implied value of the Xsd:null property is False if it does not exist. Attributes that are nullable for a given element are controlled by the XML Schema definition. For example, the following XML schema will allow only the from Access element to be empty:<br>
<br>
<type name= ' transfer ' ><br>
<element name= ' from ' type= ' adjustment ' nullable= ' true '/><br>
<element name= ' to ' type= ' adjustment ' nullable= ' false '/><br>
</type><br>
If there is no nullable attribute in the schema declaration of an element, it means that an element in an XML document cannot be empty. The exact format of the null access element is currently in the revision
