The Role of Schemas in Web Services | Programming MicrosoftВ® .NET XML Web Services (Pro-Developer)

Exactly what role do schemas play in Web services? Well, a client already knows the basic structure of a SOAP message because it’s the same (<envelope>, <header>, <body>) whatever Web service it’s calling. What it doesn’t know is how the message payload should be structured or typed or how a response will be phrased in return. Schemas allow you to specify that structure, and by including the schemas for both request and response messages in the service’s WSDL document, you give the client easy access to this information. On the server side, using schemas to define your message payload means you can validate your messages and use reflection to generate documentation and class definitions for your service.

Schemas also let you strongly type each element of the request and response. This is important for two reasons:

You can ensure that the right kind of information is stored in each element. For example, if an element is set to an integer, you can check that its text content can be cast to an integer rather than a double and has no alphabetical characters. You can’t calculate the area of a square if its height has been sent to you as “52 rabbits”—that would make no sense.
You can arbitrate between platforms how the value should be stored. Consider the situation in which a .NET server sends a value of type Integer back to a Visual Basic 6.0 client. In Visual Basic 6.0, an Integer is a 16-bit number, but in Visual Basic .NET, it’s 32-bit. If 32 bits are sent when 16 bits are expected, you’ll get overflow errors unless the service can state categorically that it will be sending a 32-bit number to the client, which can adjust accordingly.

You can arbitrate between platforms because the XML Schema specification includes its own platform-neutral type system—the XML Schema Definition (XSD) type system. Defined as part of the XML Schema 1.0 standard that was released in May 2001 (http://www.w3.org/TR/xmlschema-2/), the XSD type system includes a set of 47 predefined types (described in full in Appendix A) and a language for defining new types, which we’ll look at shortly.

You can create a schema for your Web service in two ways:

Write one explicitly in your text editor or IDE
Write one implicitly by tagging your service class with the special attributes that the .NET Framework makes available

If you choose the first approach, you can use a nice little .NET tool called xsd.exe that takes your schema and generates bare server and client classes for a Web service whose messages obey that schema. However, the second option requires less work to incorporate the schema into the service (it’s just an extension of using the Web method API introduced in Chapter 2), but it doesn’t give you as much control as writing your own schema.

Note

As noted in Chapter 2, if you’re writing a service that uses Section 5 encoding, the message structure will be influenced by SOAP’s own encoding rules. More on this later.