Detailed description of the architecture of the WCF Server Runtime [Part 1]

 

The server architecture of WCF can also become the server architecture of the service host. We know that for a service based on a certain type of boarding, you only need to use a unique object, that is, ServiceHost. Even in a certain context, the service we call actually refers to the corresponding ServiceHost object. The whole service boarding process consists of two phases: the creation of service description and the establishment of the server running framework. The service description created in the first stage aims to establish a service for the runtime framework of the server. Therefore, we need to briefly introduce the service description.

Directory: 1. Service Description 2. Overview of the server architecture system 3. End Point distributor selection mechanism

1. Start with Service Description

When ServiceHost is instantiated, The ServiceDescription object used to describe the entire service is created. For a service, its core includes a list of endpoints and a list of service actions. This can be seen through the definition of ServiceDescription as follows.

   1:publicclassServiceDescription

   2:{

3: // other members

   4:     publicKeyedByTypeCollection<IServiceBehavior> Behaviors { get; }

   5:     publicServiceEndpointCollection Endpoints { get; }

   6:}

For the end point, the three elements of ABC, namely Address, Binding and Contract, have long been taken into consideration. Therefore, the ServiceEndpoint type used to describe an endpoint has three core attributes: Address, Binding, and Contract. In addition, the behavior list based on this endpoint is represented by the Behaviors attribute. The ServiceEndpoint is defined as follows.

   1:publicclassServiceEndpoint

   2:{

3: // other members

   4:     publicEndpointAddress Address { get; set; }

   5:     publicBinding Binding { get; set; }

   6:     publicContractDescription Contract { get; }    

   7:     publicKeyedByTypeCollection<IEndpointBehavior> Behaviors { get; }

   8:}

Now we further analyze the ContractDescription type used to describe the service contract. Because a service contract is essentially a combination of related Operations, the core attribute of ContractDescription is the Operations attribute that represents all operation descriptions as follows. In addition to the operation description list, there is also a list of actions based on the service contract itself.

   1:publicclassContractDescription

   2:{

3: // other members

   4:     publicOperationDescriptionCollection Operations { get; }

   5:     publicKeyedByTypeCollection<IContractBehavior> Behaviors { get; }

   6:}

As for the service operation description, the corresponding type is OperationDescription. OperationDescription defines a series of service-based operation attributes, which are described in detail in the previous sections. Here we mainly focus on the attributes Behaviors used to represent the operation behavior list.

   1:publicclassOperationDescription

   2:{  

3: // other members

   4:     publicKeyedByTypeCollection<IOperationBehavior> Behaviors { get; }

   5:}

The above level from service ServiceDescription to ServiceEndpoint, from ServiceEndpoint to ContractDescription, and finally to OperationDescription can basically be expressed through.

 

The ServiceDescription object created during the construction of ServiceHost is used to describe the entire service, and eventually becomes the basis for building the server runtime architecture system. This architecture system is built when ServiceHost is enabled, which is the root cause of invalid service description for any table after ServiceHost is enabled.

Ii. Overview of server architecture

To give readers a deeper understanding of the architecture of the server runtime architecture, we will introduce a specific service hosting application scenario. Suppose we use the following configuration to host the service CalculatorService. With this configuration, three endpoints Based on WSHttpBinding are added.

   1:<configuration>

   2:   <system.serviceModel>

   3:     <services>

   4:       <servicename="Artech.WcfServices.CalculatorService">

   5:         <endpointaddress      = "http://127.0.0.1:7777/CalculatorService"

   6:                   binding      = "wsHttpBinding"

   7:                   contract     = "Artech.WcfServices.ICalculator"

   8:                   listenUri    = "http://127.0.0.1:6666/CalculatorService"

   9:                   listenUriMode= "Explicit"/>

  10:         <endpointaddress      = "http://127.0.0.1:8888/CalculatorService"

  11:                   binding      = "wsHttpBinding"

  12:                   contract     = "Artech.WcfServices.ICalculator"

  13:                   listenUri    = "http://127.0.0.1:6666/CalculatorService"

  14:                   listenUriMode= "Explicit"/>

  15:         <endpointaddress      = "http://127.0.0.1:9999/CalculatorService"

  16:                   binding      =  "wsHttpBinding"

  17:                   contract     = "Artech.WcfServices.ICalculator"

  18:                   listenUri    = "http://127.0.0.1:6666/CalculatorService"

  19:                   listenUriMode= "Unique"/>

  20:       </service>

  21:     </services>

  22:   </system.serviceModel>

  23:</configuration>

As shown in the configuration snippet above, although these three endpoints have different addresses, they use the same listening URI (set through the listenUri attribute ). Furthermore, although the three endpoints have the same listening URI, their listening URI mode (set through the listenUriMode attribute), the first two endpoints are Explicit, and the third is Unique. According to the principle of "physical address and logical address" introduced in chapter 3 of "WCF Technology Analysis (Volume 1)", you will know that in this case, the final listening address has two: http: // 127.0.0.1: 6666/CalculatorService and http: // 127.0.0.1: 6666/CalculatorService/<guid>.

