WCF基礎

WCF學習筆記——WCF基礎

目錄

一 WCF與SOA

二 WCF模型

三 WCF體系架構

四 WCF程序的開發步驟

五 編碼規範

一 WCF與SOA

　　SOA是一種經過爲全部軟件提供服務外觀，並將這些服務的WSDL集中發佈到一個地方的一種組織企業軟件的方法。它經過使用明肯定義的接口經過跨越邊界傳遞消息來讓多個自治的服務協同工做。SOA的真正價值是——容許開發者從代碼中抽取出公共基礎功能的實現，更多地關注業務邏輯和須要的功能特性。在開發SOA應用程序時，咱們可以實現服務代碼與客戶端使用技術與平臺的解耦，也與併發管理、事務傳播和管理以及通訊可靠性、協議和模式無關。

　　SOA的4個主要設計原則以及在WCF中的具現以下：

• 邊界是明確的 SOA系統中的每一個服務都必須被限定在某個明確的邊界以內。服務邊界指的就是服務的公共接口與其內部實現之間有清晰的界線。WCF服務的功能是經過定義明確的接口進行表達的，外部調用者和WCF服務通訊的惟一方式就是經過這個接口，客戶端沒法知道服務的實現細節，以達到信息隱藏和解耦的目的。
• 服務是自治的 自治的服務對於版本問題、部署問題和安裝問題來講應該是獨立的不會影響整個SOA系統。服務的運行不須要依賴任何外部服務或者組件。咱們爲WCF擴展功能，只能經過編寫新的接口來實現。
• 採用標準的契約定義和通訊協議 服務經過契約而不是實現進行通訊，服務契約定義和通訊協議都是行業標準。WCF對經常使用協議和主流編碼格式提供支持。
• 服務是自解釋的 服務的內容必須是自解釋的，服務必須以某種方式告訴客戶端服務的功能。WCF提供了強類型的契約，並會根據綁定來生成WSDL文檔。

　　以上原則比較抽象，爲了更好的設計SOA程序，應該遵照如下原則：

• 服務是安全的 服務與客戶端必須使用安全的通訊。
• 服務在系統中應保持一致的狀態 執行客戶端請求時，禁止進行部分替換條件，即系統提供服務給客戶端調用後必須保持一致的狀態，若是有錯誤發生，系統狀態不該該部分受到影響，必須被恢復到一致的狀態。
• 服務是線程安全的 服務必須設計爲線程安全，才能維持多線程的併發訪問。
• 服務是可靠的 客戶端以肯定的方式獲知服務是否接收了消息。
• 服務是健壯的 服務與它的錯誤分離可以防止錯誤影響服務自己或其它服務。

　　可選原則以下：

• 服務是平臺無關的 服務應該可以被任意的客戶端調用，而不用考慮客戶端技術。
• 服務的規模不可變 無論客戶端有多少，也無論服務的承載是多少，服務代碼都應該相同。
• 服務是可用的 服務老是可以接受客戶端的請求，而不會所以中止。
• 服務是及時響應的和受限的 服務開始處理客戶端的請求時，不能讓客戶端等待的過久。服務執行的任意操做應該儘量短，不能消耗太多時間去處理客戶端的請求。

　　微軟的WCF框架中的基礎設施爲咱們解決了以上原則中的多數，使咱們能夠將關注點從新迴歸的業務邏輯層上。面向服務技術展現出的魅力，促使愈來愈多的開發者投入其中。

二 WCF模型

　　WCF的體系架構以下：

　　WCF的客戶端與服務端模型以下：

1 地址 

　　WCF的每個服務都有惟一的地址。地址包括服務位置和傳輸協議（傳輸樣式）。服務位置包括目標機器名、站點、網絡、端口、管道或隊列，以及一個可選的特定路徑或者URI。

　　地址經常使用格式爲：[基地址]/[可選的URI]，如「net.tcp://localhost:8081/MyService」。

　　基地址經常使用格式爲：[傳輸協議]://[機器名或域名][:可選端口]，如「net.tcp://localhost:8081」。

　　WCF支持多種傳輸樣式：

• HTTP 採用http、https協議進行傳輸，默認端口號80。
• TCP 採用net.tcp協議進行傳輸，默認地址爲808。
• Peer network（對等網） 採用net.p2p進行傳輸，採用Windows的對等網傳輸機制。
• IPC（內部進程通訊） 採用net.pipe進行傳輸，使用Windows的命名管道機制，只能接收來自同一臺機器的調用，且每臺機器只能打開一個命名管道。
• MSMQ 採用net.msmq進行傳輸，使用Windows的MSMQ機制，必須指定隊列名，若是是處理私有隊列，則必須指定隊列類型。

