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 GET and 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 simple queries. 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.

---

---