安全性能對于每個人來說都是很重要的，一個項目首要考慮的就是安全性能，下面就來簡述一下WCF安全性方面的一些概念。例如，安全方面的需求往往會最早被提出，安全方面Bug的優先級和危害程度往往都被定為***。有時候為了提高WCF安全性，還需要犧牲一定的性能或者其他因素。因為性能，往往可以通過一些別的方式，例如添加一臺服務器作負載均衡來解決（順便插一句，我現在覺得對于企業來說，能夠用錢解決的往往就不是問題了），或者在之后的版本中進行優化；但是如果出了安全性方面的漏洞，很可能就已經造成了無法彌補的損失。試想，如果Windows Live Passport出現了安全上的漏洞導致用戶信息泄露，這將會引出多大的風波，對于微軟來說會造成多少名譽上的損害。但是如果性能上出現了問題——這方面例如Windows Live Space或Hotmail的早期版本都不怎么樣，但是在優化之后還是吸引了大量的用戶群體。

#T#安全性是如此的重要，自然WCF也會為它提供了良好的支持，否則也無法稱之為一個成熟的模型了（我認為，微軟希望，也正在把WCF變成.NET或者說Windows平臺下分布式通信的事實標準）。但是雖然WCF提出了豐富而強大的安全性支持，但是如果使用不當，依舊會產生安全方面的問題（同樣的例子還有Sql注入，要保證安全型還是必須通過良好的編程實踐來達成），甚至還不如不依賴WCF安全性的功能，直接使用傳統的方式，例如使用硬件或軟件防火墻來阻止非法的連接。反過來說，選擇什么樣的安全實踐也是要考慮到項目的實際情況。例如有的時候我們的確可以使用傳統的方式來保證安全性，再今后的版本中再采用高級的實踐——尤其我們現在有了WCF提供的模型，我們的優化可能只是部署一個新的程序集，然后更新一下配置而已。

WCF提出的通信模型主要可以分為兩大部分：Service Model和Channel Layer。它們各司其職，“互不干涉內政”，因此，能夠自由地組合與擴展，使開發人員能夠利用WCF提出的模型來輕松實現強大的通信功能。不過事實上，按照官方的說法，Channel Layer是Service Model的組成部分（而且官方的說法的確還是有道理啊），但是我在了解了這些內容之后還是認為將兩者概念分開為好，希望能夠就這方面的概念問題和大家討論一下。

WSDL是描述一個服務的XML格式的語言。通過一個服務的WSDL我們可以得知這個服務的地址、服務使用的協議以及服務中的各種具體定義（例如定義了哪些消息等等）。顯然，如果每次生成服務時都要自己編寫代碼輸出大段復雜的WSDL，或者在使用服務時都要解析WSDL并且在請求時還需要自己生成SOAP內容，這樣的開發效率就實在是太低了。因此，成熟的框架會提供一種“抽象”機制，使開發人員能夠輕松的定義服務，盡可能的將注意力集中在業務邏輯的實現上。例如使用ASP.NET釋放Web Services，或者利用.NET Framework中的wsdl.exe根據某個服務的WSDL描述來生成代理。這些框架和工具都能夠大大提高我們的開發效率。

WCF中的Service Model就是這樣的一種抽象。簡單地說，它可以被認作是一個與WSDL產生映射的模型。在Service Model中，與WSDL各部分相對應的概念被稱作為address、binding和contract，這就是被各種資料中所提到的“A、B、C”。除了提供了“定義”這樣的模型（用來與WSDL對應）之外，Service Model還負責了上述模型與外部請求或者回復信息的轉化。

例如，我們的Host一旦接受到了一個請求，那么它會把這個請求內容反序列化成為一個Message類型的對象，并交給Service Model處理。此時Service Model開始工作，例如它會構造出處理這個請求的環境，識別出該用哪個類型來處理請求，選擇或者創建一個類型的實例，確定應該調用的方法，隨后調用方法，得到一個結果對象。然后Service Model同樣負責將這個結果對象轉化為一個Message類型的對象，最終將其序列化并輸出（整個過程有十多個步驟，我這里只是提到了一些最重要并且最容易理解的環節。由此可見WCF的可擴展性是多么的強大）。如果使用WCF生成調用服務的代理，那么Service Model工作性質還是差不多，只是方向相反而已。

那么是由什么組件負責將一個外部的請求反序列化成為一個Message對象，待方法調用完成之后，又將表示結果的Message序列化成為輸出的內容呢（如果使用WCF作為客戶端代理，那么就變成將Message序列化為請求的內容，并且將收到的回復內容反序列化成Message對象）？這就是 Channel Layer的作用。

Channel Layer定義個一個由一系列Channel組成的Stack，Message對象在穿越這個Channel Stack的時候會經過每個Channel的處理，一步步地“形變”，最終成為了我們需要“數據形態”。例如服務返回的Message對象在經過了功能為 SOAP XML轉化的Channel之后便成了SOAP XML的形式，然后再經由一個負責加密的Channel則成為了Encrypted數據（當然實際的步驟也沒有那么簡單），最終經由一個負責TCP/IP信道傳送的Channel輸送出去。試想，如果我們自定義一個Channel將Message轉化為JSON格式，然后再使用一個Channel通過一個HTTP通道返回數據，那么不就能夠支持ASP.NET AJAX的Web Service請求功能了嗎？沒錯，的確可以這樣。事實上在新的ASP.NET Futures類庫中就提供了這樣的組件，它們是學習如何擴展WCF的優秀范例。不過這已經是題外話了，有機會我們可以另起一個話題再說。