5.4 SOAP Transport

This section is going to briefly cover some of the different methods of transporting SOAP messages. Later chapters will go into greater depth on some of these (such as HTTP and SMTP).

Arguably the most significant difference between SOAP and XML-RPC is the fact that the designers of SOAP refrained from binding it to a specific transport protocol. While both versions of the protocol refer heavily to the application of HTTP as a method of transport, this isn't the only available option. SOAP has been demonstrated using the Simple Mail Transfer Protocol (SMTP), the Jabber wire protocol, Microsoft's .NET framework, and others. Guidelines for protocols such as the Blocks Extensible Exchange Protocol (BEEP), ^[4] raw TCP/IP, and even FTP have been produced in various levels of maturity and acceptance.

^[4] For more on BEEP, see http://www.beepcore.org.

For each protocol, one thing is common: each must define not only the way messages are physically sent, they must also define what the terms and conditions are for sending a message along that route. In most cases, the protocol definitions themselves cover the "how" element. What remains to be defined is what extra material must be added to a message to enable the transport.

Using HTTP as an example, the specification that provides the binding for SOAP over HTTP is responsible for outlining a number of elements:

• Which HTTP methods are used or supported?

• What role does the request URI play in defining the service?

• What should the Content-type header (and any other relevant headers) look like?

• How is a SOAP message encapsulated into the HTTP request?

Fortunately, the binding for HTTP is a part of the specification in both SOAP 1.1 and 1.2. Because of this, the binding is useful as both a practical application and a roadmap for defining new bindings.

In contrast, supporting SOAP over the Jabber protocol involves very little extra work on the part of the protocol. Because of the nature of Jabber itself, the protocol is already engineered for widely varied content (or payload ). The primary concern with regards to Jabber is how to map the overall SOAP request into a Jabber payload. Matters of how to create the bridge between the SOAP functionality and the servers that receive these Jabber requests is delegated to the application developers. From the vantage point of the protocol binding, what really matters is having a clear process for getting the SOAP messages into and out of the Jabber framework. Still, the binding specification has the same responsibilities the HTTP binding has.

Another protocol of interest to developers and industry is SMTP. Often, the initial reaction to this is one of surprise because electronic mail isn't often thought of in the same request-response sense of exchange that HTTP and other, more obviously two-way protocols are. Despite this, SMTP is very capable of providing a transport binding for SOAP. The necessary element is present: SMTP provides two-way communication. It isn't often thought of in such terms because the receiver of an email message must actively choose to reply to the message, but an SMTP-based server that receives a SOAP message receives a return email address as part of it. Once the message is processed , the response can easily (and promptly) be returned to the requesting client.