Web Services Basics: XML, SOAP, and WSDL

Four technologies form the basis of Web services: eXtensible Markup Language (XML); SOAP ^[1] ; Web Services Description Language (WSDL); and Universal Description, Discovery, and Integration (UDDI) ^[2] .

^[1] SOAP used to stand for Simple Object Access Protocol, but in the W3C SOAP 1.2 specification, SOAP is now just a name and is no longer an acronym. The reason for the change is that the W3C realized that SOAP is neither especially simple, nor is it related to objects in any way.

^[2] Most authors consider the base set of Web services standards to include UDDI as well as SOAP and WSDL. UDDI stands for Universal Description, Discovery, and Integration. Advertising Web services so that systems can automatically discover them sounds like a good idea, but we don't believe it is practical for the public Internet. Instead, we view UDDI as a powerful mechanism to be used inside larger organizations to promote reuse of shared services. So, although we do view it as a useful standard, we don't view it as part of the core set of things that define Web services.

XML and XML Schema

XML was created as a structured self-describing way to represent data that is totally independent of application, protocol, vocabulary, operating system, or even programming language. Many call XML the lingua franca of business because it is being used so broadly across all industries to portably transmit business data. The use of XML presents a broad set of security challenges.

XML Schema is a way of describing the rules for a particular XML instance (also known as a document). XML can be used independently of XML Schema; however, in Web services and most business situations, the XML that you work with will be governed by an XML Schema (perhaps created by a development tool and put into your Web services WSDL file for you).

XML is the foundation of the Web services standards. All standards for describing, discovering, and invoking Web services are based on XML. SOAP and WSDL are described using XML Schema. The core security standards of XML Encryption, XML Signature, Security Assertion Markup Language (SAML), and WS-Security are XML-based and are also described by an XML Schema.

XML and HTML are both text-based formats that came from the same roots. XML was initially developed to overcome the limitations of HTML, which is good at describing how things should be displayed but is poor at describing what the data is that is being displayed. XML being text-based is very important to Web services; because it is human-readable , no tools are needed to parse and render the data, and simple text tools and editors are sufficient for its manipulation. XML documents are very wordy, and although you can easily become lost in the depth and richness of the tags, its markup format of tagged elements arranged in a hierarchical structure makes XML documents easy to comprehend. But there is a security price to pay for the open , text-based structure of XML. As you will see later, to provide data integrity ”a guarantee that not one bit in the original document has been changed ”with XML, you have to guarantee that not one character ”even whitespace ”of an XML message has been changed. Verifying data integrity is particularly challenging when using XML since differences in platforms and XML parsers can result in logically equivalent documents being physically different; consequently, a process of canonicalization is necessary to make a valid comparison with the originally signed document. This is just one example of the special considerations needed when considering Web Service Security.

SOAP

SOAP was created as a way to transport XML from one computer to another via a number of standard transport protocols. HTTP is the most common of those transports and is, of course, the most prevalent transport used by the Web itself.

SOAP itself is defined using XML, and it provides a simple, consistent, yet extensible mechanism that allows one application to send an XML message to another. SOAP is what makes application integration possible, because after XML defines the contents of a message, it is SOAP that moves the data from one place to another over the network. SOAP allows the sender and receiver of XML documents to support a common data transfer protocol. SOAP allows you to treat XML messages as requests for remote services. The SOAP model allows a clean separation between infrastructure processing and application processing of messages. Figure 1.1 shows the basic structure of a SOAP message.

Figure 1.1. The basic structure of SOAP.

SOAP provides an envelope into which an XML message is placed. This envelope is just a container to hold XML data. The idea is for SOAP to create a uniform container that can then be carried by a variety of transports. SOAP prevents applications from caring about the transport; the applications see consistency in the SOAP envelope and its contents.

Inside the SOAP envelope are two parts : the header and the body .

• SOAP header ” Contains information about the SOAP message (as opposed to the XML message contained in the SOAP body). This information is used to manage or secure the package. SOAP is designed to be extensible, and a major area for extension is the SOAP header. Chapter 7, "Building Security into SOAP," which describes WS-Security, provides more detail on SOAP header security extensions.

• SOAP body ” Contains the message payload. This information is being sent from one application to another. It might be a full document such as a purchase order or contract, or it might be a description of remote-procedure call information, including the methods to call and parameters to those method calls.

The simple SOAP message in Listing 1.1 shows an envelope that contains both a SOAP header and a SOAP body.

Listing 1.1. SOAP Envelope

 <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">  <env:Header>  <n:alertcontrol xmlns:n="http://example.org/alertcontrol">   <n:priority>1</n:priority>   <n:expires>2004-06-22T14:00:00-5:00</n:expires>  </n:alertcontrol>  </env:Header>  <env:Body>   <m:alert xmlns:m="http://example.org/alert">    <m:msg>Pick up Bobby at school at 2PM</m:msg>   </m:alert>  </env:Body> </env:Envelope> 

To understand SOAP, you need to understand the different "styles" of SOAP bodies. RPC-style SOAP bodies tend to be simple parameters to facilitate calling a remote method. Document-style SOAP bodies tend to be rich XML documents. Document style, in our view, is more appropriate for B2B Web services because it is usually more optimal to have " chunky ," coarse-grained calls across a slow network rather than the fine-grained type of RPC call that you might use locally or on a fast network. This is not just due to the network but also due to the cost of marshalling and unmarshalling the XML and performing security-related operations.

SOAP needs to be secured. The messages it carries must be kept secret from unintended recipients. The remote service being called must know who is calling it and know the caller is authorized to do so. SOAP is a packaging mechanism for XML messages and documents. Like any package, it needs to describe important information about its contents, such as who it is from, how a recipient can trust that it really is the sender, what the sender is allowed to do, and much more. These are identity- and trust-related issues; they are the core of SOAP security discussed in detail later in this book.

WSDL

WSDL is an XML language that defines the set of operations that a Web service provides and the structure of their related SOAP messages. That is, the WSDL defines what the input and output structure will be for a Web service, and that will define what you expect to see in the payload XML message. WSDL is how one service tells another which way to interact with it, where the service resides, what the service can do, and how to invoke it. WSDL directly supports developers and is absorbed at application development time into developer tools. WSDL's definitions of remote services are presented to programmer-like local objects that can be acted upon as if they were methods in classes, just like any of their other local objects.

When you publish a WSDL for one of your services, you are creating a contract for how other services may interact with you to utilize your service. WSDL is what you publish to describe your Web service and the rules for how to work with it. You might think that security would also be described in WSDL because this is part of the rules for working with a particular Web service; however, the security options (security policy) available are richer than what you typically see in WSDL, so the standards are evolving toward using WS-Policy to describe a Web services security policy and then referring to this policy from the WSDL. Chapter 8, "Communicating Security Policy," goes into more depth on WS-Policy.

A WSDL file has a what section, a how section, and a where section. The what section specifies the input and output messages. The how section defines how the messages should be packaged in the SOAP envelope and how to transfer it. It also defines what information should be included in the SOAP header. The where section describes a specific Web service implementation and ways to find its endpoint.

UDDI

UDDI is typically the fourth leg of the stool used to define Web services. Although we view UDDI as a useful standard, we do not see its usefulness beyond internal promotion of reuse inside large organizations. Given that, we do not put it front and center as a part of our discussions of Web services security and will not treat it further in this book.

Before you dive into the security implications of each of these Web services standards, you need some context: What are Web services really for? The answer is, among other uses that undoubtedly will develop as this new paradigm matures, application integration, B2B business process integration, portals, and service-oriented architectures.