Object | access
Summarize:
(This article assumes that the reader is already familiar with COM and XML technology.) ）
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.
This article takes you through a comprehensive review of the process of object remote process invocation (ORPC) technology to help you understand the basics of soap technology and how it overcomes many of the pitfalls of existing technologies such as CORBA and DCOM. It then describes the detailed soap coding rules and focuses on how SOAP maps to the existence of the ORPC concept.
Introduction:
When I started computing as my career in 1984, most programmers didn't care about network protocols. But in the 90 's, the web became ubiquitous, and now it's hard to imagine anyone using a computer but not using some form of network connectivity. Today, the average programmer is more interested in building scalable, distributed applications, rather than focusing on coolbars, a floating translucent, non rectangular rectangle, that uses MFC to personalize it.
Programmers often prefer to use programming models to think about problems, and rarely consider network protocols. Although this is usually a good thing to do, the soap I will discuss in this article is a network protocol with no obvious programming model. This does not mean that the architecture of soap fundamentally alters the way you program. Instead, 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.
The idea behind soap is "it's the first technology that hasn't invented any new technology". SOAP 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 to establish SOAP-enabled applications, but are by no means necessary.
As this article will describe, soap simply encodes the HTTP transport content with XML. The most common application of soap is as an RPC protocol. In order to understand how soap works, it is necessary to briefly review the history of RPC protocols.
The history of RPCs
The two main communication models for building distributed applications are message delivery (often grouped together with queues) and request/response. The messaging system allows any party to send messages at any time. The request/Response protocol restricts the communication mode to both sides of the request/response. Message based applications are acutely aware that they are communicating with external parallel processes and need an explicit design style. Application based on request/response is more like a single process, because the application of sending requests is more or less blocked until a response from another process is received. This makes the request/response communication naturally appropriate for RPC applications.
Although message communication and request/response have their merits, they can be implemented with each other. Message systems can be built with a lower-level request/response protocol. A DCE RPC is used internally by Microsoft's message Queue Server (MSMQ) to establish most of the control logic. RPC systems can also be built using a lower-level message system. The association ID provided by MSMQ is for this purpose. Regardless of the evaluation, most applications still tend to use RPC protocols because they are widely used, they are simpler to design, and more natural to the mapping of traditional programming techniques.
In the 80 's, two major RPC protocols were Sun RPC and DCE RPC. The most popular Sun RPC application is the network File system (NFS) used by most Unix systems. The most popular DCE RPC application is Windows NT, which uses the DCE RPC protocol to implement many system services. These two protocols are proven to be applicable to a wide range of applications. However, in the late 80, the popularity of object-oriented technology has made the software industry addicted to building a link between object-oriented language and RPC based communication.
The object RPC (ORPC) protocol, which was generated in the 90 generation, is an attempt to link object-oriented and network protocols. The main difference between the ORPC and RPC protocols is that the ORPC code maps from a communication terminal to a language-level object. There is a cookie in the header of each ORPC request, which can be used by the server-side program to locate the target object in the server process. Usually this cookie is just an array of indexes, but other techniques are often used, such as the key to the hash table with the symbol name.
Figure 1 ORPC Request and response
Figure 1 represents a typical ORPC request and response. Several request header components are used by server-side handlers for distribution calls. The object endpoint ID is used to locate the target object in the server process. The interface identifier and the method identifier are used to determine which method is invoked in the target object. The transport body is used to pass the values of the [in] and [in,out] parameters in the request (in response, [out] and [in,out]). Note that an optional protocol extension can appear between the header file and the transport body. This is a convention in protocol design because it allows new services to be carried on ORPC requests and services. Most ORPC systems use this area to pass additional contextual information, such as transaction information and causality identifiers.
Currently, the two major OPRC protocols are DCOM and CORBA's Internet Inter-ORB Protocol (IIOP) or more general Inter-ORB Protocol (GIOP). The request format for DCOM and IIOP/GIOP is very similar. All two protocols use an object endpoint ID to determine the target object and use the method identifier to determine which method to invoke.
There are two main differences between the two protocols: the main difference is that when IIOP/GIOP is used, the interface identifier is implied, because a given CORBA object implements only one interface (although the OMG is currently working on a standardized work that has multiple interfaces supported for each object). Another subtle difference between DCOM and IIOP/GIOP requests is the format of the parameter values in the transport body. In DCOM, the transport body is written in the form of a network data expression (NDR) in which the IIOP/GIOP is written in the form of a public data expression (CDR). NDRs and CDR handle different data representations on a variety of platforms, respectively. But there are some small differences between the two formats that make them incompatible with each other.
Another important difference between ORPC and RPC protocols is the way in which communication endpoints are named. In the ORPC protocol, some transitive representations of ORPC endpoints are required to pass object references between networks. In Corba/iiop, this expression is referred to as an interactive object reference (IOR). Iors contains addressing information expressed in a compact format and uses it to determine an object endpoint for any CORBA product. In DCOM, this expression is called ObjRef, which combines the reference calculation of a distribution and the endpoint/object identity. Both CORBA and DCOM provide advanced mechanisms for finding object endpoints on the network, but eventually these mechanisms are mapped back to iors or objrefs. Figure 3 shows how a ior/objref is associated with addressing information in a iiop/dcom request message.
What are the problems with the current technology?
Although both DCOM and IIOP are fixed protocols, the industry has not fully turned to any of them. The lack of integration is partly the result of cultural problems. And when some organizations try to standardize one or another agreement, the technical applicability of the two Protocols is challenged. It is traditionally considered that DCOM and CORBA are reasonable communication protocols to server-side. However, there are obvious weaknesses in both client and server communications, especially when the client is spread over the internet.
Both DCOM and Corba/iiop rely on a single vendor solution to maximize the use of the Protocol. Although the two protocols are implemented on a variety of platforms and products, the reality is that the selected releases need to be implemented by a single vendor. In the case of DCOM, this means that each machine will run in Windows NT. (Although DCOM has been moved to other platforms, it has only a broad extension on Windows.) In the case of CORBA, this means that each machine will run the same orb product. It is possible for two CORBA products to be invoked with IIOP, but many advanced services, such as security and transactions, are often not interoperable at this time. Furthermore, it is difficult to optimize the communication of any specialized manufacturer for the same machine unless all applications are built on the same orb product.
Both DCOM and CORBA/IIOP depend on a carefully managed environment. Two arbitrary computers have a low probability that DCOM or IIOP be successfully invoked outside the environment (calls out of the box). This is especially true when considering security. Although it is possible to write a tight-pack (shrink-wrap) application that can successfully use DCOM or IIOP, this is more about detail than the socket based application. This is especially true for tedious but required configuration and installation management tasks.
Both DCOM and Corba/iiop rely on a fairly high-tech operating environment. Although COM in-process seems particularly simple, com/dcom remoting is absolutely not just a matter of days. IIOP is a protocol that is easier to implement than DCOM, but two protocols have quite a number of esoteric rules for handling data flow, type information, and bitwise operations. This makes it difficult for a typical programmer to construct a simple CORBA or DCOM call without understanding the Orb product or OLE32.DLL.
Perhaps the most unbearable thing for DCOM and CORBA/IIOP is that they do not work on the Internet. For DCOM, the general user's imac or the inexpensive PC that runs Windows 95 will be almost impossible to perform domain based authentication with your server. Worse, if the firewall or proxy server separates the client and server machines, the likelihood that any IIOP or DCOM packages will pass is low, largely due to the preference of the HTTP protocol for most Internet connection technologies. Although some vendors such as Microsoft, Iona and Visigenic have established channel technology, these products are easily sensitive to configuration errors and they are not interactive.
In a server community these problems do not affect the use of DCOM or IIOP. Because the number of hosts in the server community is small (typically hundreds, not tens of thousands), this offsets the cost of DCOM's life-cycle management based on Ping. In a server community, there is a high probability that all hosts are managed by a common admin domain, making a unified configuration possible. A relatively small number of machines can also maintain the cost of controlling the use of commercial orb products, since only a small amount of orb licensing is required. If only IIOP is used in the server community, only a small amount of orb licensing is required. Finally, it is possible for all hosts in the server community to have direct IP connectivity, which eliminates the DCOM and IIOP issues associated with firewalls.
HTTP as a better RPC
Using DCOM and CORBA in the server community is a common practice, but the client uses HTTP to enter the server community. HTTP is similar to RPC protocol, which is simple, widely configured, and more likely to work with firewalls than other protocols. HTTP requests are typically handled by Web server software, such as IIS and Apache, but an increasing number of application server products are supporting HTTP as a protocol other than DCOM and IIOP.
Like DCOM and IIOP, the HTTP layer requests/responds to communication over TCP/IP. An HTTP client connects to the HTTP server with TCP. The standard port number used in HTTP is 80, but any other port can also be used. After a TCP connection is established, the client can send a request message to the server side. The server sends back an HTTP response message to the client after processing the request. Both request and response messages can contain information about any transport body, usually marked with Content-length and Content-type HTTP headers. The following is a valid HTTP request message:
Post/foobar http/1.1
host:209.110.197.12
Content-type:text/plain
Content-length:12
Hello, World
You may have noticed that the HTTP headers are just general text. This makes it easier to diagnose HTTP problems with package checker or text-based Internet tools such as Telnet. HTTP text-based Properties also make HTTP easier to apply to low technology programming environments that are popular in web development.
The first line of the HTTP request contains three components: HTTP method, request-uri, protocol version. In the previous example, these correspond to post,/foobar, and http/1.1 respectively. The Internet Engineering Task Force (IETF) has standardized a fixed number of HTTP methods. Get is the method that HTTP uses to access the Web. Post is the most common HTTP method for building an application. Unlike get, Post allows arbitrary data to be sent from the client to the server side. The request URI (uniform Resource Identifier) is an HTTP server-side software that identifies a simple identifier for the requested target (it is more like a iiop/giop object_key or a DCOM IPID). For more information on URIs please refer to "URIs, URLs, and urns". In this example, the protocol version is http/1.1, which represents compliance with RFC 2616 rules. http/1.1 adds several features to the http/1.0, including support for bulk data transfer and support for maintaining a TCP connection between several HTTP requests.
The third and fourth lines of the request specify the size and type of the request body. The Content-length header specifies the number of bits for the body information. The Content-type type identifier specifies the syntax of the MIME type as the body information. HTTP (like DCE) allows the server and the client to negotiate the transport syntax used to prepare information. Most DCE applications use NDRs. Most Web applications use text/html or other text-based syntax.
Notice the empty line between the Content-length header and the request body in the sample above. Different HTTP headers are delimited by the carriage-return/line code sequence. These heads and bodies delimit lines by using another carriage-return/line code sequence. The request then includes the original bytes, the syntax and length of which are identified by the content-length and Content-type HTTP headers. In this example, the content is a 12-byte plain text string "Hello, World".
After processing the request, the HTTP server is expected to send back an HTTP response to the client. The response must include a status code to represent the result of the request. The response can also contain arbitrary body information. The following is an HTTP response message:
OK
Content-type:text/plain
Content-length:12
Dlrow, Olleh
In this example, the server returns status code 200, which is the standard success code in HTTP. If the server side cannot crack the request code, it returns the following response:
Bad Request
content-length:0
If the HTTP server decides that the request to the target URI should be temporarily diverted to another different URI, the following response will be returned:
307 temporarily moved
Location:http://209.110.197.44/foobar
content-length:0
This response informs the customer that the request will be satisfied by passing it back to the address specified in the location header.
All standard status codes and headers are described in RFC 2616. Few of them are directly related to SOAP users, with one notable exception. At http/1.1, the underlying TCP connection is reused across multiple request/response pairs. The HTTP connection header allows either side of the client or server to close the underlying connection. By adding the following HTTP headers to the request or response, both parties require that the TCP connection be turned off after the request is processed:
Connection:close
In order to maintain a TCP connection when interacting with the http/1.0 software, it is recommended that the sender add the following HTTP headers to each request or response:
Connection:keep-alive
This header makes it impossible for the default http/1.0 protocol to restart the TCP connection after each response.
One advantage of HTTP is that it is being widely used and accepted. Figure 4 represents a simple Java program that sends the previously expressed request and resolves the result string from the response.
The following is a simple C program that uses CGI to read a string from an HTTP request and return it in reverse order via an HTTP response.
#include <stdio.h>
int main (int argc, char **argv) {
Char buf[4096];
int cb = Read (0, buf, sizeof (BUF));
BUF[CB] = 0;
Strrev (BUF);
printf ("ok\r\n");p >
printf ("content-type:text/plain\r\n");
printf ("Content-length:%d\r\n", CB);
printf ("\ r \ n");
printf (BUF);
return 0;
Figure 5 Represents a more popular version of the server's implementation using the Java servlet to avoid the overhead of each request for a CGI process.
CGI is generally the least expensive way to write HTTP server-side code. In fact, each HTTP server-side product provides a more efficient mechanism for your code to process an HTTP request. IIS provides ASP and ISAPI as a mechanism for writing HTTP code. Apache allows you to write modules with C or Perl running in the Apache daemon. Most application Server software allows you to write Java servlet,com components, EJB session beans or CORBA servants based on a Portable object Adapter (POA) interface.
XML as a better way to express network data (NDR)
HTTP is a fairly useful RPC protocol that provides support for most of the functionality of IIOP or DCOM in the areas of group framing, connection management, and serialization of object applications. (and URLs are amazingly functionally close to iors and Objrefs). What is missing in HTTP is a single, standard format for expressing an argument in an RPC call. This is where XML comes in.
Like NDRs and Cdr,xml is a platform-independent neutral data expression protocol. XML allows data to be serialized into a transitive form, making it easy to decode on any platform. XML has the following characteristics that are different from NDRs and CDR:
A large number of XML coding and decoding software exist in every programming environment and peace platform
XML is based on text and is fairly easy to deal with in a low level programming environment
XML is a particularly flexible format that is easily extended in a consistent way
To support extensibility, each element and attribute in the XML has a name domain URI associated with it, which is specified with the xmlns attribute.
Consider the following XML document:
<reverse_string xmlns= "Urn:schemas-develop-com:stringprocs" >
<string1>hello, world</string1>
<comment xmlns= ' http://foo.com/documentation ' >
This is a comment!!
</comment>
</reverse_string>
The name domain URI for element <reverse_string> and <string1> is Urn:schemas-develop-com:stringprocs. The name domain URI of the element <comment> is http://foo.com/documentation. The fact that the second URI is also a URL is unimportant. In both cases, the URI is simply used to eliminate ambiguity between element <reverse_string>,<string1>,<comment> and any other element that happens to have the same tag name.
For convenience, XML allows the name domain URIs to be mapped to a locally unique prefix. This means that the following XML document is semantically equivalent to the above document:
<sp:reverse_string
xmlns:sp= "Urn:schemas-develop-com:stringprocs"
Xmlns:doc= ' Http://foo.com/documentation '
>
<sp:string1>hello, world</sp:string1>
<doc:comment>
This is a comment!!
</doc:comment>
</sp:reverse_string>
The following form is easier for the author, especially if there are many name domain URIs in use.
XML also supports the presentation of data with a type. The XML Schema specification being introduced standardizes a word collection for describing XML data types. The following is a description of an element <reverse_string> XML Schema:
<schema
xmlns= ' Http://www.w3.org/1999/XMLSchema '
Targetnamespace= ' Urn:schemas-develop-com:stringprocs '
>
<element name= ' reverse_string ' >
<type>
<element name= ' string1 ' type= ' string '/>
<any minoccurs= ' 0 ' maxoccurs= ' * '/>
</type>
</element>
</schema>
This XML schema definition states that the XML name domain Urn:schemas-develop-com:stringprocs contains an element named <reverse_string>. This element contains a child element named string1 (type String) that is adhered to by 0 or more elements that are not specified.
The XML Schema specification also defines a set of built-in raw data types and a mechanism for building the types of elements in an XML document. The following XML document uses the XML Schema type attribute to associate the element with the type name:
<customer
xmlns= ' http://customer.is.king.com '
Xmlns:xsd= ' Http://www.w3.org/1999/XMLSchema '
>
<name xsd:type= ' string ' >don box</name>
<age xsd:type= ' float ' >23.5</name>
</customer>
A new mechanism for connecting XML document cases to XML schema descriptions is being standardized during this writing.
HTTP + XML = SOAP
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.
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:
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, 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.
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:
post/string_server/object17 http/1.1
host:209.110.197.2
Content-type:text/xml
content-length:152
Soapmethodname:urn:strings-com:istring#reverse
<Envelope>
<Body>
<m:reverse xmlns:m= ' urn:strings-com:istring ' >
<thestring>hello, world</thestring>
</m:reverse>
</Body>
</Envelope>
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.
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:
OK
Content-type:text/xml
content-length:162
<Envelope>
<Body>
<m:reverseresponse xmlns:m= ' urn:strings-com:istring ' >
<result>dlrow,olleh</result>
</m:reverseResponse>
</Body>
</Envelope>
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.
Figure 6 and Figure 7 show how soap corresponds to the ORPC protocol discussed earlier. What makes many soap novices confused is that there is no requirement in soap for the SOAP server to use the request headers to distribute requests; This is left as a implementation detail. Some SOAP servers-uris the mapping request to the class name and assign instances of calls to static methods or to classes that survive during the request duration. Other SOAP servers map the request-uris to an object that is always alive, often using a query string to encode an object keyword to locate in the server process. There are other SOAP servers that use HTTP cookies to encode an object keyword that can be used to recover the state of an object in each method request. It is important that the customer is unaware of these differences. The client software simply follows the rules of HTTP and XML to form a SOAP request, leaving the server free to service the request in the way it deems most appropriate.
The core of the SOAP body
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:
[UUID (Deadf00d-bead-bead-bead-baabaabaabaa)]
Interface Ibank:iunknown {
HRESULT withdraw ([in] long account,
[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,overdrawn parameter, and the updated value of the amount parameter will appear in the response message.
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:
struct Withdraw {
Long account;
float amount;
};
This is an all request parameter is packaged into a single data type. The same data below indicates that all response parameters are packaged to a single data type.
struct Withdrawresponse {
float newbalance;
float amount;
Variant_bool overdrawn;
};
The following simple Visual Basic program is given, which uses the previously defined IBank interface:
Dim Bank as IBank
Dim Amount as Single
Dim Newbal as Single
Dim overdrawn as Boolean
Amount = 100
Set Bank = GetObject ("Soap:http://bofsoap.com/am")
overdrawn = Bank.withdraw (3512, amount, Newbal)
You can imagine that the underlying agent (possibly a soap,dcom, or IIOP proxy) looks like the one shown in Figure 8. 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.
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 the encoding of a IBANK::WITHDRAW request:
<soap:envelope
xmlns:soap= ' Urn:schemas-xmlsoap-org:soap.v1 ' >
<soap:Body>
<ibank:withdraw xmlns: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 as:
<soap:envelope
xmlns:soap= ' Urn:schemas-xmlsoap-org:soap.v1 ' >
<soap:Body>
<ibank:withdrawresponse xmlns: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 objects, you may have noticed that the serialization format is usually:
<t:typename xmlns:t= ' NamespaceURI ' >;
<fieldname1>field1value</fieldname1>
<fieldname2>field2value</fieldname2>
</t:typename>
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.
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 looks for an object as follows:
struct Causality {
UUID ID;
};
In this case, if the URI of the header element cannot be recognized, the header element can be safely ignored.
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:
<soap:envelope
xmlns:soap= ' Urn:schemas-xmlsoap-org:soap.v1 ' >
<soap:Header>
<causality
Soap:mustunderstand= ' true '
xmlns= "Http://comstuff.com" >
<id>362099cc-aa46-bae2-5110-99aac9823bff</id>
</causality>
</soap:Header>
<!-soap:body element elided for clarity->
</soap:Envelope>
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 COM case, this will be mapped to an explicit HRESULT)
SOAP data types
In a SOAP message, each element may be a SOAP structure element, a root element, an access element, or a separate element. In soap, Soap:envelope, Soap:body, and Soap:header are the only three structural elements. Their basic relationships are described by the following XML Schema:
<schema
Targetnamespace= ' Urn:schemas-xmlsoap-org:soap.v1 ' >
<element name= ' Envelope ' >
<type>
<element name= ' header ' type= ' header '
minoccurs= ' 0 '/>
<element name= ' body ' type= ' body '
minoccurs= ' 1 '/>
</type>
</element>
</schema>
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.
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.
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:
Package Com.bofsoap.IBank;
public class Adjustment {
public int account;
public float amount;
}
The instances that are serialized in a SOAP message are as follows:
<t:adjustment
xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank ' >
<account>3514</account>
<amount>100.0</amount>
</t:adjustment>
In this example, the Access element account and amount are referred to as simple access elements because they access the part that corresponds to the XML schema specification (see HTTP://WWW.W3.ORG/TR/XMLSCHEMA-2) in the Consortium The value of the original data type defined in 2. This specification specifies the names and expressions of data types such as strings, numeric values, dates, and the mechanism for defining new primitive types using the <datatype> structure in a new schema definition.
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:
Package Com.bofsoap.IBank;
public class Transfer {
public adjustment from;
public adjustment to;
}
If you encode access elements with embedded values, a serialized transfer object in soap looks like this:
<t:transfer
xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank '
>
<from>
<account>3514</account>
<amount>-100.0</amount>
</from>
<to>
<account>3518</account>
<amount>100.0</amount>
</to>
</t:transfer>
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:
<t:transfer
xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank '
Xmlns:xsd= ' Http://www.w3.org/1999/XMLSchema/instance '
>
<from xsd:null= ' true '/>
<to>
<account>3518</account>
<amount>100.0</amount>
</to>
</t:transfer>
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 only allow null from Access elements:
<type name= ' transfer ' >
<element
Name= ' from '
Type= ' Adjustment '
Nullable= ' true '
/>
<element
Name= ' to '
Type= ' Adjustment '
Nullable= ' false ' <!-false is the default->
/>
</type>
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
