WCF follow-up tour (16) How messages are distributed to endpoint-message Filter

In introducing the listenurimode of endpoints, we mentioned two special objects ChannelDispatcher and Channellistener. These two objects have an important place in the entire WCF messaging system, and in this section we make a simple introduction to the entire message distribution process for WCF.

1, the connection request listens

When we host a service through ServiceHost, WCF actually creates a listener for us and listens for service access requests from outside. We give an example, for example, for service Calculateservice, with the following configuration: The service has three endpoints based on BasicHttpBinding, and their addresses (logical addresses) are: http://127.0.0.1:9999/ Calculateservice,http://127.0.0.1:8888/calculateservice and Http://127.0.0.1:7777/calculateservice, The first two share the same listenuri--http://127.0.0.1:6666/calculateservice. The third one uses the default ListenUri (that is, the endpoint address).

<?xml version= "1.0" encoding= "Utf-8"
<configuration>
<system.serviceModel>
<services>
<service name= "Artech.WcfServices.Services.CalculateService"
<en Dpoint address= "Http://127.0.0.1:9999/calculateservice" binding= "BasicHttpBinding"
contract= "Artech.wcfservi" Ces. Contracts.icalculate "listenuri=" Http://127.0.0.1:6666/calculateservice "/>
<endpoint address=" HTTP://12 7.0.0.1:8888/calculateservice "binding=" BasicHttpBinding "
contract=" Artech.WcfServices.Contracts.ICalculate " Listenuri= "Http://127.0.0.1:6666/calculateservice"/>
<endpoint address= "Http://127.0.0.1:7777/calculat EService "binding=" BasicHttpBinding
contract= "Artech.WcfServices.Contracts.ICalculate"/>
< /service>
</services>
</system.servicemodel>
</configuration>

When we host the service through ServiceHost, a ServiceHost object is created for the service. When we execute the ServiceHost open method, WCF creates two ChannelDispatcher objects. Why would it be two ChannelDispatcher objects? This is because the ChannelDispatcher is created from the actual listener address, and in this case, although we created three endpoints for the service, because the first two shared the same listener address, the ServiceHost object for the service, Matches two ChannelDispatcher objects. For each ChannelDispatcher object, each of them corresponds to a unique Channellistener object, Channellistener has two aspects, one is binding to a specific URI, listening to the connection request from the outside, The second is that when a request is detected, the channel stack (channel stack) is created to accept and process the request. The execution of the ServiceHost open method also heralds the beginning of the Channellistener listening process.

Because we have registered three endpoints for this service, WCF also creates 3 EndpointDispatcher objects that correspond to three endpoints. The message to the service access request is first Channeldispacher (depending on which Channellistener received the message), and channeldispacher itself does not handle the message. Instead of forwarding it to the corresponding endpointdispatcher, all subsequent processing based on the message is called by the EndpointDispatcher for processing. For these three EndpointDispatcher objects, the preceding two matches the first ChannelDispatcher (matched according to the actual listener address).

To sum up, a calculateservice service corresponds to a ServiceHost object. The ServiceHost object has two ChannelDispatcher objects, each of which has a Channellistener object, and their corresponding listener addresses are http:// 127.0.0.1:6666/calculateservice and Http://127.0.0.1:7777/calculateservice. For the previous channeldispatcher, there are two matching EndpointDispatcher objects, the latter having a matching EndpointDispatcher object. The specific relationship is shown in the following illustration: