While messaging protocols are responsible for message serialization formats,
there must be a way to capture the protocols required to communicate between clients and services.
In Chapter 1,you worked with WSDL documents,which describe the requirements of a service,
including the operations associated with each endpoint and the protocols used by each endpoint.
In this section,I’ll discuss the relationship between the service description, message exchange patterns, and WSDL.

Service Description

Services may implement one or more endpoints,each possibly supporting a different set of operations,messaging protocols,message encoding formats,and transport protocols.
Collectively,this information about a service is part of the service metadata,as I discussed in Chapter 1.
This can also be referred to as the service description.

In fact,WCF represents this information at runtime as a ServiceDescription type from the System.ServiceModel namespace.
The ServiceDescription type is a runtime representation of
all service endpoints and their associated service contracts,
the binding configuration that describes protocol support,
and local behaviors that affect how the service model processes messages.

It is the ServiceDescription type that is used to generate the WSDL document,
and it also supports dynamic metadata exchange so that clients can discover at runtime what protocols are required to invoke service operations.
Recall from Chapter 1 that SvcUtil is used to generate proxies for clients by consuming a WSDL document or using dynamic metadata exchange,
which is based on WS-MetadataExchange protocol (see Figure 2-1).

Figure 2-1. SvcUtil can generate proxies from a WSDL document or by using dynamic metadata exchange

WSDL
SOAP protocol defines the basic requirements to allow platforms to process SOAP messages,extracting headers and body elements to perform work.
Obviously,to understand the header and body elements,the platform also needs to know the format of those elements.
That’s where WSDL comes in.

WSDL describes the core messaging requirements for communicating with a service.
As you learned in Chapter 1,an XML document describes a service,its available endpoints and associated addresses,the protocols supported by each endpoint,and the list of operations and messages associated with each endpoint.
It includes XSD schema describing each message and the contents of the message.
While the message is framed in SOAP,WSDL describes the application-specific schema for each header and each body element.
In this chapter,I’ll be discussing how service contracts and data contracts contribute to the WSDL document.

WSDL is enough to describe application messaging requirements;
however,it is not enough to describe other protocol support related to WS*,for example.
That’s where WS-Policy comes in.

WS-Policy
WS-Policy is an interoperable standard for describing extended protocol requirements,or policy,for a particular endpoint.
The WS-Policy specification describes how to include policy in the WSDL document either directly or as an attachment(actually, that specification is called WS-PolicyAttachment).

While policy does not have an effect on the business messages exchanged between clients and services,
it does affect how the plumbing provided by the service model builds and serializes messages.
WS-Policy extensions exist for security,transactions,reliable messaging,sessions,
and other features that are defined by attributes applied to the service contract or through binding configuration.
Most aspects of the binding configuration are shared with clients through the policy section of the WSDL document,
enabling clients to build an equivalent channel stack to call services.

Note:
Throughout this book as I discuss bindings (Chapter 3) and other features related to security and reliability, I’ll discuss policy-related features.

WS-MetadataExchange
WS-MetadataExchange is a standard protocol that defines how to retrieve some or all of the service description at runtime.
This includes retrieving the contents of the entire WSDL document or possibly retrieving specific policy requirements related to security, for example. SvcUtil uses this protocol to generate proxies.