WCF back-pass series (1): goes deep into the WCF addressing Part 1-Web Service Addressing Specification

Overview

As we all know, all communication of a WCF Service occurs through the service endpoint. Each service endpoint contains an Address, a Binding, and a Contract. The contract specifies available operations, binding specifies how to communicate with the service, and the address specifies the location of the search service, that is, the very classic "ABC ". WCF uses a variety of different communication protocols to provide a flexible mode for public service endpoints and communication with them. In the first part of the WCF topic series, I will discuss the addressing details of endpoints, before that, let's take a look at the WCF programming model, as shown in 1:

Figure 1

Web Service Addressing Specification

In WCF, an Endpoint address is an Endpoint Reference (EPR) model established according to the definitions in the WS-Addressing Specification for Web service Addressing, we need to understand the Web service addressing specification. Here we first raise a question: why do we need Web service addressing? On the one hand, if SOAP is to be truly unrelated to the transmission protocol, it is necessary to define the receiver of the message and the address returned by the message in a way unrelated to the transmission protocol; on the other hand, defining addressing information helps to return a message to the requester in the event of a network error or a loss of response. The last set of addressing mechanisms makes the complex interaction mode possible, as shown in Figure 2:

Figure 2

In WS-Addressing, there are actually two concepts: Endpoint Reference and Message Information Headers in the SOAP structure ). The following example shows sending a SOAP 1.2 message to http://fabrikam123.com/purchasing. :

<S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope"   xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">  <S:Header>    <wsa:ReplyTo>      <wsa:Address>http://business456.com/client1</wsa:Address>    </wsa:ReplyTo>    <wsa:To>http://fabrikam123.com/Purchasing</wsa:To>    <wsa:Action>http://fabrikam123.com/SubmitPO</wsa:Action>  </S:Header>  <S:Body>    ......  </S:Body></S:Envelope>

Endpoint reference

A Web service endpoint is a referenced entity, processor, or resource that can be used as a Web Service Message target. An endpoint reference conveys the information required to identify or reference a Web service endpoint, it can be used in a variety of ways: the endpoint reference can be used to convey the information required to access the Web service endpoint, or to provide addresses for each message between Web Services. The following code indicates the information set referenced by the endpoint:

<wsa:EndpointReference>  <wsa:Address>xs:anyURI</wsa:Address>  <wsa:ReferenceProperties>... </wsa:ReferenceProperties> ?  <wsa:ReferenceParameters>... </wsa:ReferenceParameters> ?  <wsa:PortType>xs:QName</wsa:PortType> ?  <wsa:ServiceName PortName="xs:NCName"?>xs:QName</wsa:ServiceName> ?  <wsa:Policies> ... </wsa:Policies>?  <xs:any/>*</wsa:EndpointReference>

In the simplest sense, an endpoint reference is a URL encapsulated using XML elements, as shown in the following code:

<wsa:myLocation>  <wsa:Address>http://localhost:8887/CalculatorService</wsa:Address></wsa:myLocation>

Here, wsa: myLocation refers to the endpoint reference, which is an element defined in the Web service addressing specification. It is used to specify the address used to access the CalculatorService. As part of the endpoint reference model, each endpoint reference can contain reference parameters that add additional identifiers.

Message Header

Message Information Headers are some additional and standard SOAP Headers defined in the Web service addressing specification. They are used to help transmit Information about a Message, which is different from the endpoint reference, the message information header is included in the SOAP message as an extension of the SOAP Head. Its information set is as follows:

<wsa:To>xs:anyURI</wsa:To> ?<wsa:From>wsa:EndpointReferenceType</wsa:From> ?<wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo> ?<wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo> ?<wsa:Action>xs:anyURI</wsa:Action><wsa:MessageID>xs:anyURI</wsa:MessageID> ?<wsa:RelatesTo RelationshipType="xs:anyURI"?>xs:anyURI</wsa:RelatesTo> *<wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?

Let's explain it as follows:

To: Indicates the URL of the target Web Service. When using the endpoint reference (EPR), The To header should have the same value as the <wsa: Address> element.

From: Indicates the end point reference of the message sender. If the message receiver needs to send back the message to the end point of the sent message, it should use this end point reference.

ReplyTo: Indicates that any response from the Web service should be sent to the ReplyTo endpoint for reference. That is, the sender of the message is not necessarily the end point of the response message to be received, this is different From.

Faul.pdf: If the message response is a SOAP error, the error should be sent to the endpoint reference in the FaultTo header.

MessageID: Uniquely identifies a message.

Action: The Action can be understood in this way. When a message is sent to a service, it is simpler to specify the method to be called by the Service to process the message. The following code is used to call the Add method when you want the message to arrive at the service.

<wsa:Action>http://tempuri.org/ICalculator/Add</wsa:Action>

RelatesTo: RelatesTo is often used in response messages to indicate a URI that is related to a previously known message and defines this relationship. This is critical in the request response mode, especially in asynchronous message transmission. the receiver of the response message must be able to associate it with the original request message.

We use Figure 3 to clearly express the Message Headers and SOAP in the Message header:

Figure 3

For details about the WS-Addressing specification, refer to http://www.w3.org/submission/ws-addressing /.

Analyze WCF messages

I have introduced the Web Service Addressing Specification above. Now we can intercept the message of WCF to see how it complies with WS-Addressing. Write a simple WCF Service:

/// <summary>/// Author: TerryLee/// Url:http://www.cnblogs.com/terrylee/// </summary>[ServiceContract]public interface ICalculator{    [OperationContract]    int Add(int x, int y);}public class CalculatorService : ICalculator{    public int Add(int x, int y)    {        return x + y;    }}

We can use tracking and diagnosis To intercept SOAP messages, as shown below. We can see the To address and Action in the message header during this service call, the Action here is the Add method defined in the Service and the Body of the message:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">  <s:Header>    <To s:mustUnderstand="1">http://localhost:8887/CalculatorService</To>    <Action s:mustUnderstand="1">http://tempuri.org/ICalculator/Add</Action>  </s:Header>  <s:Body>    <Add xmlns="http://tempuri.org/">      <x>1</x>      <y>2</y>    </Add>  </s:Body></s:Envelope>

Conclusion

The Web Service Addressing Specification brings the addressing standard of the Web service world. It defines the Endpoint Reference and Message Information Headers) to provide a unified mechanism. In the next article, I will continue to analyze the addressing in WCF in depth. articles related to the WCF addressing:

WCF topic series (5): go deep into WCF addressing Part 5-Logical Address and physical address

WCF topic series (4): go deep into WCF addressing Part 4-custom message Filter

WCF topic series (3): go deep into WCF addressing Part 3-message filtering engine

WCF topic series (2): go deep into WCF addressing Part 2-custom addressing Header