2 綁定

　　綁定將通訊模式與交互方式直接的組合進行規範，將這些通訊特徵合理地組合在一塊兒。一個綁定封裝了諸如傳輸協議、消息編碼、可靠性、安全性、事務傳播以及互操做性等相關選項的組合，使得它們保持一致。

　　WCF定義了六種經常使用的綁定：

• 基本綁定 由BasicHttpBinding類提供，將WCF服務公開爲Web服務。
• TCP綁定 由NetTcpBinding類提供，使用TCP協議通訊，支持多種特性，包括可靠性、事務性、安全性及WCF之間通訊的優化，缺點是客戶端必須使用WCF。
• IPC綁定 由NetNamedPipeBinding類提供，使用命名管道爲同一機器的通訊進行傳輸，支持的特性與TCP綁定相似，是性能和安全性最佳的綁定。
• Web服務綁定 由WSHttpBinding類提供，WS綁定使用HTTP或HTTPS進行傳輸，提供了諸如可靠性、事務性與安全性在內的多種特性，這些特性遵循WS-*標準，該綁定被設計用來與支持WS-*標準的系統進行互操做。
• WS雙向綁定 由WSDualHttpBinding類提供，支持雙向通訊。
• MSMQ綁定 由NetMsmqBinding類提供，使用MSMQ進行傳輸。

　　經常使用綁定的傳輸協議與編碼格式以下：

名字	傳輸協議	編碼格式	互操做性
BasicHttpBinding	HTTP/HTTPS	Text,MTOM	yes
NetTcpBinding	TCP	Binary	no
NetNamedPipeBinding	IPC	Binary	no
WSHttpBinding	HTTP/HTTPS	Text,MTOM	yes
WSDualHttpBinding	HTTP	Text,MTOM	no
NetMsmqBinding	MSMQ	Binary	no

　　注意：TCP、IPC和MSMQ綁定使用的二進制編碼器是WCF專有的，不要試圖爲其編寫針對其餘平臺的自定義解析器。

3 契約 

　　WCF的全部服務都公開爲契約，契約與平臺無關，是描述服務功能的標準方式。WCF包含4類契約：

• 服務契約 描述了客戶端可以執行的服務操做。
• 數據契約 定義了與服務交互的數據類型。
• 錯誤契約 定義了服務拋出的錯誤，以及服務處理錯誤和傳遞錯誤到客戶端的方式。
• 消息契約 消息契約容許服務直接與消息交互，用於定製專有的消息格式，也意味着要本身的應用程序上下文，由於會增長代碼的複雜度，因此不屬於常見用法。

4 終結點

　　終結點是WCF進行通訊的惟一手段，ChannelFactory<T>本質上是經過制定的終結點建立用於進行服務調用的服務代理。終結點在WCF體系中經過Systtm.ServiceModel.Description.ServiceEndpoint類型表示，其包含三個核心屬性——地址、綁定、契約。終結點是用來發送和接收消息的構造，終結點是真正意義上的接口，它包含了一個對象接口所需的所有信息。每一個服務至少必須公開一個業務終結點，每一個終結點有且只能擁有一個契約。服務上的全部終結點都包含了惟一的地址，而一個單獨的服務則能夠公開多個終結點。這些結點可使用相同或不一樣的綁定，公開相同或不一樣的契約。

5 元數據

　　服務的元數據描述服務的特徵，外部實體須要瞭解這些特徵以便與該服務進行通訊。服務的元數據包括XML、架構文檔（用於定義服務的數據協定）和WSDL文檔（用於描述服務的方法）。啓用元數據後，WCF經過檢查服務及其終結點自動生成服務的元數據。

6 上下文

　　WCF上下文將服務宿主與公開本地CLR類型爲服務的上下文組合在一塊兒，上下文是服務實例最核心的執行範圍，上下文能夠爲空，即不包含任何服務實例。

7 宿主

　　WCF服務類不能憑空存在，每一個WCF服務類必須託管在某個宿主進程中。單個宿主進程能夠託管多個服務，而相同的服務類型也能夠託管在多個宿主進程中，若是服務與客戶端駐留在相同的進程中，則稱爲進程內託管。經常使用宿主以下：

• Web站點
• Windows窗體應用程序
• Windows服務
• Windows激活服務（WAS）

　　WCF宿主體系結構以下：

 　　每一個.NET宿主進程都包含了多個應用程序域，每一個應用程序域包含零到多個宿主實例，每一個服務宿主實例專門對於於一個特殊的服務類型。所以，建立一個宿主實例，實際上就是爲對應於基地址的宿主機器的類型註冊一個包含了全部終結點的服務宿主實例。每一個服務宿主實例擁有零到多個上下文。一個上下文能夠與零個或一個服務實例關聯。