After the ServiceHost created based on the above configuration is enabled normally, WCF will create an architecture system as shown in. First, call the BuildChannelListener method to create a channel listener (actually a channel listener stack consisting of multiple channel listeners, and the top-layer channel listener will be returned. If you do not have a special understanding of the content of the channel layer, refer to Chapter 3rd of WCF Technology Analysis (Volume 1) binding and channel stack. These two channel listeners are respectively bound to the above two listening addresses for Request Message listening.

For these two channel listeners, WCF creates the corresponding channel distributor (ChannelDispatcher) object. For the three endpoints defined in the configuration, they correspond to an endpoint dispatcher respectively ). Each end point distributor has its own runtime, which is called the distribution runtime ).

 

When the channel listener successfully monitors the incoming request message, it uses the created channel stack to receive and process the message. Messages processed through the channel Stack are forwarded to the corresponding endpoint distributor through the channel distributor where the channel listener is located. The endpoint finally processes the received messages in its own distribution runtime. The processed result is encapsulated in the created reply message and returned to the channel distributor, and finally to the client through the channel stack. Now there is a problem: After the channel listener receives the messages received and processed by the channel stack, if it determines which endpoint distributor to forward the messages? This involves the selection mechanism of the end point distributor.

3. Selection Mechanism of the end point distributor

We will return our attention again. In addition to distribution, each end point distributor has two important objects: address filter and ContractFilter ). They all belong to a message filter object. The channel distributor determines whether the distributor is suitable for processing the current request message through the two message filters.

Specifically, each message filter is inherited from the abstract class Dispatcher. MessageFilter. MessageFilter has two overloaded methods that use Message and MessageBuffer as parameters. The channel distributor takes the Message or MessageBuffer object based on the routing Message as the input parameter before deciding which end point to route the received Message to the distributor, call the Match method of the two message filters of the end point distributor. If the method returns True, the end point distributor matches the expected message.

   1:publicabstractclassMessageFilter

   2:{    

   3:     publicabstractboolMatch(Message message);

   4:     publicabstractboolMatch(MessageBuffer buffer);

   5:}

The endpoint distributor is represented by the System. ServiceModel. Dispatcher. EndpointDispatcher type in the WCF application programming interface. The following code snippet defines the EndpointDispatcher part. In addition to representing the two attributes AddressFilter and ContractFilter of the two message filters, there is an additional integer FilterPriority attribute. The FilterPriority attribute indicates the filtering priority. When two or more end point distributors match the route message at the same time, the highest priority end point distributor will be selected. The greater the data that represents FilterPriority, the higher the priority. If there are two or more end point distributors with the highest filtering priority at the same time, the system will throw a MultipleFilterMatchesException exception.

   1:publicclassEndpointDispatcher

   2:{

3: // other members

   4:     publicMessageFilter AddressFilter { get; set; }

   5:     publicMessageFilter ContractFilter { get; set; }

   6:     publicintFilterPriority { get; set; }

   7:}

To meet the needs of various message reasons, WCF defines the following six typical message filters. If these 6 Message filters still cannot meet your needs, you can create custom message filters by inheriting the abstract class MessageFilter.

• ActionMessageFilter:Each service operation has an Action attribute, which is defined through the OperationContractAttribute feature. A service contract contains one or more service operations. Therefore, an endpoint has a group of actions. AddressMessageFilter determines whether the value of the Action header of the SOAP message is in the end point Action list, and selects the correct end point.
• EndpointAddressMessageFilter:EndpointAddress is an indispensable element of an endpoint. EndpointAddress not only contains the service address but also the addressing header (AddressHeader). The endpoint filtered by EndpointAddressMessageFilter must meet two requirements at the same time: the endpoint url uri must be consistent with the To header value of SOAP; the SOAP message must have consistent header information.
• XPathMessageFilter:The SOAP message is also an XML file, so you can match it with the SOAP content based on a specific XPath expression.
• PrefixEndpointAddressMessageFilter:Similar to the filtering mechanism of EndpointAddressMessageFilter, the difference is that PrefixEndpointAddressMessageFilter adopts the "Longest prefix matching" mechanism. For example, the URI specified by the endpoint address is vertex
• MatchAllMessageFilter:No matter what the message content is, it will match successfully.
• MatchNoneMessageFilter:Unlike MatchAllMessageFilter, no matter what the message content is, it will not match successfully.

By default, EndpointDispatcher uses EndpointAddressMessageFilter and ActionMessageFilter respectively. If you want to use other values, you can overwrite the default values in the form of custom Behavior. The most direct method for AddressFilter is to specify the MessageFilter mode you need through the AddressFilterMode attribute of ServiceBehaviorAttribute. The type of this attribute is AddressFilterMode enumeration. It has three enumerated values (Exact, Prefix, and Any) that correspond to the Message filters EndpointAddressMessageFilter, PrefixEndpointAddressMessageFilter, and MatchAllMessageFilter.

   1:publicsealedclassServiceBehaviorAttribute : Attribute, IServiceBehavior

   2:{

3: // other members

   4:     publicAddressFilterMode AddressFilterMode { get; set; }

   5:}

   6:publicenumAddressFilterMode

   7:{

   8:     Exact,

   9:     Prefix,

  10:     Any

  11:  }