Chapter 3: SOAP

Putting the Vocabulary into Action

The last section covered a great deal of new terminology. Covering a few examples should lend to greater understanding.

A Simple SOAP Transaction

Figure 3.1 shows a simple model of a SOAP transaction. The first item to note is the different protocols available for transmission. FTP, HTTP, and SMTP are available. This provides a great deal of flexibility especially if consumers of your Web Service are in an area that doesn’t have a good connection to the Web but still has e-mail access.

Figure 3.1: This image demonstrates a simple SOAP transaction.

The SOAP message is the XML document being sent to the SOAP receiver. The message contains information in XML that is eventually processed by an object on the receiver. The SOAP nodes are both the SOAP sender and receiver. Think of the SOAP sender as a Web page or an application that consumes the Web Service, and the SOAP receiver as the server that hosts the Web Service.

Using an Intermediary

In the next example, Figure 3.2, a SOAP intermediary node is introduced. As mentioned earlier, an intermediary acts as a Web Services router sending requests to the appropriate location based on data found in the XML of the SOAP document.

Figure 3.2: How a SOAP message can be routed by a SOAP intermediary.

In this case, the SOAP sender is a client for a large brokerage house. This brokerage house possesses several SOAP receivers each with a different function. By having the SOAP intermediary, the brokerage house only needs to publish one address to fulfill all the different requests. Once a SOAP message reaches the intermediary, the XML inside the message reveals the next node the request needs to go to. In this case, the brokerage house is offering services for stock quotes, account information, and stock trading. Thus, the XML contains information telling the intermediary where to send the message next. The important thing to note is that the intermediary can act on other information in the SOAP message, but it is not required to do so.

How SOAP Differs

This book mentions several times that SOAP is just a request and response system. This is much like a browser making a request to a Web page. You enter the address into the browser and the request goes out to the Internet and finds the server. Then the server sends the response in the form of HTML; then there is no longer a connection between client and server.

Figure 3.3 shows this request and response pattern between two SOAP nodes. This is a conversation between the two nodes about getting some stock quotes. In the first request, the SOAP client asks for stock quotes for the symbols: “GE,” “C,” and “DJI.” The response is “35,” “48,” and “10,000.” The SOAP client then asks for a quote for the symbol “HOCH,” and the receiver sends back information stating there is not such symbol. This pattern of request and response over related information is the message Exchange Pattern mentioned earlier in the chapter.

Figure 3.3: How two SOAP nodes converse over a stock quote.

The difference between a client and server in COM+, CORBA, or another remote object technology is the fact that the entire conversation occurs over a single connection. Figure 3.4 shows the same exchange of information over stock quotes as the previous example In this case, however, there is only one connection, and it is held until the entire conversation is complete. This connection is much more like telnet—a session is held constant between a client and server. Because the connection is constant, the response to multiple requests will most likely be faster than a request and response model such as Web Services, but the implementation is far more difficult.

Figure 3.4: How a CORBA or COM+ connection can handle the same conversation over one connection.

Now that you’ve looked at the terminology and a couple of connection models, take a look at the next section where the XML document in the SOAP message is finally discussed.