8 代理 

　　WCF不容許客戶端直接與服務交互，客戶端使用代理將調用轉發給服務。即便對象是本地的，WCF仍然使用遠程編程模型的實例化方式，而且使用代理。

三 WCF體系架構

（一） 通道棧模型

　　WCF通道模型：

　　不管交互的另外一方的具體位置在哪裏，WCF都會爲消息的發送和接收創建一套完整的消息管道，這個消息管道被成爲通道棧。通道棧中的每個通道組件都有機會對消息進行處理，而整個通道棧是可編輯且可插入的，這就確保WCF的通道模型具備至關大的靈活性。另外，WCF通道模型是徹底和上層程序隔離的，任何一個服務/客戶端均可以輕鬆配置到不一樣的通道模型上去。通道模型能夠被分爲兩部分——協議通道和傳輸通道。一個通道棧能夠擁有任意多個協議通道，但通常只擁有一個傳輸通道。傳輸通道負責把消息進行編碼而且發送到遠端，編碼時須要使用調用棧的編碼器。通常而言，協議通道負責維護消息的非業務邏輯功能，包括：事務、日誌、可靠消息、安全性等。開發者能夠自定義協議通道並插入到通道棧中。在一個通道棧中，必須包含至少一個傳輸通道和編碼器，傳輸通道負責把消息編碼和發送。（傳輸通道會嘗試從BindingContext對象中查找編碼器，若是沒有找到則會使用默認的編碼器，在完成消息的編碼以後，傳輸通道負責把消息發送到遠端，不一樣的傳輸通道將使用不一樣的傳輸協議，如HTTP、TCP、IPC等。）

　　WCF體系體系架構是基於攔截機制的，經過代理與客戶端的交互意味着WCF老是處於服務與客戶端之間，攔截全部的調用，執行調用前和調用後的處理。當代理將調用棧幀序列化到消息中，並將消息經過通道鏈向下傳遞時，WCF就開始執行攔截。通道至關於一個攔截器，目的在於執行一個特定的任務。每一個客戶端通道都會執行消息的調用前處理。鏈的組成與結構主要依賴於綁定。客戶端的最後一個通道是傳輸通道，根據配置的傳輸方式發送消息給宿主。在宿主端，消息一樣經過通道鏈進行傳輸，它會對消息執行宿主端的調用前處理。宿主端的第一個通道是傳輸通道，接收傳輸過來的消息。隨後的通道執行不一樣的任務。宿主端的最後一個通道負責將消息傳遞給分發器。分發器將消息轉換到一個棧幀，並調用服務實例。事實上，服務會被本地客戶端——分發器調用。客戶端與服務端的攔截器確保了它們可以得到運行時環境，以便於它們執行正確的操做。

　　服務實例會執行調用，而後將控制權返回給分發器。分發器負責將返回值以及錯誤信息轉換爲一條返回消息。分發器得到控制權，執行的過程恰好相反：分發器經過宿主端通道傳遞消息，執行調用後的處理，如管理事務、加密等。爲了執行客戶端調用後的處理，包括解密、解碼、提交或取消事務等任務，傳輸通道會將返回消息發送到客戶端通道。最後一個通道將消息傳遞給代理。代理將返回消息轉化到棧幀，而後將控制權返回給客戶端。

（二） 消息交換模式

　　WCF定義的6種消息交換模式：

1  請求-響應模式

　　客戶端向服務器發送一個請求，等待服務器的響應，等待時間是一個預約義的時間，是最經常使用的模式。WCF中經過在接口上定義[ServiceContact]和[OperationContract]來表示請求和響應的細節。

2 單工消息處理模式

 　　只按一個方向把消息從客戶端發送到服務器，服務器只處理消息，但不返回處理結果。這種模式最大的價值在於可以實現異步通訊以及保證消息傳送環境的能力，利用單工模式，能夠經過MSMQ來發送消息。WCF經過把[OperationContract]的IsOneWay設置爲True，來實現單工模式。

3 雙工消息處理模式

 　　客戶端和服務端相互調用，客戶端和服務端的角色也在不斷交替。爲了完成回調，服務端必須知道回調操做的方法簽名，並且該回調操做將同時出如今客戶端和服務端中。爲此，在WCF中實現雙工模式，須要在它的綁定信息中說明，在客戶端實現的方法簽名須要在服務層定義，同時須要這些方法在客戶端實現，這樣服務端才能調用他們。

4 流模式

