SOAP Encoding

Protocol Binding

You have learned how to properly encode a SOAP message, but you still need a way to send the message to the remote application. One advantage of SOAP is that it is not tied to a particular transport protocol. SOAP messages can be sent over any transport protocol that is capable of carrying XML.

Arguably the most popular transport protocol used to send SOAP messages is HTTP. However, SOAP messages can also be sent via SMTP, via fax, to a ship at sea via a shortwave radio, or whatever else can be dreamed up.

How a SOAP message is carried by a particular transport protocol is known as the protocol binding. A protocol binding can be defined to exploit any unique characteristics of the transport protocol. As you will soon learn, the HTTP POST binding extends the protocol so that HTTP-aware firewalls have the ability to filter SOAP messages.

The SOAP specification describes only one protocol binding: sending SOAP messages via HTTP POST. Therefore, the only protocol binding I will discuss is HTTP POST.

Most SOAP implementations, including .NET, support the HTTP protocol. Because most systems support HTTP, it has arguably become the protocol of choice for ensuring that a Web service has a high degree of interoperability between different platforms. The advantages of the HTTP protocol include the following:

• It is firewall friendly. Older protocols such as Distributed Component Object Model (DCOM) are not. Most firewalls have port 80, at the very least, open for HTTP traffic.

• It has a robust supporting infrastructure. Many technologies have been introduced in the effort to increase the scalability and availability of HTTP-based applications. I will discuss this further in Chapter 12.

• It is inherently stateless. The stateless nature of HTTP helps ensure that communication between the client and the server is reliable, especially across the Internet. Intermittent dropped connections pose problems for protocols such as DCOM and CORBA.

• It is simple. The HTTP protocol is composed of a header section and a body section.

• It maps nicely to RPC-style message exchanges. HTTP is a natural protocol for RPC-style communication because a request is always accompanied by a response.

• It is open. Practically every network-aware system supports HTTP.

An HTTP request is composed of two parts, a header and a body. The header contains information about the request and about the client that sent the request. The body follows the header and is delimited by two carriage-return/linefeed pairs. The body contains the payload, which in this case would be the SOAP message. Here is an example of an HTTP request that contains a SOAP message:

POST /SomeWebService HTTP/1.1 Content-Type: text/xml SOAPAction: "http://somedomain.com/SomeWebService.wsdl" Content-Length: 243 Host: sshort3 <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/">   <soap:Body>     <Add>       <x>2</x>       <y>2</y>     </Add>   </soap:Body> </soap:Envelope>

The HTTP header for a SOAP message is similar to that for an HTML request, with a couple of differences: The Content-Type header entry is always set to text/xml, and the body of the message contains the SOAP message. The other difference is that every SOAP HTTP POST request must contain a SOAP Action header entry.

The SOAPAction header entry is used to communicate the intent of the SOAP message. The URI can be represented in any format and is not required to be resolvable. In my example, the URI resolves to the Web Services Description Language (WSDL) document for the Web service. I will cover WSDL in Chapter 5.

The value of the SOAPAction header can be blank if the intent of the SOAP message is conveyed in the HTTP request header entry. The HTTP request is the first entry in the header and contains the action (in this case, always POST) and the targeted URI. If the URI in the HTTP request header entry adequately communicates the intent of the SOAP message, either of the following entries would be valid:

SOAPAction: "" SOAPAction:

The HTTP response is used to communicate the results of the SOAP request.

HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sun, 25 Mar 2001 19:44:55 GMT Content-Type: text/xml Content-Length: 243 <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <AddResponse>       <result>4</result>     </AddResponse>   </soap:Body> </soap:Envelope>

Once again, the MIME type is set to text/xml. For RPC-style messages, the HTTP body contains the SOAP response message. Otherwise, the HTTP body would be empty. Because the example request message results in a response message being generated from the server, the HTTP body contains the results.

In either case, the status reported in the first line of the HTTP header must contain a value between 200 and 299. In the event of an error while processing the SOAP message, the HTTP status must be 500, indicating that an internal server error occurred.