WCF是構建和運行互聯繫統的一系列技術的總稱，它是建立在Web Service架構上的一個全新的通信平臺。你可以把它看成是.NET平臺上的新一代的Web Service。WCF爲我們提供了安全、可靠的的消息通信，也爲我們提供了更好的可互操作性是的我們可以和其他的平臺進行“交流”。
微軟斥巨資打造WCF，在我們看來主要出於下面兩個目的：實現其對現有的分佈式技術的整合以及順應SOA的浪潮。在WCF之前，微軟已經爲了提供了一套完整的基於分佈式的技術和產品，這些技術和產品使我們構建一個基於於分佈式的互聯繫統變得異常簡單。我們熟悉的技術包括Enterprise Service,.NET Remoting, XML Web Service, MSMQ等等，這些不同的技術和產品爲相同的功能提供了不同的實現。對於技術的發展，我覺得“統一”是一個主線：爲了讓基於Web的開發可以採用我們基於Windows Form的事件驅動、基於控件開發模式，我們有了ASP.NET；爲了使具有不同結構的數據（.NET Object, XML, Relational Data etc）採用相同的操作方式，我們有了LINQ。同樣，對於一個分佈式系統的開發，將不同的分佈式技術整合起來，提供一個統一的編程模型是絕對有必要的，WCF就是基於這樣的一個目的發展起來的。
但是，如果你認爲WCF僅僅是這些不同的分佈式技術簡單地組合在一起，那就錯了。WCF在對這些技術進行整合的時候，始終有一個指導方針，那就是SOA。SOA，毫無疑問是今後開發互聯繫統的一個趨勢，對於SOA，我想網上充斥着太多的相關的信息，我在這裏就不做任何介紹了。SOA的發展離不開一個大家能夠一致尊崇的一個標準，而WS-* 就是這個標準。WCF基本上實現了目前所有的WS-* 標準。
在過去半年之後，我陸陸續續寫了一些關於WCF介紹的一些文章，我把它命名爲“我的WCF之旅”，目的在於向大家分享我學習WCF這一段旅程。現在把把這個系列做一個階段性的總結，以饗讀者。
[第1篇] 創建一個簡單的WCF程序
在Microsoft提出.NET戰略以來，先後推出了一系列產品和技術，這些產品和技術爲我們在.NET平臺下建立企業級的分佈式應用提供了很大的 便利。這些技術和產品包括：.NET Remoting，XML WebSerivce，WSE(2.0,3.0)，Enterprise Service， MSMQ 等等。通過合理利用上面這些分佈式的技術完全可以爲我們建立的一套適合不同層次需要的分佈式構架。但這裏面仍然存在一些問題，那就是上面這些技術和產品只能解決某一方面的問題；比如.NET Remoting雖然在.NET平臺下是一個很好的依靠，但是考慮到他不能提供不同平臺之間的互操作性。另外，這些技術適合用了完全不同的編程方式，使得我們很難從容地從其中一種轉移到另一種上來。基於這些原因， 我們需要一套全新的技術整合以上都這些技術，於是我們有了今天的WCF—— Windows Communication Foundation。WCF建立一套框架，是我們通過一致的編程模式，使用不同的技術構建我們的分佈式應用。
雖然很早開始接觸WCF，但所學的總是零零碎碎。現在開始系統地研究WCF，希望與大家一同分享我的一些所得， 同時希望能通過這樣的一個機會與大家一些探討WCF，不對的地方希望大家指正。
一開始我們先建立一個簡單程序看WCF如何工作。
[第2篇] Endpoint Overview
WCF實際上是構建了一個框架，這個框架實現了在互聯繫統中各個Application之間如何通信。使得Developers和Architect在構建分佈式系統中，無需在考慮如何去實現通信相關的問題，更加關注與系統的業務邏輯本身。而在WCF Infrastructure中，各個Application之間的通信是由Endpoint來實現的。
當我們Host一個WCF Service的時候，我們必須給他定義一個或多個Endpoint，然後service通過這個定義的Endpoint進行監聽來自Client端的請求。當我們的Application需要調用這個Service的時候，因爲Client 和Service是通過Endpoint的進行通信的，所以我們必須爲我們的Application定義Client端的Endpoint。只有當 Client的Endpoint和Service端某個 Endpoint相互匹配（Service端可以爲一個Service定義多個Endpoint），Client端的請求才能被Service端監聽到。也就是說，我們只有在Client具有一個與Service端完全匹配的Endpoint，我們才能調用這個Service。而這種匹配是比較嚴格的，比如從匹配Address方面，Client端和Service端的Endpoint Address不僅僅在URI上要完全匹配Service，他們的Headers也需要相互匹配。對於Binding, 一般地，Client需要有一個與Service端完全一樣的Binding，他們之間才能通信。
[第3篇] 在WCF中實現雙向通信（Bi-directional Communication）
作爲Remoting中實現雙向通信對比，來討論一下WCF的雙向通信。爲了使我們能夠更好地對比雙向通信在 Remoting中和WCF中的實現，我們的Sample採用一樣的業務邏輯——調用一個數學計算的遠程調用，除了傳遞相應的操作數之外，我們還傳遞一個對象，這個對象可以在Server端中回調 (Callback) 把運算結果在Client端顯示出來。
[第4篇] WCF中的序列化（Serialization）
在分佈式系統中，一個Application與另一個Application之間進行交互，必然需要攜帶數據。系統交互完全是應 Message的方式進行的，Message是XML，當然置於Message中的數據也應該是XML（XML Infoset）。如何處理這些交互的數據，我們可能首先想到的就是直接處理XML，我們可以在XML級別通過相關的XML技術——XSD，XPath， XSLT來操作數據。但是要使我們處理後的XML需要和要求的完全一致，這樣的工作無疑是非常枯燥乏味而且費時費力的。而我們最擅長的就是使用.NET對象來封裝我們的數據。如何使我們創造的對象能夠有效地轉化成結構化的XML Infoset，就是今天我們要講的內容——Serialization。
[第5篇] 面向服務架構（SOA）和麪向對象編程（OOP）的結合——如何實現Service Contract的重載（Overloading）
給予XML的WCF，並不具有對Overloading的原生支持，但是Overloading是.NET Framework原生支持的。通過Overloading，我們可以使用同名的方法來定義不同的操作，從而使我們的Code顯得更加優雅（Elegant）。要是Overloading在WCF中可以使用，WCF必須提供這樣的一個Mapping——是被重載的具有相同方法的的方法 Mapping到不同的Operation上。而提供着一個功能的就是ServiceContract。下面我們來結合一個Sample來看如何在WCF 中使用Overloading。
[第6篇] 在Winform Application中調用Duplex Service出現TimeoutException的原因和解決方案
針對一個讀者將我的demo從Console Application移植到Windows Form而出現TimeoutException，進一步瞭解WCF的Messaging。
[第7篇] 面向服務架構（SOA）和麪向對象編程（OOP）的結合——如何實現Service Contract的繼承
而在編程模型層面，OO仍然是不可替代的編程模式。所以OO應用於Programming，而SO則更多地運用在Architecture。既然是這樣，我們必須有一種調和劑來調和這兩個運用不同原理的兩個層面的差異，實現他們之間的無縫的結合。比如如何來對繼承，多態，重載等基於OO行爲的支持。在這方面，WCF爲我們提供了很好的解決方案。所以我說WCF不但是爲基於SOA的應用架構提供了技術支持，還通過相關的機制完成我們提出的這個“調和劑”的使命。
在這裏我們通過一個Sample來討論WCF對繼承的支持。這個Sample中，我們通過一個WCF Service實現了提供天氣信息的功能，或者說，我們實現了一個用作天氣預報的WCF Service。
[第8篇] WCF中的Session和Instancing Management
在一個C/S（Client/Service）場景中，Context無關性體現在Client對Service的每次調用都是完全不相關的。但是在有些情況下，我們卻希望系統爲我們創建一個Session來保留某個Client和Service的進行交互的狀態。所以，像Web Service一樣，WCF也提供了對Session的支持。對於WCF來說，Client和Service之間的交互都通過Soap Message來實現的，每次交互的過程就是一次簡單的Message Exchange。所以從Messaging的角度來講，WCF的Session就是把某個把相關的Message Exchange納入同一個Conversation。每個Session用一個Session ID來唯一標識。
真正的邏輯實現是通過調用真正的Service instance中。在一個分佈式環境中，我們把通過Client的調用來創建最終的Service Instance的過程叫做Activation。在Remoting中我們有兩種Activation方式：Server Activation（Singleton和SingleCall），Client Activation。實際上對WCF也具有相似的Activation。不過WCF不僅僅創建對應的Service Instance，而且還構建相關的Context, 我們把這些統稱爲Instance Context。不同的Activation方式在WCF中體現爲的Instance context model。不同的Instance Context Mode體現爲Proxy、Service 調用和Service Instance之間的對應關係。可以這麼說，Instance Context Mode決定着不同的Session表現。
[第9篇] 如何在WCF中使用tcpTrace來進行Soap Trace
無論對於Web Service還是WCF，Client和Service之間交互的唯一形式是通過發送和接收Soap Message。在我們對Web Service和WCF進行深入學習的時候，藉助一些Soap Trace 工具對Soap Message進行深入剖析是非常有必要的。在這些工具之中，我覺得最好用的就是Microsoft Soap Toolkit中的Soap Trace Utility和tcpTrace。我們今天就來講講如何在WCF中使用tcpTrace這個工具。
[第10篇] 如何在WCF進行Exception Handling
在任何Application的開發中，對不可預知的異常進行troubleshooting時，異常處理顯得尤爲重要。對於一般的.NET系統來說，我們簡單地藉助try/catch可以很容易地實現這一功能。但是對於一個分佈式的環境來說，異常處理就沒有那麼簡單了。按照面向服務的原則，我們把一些可複用的業務邏輯以Service的形式實現，各個Service處於一個自治的環境中，一個Service需要和另一個Service進行交互，只需要獲得該Service的描述（Description）就可以了（比如 WSDL，Schema和Strategy）。藉助標準的、平臺無關的通信構架，各個Service之間通過標準的Soap Message進行交互。Service Description、Standard Communication Infrastructure、Soap Message based Communication促使各Service以鬆耦合的方式結合在一起。但是由於各個Service是自治的，如果一個Service調用另一個 Service，在服務提供方拋出的Exception必須被封裝在Soap Message中，方能被處於另一方的服務的使用者獲得、從而進行合理的處理。下面我們結合一個簡單的Sample來簡單地介紹我們可以通過哪些方式在 WCF中進行Exception Handling。
[第11篇] 再談WCF的雙向通訊-基於Http的雙向通訊 V.S. 基於TCP的雙向通訊
在一個基於面向服務的分佈式環境中，藉助一個標準的、平臺無關的Communication Infrastructure，各個Service通過SOAP Message實現相互之間的交互。這個交互的過程實際上就是Message Exchange的過程。WCF支持不同形式的Message Exchange，我們把這稱之爲Message Exchange Pattern（MEP）, 常見的MEP包括: Request/Reply，Request/Forget（One-way）和Duplex。通過採用Duplex MEP，我們可以實現在Service端Callback Client的操作。雖然WCF爲我們實現底層的通信細節，使得我們把精力轉移到業務邏輯的實現，進行Transport無關的編程，但是對底層 Transport的理解有利於我們根據所處的具體環境選擇一個合適的Transport。說到Transport， WCF 經常使用的是以下4個：Http，TCP，Named Pipe，MSMQ。由於不同協議自身的差異，他們對具體MEP的支持方式也會不同，我們今天就來談談Http和TCP對Duplex的支持。
[第12篇] 使用MSMQ進行Reliable Messaging
在一個分佈式的環境中，我們往往需要根據具體的情況採用不同的方式進行數據的傳輸。比如在一個Intranet內，我們一般通過TCP進行高效的數據通信；而在一個Internet的環境中，我們則通常使用Http進行跨平臺的數據交換。而這些通信方式具有一個顯著的特點，那就是他們是基於 Connection的，也就是說，交互雙方在進行通信的時候必須保證有一個可用的Connection存在於他們之間。而在某些時候，比如那些使用撥號連接的用戶、以及使用便攜式計算機的用戶，我們不能保證在他們和需要訪問的Server之間有一個的可靠的連接，在這種情況下，基於Messaging Queue的連接就顯得尤爲重要了。我們今天就來談談在WCF中如何使用MSMQ。
[第13篇] 創建基於MSMQ的Responsive Service
我們知道MSMQ天生就具有異步的特性，它只能以One-way的MEP（Message Exchange Pattern）進行通信。Client和Service之間採用One-way MEP的話就意味着Client調用Service之後立即返回，它無法獲得Service的執行結果，也無法捕捉Service運行的 Exception。
但是在有些場景 中，這是無法容忍的。再拿我在上一篇文章的Order Delivery的例子來說。Client向Service提交了Order，卻無法確認該Order是否被Service正確處理，這顯然是不能接受的。我們今天就來討論一下，如何創建一個Responsive Service來解決這個問題：Client不再是對Service的執行情況一無所知，它可以獲知Order是否被Service正確處理了。
出處：http://artech.cnblogs.com
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。