So far I’ve talked about the standards behind it all,
but in fact WCF hides most of this from the developer by providing a programming interface for designing service contracts and controlling the message format.
Application messaging requirementsare described by contracts in WCF.
There are three types of formal contracts that clients and services rely on to control messaging.
The service contract describes the operations exposed by a particular service endpoint.
Each operation,through parameters and return types,defines the format of request and response messages.
A data contract describes how a complex type is serialized as part of a message.
Data contracts are the preferred way to include complex types in a service contract.
A message contract provides control over the format of the entire SOAP message,
including support for custom message headers and individual body elements that can be described by data contracts.
By default,message serialization is handled by the DataContractSerializer.
This is a new serializer introduced with WCF that requires all types to opt-in their exact requirements for serialization—in compliance with SOA tenets.
The DataContractSerializer can serialize data contracts,message contracts,and other serializable types such as those marked with the SerializableAttribute or those that inherit IXmlSerializable (see Figure 2-2).
Figure 2-2. The DataContractSerializer can serialize message contracts, data contracts, and other serializable types
It is also possible to tell WCF to use the XmlSerializer that ASP.NET web services use (useful only in rare cases).
The XmlSerializer provides much less control over serialization in that all public members are serialized.
I’ll discuss these and other serialization concepts later in this chapter.
As you complete the labs in this chapter,you will practice working with service contracts,data contracts,message contracts,other serializable types,and raw messages.
Throughout,I’ll provide you with practical design tips,discuss approaches in contract versioning,and teach you how to override default serialization behaviors.
SOAP, WSDL, and WS*
It is amazing to think about the simplicity of the early specifications: SOAP and WSDL.
By their simplicity,adoption was promoted—web service platforms appeared left and right.
Interoperability issues quickly surfaced,forcing platform vendors to pay close attention to their XML parsers and SOAP engines to improve consistency in how XML schema and WSDL were interpreted.
In the meantime,standards building on SOAP and WSDL emerged to deal with addressing and routing scenarios,security,large binary attachments,reliable messaging,transactions,policy,and more.
Like with SOAP and WSDL,these advanced standards—collectively labeled WS*—cycle through phases of development and approval,vendor adoption,and interoperability testing.
A healthy collection of these advanced standards have been fully ratified by W3C (www.w3c.org) and OASIS (www.oasis-open.org),
while others are still in the development or approval process.