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

In this article, we will have an in-depth understanding of the channel distributor itself. First, let's take a look at which components it can be expanded, and the possible extensions that can be implemented by the channel distributor for WCF.

The type of the channel distributor is ChannelDispatcher. The following code snippet defines some attributes of ChannelDispatcher. These attributes represent the components that can be expanded in the channel distributor. A channel distributor is created based on a channel listener, which is used to request messages and create a channel stack for message receipt. The channel Listener corresponds to the Listener read-only attribute.

1: public class ChannelDispatcher: ChannelDispatcherBase 2: {3: // other Member 4: public SynchronizedCollection <IChannelInitializer> ChannelInitializers {get;} 5: public Collection <IErrorHandler> other {get ;} 6: public ServiceThrottle {get; set;} 7: 8: public override IChannelListener Listener {get;} 9 :}

ErrorHandler & ServiceThrottle
The ErrorHandlers attribute represents a set of ErrorHandler objects. ErrorHandler provides error messages for exception handling. The same name attribute of ServiceThrottle is used for traffic control. For more information, see Concurrency and Throttling in WCF.

ChannelInitializer
As for the ChannelInitializers attribute, it indicates a group of objects that implement the interface System. ServiceModel. Dispatcher. IChannelInitializer and are called channel initializers. As the name suggests, a channel initiator is used to initialize a service channel after it is created. The IChannelInitializer interface is defined as follows. It has only one unique Initialize method.

1: public interface IChannelInitializer 2: {3: void Initialize (IClientChannel channel); 4 :}
In terms of scalability, you can apply custom ErrorHandler and ServiceThrottle to the channel distributor for exception handling and traffic control. You can also customize the channel initialization tool to change the channel status. The above structure of the channel distributor can be simply expressed.

Channel distributor Structure

To implement custom exception handling and traffic Scaling Functions, you can apply custom components to the channel distributor. On the other hand, the channel distributor has some attributes used for the Controller's operation behavior. You can also change these attributes as needed because the channel distributor operates as expected. The following code snippet lists the main attributes that can be modified by the channel distributor. The message version (SOAP version and WS-Addressing version) indicated by the MessageVersion attribute is determined by the bound attributes with the same name.

1: public class ChannelDispatcher: ChannelDispatcherBase 2: {3: // other Member 4: public bool IncludeExceptionDetailInFaults {get; set;} 5: public bool ManualAddressing {get; set;} 6: public MessageVersion {get; set;} 7: public int maxpendinges {get; set;} 8: public bool effecesynchronously {get; set;} 9: public bool IsTransactedReceive {get; set ;}10: public int MaxTransactedBatchSize {get; set ;}11: public IsolationLevel TransactionIsolationLevel {get; set ;}12: public TimeSpan TransactionTimeout {get; set ;}13 :}

IncludeExceptionDetailInFaults
IncludeExceptionDetailInFaults: indicates whether the detailed information about the exception thrown by the server needs to be returned to the client through an error message. Based on security requirements, the default value of this attribute is False. Generally, the client must obtain the original error information of the server only during debugging. Therefore, this switch is controlled by the Service Behavior ServiceDebugBehavior. As shown in the following code, ServiceDebugBehavior has an attribute with the same name. You can also directly apply the ServiceBehaviorAttribute feature on the service type to control this Toggle through the naming attribute. For the principles behind this attribute, refer to my article "How does ServiceDebugBehavior service behavior spread exceptions?"

1: public class ServiceDebugBehavior: IServiceBehavior 2: {3: // other members 4: public bool IncludeExceptionDetailInFaults {get; set;} 5:} 6: public sealed class ServiceBehaviorAttribute: Attribute, IServiceBehavior 7: {8: // other member 9: public bool IncludeExceptionDetailInFaults {get; set;} 10 :}

ManualAddressing
Attribute ManualAddressing involves the concept of Addressing. For a SOAP message that supports WS-Addressing, its header list contains a series of WS-Addressing headers (such as To, ReplyTo, RelatesTo, etc.) To provide Addressing information required for message routing. By default, these addressing headers are finally added through the Transport Channel located at the bottom of the Channel stack. However, in some cases, we want to manually add the corresponding addressing header for the status message and route the message according to the manually added addressing information. We turn this mechanism into Manual Addressing ).

If manual addressing is enabled, when a message is finally sent to the transport layer through the transport channel, the transport channel considers that the corresponding addressing header has been successfully added, so no repeated addressing header is added. The ManualAddressing attribute of ChannelDispatcher indicates whether manual addressing is enabled. The default value is determined by the same name attribute of the bound transmission binding element. According to the addressing requirements, you can dynamically change the attribute value to force or disable manual addressing at runtime.

1: public abstract class TransportBindingElement: BindingElement 2: {3: // other members 4: public bool ManualAddressing {get; set;} 5 :}

Maxpendinges
MaxPendingReceives indicates the maximum number of messages that can be suspended (unprocessed). The default value is 1. This value can be modified through the end point behavior DispatcherSynchronizationBehavior. As shown below, DispatcherSynchronizationBehavior has an attribute of the same name.

1: public class DispatcherSynchronizationBehavior: IEndpointBehavior 2: {3: // other members 4: public int maxpendinges {get; set;} 5 :}

ReceiveSynchronously
The synchronous or Asynchronous Method for receiving request messages from the server channel layer is more effective depending on the specific communication method. By default, the choice of synchronous/asynchronous message receiving mode depends on the binding of the endpoint. For all system pre-defined binding types, they all implement a special interface IBindingRuntimePreferences. As shown in the following code snippet, The IBindingRuntimePreferences interface has a unique read-only attribute: ReceiveSynchronously. This attribute indicates whether the binding should adopt synchronous message receiving mode. By default, the bound ReceiveSynchronously attribute value is used as the same name attribute value of the corresponding channel distributor.

1: public interface IBindingRuntimePreferences 2: {3: bool effecesynchronously {get;} 4 :}
For some common system pre-defined bindings (BasicHttpBinding, WSHttpBinding, listener, listener, NetTcpBinding, NetNamedPipeBinding, and NetMsmqBinding), The ReceiveSynchronously attribute of NetMsmqBinding can be True, for other bound attributes, False is always returned. That is to say, except for NetMsmqBinding, other bindings always receive messages in asynchronous mode. In this way, messages arriving at the same time can be processed in a timely manner and the service throughput can be greatly improved. For NetMsmqBinding, its ReceiveSynchronously attribute has the same value as ExactlyOnce.

Although, by default, the attributes bound to javasesynchronously determine the attributes of the same name of the channel distributor. However, you can also change the attribute value through extension. In fact, WCF defines an endpoint behavior of the System. ServiceModel. Description. SynchronousReceiveBehavior type to set the value of the javasesynchronously attribute of the channel distributor. When this behavior is applied to the end point, the corresponding channel distributor is automatically set to True, meaning that the request message is received synchronously.

IsTransactedReceive & MaxTransactedBatchSize
Next, let's take a look at several transaction-related attributes of the channel distributor. The first is transaction-based message receipt. To determine whether a binding supports receiving transactional messages, WCF defines an interface named System. ServiceModel. Channels. ITransactedBindingElement. The definition below shows that the ITransactedBindingElement has a unique read-only attribute TransactedReceiveEnabled, indicating whether to include the message receiving work in the transaction.

1: public interface ITransactedBindingElement 2: {3: bool TransactedReceiveEnabled {get;} 4 :}
We can see from the interface name that ITransactedBindingElement is an interface defined for the binding element. For a specific binding, as long as there is any binding element in its binding element list, the ITransactedBindingElement interface is implemented, and the TransactedReceiveEnabled attribute returns True, this means that this is a binding Based on transactional message receipt. Whether the bound message can receive transactional messages is reflected in the IsTransactedReceive attribute of the channel distributor by default, maxTransactedBatchSize, another attribute, indicates the maximum number of message receipt operations that can be included in the same transaction. Only two MSMQ-based binding elements, MsmqTransportBindingElement and MsmqIntegrationBindingElement, implement the ITransactedBindingElement interface.

For the two attributes originally determined by the binding Based on transactional message receipt, we can also dynamically modify them through extensions to force or avoid transactional message receipt. For setting the MaxTransactedBatchSize attribute, WCF also defines the corresponding endpoint attribute: System. ServiceModel. Description. TransactedBatchingBehavior. The MaxTransactedBatchSize of the channel distributor corresponds to the MaxBatchSize attribute of TransactedBatchingBehavior.

1: public class TransactedBatchingBehavior: IEndpointBehavior 2: {3: // other members 4: public int MaxBatchSize {get; set;} 5 :}

TransactionIsolationLevel & TransactionTimeout
If you have read my article "WCF transaction programming ([Part 1], [Part 2], [Part 2]) you should be familiar with the other two transaction-based attributes of the channel distributor, TransactionIsolationLevel and TransactionTimeout. They represent the isolation level and timeout period of the transaction. These two attributes correspond to the same name attributes of the familiar ServiceBehaviorAttribute feature.

1: [AttributeUsage (AttributeTargets. class)] 2: public sealed class ServiceBehaviorAttribute: Attribute, IServiceBehavior 3: {4: // other Members 5: public IsolationLevel TransactionIsolationLevel {get; set;} 6: public string TransactionTimeout {get; set;} 7 :}