Binding SOAP to a Transport Protocol
The key issue in deciding how to bind SOAP to a particular transport protocol is about determining how the requirements for a Web service (communication style, such as RPC vs. document, synchronous vs. asynchronous, etc.) map to the capabilities of the transport protocol. In particular, we need to determine how much of the overall contextual information needed to successfully execute the Web service needs to go in the SOAP message versus in the message of the transport protocol.
Figure 5-1 illustrates this issue on an HTTP example. In HTTP, context information is passed via
the target URI and the
SOAPAction header. In the case of SOAP, context information is passed
in the SOAP header.
As a communication protocol, SOAP is stateless and one-way. Although it is possible to implement statefull SOAP interactions so that the Web service maintains a session, this is not the most common scenario.
When using HTTP for SOAP messages, the developer must decide which HTTP method is appropriate to use in HTTP request messages that are exchanged between the
service consumer and the Web service. Usually the choice is between
POST. In the
context of the Web as a whole (not specific to Web services), the W3C Technical Architecture
Group (TAG) has addressed the question of when it is appropriate to use GET, versus when to use
POST, in [Jacobs, 2004]. Their finding is that
GET is more appropriate for safe operations such as
POST is appropriate for other types of applications where a user request has the
potential to change the state of the resource (or of related resources). Figure 5-1 above shows the HTTP
request using the
POST method, which is most often used in the context of Web services.