Transports and RPC

SOAP messages do not dictate either a transport or a convention.  This means that you can use SOAP messages as greeting cards and have them hand-delivered, if that's something that interests you.  The possibilities are endless.  The overwhelming majority of developers, however, are interested in SOAP because it can help them perform remote procedure calls over HTTP.  The specification leaves the possibility for SOAP to be used in a variety of ways, but it specifically describes how to do RPC over HTTP.

The first issue is transport and how SOAP messages travel over HTTP.  The HTTP request-response model matches up well with SOAP.  SOAP requests are transported in the body of a POST or M-POST, and the SOAP response is returned in the HTTP response.  It is important that the Content-Type header indicate that the body is "text/xml" for a SOAP message.  The specification defines one additional HTTP header for SOAP use (not to be confused with SOAP Header), SOAPAction, that can be used to help identify incoming SOAP requests to firewalls.

The second issue is RPC and how SOAP messages can be used to hold RPC data.  The payload (child element) of the Body represents a method call, and the child elements of the call are parameters.  The convention is to use the method name for the request payload and method name + "Response" for the response (ex. Add & AddResponse).  For the response, the specification states that the return value must appear as the first child element of the payload, and that it's name is not important (you know it by its position, not its name).

Below you will find an example of a HTTP-RPC exchange of SOAP messages.  In reality, the messages included in these HTTP requests and responses might not have nice indentations, but it makes the examples more readable.  Both HTTP and RPC are dealt with in detail in the specification, but development tools will take care of most of this for you.  The next page shows an example of how that is done.