SOAP, WSDL, Encoding, and Styles

Back when SOAP 1.1 was introduced, the W3C hadn’t finished working on the XML Schema standard. However, the creators of SOAP knew that schema should be used to describe the body of a SOAP message. Not wanting to wait around for the release of XML Schema, they created a schema-like type system and allowed a distinction to be made between messages templated by schemas (literal messages) and those using their stopgap type system (encoded messages). Section 5 encoding, as the stopgap is known, is part of the SOAP 1.1 spec and lays out its own wrapper types in an attempt to mirror the XSD type system. It was used heavily for a while but is now being dropped in favor of using schemas.

WSDL also makes a distinction between document-style messages, which adhere to a schema, and RPC-style messages, which take the form of a remote procedure call (RPC) and include operating system and runtime-specific information for use by the recipient. When SOAP was first designed, it was with RPC messages in mind, but over time document-style messages have been acknowledged as the way forward.

The System.Xml.Serialization namespace contains a number of attributes we can use to tag our Web service class and members to identify the type of service and what type of encoding the serializer should use. Based on that information, the serializer generates the service’s WSDL document, which includes the service’s schema. In the next section, we’ll look at the serialization attributes you can use with .NET classes to generate schemas for document/literal messages (the default style in .NET)—this is the scenario we’ve already explored in this chapter by writing our own schema. Then we’ll look at attributes you can use to influence the layout of services that use Section 5 encoding. In the final section of the chapter, we’ll look at the System.Runtime serializer as an alternative to the System.Xml serializer when you work with a Web service in a .NET-only environment.