This chapter is from the book
This chapter is from the book
This chapter is from the book
Message Passing
You may have noticed that I used the term message passing earlier. At a very fundamental level, Web services are expressed in messages that are sent from one process to another. Typically (and I would argue that this is a near requirement), those messages are XML based. The message is the core piece of Web services. It is like the function in the C programming language: Just as you can't discuss C without discussing functions, you can't discuss Web services, in particular SOAP, without talking about messages.
Messages, Methods, and Operations
Note that messages do not map to methods. Methods can be modeled by combining related messages into a set called an operation. Operations are analogous to methods in many cases, but I would warn against thinking of the term operation as a synonym of method. The two are only similar.
As a matter of fact, we can mimic function calls with messages—two to be exact. We can map the first message, the request, to the function call with the parameter values, and express the return value and out parameters as a response message. When we combine a set of messages into a logical unit in this way, we call them an operation. The request–response operation is the most common in the Web services world. Listing 1.1 shows a typical SOAP message (in this case a request for a stock quote).
Listing 1.1: A Typical SOAP Request Message
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:SessionOrder
xmlns:t="http://example.com"
xsi:type="xsd:int" mustUnderstand="1">
5
</t:SessionOrder>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<GetStockQuote
xmlns="http://someexample.com">
<Price>MSFT</Price>
</GetStockQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The difficult thing about messages is that they are essentially asynchronous and very concurrent. Nothing in the SOAP specification or the Web architecture in general guarantees that a machine on a network will receive the messages I send in the same order in which I sent them.
Dealing with asynchronous and concurrent behavior is difficult. However, most current Web service implementations already have been fairly successful at mapping the more familiar synchronous programming model on top. This programming model is appropriate for many uses, but never forget that you are really dealing with something unlike a call stack in a computer with a single processor. You are dealing with a much more complex system.