Learning WCF Chapter2 Messaging Protocols

In Chapter 1,you were introduced to fundamental WCF concepts,      在章节1中，学习了wcf中的基础概念
including how to create and consume a service,           包括如何创建以及调用服务
how to host a service and expose endpoints where it can be reached by clients,    如何托管服务，使得客户端可以使用endpoint去访问
how to support metadata exchange so that clients can generate service contracts,    如何支持元数据交互，确保客户端可以生成服务契约
and how to work with client proxies to invoke service operations.    如何使用客户端代理来调用服务操作

In Chapter 1,you also learned the importance of service metadata,which is shared with clients through a WSDL document.
Service metadata includes all of the necessary information for a client to invoke service operations, including:
• The address where messages should be sent
• The protocols supported by the service,including transport protocol,message encoding format, and other messaging protocols
• A list of service operations and the required information to be passed to or returned from those operations

The service contract is the hub of this metadata—defining a set of operations,parameters,and return values.
Each service contract represents a group of logically related operations that are exposed through endpoints.
Endpoints describe the address where messages can be sent to reach those operations and the other required protocols to process those messages.

Services may implement one or more service contracts,and thus may have different logical groupings of operations,
but all of this is still ultimately included in the WSDL document.

As discussed in Chapter 1,clients communicate with services by exchanging messages
that are serialized on the wire and deserialized into CLR types at each end.

In the simplest scenario,client and service developers work only with objects,and all the serialization magic happens somewhere down below in the plumbing. WCF provides this plumbing.
WSDL describes the protocols required to reach the service,clients use proxies to communicate with the service,and messages just happen.
There are times,however,when developers must exercise more control over service contract design over message serialization and over the choice of protocols.
For these scenarios, it helps to understand the options available.

This chapter is all about contracts and serialization.
I’ll be describing in detail how to design service contracts,
how to work with complex types using data contracts and other serializable types,
and how to gain more control over the entire message structure using message contracts.

Toward the end of the chapter,I’ll also be discussing ways you can interact with raw messages.
Before I dive into these core concepts,I’ll provide you with a brief overview of the messaging protocols supported by WCF,
since those are what define the message format.
I’ll also provide you with more details on the WSDL document that guides serialization between clients and services.

 

Messaging Protocols
Regardless of the transport protocol (TCP,named pipes,MSMQ,or HTTP),messages are represented by the runtime in the same way,
as a Message type from the System.ServiceModel.Channels namespace.

The Message type is essentially a runtime representation of a SOAP message.
When serialized,the wire format of the message complies with SOAP 1.1 or 1.2 depending on the binding configuration for the endpoint.

The Message type also holds addressing headers,consistent with the WS-Addressing standard.
These are serialized with the message if the binding supports addressing.

When the service model processes messages,other standards may also come into play to add features such as security and reliability.
The service model supplies channels for many of the emerging protocols,usually referred to as WS* (pronounced WS-Star).
Through bindings (discussed in Chapter 3),you can enable features that use these protocols.
In short,WCF relies on standards to serialize messages;
here I’ll provide you with an overview in this chapter of the core standards that will be elaborated on throughout this book.

 

Note：Keep in mind that you will rarely need to worry about the details of messaging protocols because WCF implements them in the plumbing of the service model.

 

SOAP
SOAP was introduced in 1999—a short specification that finally made it possible to standardize how messages are exchanged on the wire,
using XML at its core to support interoperability.
A SOAP message contains message headers and a message body.
The basic XML structure for a SOAP message contains a root Envelope element with two child elements:
an optional Header element and a required Body element as follows:

<Envelope>
  <Header>
    <!-- message headers -->
  </Header>
  <Body>
    <!-- message body elements -->
  </Body>
</Envelope>

 

The message body is required. It contains data custom to an application.
For example,when a client invokes a service operation,a request message is sent containing the data required by the operation.
For each parameter,a separate XML element is provided within the message body.
These elements are ultimately deserialized into the appropriate associated CLR types.
If the operation returns a value,or if there are any out parameters,a response message is sent containing these values,each wrapped in an XML element. These are deserialized at the client into the appropriate CLR type.

A message header contains information that supports communication but is not usually directly tied to the business functionality of the specific service operation.
Message headers are a useful way to pass addressing and routing instructions,credentials,message identifiers,
and other details that support communications.
Many specifications exist that provide standardized headers to accomplish these types of goals.

 

