你或許可以使用某一技術實現某些功能，可以按着指定的要求，完成特定的功能，實現某一想要的效果，這表示你可以使用該技術，會使用該技術，但是我們不能停留在使用的層次上，還要了解它們的運行機制，可能有點深了，有點難度，或者可以淺一些了解程序運行自己的關系，尤其像WCF將各個技術集大成，它的各個術語的含義，以及它們是如何聯系的，又是如何發揮作用的，怎樣實現WCF這一技術的特性、優點的。我們不要只是可以簡單的使用一項技術並使用的很好，當我們去講述這些技術如何時？有什么好的優點、缺點，對於解決那些方面的問題真的起到很不錯的作用，真的也很有發展前景，以及可以講述這個技術一些功能點和技術特色。像大家所想的那樣，我們不僅要知其然，還要知其所以然，不僅要會使用這些技術還有能夠講明白這些技術(技術優點、缺點、特性、適用場合、應用前景、以及各個功能點的細節等等)。凡事總是說起來容易，做起來難，但我們學這個的就欣然接受吧！程序員的我們要擁抱變化，要適應變化，要做好技術儲備。學習編程，學技術，做開發，做軟件，真的很累啊！不過，也挺快樂的，有接觸新鮮事物的好奇，有解決一個問題的喜悅，有實現某個功能（小項目）的成就感。 像大家常說的干IT，老挨踢，加班趕工，又苦逼。很累也很快樂。讓我們痛苦的幸福着吧！ (牢騷一下！)
本篇主要是自己對WCF服務編程的書籍的學習筆記或是簡單的摘錄吧！基本沒代碼，都是一些術語、各個技術點的聯系、和各個技術點的優缺點。對於一個對分布式應用不太了解的菜鳥，去學習一門把Windows下分布式應用技術集大成的WCF了解、熟悉也是不錯的吧！
對於WCF的更多使用和了解，推薦博客Artech：http://www.cnblogs.com/artech/
WCF服務編程 學習筆記
Windows Communication Foundation, WCF。集成分布式系統技術，包括 ASP.NET 服務、Web 服務增強（WSE）、.NET Remoting、消息傳輸/MSMQ以及企業服務/COM+等的實現。 WCF 內建的特性，例如服務托管、實例管理、並發管理、事務、離線隊列調用以及安全。
WCF基礎
1.什么是WCF
Windows 通信基礎（Windows Communication Foundation，WCF）是基於 Windows平台下開發和部署服務的軟件開發包（Software Development Kit，SDK）。WCF 的第一個版本為服務開發提供了許多有用的功能，包括托管（Hosting）、服務實例管理（Service Instance Management）、 異步調用、可靠性、事務管理、離線隊列調用（Disconnected Queued Call）以及安全性。
2.服務
服務（Services）是公開的一組功能的集合。從軟件設計的角度考慮，軟件設計思想經歷了從函數發展到對象，從對象發展到組件，再從組件發展到服務的幾次變遷。面向服務 （Service-Orientation，SO）是一組原則的抽象，是創建面向服務應用程序的最佳實踐。
服務可以是本地的，也可以是遠程的，可以由多個參與方使用任意技術進行開發。服務與版本無關，甚至可以在不同的時區同時執行。服務內部包含了諸如語言、技術、平台、版本與框架等諸多概念，而服務之間的交互，則只允許指定的通信模式。
客戶端與服務通過消息的發送與接收進行交互。消息可以直接在客戶端與服務之間進行傳遞，也可以通過中間方進行傳遞。WCF 中的所有消息均為 SOAP 消息。注意 WCF 的消息與傳輸協議無關，這與 Web 服務不同。因此，WCF 服務可以在不同的協議之間傳輸，而不僅限於 HTTP。WCF 客戶端可以與非 WCF 服務完成互操作，而 WCF 服務也可以與非WCF 客戶端交互。不過，如果需要同時開發客戶端與服務，則創建的應用程序兩端都要求支持 WCF，這樣才能利用 WCF 的特定優勢。 因為服務的創建對於外界而言是不透明的，所以 WCF 服務通常通過公開元數據（Metadata）的方式描述可用的功能以及服務可能采用的通信方式。元數據的發布可以預先定義，它與具體的技術無關（Technology-Neutral），例如采用基於 HTTP-GET 方式的WSDL，或者符合元數據交換的行業標准。一個非 WCF 客戶端可以將元數據作為本地類型導入到本地環境中。相似的，WCF 客戶端也可以導入非 WCF 服務的元數據，然后以本地CLR 類與接口的方式進行調用。
3.服務的執行邊界
WCF 不允許客戶端直接與服務交互，即使它調用的是本地機器內存中的服務。相反，客戶端總是使用代理（Proxy）將調用轉發給服務。代理公開的操作與服務相同，同時還增加了一些管理代理的方法。
WCF 允許客戶端跨越執行邊界與服務通信。在同一台機器中（參見圖 1-2），客戶端可以調用同一個應用程序域中的服務，也可以在同一進程中跨應用程序域調用，甚至跨進程調用。WCF 允許客戶端跨越執行邊界與服務通信。在同一台機器中（參見圖 1-2），客戶端可以調用同一個應用程序域中的服務，也可以在同一進程中跨應用程序域調用，甚至跨進程調用。
4.WCF與位置透明度
過去，諸如 DCOM 或.NET Remoting 等分布式計算技術，不管對象是本地還是遠程，都期望為客戶端提供相同的編程模型。本地調用時，客戶端使用直接引用；處理遠程對象時，則使用代理。因為位置的不同而采用兩種不同的編程模型會導致一個問題，就是遠程調用遠比本地調用復雜。復雜度體現在生命周期管理、可靠性、狀態管理、可伸縮性（scalability）以及安全性等諸多方面。由於遠程對象並不具備本地對象的特征，而編程模型卻力圖讓它成 為本地對象，反而使得遠程編程模型過於復雜。WCF 同樣要求客戶端保持一致的編程模型，而不用考慮服務的位置。但它的實現途徑卻大相徑庭：即使對象是本地的，WCF 仍然使用遠程編程模型的實例化方式，並使用代理。由於所有的交互操作都經由代理完成，要求相同的配置與托管方式，因而對於本地和遠程方式而言，WCF 都只需要維持相同的編程模型。這就使得開發者不會因為服務位置的改變影響客戶端，同時還大大地簡化了應用程序的編程模型。
5.地址
WCF 的每一個服務都具有一個唯一的地址（Addresses）。地址包含兩個重要元素：服務位置與傳輸協議（Transport Protocol），或者是用於服務通信的傳輸樣式（Transport Schema）。服務位置包括目標機器名、站點或網絡、通信端口、管道或隊列，以及一個可選的特定路徑或者 URI。URI 即統一資源標識（Universal Resource Identifier），它可以是任意的唯一標識的字符串，例如服務名稱或 GUID。
WCF 1.0 支持下列傳輸樣式：HTTP、TCP、Peer network（對等網）、IPC（基於命名管道的內部進程通信）、MSMQ 。 地址通常采用如下格式：[基地址]/[可選的 URI] 基地址（Base Address）通常的格式如下：[傳輸協議]://[機器名或域名][:可選端口]
下面是一些地址的示例：
http://localhost:8001
http://localhost:8001/MyService
net.tcp://localhost:8002/MyService
net.pipe://localhost/MyPipe
net.msmq://localhost/private/MyService
net.msmq://localhost/MyService
可以將地址http://localhost:8001 讀作：“采用HTTP協議訪問localhost機器，並在 8001端口等待用戶的調用。”
如果URI為http://localhost:8001/MyService，則讀作：“采用HTTP協議訪問localhost機器，MyService服務在 8001 端口處等待用戶的調用。”
(1).TCP地址
TCP 地址采用 net.tcp 協議進行傳輸，通常它還包括端口號，例如： net.tcp://localhost:8002/MyService 如果沒有指定端口號，則 TCP 地址的默認端口號為 808： net.tcp://localhost/MyService 兩個 TCP 地址（來自於相同的宿主，具體內容將在本章后面介紹）可以共享一個端口： net.tcp://localhost:8002/MyService net.tcp://localhost:8002/MyOtherService 本書廣泛地使用了基於 TCP 協議的地址。 注意：我們可以將不同宿主的 TCP 地址配置為共享一個端口。
(2).HTTP地址
HTTP地址使用http協議進行傳輸，也可以利用https進行安全傳輸。HTTP地址通常會被用作對外的基於Internet的服務，並為其指定端口號，例如： http://localhost:8001 如果沒有指定端口號，則默認為 80。與TCP地址相似，兩個相同宿主的HTTP地址可以共享一個端口，甚至相同的機器。 本書廣泛地使用了基於 HTTP 協議的地址。
(3).IPC地址
IPC 地址使用 net.pipe 進行傳輸，這意味着它將使用 Windows 的命名管道機制。在 WCF中，使用命名管道的服務只能接收來自同一台機器的調用。因此，在使用時必須指定明確的本地機器名或者直接命名為 localhost，為管道名提供一個唯一的標識字符串： net.pipe://localhost/MyPipe 每台機器只能打開一個命名管道，因此，兩個命名管道地址在同一台機器上不能共享一個管道名。 本書廣泛地使用了基於 IPC 的地址。
(4).MSMQ地址
MSMQ 地址使用 net.msmq 進行傳輸，即使用了微軟消息隊列（Microsoft Message Queue，MSMQ）機制。使用時必須為 MSMQ 地址指定隊列名。如果是處理私有隊列，則必須指定隊列類型，但對於公有隊列而言，隊列類型可以省略： net.msmq://localhost/private/MyService net.msmq://localhost/MyService 本書第 9 章將專門介紹隊列調用。
(5).對等網地址
對等網地址（Peer Network Address） 使用 net.p2p 進行傳輸，它使用了 Windows 的對等網傳輸機制。如果沒有使用解析器（Resolver），我們就必須為對等網地址指定對等網名、唯一的路徑以及端口。對等網的使用與配置超出了本書范圍，但在本書的后續章節中會簡略地介紹對等網。
6.契約
WCF 的所有服務都會公開為契約（Contract）。契約與平台無關，是描述服務功能的標准方式。
WCF 定義了四種類型的契約：
(1).服務契約（Service Contract）
服務契約描述了客戶端能夠執行的服務操作。
(2).數據契約（Data Contract）
數據契約定義了與服務交互的數據類型。WCF 為內建類型如 int 和 string 隱式地定義了契約；我們也可以非常便捷地將定制類型定義為數據契約。
(3).錯誤契約（Fault Contract）
錯誤契約定義了服務拋出的錯誤，以及服務處理錯誤和傳遞錯誤到客戶端的方式。
(4).消息契約（Message Contract）
消息契約允許服務直接與消息交互。消息契約可以是類型化的，也可以是非類型化的。如果系統要求互操作性，或者遵循已有消息格式，那么消息契約會非常有用。由於 WCF 開發者極少使用消息契約，因此本書不會介紹它。
7.服務契約
ServiceContract 特性可以將一個 CLR 接口（或者通過推斷獲得的接口，后面將詳細介紹）映射為與技術無關的服務契約。ServiceContract 特性公開了 CLR 接口（或者類）作為 WCF契約。WCF 契約與類型的訪問限定無關，因為類型的訪問限定屬於 CLR 的概念。即使將ServiceContract 特性應用在內部（Internal）接口上，該接口同樣會公開為公有服務契約，以便於跨越服務邊界實現服務的調用。如果接口沒有標記 ServiceContract 特性，WCF 客戶端則無法訪問它（即使接口是公有的）。這一特點遵循了面向服務的一個原則，即明確的服務邊界。為滿足這一原則，所有契約必須明確要求：只有接口（或者類）可以被標記為ServiceContract 特性，從而被定義為 WCF 服務，其他類型都不允許。
即使應用了 ServiceContract 特性，類型的所有成員也不一定就是契約中的一部分。我們必須使用 OperationContractAttribute 特性顯式地標明哪些方法需要暴露為 WCF 契約中的一部分。WCF 只允許將 OperationContract 特性應用到方法上，而不允許應用到同樣屬於 CLR 概念的屬性、索引器和事件上。WCF 只能識別作為邏輯功能的操作（Operation）。通過應用 OperationContract 特性，可以將契約方法暴露為邏輯操作，使其成為服務契約的一部分。接口（或類）中的其他方法如果沒有應用 OperationContract 特性，則與契約無關。這有利於確保明確的服務邊界，為操作自身維護一個明確參與（Opt-In）的模型。此外，契約操作不能使用引用對象作為參數，只允許使用基本類型或數據契約。
8.應用Service Contract特性
WCF 允許將 ServiceContract 特性應用到接口或類上。當接口應用了 Service-Contract特性后，需要定義類實現該接口。
一個單獨的類通過繼承和實現多個標記了 ServiceContract 特性的接口，可以支持多個契約。
然而，服務類還有一些實現上的約束。我們要避免使用帶參構造函數，因為 WCF 只能使用默認構造函數。同樣，雖然類可以使用內部（internal）的屬性、索引器以及靜態成員，但WCF 客戶端卻無法訪問它們。
WCF 允許我們直接將 ServiceContract 特性應用到服務類上，而不需要首先定義一個單獨的契約。通過服務類的定義，WCF 能夠推斷出契約的定義。至於 OperationContract 特性，則可以應用到類的任何一個方法上，不管它是私有方法，還是公有方法。
警告：應盡量避免將 ServiceContract 特性直接應用到服務類上，而應該定義一個單獨的契約，這有利於在不同場景下使用契約。
9.名稱與命名空間
可以為契約定義命名空間。契約的命名空間具有與.NET 編程相同的目的：確定契約的類型范圍，以降低類型的沖突幾率。可以使用 ServiceContract 類型的 Namespace 屬性設置命名空間。
若非特別指定，契約的默認命名空間為http://tempuri.org 。對外服務的命名空間通常使用公司的URL；至於企業網（Intranet）內部服務的命名空間，則可以定義有意義的唯一名稱，例如MyApplication。
在默認情況下，契約公開的名稱就是接口名。但是也可以使用ServiceContract特性的Name屬性為契約定義別名，從而在客戶端的元數據（Metadata）中公開不同的名稱。相似的，操作公開的名稱默認為方法名，但我們同樣可以使用 OperationContract 特性的Name 屬性設置別名，從而公開不同的操作名。
10.托管(寄宿)
WCF 服務類不能憑空存在。每個 WCF 服務都必須托管（Hosting） 在 Windows 進程中，該進程被稱為宿主進程（Host Process）。單個宿主進程可以托管多個服務，而相同的服務類型也能夠托管在多個宿主進程中。WCF 沒有要求宿主進程是否同時又是客戶端進程。顯然，一個獨立的進程有利於錯誤與安全的隔離。誰提供進程或是提供何種類型的進程並不重要。宿主可以由 IIS 提供，也可以由 Windows Vista 的 Windows 激活服務（Windows Activation Service，WAS）提供，或者開發者直接將它作為應用程序的一部分。
注意：一種特殊的托管方式稱為進程內托管（In-Process Hosting），簡稱 in-proc。服務與客戶端駐留在相同的進程中。通過定義，開發者能夠提供進程內托管。 (1).IIS 托管
在微軟的 Internet 信息服務器（Internet Information Server，IIS）中托管服務，主要的優勢是宿主進程可以在客戶端提交第一次請求的時候自動啟動，還可以借助 IIS 管理宿主進程的生命周期。IIS 托管的主要缺點在於只能使用 HTTP 協議。如果是 IIS 5，還要受端口限制，要求所有服務必須使用相同的端口號。 在 IIS 中托管服務與經典的 ASMX Web 服務托管相似，需要在 IIS 下創建虛擬目錄，並提供一個.svc 文件。.svc 文件的功能與.asmx 文件相似，主要用於識別隱藏在文件和類后面的服務代碼。例 1-2 展示了.svc 文件的語法結構。(此文件是通過創建網站WCF服務，創建文件，IIS宿主。)
例 1-2：.svc 文件 <%@ ServiceHost Language= "C#" Debug = "true" CodeBehind = "~/App_Code/MyService.cs" Service = "MyService" %> 注意：我們甚至可以將服務代碼注入到.svc 文件中，但這樣的做法並不明智。這與 ASMX Web 服務的要求相同。
使用 IIS 托管，服務的基地址必需與.svc 文件的地址保持一致。
Web.Config文件 Web 站點的配置文件（Web.Config）必須列出需要公開為服務的類型。類型使用類型全名，如果服務類型來自於一個沒有被引用的程序集，則還要包括程序集名。
(2).自托管
所謂自托管（Self-Hosting） ，就是由開發者提供和管理宿主進程的生命周期。自托管方式適用於如下場景：需要確定客戶端與服務之間的進程（或機器）邊界時；使用進程內托管，即服務與客戶端處於相同的進程中時。進程可以是任意的 Windows 進程，例如 Windows窗體應用程序、控制台應用程序或 Windows NT 服務。注意，進程必須在客戶端調用服務之前運行，這意味着通常必須預先啟動進程。但 NT 服務或進程內托管不受此限制。宿主程序的實現只需要簡單的幾行代碼，就能夠實現 IIS 托管的一部分特性。
與 IIS 托管相似，托管應用程序的配置文件（App.Config）必須列出所有希望托管和公開的服務類型。
此外，宿主進程必須在運行時顯式地注冊服務類型，同時為客戶端的調用打開宿主，因此，我們才要求宿主進程必須在客戶端調用到達之前運行。創建宿主的方法通常是在 Main()方法中調用 ServiceHost 類。
創建 ServiceHost 對象時，需要為 ServiceHost 的構造函數提供服務類型，至於默認的基地址則是可選的。可以將基地址集合設置為空。如果提供了多個基地址，也可以將服務配置為使用不同的基地址。ServiceHost 擁有基地址集合可以使得服務能夠接收來自於多個地址和協議的調用，同時只需要使用相對的 URI。注意，每個 SeriviceHost 實例都與特定的服務類型相關，如果宿主進程需要運行多個服務類型，則必須創建與之匹配的多個ServiceHost 實例。在宿主程序中，通過調用 Open()方法，可以允許調用傳入；通過調用Close()方法終結宿主實例，完成進程中的調用。此時，即使宿主進程還在運行，仍然會拒絕客戶端的調用。而在通常情況下，執行關閉操作會停止宿主進程。
打開宿主時，將裝載 WCF 運行時（WCF runtime），啟動工作線程監控傳入的請求。由於引入了工作線程，因此可以在打開宿主之后執行阻塞（blocking）操作。通過顯式控制宿主的打開與關閉，提供了 IIS 托管難以實現的特征，即能夠創建定制的應用程序控制模塊，管理者可以隨意地打開和關閉宿主，而不用每次停止宿主的運行。
(3).自托管與基地址
可以在啟動服務宿主時，無需提供任何基地址。(即為創建ServiceHost對象時，只指定服務對象類型，不指定任何基址，但不能將其指定為null，會報錯的。params參數是可選的。) 只要這些地址沒有使用相同的傳輸樣式（Transport Schema），我們也可以注冊多個基地址，並以逗號作為地址之間的分隔符。 WCF 也允許開發者在宿主配置文件中列出基地址內容：
<system.serviceModel>
<services>
<service name = "MyNamespace.MyService">
<host>
<baseAddre sses>
<add baseAddress = "net.tcp://localhost:8001/"/>
<add baseAddress = "http://localhost:8002/"/>
</baseAddresses>
</host>
...
</service>
</services>
</system.serviceModel>
創建宿主時，無論在配置文件中找到哪一個基地址，宿主都會使用它，同時還要加上以編程方式提供的基地址。需要特別注意，我們必須確保配置的基地址的樣式不能與代碼中的基地址的樣式重疊。 我們甚至可以針對相同的類型注冊多個宿主，只要這些宿主使用了不同的基地址。(極為創建多個基址，創建多個host對象，指定不同的基址。) 然而，這並不包括第 8 章介紹的使用線程的情況，以這種方式打開多個宿主並無優勢可言。此外，如果基地址是配置文件提供的，那么就需要使用 ServiceHost 的構造函數為相同的類型打開多個宿主。
(4).托管的高級特性
ServiceHost 實現的 ICommunicationObject 接口定義了一些高級特性，如例 1-4 所示。 如果打開或關閉宿主的操作耗時較長，可以采用異步方式調用 BeginOpen()和 BeginClose()方法。我們可以訂閱諸如狀態改變或錯誤發生等宿主事件，通過調用 State 屬性查詢當前的宿主狀態。ServiceHost 類同樣實現了 Abort()方法。該方法提供強行退出功能，能夠及時中斷進程中的所有服務調用，然后關閉宿主。此時，活動的客戶端會獲得一個異常。
(5).ServiceHost<T>類
ServiceHost<T>類能夠改進 WCF 提供的 ServiceHost 類。 ServiceHost<T>簡化了構造函數，它不需要傳遞服務類型作為構造函數的參數，還能夠直接處理字符串而不是處理令人生厭的Uri值。在本書余下的內容中，對 Service-Host<T>進行了擴展，增加了一些特性，提高了它的性能。
(6).WAS托管
Windows 激活服務（WAS）是一個系統服務，只適用於 Windows Vista。WAS 是 IIS 7的一部分，但也可以獨立地安裝與配置。若要使用 WAS 托管 WCF 服務，必須提供一個.svc文件，這與 IIS 托管一樣。IIS 與 WAS 的主要區別在於 WAS 並不局限於使用 HTTP，它支持所有可用的 WCF 傳輸協議、端口與隊列。
WAS 提供了大量基於自托管的強大功能，包括應用程序池、回收機制、空閑時間管理（Idle Time Management）、身份管理（Identity Management）以及隔離（Isolation）；宿主進程可以根據情況選擇使用這些功能。若需考慮可擴展性，就應該使用 Vista 服務器作為目標機器；如果只有少數客戶端，則可以將 Vista 客戶機作為服務器。
當然，自托管進程還提供了許多卓越特性，例如進程內宿主、匿名用戶環境的處理，同時還為之前介紹的高級宿主特性提供了便捷地編程訪問方式。
11.綁定
服務之間的通信方式是多種多樣的，有多種可能的通信模式。
包括：同步的請求/應答（Request/Reply）消息，或者異步的“即發即棄（Fire-and-Forget）”消息；雙向（Bidirectional）消息；即時消息或隊列消息；以及持久（Durable）隊列或者可變（Volatile）隊列。
傳遞消息的傳輸協議包括：HTTP（或 HTTPS）、TCP、P2P（對等網）、IPC（命名管道）以及 MSMQ。
消息編碼格式包括：保證互操作性的純文本編碼格式；優化性能的二進制編碼格式；提供有效負載的 MTOM（消息傳輸優化機制，Message Transport Optimization Mechanism）編碼格式。
消息的安全保障也有多種策略，包括：不實施任何安全策略；只提供傳輸層的安全策略；消息層的隱私保護與安全策略。
當然，WCF 還包括多種對客戶端認證與授權的安全策略。消息傳遞（Message Delivery）可能是不可靠的，也可能是可靠的端對端跨越中間方，然后斷開連接的方式。消息傳遞可能按照發送消息的順序處理，也可能按照接收消息的順序處理。服務可能需要與其他服務或客戶端交互，這些服務或客戶端或者只支持基本的 Web 服務協議，或者使用了流行的 WS-*協議，例如WS-Security 或者 WS-Atomic Transaction。服務可能會基於原來的 MSMQ 消息與舊的客戶端（Legacy Client）交互，或者限制服務只能與其他的 WCF 服務或客戶端交互。
若要計算所有可能的通信模式與交互方式之間的組合，數量可能達到上千萬。在這些組合選項中，有的可能是互斥的，有的則彼此約束。顯然，客戶端與服務必須合理地組合這些選項，才能保證通信的順暢。對於大多數應用程序而言，管理如此程度的復雜度並無業務價值。然而，一旦因此作出錯誤決定，就會影響系統的效率與質量，造成嚴重的后果。 為了簡化這些選項，使它們易於管理，WCF 引入了綁定（Binding）技術將這些通信特征組合在一起。一個綁定封裝了諸如傳輸協議、消息編碼、通信模式、可靠性、安全性、事務傳播以及互操作性等相關選項的集合，使得它們保持一致。理想狀態下，我們希望將所有繁雜的基礎功能模塊從服務代碼中解放出來，允許服務只需要關注業務邏輯的實現。綁定使得開發者能夠基於不同的基礎功能模塊使用相同的服務邏輯。
在使用 WCF 提供的綁定時，可以調整綁定的屬性，也可以從零開始定制自己的綁定。服務在元數據中發布綁定的選項，由於客戶端使用的綁定必須與服務的綁定完全相同，因此客戶端能夠查詢綁定的類型與特定屬性。單個服務能夠支持各個地址上的多個綁定。
(1).標准綁定
WCF定義了9種標准綁定：
<1>.基本綁定(Basic Binding)
由 BasicHttpBinding 類提供。基本綁定能夠將 WCF 服務公開為舊的 ASMX Web 服務，使得舊的客戶端能夠與新的服務協作。如果客戶端使用了基本綁定，那么新的 WCF 客戶端就能夠與舊的 ASMX 服務協作。
<2>.TCP綁定
由 NetTcpBinding 類提供。TCP 綁定使用 TCP 協議實現在 Intranet 中跨機器的通信。TCP綁定支持多種特性，包括可靠性、事務性、安全性以及 WCF 之間通信的優化。前提是，它要求客戶端與服務都必須使用 WCF。
<3>.對等網絡
由 NetPeerTcpBinding 類提供。它使用對等網進行傳輸。對等網允許客戶端與服務訂閱相同的網格（Grid），實現廣播消息。因為對等網需要網格拓撲（Grid Topology）與網狀計算策略（Mesh Computing Strategies）方面的知識，故而不在本書討論范圍之內。
<4>.IPC綁定
由 NetNamedPipeBinding 類提供。它使用命名管道為同一機器的通信進行傳輸。這種綁定方式最安全，因為它不能接收來自機器外部的調用。IPC 綁定支持的特性與 TCP 綁定相似。
<5>.WS Web 服務（WS）綁定
由 WSHttpBinding 類提供。WS 綁定使用 HTTP 或 HTTPS 進行傳輸，為基於 Internet 的通信提供了諸如可靠性、事務性與安全性等特性。
<6>.WS 聯邦綁定（Federated WS Binding）
由 WSFederationHttpBinding 類提供。WS 聯邦綁定是一種特殊的 WS 綁定，提供對聯安全（Federated Security）的支持。聯邦安全不在本書討論范圍之內。 <7>.WS雙向綁定(Duplex WS Binding)
由 WSDualHttpBinding 類提供。WS 雙向綁定與 WS 綁定相似，但它還支持從服務到客戶端的雙向通信，相關內容在第 5 章介紹。
<8>.MSMQ綁定
由 NetMsmqBinding 類提供。它使用 MSMQ 進行傳輸，用以提供對斷開的隊列調用的支持。相關內容在第 9 章介紹。
<9>.MSMQ 集成綁定（MSMQ Integration Binding）
由 MsmqIntegrationBinding 類提供。它實現了 WCF 消息與 MSMQ 消息之間的轉換，用以支持與舊的 MSMQ 客戶端之間的互操作。MSMQ 集成綁定不在本書討論范圍之內。
(2).格式與編碼
每種標准綁定使用的傳輸協議與編碼格式都不相同，如表 1-1 所示。 表 1-1：標准綁定的傳輸協議與編碼格式（默認的編碼格式為黑體） 文本編碼格式允許 WCF 服務（或客戶端）能夠通過 HTTP 協議與其他服務（或客戶端）通信，而不用考慮它使用的技術。二進制編碼格式通過 TCP 或 IPC 協議通信，它所獲得的最佳性能是以犧牲互操作性為代價的，它只支持 WCF 到 WCF 的通信。
(3).選擇綁定
為服務選擇綁定應該遵循圖 1-4 所示的決策活動圖表。 首先需要確認服務是否需要與非 WCF 的客戶端交互。如果是，同時客戶端又是舊的 MSMQ客戶端，選擇 MsmqIntegrationBinding 綁定就能夠使得服務通過 MSMQ 與該客戶端實現互操作。如果服務需要與非 WCF 客戶端交互，並且該客戶端期望調用基本的 Web 服務協議（ASMX Web 服務），那么選擇 BasicHttpBinding 綁定就能夠模擬 ASMX Web 服務（即 WSI-Basic Profile）公開 WCF 服務。缺點是我們無法使用大多數最新的 WS-*協議的優勢。但是，如果非 WCF 客戶端能夠識別這些標准，就應該選擇其中一種 WS 綁定，例如 WSHttpBinding、WSFederationBinding 或者 WSDualHttpBinding。
如果假定客戶端為 WCF 客戶端，同時需要支持脫機或斷開狀態下的交互，則可以選擇NetMsmqBinding 使用 MSMQ 傳輸消息。如果客戶端需要聯機通信，但是需要跨機器邊界調用，則應該選擇 NetTcpBinding 通過 TCP 協議進行通信。如果相同機器上的客戶端同時又是服務，選擇 NetNamePipeBinding 使用命名管道可以使性能達到最優化。如果基於額外的標准，例如回調（選擇 WSDualHttpBinding）或者聯邦安全（選擇WSFederationBinding），則應對選擇的綁定進行微調。 注意：即使超出了使用的目標場景，大多數綁定工作仍然良好。例如，我們可以使用 TCP綁定實現相同機器甚至進程內的通信；我們也可以使用基本綁定實現 Intranet 中 WCF 對WCF 的通信。然而，我們還是應盡量按照圖 1-4 選擇綁定。
(4).使用綁定
每種綁定都提供了多種可配置的屬性。綁定有三種工作模式。如果內建綁定符合開發者的需求，就可以直接使用它們。我們也可以對綁定的某些屬性如事務傳播、可靠性和安全性進行調整與配置，還可以定制自己的綁定。最常見的情況是使用已有的綁定，然后只對綁定的幾個方面進行配置。應用程序開發者幾乎不需要編寫定制綁定，但這卻是框架開發者可能需要做的工作。
（顯得很枯燥，但是對於分布式應用很龐大，掌握是需要時間的，學習要循序漸進！痛苦並幸福着！）