Summary

Chapter 4

XML Schema

SOAP provides a standard method of encoding data into an XML document. This technology is also extremely flexible. Anything can be encoded into the body of a SOAP message as long as it does not invalidate the XML. The body of a message can contain a request for the latest weather information, a purchase order, part of an instant message thread, a satellite image, or whatever else the implementer of a Web service can dream up.

With the variety of content and types of data that can be contained within a SOAP message, you need a way of expressing the structure of a message. You also need a way to determine the type of data that should appear within a message.

One potential solution could be for the developer to provide a sample of what a valid SOAP message should look like. For example, say you need to interface with a Web service to place an order with a vendor, and the vendor has provided the following sample message:

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <PurchaseItem>       <Item>Apple</Item>       <Quantity>12</Quantity>     </PurchaseItem>   </soap:Body> </soap:Envelope>

The XML document is pretty straightforward. From the sample message, you can see that the Web service accepts two parameters, Item and Quantity. Both of these parameters are child elements of the PurchaseItem element.

The problem is that the sample message leaves a lot of ambiguity remaining. For example, you know you need to pass an Item parameter, but should it contain a short description of the item? Should it contain one of a select number of enumerations? Is the value limited to a maximum number of characters?

There are just as many questions regarding the Quantity parameter. Can you specify partial quantities such as 1.5 cases? Is there a minimum number that must be purchased? Is there a maximum number that can be purchased?

One way to clear up the ambiguity would be to have the sample message be accompanied by a document that describes all of the nuances of the message because at the very least, the Web service needs to validate the received message. Also, you would probably want to validate the message before you sent it to the Web service. But with this approach, both you and the developer of the Web service would probably be stuck hand-writing validation code. This doesn't sound very pleasant or productive.

What's needed is a standard way of describing the structure and the type of information that should be contained within an XML message sent to the Web service. In other words, you need a way of representing the schema an XML message must conform to in order to be processed by the Web service. Furthermore, the schema needs to be standardized and accompanied by a set of APIs that can be used to programmatically validate an XML document against the schema.

By the end of this chapter, you will be armed with more than enough information to create schemas for your Web services. In this chapter, I will create a schema for the Commerce Web service. This schema will describe the expected format of the request and response message of the PurchaseItem method.