WCF客戶端運行時架構體系詳解[上篇]
客戶端調用WCF服務的方式不外乎有兩種：其一、通過代碼生成工具（比如SvcUtil.exe）導入服務的元數據生成服務代理相關的類型；其二、通過ChannelFactory<TChannel>創建服務代理對象。對于前者，生成的服務代理是一個繼承自ClientBase<TChannel>的類型。對于這樣一個服務代理對象，其內部本質上還是借助于ChannelFactory<TChannel>創建真正用于進行服務調用的代理對象。對于WCF客戶端應用編程接口來說，ChannelFactory<TChannel>是一個核心類型。
目錄
一、創建ChannelFactory<TChannel>
二、客戶端架構體系
信道初始化
消息檢驗
操作和操作選擇
三、 客戶端操作（ClientOperation）
一、創建ChannelFactory<TChannel>
服務調用的本質實際上是針對服務的某個終結點的調用，說得具體地應該是：客戶端通過相匹配的終結點調用服務的終結點。終結點具有ABC(Address, Binding, Contract)三要素，這里所說的“相匹配”的終結點具體體現在這三要素的匹配上。而服務調用最終體現在消息交換上，接下來我們從消息交換的角度來談談匹配終結點在服務調用的必要性。
- 地址（Address）：地址作為調用服務的唯一標識并代表了服務所在的位置，客戶端終結點必須具有一個正確的地址才能確保請求的消息被發送到正確的目的地；
- 綁定（Binding）：作為信道層的締造者，綁定最終創建了用于實現消息處理和傳輸的信道棧。客戶端必須具有一個與服務端一致的信道棧，才能確保消息的一致性處理。具體來說，客戶端必須具有與服務端一致的傳輸信道，才能確保消息能夠被正常地傳輸到服務端。如果服務端具有采用一個基于HTTP協議的傳輸信道進行請求的監聽，客戶端就不能使用一個基于TCP的傳輸信道。服務端和客戶端必須具有一個相同的消息編碼信道才能確保被一方編碼的消息能夠被另一個解碼。如果服務端采用基于文本的消息編碼信道，客戶端采用的消息編碼信道就不能是基于二進制的。此外，幾乎所有的WS-*規范在WCF的實現都是通過自定義信道來控制消息交換來完成的，所以這也要求客戶端和服務端必須具有對等的信道設置；
- 契約（Contract）：契約最終決定了基于某個操作的服務調用應該采用的消息交換模式，以及參與消息交換的消息本身所具有的結構。為了讓客戶端和服務端就此達成一致，必要要求雙方采用等效的契約。
用于創建服務代理對象的ChannelFactory<TChannel>對象本身就是基于某個具體的客戶端終結點創建的。你可以通過編程的方式（構造函數）指定終結點的三要素，也可以將此三要素定義在配置文件中，通過終結點配置名稱（構造函數的endpointConfigurationName參數）來創建ChannelFactory<TChannel>。下面的代碼片斷給出了相關定義。
{
public ServiceEndpoint Endpoint { get; }
}
public class ChannelFactory<TChannel> : ChannelFactory, IChannelFactory<TChannel>, IChannelFactory, ICommunicationObject
{
//其他成員
public ChannelFactory(string endpointConfigurationName);
protected ChannelFactory(Type channelType);
public ChannelFactory(Binding binding, EndpointAddress remoteAddress);
public ChannelFactory(Binding binding, string remoteAddress);
public ChannelFactory(string endpointConfigurationName, EndpointAddress remoteAddress);
}
當我們通過調用構造函數創建某個ChannelFactory<TChannel>對象后，WCF會根據指定的終結點創建一個ServiceEndpoint對象。而該ServiceEndpoint就是ChannelFactory<TChannel>對象的核心，只讀屬性Endpoint返回的也就是這個ServiceEndpoint對象。ServiceEndpoint在ChannelFactory<TChannel>中的結構分布如下圖所示。
WCF服務端架構體系的建立始于ServiceHost的開啟，而整個架構體系根據創建ServiceHost時初始化的用于描述服務的ServiceDescription對象來構建的。與此類似，當我們開啟ChannelFactory<TChannel>的時候，WCF會根據之前創建的ServiceEndpoint來構建客戶端的運行時架構體系。
下圖揭示了WCF客戶端框架體系的大體結構。在該架構體系中，表示客戶端運行時的ClientRuntime是其核心。當ChannelFactory<TChannel>開啟的時候，Binding的BuildChannelFactory<TChannel>方法會被調用，其結果就是：調用所有綁定元素的同名方法，并將創建出來的信道工廠組合成信道工廠棧。而連接它和ClientRuntime的是一個名為ServiceChannelFactoryOverXxx的對象。根據由消息交換模式決定的信道形狀（Channel Shape）和是否支持會話，ServiceChannelFactoryOverXxx具體可分為6種：ServiceChannelFactoryOverOutput/ServiceChannelFactoryOverOutputSession、ServiceChannelFactoryOverRequest/ServiceChannelFactoryOverRequestSession、ServiceChannelFactoryOverDuplex/ServiceChannelFactoryOverDuplex。
ClientRuntime是與DispatchRuntime相匹配的位于客戶端的運行時，也是整個客戶端框架體系的核心，以及我們正對客戶端進行擴展頻繁使用到的對象。接下來，我們也從擴展的角度來介紹客戶端運行時。
信道初始化
ClientRuntime具有兩個基于信道初始化器（ChannleInitializer）列表的屬性，分別是ChannelInitializers和InteractiveChannelInitializers。
{
//其他成員
public SynchronizedCollection<IChannelInitializer> ChannelInitializers { get; }
public SynchronizedCollection<IInteractiveChannelInitializer> InteractiveChannelInitializers { get; }
}
其中ChannelInitializers中元素被稱為ChannelInitializer，實現了IChannelInitializer接口。如下面的代碼片斷所示，IChannelInitializer具有唯一的Initialize方法用以對客戶端信道（以IClientChannel對象表示）進行初始化。當客戶端信道被創建之后，客戶端運行時的每個ChannelInitializer的Initialize方法會被調用。
{
void Initialize(IClientChannel channel);
}
InteractiveChannelInitializers屬性表示的信道初始化器被稱為InteractiveChannelInitializer，實現了IInteractiveChannelInitializer接口。如下面的代碼片斷所示，該接口具有一組以異步模式定義的方法：BeginDisplayInitializationUI和EndDisplayInitializationUI。一般情況下，我們通過自定義InteractiveChannelInitializer提供一個指定客戶端用戶憑證的UI。
{
IAsyncResult BeginDisplayInitializationUI(IClientChannel channel, AsyncCallback callback, object state);
void EndDisplayInitializationUI(IAsyncResult result);
}
消息檢驗
對于服務端來說，當請求消息被反序列化之前，回復消息在序列化之后，它們會被分發給DispatchRuntime的DispatchMessageInspector列表以實現針對消息的后續處理。我們將這個機制成為“消息檢驗（Message Inspection）”。消息檢驗機制同樣應用于客戶端。具體來說，ClientRuntime同樣具有一組消息檢驗器,對應于它的只讀屬性MessageInspectors。
{
//其他成員
public SynchronizedCollection<IClientMessageInspector> MessageInspectors { get; }
}
不過它們的名稱為ClientMessageInspector，實現了具有如下定義的IClientMessageInspector接口。當被序列化后的請求消息被分發到信道層之前，接收到的回復消息被反序列化之后，都會被分發給ClientRuntime的ClientMessageInspector列表。在這兩種情況下，BeforeSendRequest和AfterReceiveReply這兩個方法分別被調用，實現針對于請求消息和回復消息的消息檢驗。
{
void AfterReceiveReply(ref Message reply, object correlationState);
object BeforeSendRequest(ref Message request, IClientChannel channel);
}
操作和操作選擇
作為服務描述的OperationDescription對象在服務端運行時被轉化成DispatchOperation對象，而客戶端則被轉化成一個ClientOperation對象。ClientRuntime的Operations屬性包含一個ClientOperation的列表，用于表示定義在當前終結點契約的所有操作。
針對某個具體的服務調用，客戶端必須針對當前的調用上下文從該操作列表中選擇一個正確的ClientOperation對象。服務端運行時的操作選擇機制可以實現在一個被稱為DispatchOperationSelector的組件中。客戶端也具有相似的操作選擇機制，而操作選擇器被稱為ClientOperationSelector，實現了一個具有如下定義的IClientOperationSelector接口。具體的操作選擇機制實現在SelectOperation方法中，傳入的參數分別表示代表操作方法的MethodBase對象和傳入的參數列表，而返回值表示最終選擇的操所名稱。具有布爾類型返回值的屬性AreParametersRequiredForSelection則表示實施操作選擇邏輯是否依賴于參數。
{
string SelectOperation(MethodBase method, object[] parameters);
bool AreParametersRequiredForSelection { get; }
}
客戶端最終采用的操作選擇器通過屬性OperationSelector表示。除了Operations和OperationSelector屬性之外，ClientRuntime還具有一個額外的屬性UnhandledClientOperation。和DispatchRuntime的UnhandledDispatchOperation屬性類似，此屬性表示的ClientOperation并不存在于Operations屬性表示的操作列表中。當操作選擇器不能正確定找到相應的ClientOperation是，此屬性表示的ClientOperation會被自動用于處理當前的服務調用。一般地，當你在定義服務契約的時候，將OperationContractAttribtue特性的Action定義成“*”時，ClientRuntime的UnhandledClientOperation屬性就代表這個操作。Operations、OperationSelector和UnhandledClientOperation屬性在ClientRuntime中的定義如下面的代碼片斷所示。
{
//其他成員
public SynchronizedKeyedCollection<string, ClientOperation> Operations { get; }
public IClientOperationSelector OperationSelector { get; set; }
public ClientOperation UnhandledClientOperation { get; }
}
至此，我們對ClientRuntime具有的可擴展組件進行了全面的介紹，這些組件在ClientRuntime中的分布大致可以通過下圖表示。
代表客戶端運行時的ClientRuntime的核心是一組代表定義在當前終結點契約中的所有操作的ClientOperation列表，我們很有必要對ClientOperation進行深入的了解。下面的代碼片斷列出了定義在ClientOperation的主要屬性。
{
//其他成員
public string Name { get; }
public string Action { get; }
public string ReplyAction { get; }
public bool IsOneWay { get; set; }
public MethodInfo SyncMethod { get; set; }
public MethodInfo BeginMethod { get; set; }
public MethodInfo EndMethod { get; set; }
public bool SerializeRequest { get; set; }
public bool DeserializeReply { get; set; }
public bool IsInitiating { get; set; }
public bool IsTerminating { get; set; }
public IClientMessageFormatter Formatter { get; set; }
public SynchronizedCollection<FaultContractInfo> FaultContractInfos { get; }
public SynchronizedCollection<IParameterInspector> ParameterInspectors { get; }
}
在定義服務契約的時候，我們通過應用OperationContractAttribute特性將定義在契約接口或類中的某個方法定義成服務操作。當我們針對某個終結點創建ChannelFactory<TChannel>的時候，反映操作描述的OperationDescription被創建出來。而當我們開啟了ChannelFactory<TChannel>之后，OperationDescription對象被轉變成真正的運行時操作對象ClientOperation。所以ClientOperation主要來源于OperationDescription，而最終決定于應用在操作方法上的OperationContractAttribute的定義。
首先，ClientOperaiton的Name、Action、ReplayAction和IsOneway對應于OperationContractAttribute特性的同名屬性。而SyncMethod和BeginMethod/EndMethod則表示同步和異步調用時對應的MethodInfo對象。具體來說，當我們通過將應用在早最方法的OperationContractAttribute特性的AsyncPattern屬性設置成true以定義異步模式的服務操作的情況下，BeginMethod/EndMethod屬性對應于BeginXxx/EndXxx方法。關于具有異步模式的操作定義，請參閱《WCF技術剖析（卷1）》第4章《服務契約（Service Contract）》。
布爾類型的屬性SerializeRequest/DeserializeReply分別表示是否需要對請求消息進行序列化，以及對回復消息進行反序列化。如果操作僅僅具有一個唯一的類型為Message的參數，就無需對參數進行序列化。相應地，如果返回值（或者ref/out參數）也是一個唯一的Message對象，那么也無需對回復消息進行反序列化。另為一組布爾類型的屬性IsInitiating/ IsTerminating對應于OperationContractAttribute特性的同名屬性，表示在支持會話（Session）的情況下，相應的操作是否是用于初始化/終止會話的操作。
DispatchOperation使用DispatchMessageFormatter進行請求消息的反序列化和回復消息的序列化。與之類似，ClientOperation則采用ClientMessageFormatter進行請求消息的序列化和回復消息的反序列化。ClientMessageFormatter實現了一個具有如下定義的IClientMessageFormatter接口。上述的序列化和反序列化的操作分別實現在SerializeRequest和DeserializeReply方法中。而真正被使用的ClientMessageFormatter定義在ClientOpoeration的Formatter屬性中。
{
object DeserializeReply(Message message, object[] parameters);
Message SerializeRequest(MessageVersion messageVersion, object[] parameters);
}
而最后一個FaultContractInfos屬性表述一個元素為FaultContractInfo的集合。該集合最終用于在出現異常時輔助實現針對錯誤消息（Fault Message）的序列化和反序列化。
和DispatchOperation一樣，ClientOperation具有一個ParameterInspectors屬性表示一組參數檢驗器列表。DispatchOperation和ClientOperation的參數檢驗器實現了相同的接口IParameterInspector。我們可以自定義參數檢器實現針服務調用前對輸入參數的驗證，以及服務調用后對返回值和輸出參數的驗證。
留言列表
