An Overview of the SOAP v1.1 Specification
The SOAP specification clearly establishes SOAP's role as a protocol for defining a messaging system as well as remote procedure calls. Although the O in SOAP stands for Object, nothing in the specification suggests that the intention of SOAP is to provide any sort of object or component runtime. To the contrary, SOAP makes no attempt to define mechanisms for object invocation, garbage collection, and so on. SOAP does, however, provide the necessary mechanisms for building object-oriented systems on top of its infrastructure.
HTTP as a Base Transport
Version 1.0 of the specification mandated HTTP as its base transport, but version 1.1 has decoupled SOAP from HTTP to allow SOAP to be used in a messaging paradigm. This leaves the door wide open for a variety of other transports to carry SOAP such as FTP, SMTP, and others.
Regardless of the transport, there is always some underlying work that must be done to invoke a method on a server. For SOAP as an RPC mechanism, this means constructing a valid HTTP request message.
By default, clients should start by using the POST method; only in the case where this fails with an HTTP status of 405 Method Not Allowed should they attempt the request using M-POST. With the existing Web infrastructure, POST seems to be the reasonable choice at this point and time.
Although it is slightly easier to construct and parse the header fields for a POST than for an M-POST, conforming to M-POST can force clients to provide more detail about the client's request. Consider the examples of POST versus M-POST in the following listing.Listing 1 - POST Versus M-POST
POST /Script.pl HTTP/1.1 Host: www.mcp.com Accept: text/* Content-type: text/xml Content-length: nnnn SOAPAction: the-method-uri#DoSomething M-POST /Script.pl HTTP/1.1 Host: www.mcp.com Accept: text/* Content-type: text/xml Content-length: nnnn Man: "urn:schemas-xmlsoap-org:soap.v1"; ns=01 01-SOAPAction: the-method-uri#DoSomething
The original SOAP specification v0.9 originally forced M-POST calls to occur before POST calls, thus forcing clients to provide more detail with the first request.
In SOAP v1.0, the specification called for POST calls to occur before M-POST, due to the limited adoption of M-POST.
SOAP recommends that a SOAPAction header field be provided with each SOAP request, such that the server can gather call information without having to parse the entire SOAP payload. At this point, SOAPAction is optional, and clients only have to use it when mandated by the server. However, it is expected that many of you will want to include SOAPAction in your SOAP implementations, so your server can know the intention of the request message.
Using XML in SOAP
One of the simplest aspects of SOAP is that it only requires calls to conform to proper XML syntax. No other XML technologies are required to make SOAP work, although XML Namespaces and XML Schemas make SOAP development much easier.
SOAP recommends the use of namespaces because they provide a mechanism to scope elements and attributes to various contexts. The specification states that clients are able to dictate whether or not namespaces are to be used in a conversation with the server. On the other hand, servers are responsible for ensuring that clients that use namespaces use them correctly. Servers also have the option to process requests that do not contain namespaces or, at a minimum, to respond with a fault.
The namespace 'urn:schemas-xmlsoap-org:soap.v1' is the proposed namespace value for SOAP. This value is simply an URN that should be used to qualify SOAP element and attribute names and does not necessarily reflect any particular resource on the Internet.
SOAP also uses the id/href attribute pairs to distinguish between unique entities within the SOAP payload. This is necessary for providing multi-reference elements in the request and response payloads, such that you serialize the element once and reference it as many times as necessary.
To execute a SOAP method call, the SOAP payload must be constructed with a <SOAP:Envelope> root element containing an optional <SOAP:Header> element and a mandatory <SOAP:Body> element.
The <SOAP:Header> element is used to encapsulate extended information about the call. The <SOAP:Body> element contains the actual method call (as its first child element) and the associated method parameters as either embedded or independent elements.
Figure 1 shows the basic structure of a SOAP payload.
Listing 2 shows the basic SOAP structure in use.Listing 2 - Basic SOAP Structure
<SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <r:RequestNumber xmlns:r="Request-URI"> 2 </r:RequestNumber> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetTemperature xmlns:m="Thermostat-URI"> <City>Orlando</City> <State>FL</State> </m:GetTemperature> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Here, the header contains a namespace-qualified element called RequestNumber that keeps track of the number of times this request has been made.
The body contains a namespace-qualified method name GetTemperature that contains the city and state parameters.
|By qualifying the method name, you are implicitly qualifying its embedded elements so they do not require a namespace prefix.|