Message headers are usually handled by the underlying plumbing,while the message body is defined by the application.
The serialized format of the SOAP message depends on the version of the SOAP specification being used: SOAP 1.1 or 1.2.
SOAP 1.1 is the original specification supported by earlier web service platforms,and SOAP 1.2 is the more commonly used standard today.
Consider this service contract with a single operation:

[ServiceContract(Namespace = "http://www.thatindigogirl.com/samples/2006/06")]
public interface IRequestReply
{
[OperationContract]
bool RequestReply(string param1, int param2, DateTime param3);
}

Without adding any fancy protocols for security or reliability,the request message would look like Example 2-1.

Example 2-1. SOAP request message

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <To s:mustUnderstand="1"
    xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">
      http://localhost:8000/Soap11
    </To>
    <Action s:mustUnderstand="1"
    xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">
      http://www.thatindigogirl.com/samples/2006/06/IRequestReply/RequestReply
    </Action>
  </s:Header>
  <s:Body>
    <RequestReply xmlns="http://www.thatindigogirl.com/samples/2006/06">
      <param1>string value</param1>
      <param2>10</param2>
      <param3>2007-02-17T12:13:35.0903315-08:00</param3>
    </RequestReply>
  </s:Body>
</s:Envelope>

 

In the request message, you’ll notice the following characteristics:

• The To header indicates the URI of the service endpoint.
• The Action header indicates the URI for the operation being invoked.
• The message body includes a wrapper element named for the operation,RequestReply, which has a child element for each parameter.
• The message body wrapper uses the namespace of the service contract.

The message response for the same operation would look as shown in Example 2-2.
In this case,no headers are present,and the message body contains a wrapper named for the operation with the suffix “Response.”
Inside the wrapper is a child containing the actual return value named for the operation with the suffix “Result.”

Example 2-2. SOAP response message

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <RequestReplyResponse xmlns="http://www.thatindigogirl.com/samples/2006/06">
      <RequestReplyResult>true</RequestReplyResult>
    </RequestReplyResponse>
  </s:Body>
</s:Envelope>

 

My point is not to inspect each aspect of the SOAP message format here,but to raise awareness to the contents of a SOAP message
so that when I discuss features of WCF that control how messages are serialized,you’ll know which aspect of the message I’m referring to.

 

WS*
SOAP describes a general format for messages.
The actual contents of the message header and body are not controlled by the SOAP specification.

An application can fully customize what headers it expects and what data the body should include to do meaningful work.
Certain common needs are shared,however,across most business implementations of SOAP—the need to communicate securely and reliably at the forefront.
That’s where WS* comes in.
WS* is a growing set of standard protocols developed with wide industry backing to handle common messaging needs between applications.
The list of WS* protocols is long,but there are a set of standards that are quite well-adopted today across platforms,
and a few more that are well on their way.
Here are some of the key protocols that I’ll be touching on in this book:

 

WS-Addressing
Describes a standard set of message headers that describe
which operation the message is targeting (To),
where the operation should reply to (ReplyTo),
which application the message is from (From),
and other information that can impact the routing of the message.
I’ll touch on various addressing headers throughout the book.

WS-MetadataExchange
Is a protocol for discovering the messaging requirements and policy for a particular service endpoint.
SvcUtil uses this protocol to generate WSDL documents from a service description.

WS-Policy
Is a protocol for describing information about WS* protocol requirements inside the WSDL document or in WS-MetadataExchange operations.

MTOM
Is an encoding format that is useful for sending large messages over HTTP. I’ll discuss this in Chapter 3.

WS-Security, WS-Trust, and WS-SecureConversation
Are standard protocols for securing message exchanges. I’ll discuss these in detail in Chapter 7.

WS-ReliableMessaging
Is a protocol for improving reliable transfer of messages by providing delivery guarantees. This is discussed in Chapter 6.

WS-AtomicTransaction
Is a protocol for distributing transactions over HTTP. I’ll also discuss this in Chapter 6.

 

I want to emphasize that each of these sets of protocols are described in quite lengthy documents at the W3C (www.w3c.org) or at OASIS(www.oasis-open.org).

The beauty of WCF is that it hides the plumbing related to these standards so that developers do not have to learn the details.
It helps to have a high-level understanding of each protocol, and I will provide this as I touch on each throughout this book.