SOAP is a way to send messages across the wire. One computer can use SOAP to send a block of data, say for instance a billing record, to another computer. When using SOAP, both computers understand the protocol and can send and receive the data using it.
The SOAP acronym starts with Simple, and that's one of the key things it delivers. If you've ever worked with DCOM to communicate to remote servers, you know that DCOM is anything but simple as a matter of fact, it's pretty ugly. I realize that some readers have been using DCOM for years and are very comfortable with it. I had a student who fit this description, and the two of us had a spirited debate about whether Web Services using SOAP offered a better alternative than DCOM. If you're in this camp, I respect your opinion but respectfully disagree.
SOAP is based on XML. The data that is carried in a SOAP package is always represented by XML. If you plan to do much with SOAP, you may want to take a look at the XML specification or do some reading to understand the basics of XML. You might also want to look at the XSD specification, which sometimes causes more confusion than XML.
SOAP works with any operating system because it doesn't rely in any way on operating systems. It's a protocol on its own merit that dictates no hardware, operating system, or language specifications.
SOAP is also built on standards and therefore can easily be implemented by anyone. First, it relies on HTTP to send data across the wire. Second, it relies on XML to represent the data. And third, it relies on the SOAP specification so that every implementer will be in compliance and able to communicate with all other implementers. You can get the SOAP specification at HTTP://msdn.microsoft.com/workshop/XML/general/soapspec.asp.
SOAP data is sent in a well-organized manner as it goes across the Internet. This section shows you the hierarchy of SOAP packages.
Because all SOAP packages are sent within an HTTP message, the first part of a SOAP message is the HTTP header. Information in the section usually contains the domain name, the keyword POST, the Content-Type specification, and other optional information.
After the HTTP header comes the SOAP envelope. This encompasses the entire SOAP message. It's kind of like what's inside the box that arrived at your doorstep. It's all the important stuff you need (the actual data). The address label on the front of the box (the HTTP header) can almost always be discarded.
The SOAP envelope starts off with a SOAP header (which is optional). This is different from the HTTP header. It contains information about the routing of the data (such as the domain name and the size of the content), and it contains information related to the data, such as a transaction ID.
The SOAP body is also in the SOAP envelope after the SOAP header, and it contains the data. Figure 14.3 shows a diagram of SOAP messages.
Figure 14.3. This Figure Shows the Hierarchy of SOAP Data as It's Sent over the Wire.
In this section, I'm going to show you some captured SOAP packages, to give you an idea of what they look like.
A simple SOAP request might look like the following (the HTTP header is in gray):
POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/XML; charset="utf-8" Content-Length: 323 SOAPAction: Some-Namespace-URI#GetLastTradePrice <SQ:Envelope xmlns:SQ="http://schemas.xmlsoap.org/soap/envelope/" SQ:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SQ:Body> <m:GetLastTradePrice xmlns:m="Some-Namespace-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SQ:Body> </SQ:Envelope>
A simple SOAP response might look like the following (the HTTP header is in gray):
HTTP/1.1 200 OK Content-Type: text/XML; charset="utf-8" Content-Length: nnnn <SP:Envelope XMLns:SP="http://schemas.XMLsoap.org/soap/envelope/" SP:encodingStyle="http://schemas.XMLsoap.org/soap/encoding/"> <SP:Body> <m:GetLastTradePriceResponse XMLns:m="Some-Namespace-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SP:Body> </SP:Envelope>