　　客戶端發起一個請求，請求一個很是大的數據，服務把數據分割爲小塊，並把這些數據塊按使用順序逐個地發送給客戶端。在這種模式下，一個數據請求緊跟着多個響應，每一個響應都包含了所有數據的一個子集，由發送者在最後的消息中標識數據流的結束，以告知客戶端不須要繼續等待更多的數據。

5 發佈-訂閱模式

　　發佈-訂閱模式中，發佈者不關心是否有訂閱者，它只關心從本身的系統中發送數據。這種模式表示了一種驅動方法，即發佈者在客戶端應用程序中啓動一個事件，客戶端針對這些事件做出響應。WCF不直接支持發佈-訂閱模式，而是利用與雙工模式相同的構造來實現發佈-訂閱模式。發佈-訂閱模式的實現經過一個訂閱服務，此服務在內存中保存訂閱者回調通道的引用。當服務須要向全部訂閱者發送數據時，它便循環地訪問這些訂閱者，並調用一個方法來發送數據。這裏沒有使用輪詢的方法，是由於訂閱者起宿主的做用，它在等待被服務調用的方法。

6 隱式順序調用模式

　　在該模式中，客戶端以某個順序調用服務端的多個操做。隱式順序調用模式容許定義邏輯順序中最後調用的方法，此後客戶端將不能再調用其它方法。WCF使用[OperationContract]定義操做的調用順序，把方法的IsInitiating設置爲false，能夠起動一個會話；把IsTerminating設置爲true，表示調用這個方法以結束會話。（另外一種實現方式，是藉助工做流。）

（三） 通道形狀

　　WCF中經過通道形狀來實現具體的消息交換模式，通道形狀則是隻繼承自IChannel的一組接口，WCF會根據上層協議來自動選取須要的通道形狀。消息交換模式與通訊協議是密切相關的，經過在傳輸通道上層添加特殊的協議通道，能夠強制使用某種傳輸通道不支持的消息交換模式。（OneWayBindingElement單工模式和CompositeDuplexElement雙工模式）

（四） 通道管理器

　　WCF中實現了兩類通道管理器，分別實現IChannelListener<T>和IChannelFactory<T>。IChannelListener<T>負責接收端的信息交換控制工做，負責偵聽消息、創建通道棧，而且經過通道棧頂層通道的引用，它能夠獨立於它的通道棧而關閉。ServiceHost內部就是使用了IChannelListener<T>來實現通道的管理。IChannelListener<T>負責在發送端控制消息的發送以及建立並管理通道棧，而且負責關閉通道棧，通常使用ClientBase<T>來代替直接使用IChannelFactory<T>。

（五）ICommunicationObject

　　WCF的ICommunicationObject定義了狀態機制的統一模型。基本全部的通訊組件，包括通道和通道管理器都實現了ICommunicationObject。ICommunicationObject用於狀態管理，其定義了改變狀態的方法、狀態改變觸發的事件已經當前狀態的獲取。ICommunicationObject的State爲CommunicationState枚舉類型，用於表示「狀態」，有6種可用狀態，分別爲：Created（已建立），Opening（打開中），Opened（已打開），Closing（關閉中），Closed（已關閉），Faulted（錯誤），其狀態變化順序以下：

 　　由上圖可見，狀態機的改變是隻進的，狀態的改變是不可逆的。

四 WCF程序的開發步驟

1. 使用.NET接口定義契約。
2. 編寫實現契約的服務類。
3. 添加相應特性對WCF的行爲進行控制。
4. 開發宿主程序承載服務。
5. 設置服務端配置文件，定製個性化須要。
6. 客戶端添加服務引用，生成代理類。
7. 設置客戶端配置文件，定製個性化須要。

五 編碼規範

• 應該將服務代碼放入到類庫中，而不是放到宿主程序中。
• 不要爲服務類型提供帶參數的構造器，除非託管的服務是明確的單例服務。
• 在相關綁定中啓用可靠性。
• 爲契約提供有意義的命名空間。
• 對於運行在Windows XP或Windows Server 2003上的局域網應用程序，最好選用自託管，而不是IIS託管。
• 在Windows Vista和Windows Server 2008或更高版本中，最好使用WAS託管，而不是自託管。
• 啓用元數據交換。
• 爲客戶端配置文件中的全部終結點命名。
• 儘可能本身編寫配置文件。
• 不要複製代理的代碼，能夠將代理分解到單獨的類庫中。
• 及時關閉和釋放代理。

做者：MeteorSeed

感謝您閱讀本文，若是您以爲有所收穫，麻煩點一下右邊的「推薦」，您的支持是對我最大的鼓勵...

轉載請註明出處。

轉自http://www.cnblogs.com/MeteorSeed/archive/2012/04/24/2399455.html