Learning WCF Chapter2 Messaging protocols

In the Chapter 1,you were introduced to fundamental WCF concepts, the basic concepts in WCF are learned in Chapter 1
including how to create and consume a service, including creating and invoking services
How to host a service and expose endpoints where it can is reached by clients, and how the services are managed so that the client can use endpoint to access
How to supports metadata exchange so, clients can generate service contracts, enabling metadata interactions to ensure that clients can generate service contracts
Proxies to invoke service operations. How to invoke a service operation by using a client proxy

In Chapter 1,you also learned the importance of service Metadata,which are 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 Protoco Ls
a list of service operations and the required information to being 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 is exposed through endpoints.
Endpoints describe the address where messages can be sent to reach those operations and the other required protocols to PR Ocess those messages.

Services may implement one or more service Contracts,and thus could have different logical groupings of operations,
But all of the still ultimately included in the WSDL document.

As discussed in Chapter 1,clients communicate with services by exchanging messages
That is serialized the wire and deserialized to the CLR types at each end.

In the simplest scenario,client and service developers work only with Objects,and all the serialization magic happens some Where 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 message s just happen.
There is 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 are all about contracts and serialization.
I ' ll be describing in detail what to design service contracts,
How to work with complex types using data contracts and other serializable types,
Gain more control over the entire message structure using message contracts.

Toward the end of the Chapter,i ' ll also is 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 is 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 is represented by the runtime in the same WA Y
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 th E endpoint.

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

When the service model processes Messages,other standards could also come into play to add features such as security and rel Iability.
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 the features that use these protocols.
In SHORT,WCF relies-standards to serialize messages;
Here I'll provide you with a overview in this chapter of the core standards that'll be elaborated on throughout this Bo Ok.

Note: Keep in mind so you'll rarely need to worry about the details of messaging protocols because WCF Impleme NTS them in the plumbing of the service model.

Soap
SOAP is introduced in 1999-A short specification that finally made it possible to standardize how messages is exchanged On the Wire,
The using XML at it 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 both 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 was sent containing the data required by the OP Eration. The
for each parameter,a separate XML element is provided within the message body.
These elements is ultimately deserialized into the appropriate associated CLR types.
If the operation returns a value,or if there is any out Parameters,a response message is sent containing these values , each of the wrapped in an XML element. These is deserialized at the client into the appropriate CLR type.

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

Message headers was usually handled by the underlying plumbing,while the message body was 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 are the more commonly used s Tandard today.
Consider this service contract with a single operation:

" http://www.thatindigogirl.com/samples/2006/06 " )]publicinterface  irequestreply{[operationcontract]bool Requestreply (stringint  param2, DateTime param3);}

Without adding any fancy protocols to 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>stringValue</param1> <param2>Ten</param2> <param3> -- Geneva-17T12: -:35.0903315- ,:xx</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 have a child element for each par Ameter.
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 is present,and The message body contains a wrapper named for the operation with the suffix "respo NSE. "
Inside The wrapper is a child containing the actual return value named in the operation with the suffix "Result."

Example 2-2. SOAP Response Message

<S:envelopexmlns:s= "http://schemas.xmlsoap.org/soap/envelope/">  <S:body>    <Requestreplyresponsexmlns= "http://www.thatindigogirl.com/samples/2006/06">      <Requestreplyresult>True</Requestreplyresult>    </Requestreplyresponse>  </S:body></S:envelope>

My point isn't to inspect each aspect of the SOAP message format here,but to raise awareness to the contents of a SOAP Me Ssage
So if I discuss features of WCF that control how messages is 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 is not controlled by the SOAP specification.

An application can fully customize what headers it expects and what data the body should include to does meaningful work.
Certain Common needs is 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 the standard protocols developed with wide industry backing to handle common messaging needs between a Pplications.
The list of ws* protocols is long,but there was a set of standards that was quite well-adopted today across platforms,
And a few more that is well on their.
Here is some of the key protocols that I ' ll be touching on

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,
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 the 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-metadataexchang E operations.

MTOM
is a encoding format is useful for sending large messages over HTTP. I ' ll discuss this in Chapter 3.

Ws-security, Ws-trust, and Ws-secureconversation
is 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 was 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 for each of these sets of protocols is described in quite lengthy documents at the The (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 does not has to learn the DET Ails.
It helps to has a high-level understanding of each protocol, and I'll provide this as I touch on each throughout this B Ook.

Learning WCF Chapter2 Messaging protocols