Chapter 2: Web Services and SOAP

Overview

Having started in the opening chapter with an overview of how Web services expose functionality via the Web, we’ll focus over the next few chapters on the building blocks that allow Web services to be called remotely. One of the vital processes involved in the invocation of Web services is the provision of data to and from the Web service. Messages carrying the necessary data can be parceled in a variety of different formats, but a popular and effective way of invoking Web services, and one that is governed by a set of standards, is to pass messages within a SOAP wrapper.

SOAP is an XML-based message format that allows two applications to exchange data over the Web. Web services use SOAP to carry method calls from a client to a remote server; a SOAP message is sent containing data that the Web service will need to act on. The Web service can also return a response to a method call, again placing information within the format of a SOAP message. The vast majority of Web services will use SOAP whether the user physically creates a SOAP message or leaves it to the application to parcel up the message in XML and send it.

Using SOAP is preferable to just wrapping up your messages in XML because SOAP is tailored to the needs of carrying method calls and provides the minimum format required to send a message from one application to another. Information in SOAP messages is stored within a simple header and body structure within an envelope. The information can be stored either as a straight XML document or as a remote procedure call (RPC), together with information about accompanying data types. The information in a SOAP message is spread between header and body—information about the Web service (metadata) is kept in the header, and the data itself is stored in the body. The metadata in the header is easily retrievable by applications other than those that need to receive the data. The SOAP message structure also makes it easier to uniquely identify elements within the message body because they can be defined in the envelope using XML namespaces.

Although it’s possible to hide from the internals of SOAP, SOAP really isn’t difficult to master. And if you understand how SOAP works, tasks such as debugging and testing your Web services become much simpler. Because SOAP closely couples with the other Web service technologies, most notably Web Services Description Language (WSDL), understanding SOAP also makes it easier to understand those technologies.

We’ll start with a quick overview of what SOAP is and then discuss the current state of the standards. Next, we’ll break down SOAP into its constituent parts, examine the format of a SOAP message, and look at what kind of information can be sent in a SOAP message. We’ll then invoke a simple Web service using SOAP to send the necessary information the Web service needs. We’ll also take a close look at SOAP headers and the kind of information that can be sent in them, the XML payload contained in the SOAP body, and how other applications might act on that payload. We’ll look at how to use SOAP messages to send fault information and what the recipient of the fault message can do with this information. Last, we’ll embark on a brief introduction to the SOAP extensibility model, which will lead to a subject explored more fully in Chapter 12.