WCF介紹
在上世紀90年代微軟和其他公司看到了互聯的普遍需求和面向服務的普遍概 念。那時，還沒有被普遍接受的消息標准，結果，就沒有平台、應用程序編程接 口 API、或者能夠讓開發者輕易創建面向服務的應用系統的運行時環境。技術上 說，是可以創建面向服務的應用，但是開發工具和運行時環境的功能使得這一切 看來相當困難。幸運的是，微軟和其他廠商開始定義一個可以產生統一消息結構 的基礎架構。最終努力的結果就是WS-*規范。於此同時，微軟也在制定可以給開 發者提供他們開發支持WS-*規范的面向服務應用的開發工具和運行時環境的技術 計劃。在這個指導性計劃中包含Microsoft .NET Framework、ASP.NET Web Services (ASMX)、Web Services Enhancements (WSE)、Windows Vista、當然 也有WCF.
不僅僅是另一個API
隨著時間的推移，開發社區可以看到很多新的APIs,每個都許諾各種新的完美 的功能。常常是這些新的API用來包裝這些新的功能。結果，你也許本能上認為 WCF只是另外一個API。地址這些誘惑。Jackie Gleason在電影《熊和強盜》中說 的很好（我一直最喜歡的電影之一）：“伙計，...不要這麼干，再考慮一下， 但是你不要做。”WCF不僅僅是包裝了現有的功能或者另外一個很棒的API。WCF 是在分布式開發領域裡技術轉移的一個證據。微軟花費巨資在這個上面就是因為 它可以建立真正的SOA應用，並且提供在微軟平台上建立應用的更好方式。IBM, BEA, SAP和其它廠商已經做了相似的努力，各個被連接不同平台上應用系統的動 力所鼓舞。
WCF總覽
WCF 是建立在Microsoft .NET Framework上類型的集合，並且存在於微軟 Windows操作系統上，在面向服務的世界和面向對象的世界裡起著橋梁的作用。 通常來說，與對象協作比在面向對象的世界裡運行會更高效而且較低的錯誤，即 便當這些對象發送、接受和處理面向對象的消息的時候。WCF給了我們可以在不 同世界裡工作的能力，但是它目標的是讓我們可以在面向服務的世界裡使用大家 熟悉的東西編程。
WCF下層：Windows
分布式應用需要頻繁的跨進程辯解通信。分布式應用同樣需要托管，結果， 他們需要依賴像Windows激活服務（WAS），Internet信息服務（ IIS）， Windows NT服務。像XP帶有Service Pack 2，Windows Server 2003 還有Vista 都是允許應用系統互連的操作系統的一部分典型例子。
這些內置支持服務的操作系統，機器本身，都是重要的分布式計算的一部分 。
最低層次上，WCF應用程序通過操作系統的I/O機制(sockets, named pipes, 等等)發送和接受消息。但是抽象的公共層使得WCF開發者已經遠離了底層復雜的 實現細節。
有用的產品：Windows 服務器系統
Microsoft has many products that automate and simplify the tasks associated with distributed computing:
微軟有很多產品可以自動完成和簡化分布式計算的任務。
1.BizTalk Server
2.Commerce Server
3.Application Center
4.Internet Security and Acceleration Server
5.SQL Server
6.Exchange Server
7.Host Integration Server
隨著時間的前移，我希望看到這些產品在某些方面能夠使用WCF通信（備注： Biztalk已經提供了不同Binding的WCF Adapter）。
將來，希望可以看到WCF應用可以直接與這些服務通信。例如，能夠支持從 WCF應用到SQL Server 2005的事務Broker的協調。
開發平台：Microsoft .NET Framework
自2002年，Microsoft .NET Framework已經是Windows開發的一個選擇。它由 4個重要機制：自動內存管理，JIT編譯，元數據和代碼訪問安全。這些重要機制 可以提供快速的組件開發，類型安全的執行環境，多語言的選擇，簡化開發場景 和組件安全。（我可以繼續）WCF是建立在.NET Framework之上，完全由C#編寫 的。
.NET Framework通過System.Net.Sockets.Socket和 System.Messaging.MessageQueue類型 (這裡提到一些)抽象了操作系統的IO機制 。這些類型會被WCF的基礎框架用來發送和接受消息。正如你將會再本書的後面 看到內容，這些都可以通過WCF的擴展點與這些類型直接交互。
分布式平台：WCF
WCF是微軟創建獨立於版本的，安全的，可靠的，支持事務的面向服務的API 。它完全包含面向服務的概念，並且可以創建符合WS-*規范的消息，但它同樣可 以使用在表屬性狀態傳輸（Rest）架構裡和其它的使用樸素的舊的（POX）XML消 息的分布式應用系統中。本質上，WCF是開發者通往面向服務世界的橋梁。在WCF 之前，也可以使用像WSE和 ASMX這樣的技術來編寫面向服務的應用，但是WCF比 微軟其它的面向服務的技術提供了更好的安全性，可靠性，靈活性，並且性能選 擇。換句話說，WCF滿足了互聯的普遍需求，因此，世界因此而不同（月亮是藍 色的）。
集成到一起
圖1-3 說明了Windows，.NET Framework, WCF, 和 WCF應用程序如何在概念 上組織在一起的
圖1-3 上下文裡的WCF
在概念上和邏輯上，WCF是能使得開發者可以快速開發面向服務應用的程序集 的集合。使用WCF的應用系統可以通過消息schema和WS-*裡定義的編排、REST 架 構、POX消息來通信。WCF使得開發者遠離許多原始通信和 WS-*規范的細微差別 。根本上，WCF是暴露一個類型集的程序集的集合。這些類型由一些面向開發的 API和一些面向底層的類型集組成。正如你可能想象的一樣，面向開發的API是非 WCF開發團隊的人使用，面向內部的類型為了發送、接受和其它處理消息與.NET Framework和操作系統交互。WCF建立在自己的擴展架構上，所以開發者可以改變 這些即裝即用的WCF功能以適合特別應用的需求。
WCF 特性
設計、構建、維護和版本控制分布式應用時一個復雜的任務。安全性、可靠 性、事務性和伸縮性的因素和任務變得更加復雜。因為問題的復雜性，所以WCF 被設計來解決這些問題，WCF是相當復雜的技術。為了能看清WCF的特性，我把主 要的功能分為10個類別：獨立版本控制、異步只進消息、平台統一、安全性、可 靠性、事務支持、互操作性、性能、擴展性和配置性。
Independent Versioning
獨立版本控制
應用系統版本控制已經成為一個頭疼的問題。如我之前提到的，面向組件的 設計不能在分布式應用中很好地解決這些問題。任何技術如果在分布式世界裡獲 得認可，必須允許分布式應用的不同部分能夠獨立的版本控制。遵照WS-*規范， 關注WS-*關於消息定義的內容，允許被調用的服務可以再不同速率開發。這些特 性不像創建WCF應用的底層原理那麼重要，但是我認為這是使用WCF最重要的副產 品。
異步單向消息
我們的許多應用是使用請求-響應模式調用功能的。典型的是，我們調用一個 功能，然後等待結果返回，然後根據返回結果執行。這種方式在Internet上尤為 多見。每次我們請求一個頁面，我們必須等待網頁的響應。局限我們的條件，大 部分分布式應用使用的都是請求-響應方式。盡管開始看起來不自然，對於穿越 IO邊界的任務分布式應用，異步只進消息方式是更加高效的方式。我認為這是使 用WCF的又一個好處。異步只進消息方式允許使用高效的處理資源，更加方便地 使用分布式應用的高級的功能、可靠性和相應能力。
平台統一
過去微軟已經發布的很多分布式技術;有些成為WCF誕生的重要的導向技術。 並且許多技術依然在使用。例如，在WCF發布以前，微軟支持5種主要的分布式技 術： RPC, WSE, ASMX, Remoting, COM+, 和MSMQ。過去，最好的分布式技術取 決於應用系統的需求。例如，假如分布式應用都是基於.NET Framework，那麼會 選擇.NET Remoting，因為它是.NET Remoting應用程序之間一種高效的通信方式 。如果一個應用需要擔保消息傳輸和持久化，那麼MSMQ是最好的選擇。兩個技術 有不同的API、編程方式、操作要求和配置需求。結果，應用程序代碼緊密地綁 定到這些技術上，這些技術也綁定到特定的功能上。一些新的技術允許我們組合 特性，比如事務性和隊列性的COM+。只要需求不改變或者不使用其它的不支持的 方式，這種模式是可以工作的。
什麼是你的應用系統與其他的 .NET Framework應用、非 .NET Framework應 用和支持事務的處理通信所需要的？在WCF之前，沒有好的選擇，本質上講，這 些需求使得開發者要麼放棄一個需求要麼編寫自己的通信技術。與舊的技術相比 ，WCF能夠集成舊的技術特性並且統一為一個編程模型，如表1-1所示。
表1-1 WCF特性對比
Feature WSE ASMX Remoting COM+ MSMQ WCF WS-* support X X X Basic Web service interoperability X X X .NET -to-.NET communication X X Distributed transactions X X X Queued messaging X X
客觀地說，WCF沒有提供給我們無約束連接的特性，但是確實提供給了我們比 以更多的連接特性。
安全性
沒人想建立一個全是安全隱患的應用系統。恰恰相反，我們會盡量確保我們 的系統是安全的。如果我們現在這樣做，將來一定會做。過去，它取決於我們、 開發者】架構師或者測試人員知道如何用安全的方式配置我們的系統。我們可以 看到無數為我們的系統提供安全的技術，而確定那種技術或者技術的整個對我們 的應用安全是正確的選擇是非常困難的。
創新的是，WCF支持多種安全模型，並且可以方便地實現廣泛接受的安全措施 。自從WCF有的擴展架構，擴展WCF安全滿足特殊應用的需求相對變的容易許多。 默認的安全選項從像WS-Security和相關規范裡描述的傳統的傳輸安全到現代的 消息安全。
可靠性
分布式應用經常需要支持可靠消息。在分布式計算，可靠消息在保證裡經常 提到。一個保證就像擔保。下面是4種保證使用在分布式計算場景裡;
1.最多一次 一個消息保證最多發送到目的地一次。如果一個消息到達目 的地多次，可以被忽略或者當做錯誤。
2.最少一次 一個消息保證最少到達目的地一次，如果沒有到達，則視為 錯誤。
3.僅僅一次 最多一次和最少一次的結合，它擔保消息只到達目的地一 次。
4.有序 一個信息的邏輯集合可以分布在多個消息體了，這些 消息可以在特定的順序發送，有序保證就是確保消息可以按照發送的順序處理。
經驗告訴我們，網絡和產生網絡通信的應用程序師部可靠的。整體來說，如 果一個應用經過網絡發送消息到另外一個應用，保證消息到達目的地的機制傳統 上來自於傳輸。肯定可能一個或者兩個消息在傳輸的過程中丟失。接受和發送的 消息也可能不同，盡管消息到達的次數多於發送次數。粗多因素導致了不可靠性 ，包括網絡過載，網絡連接丟失，程序bug和環境變化這些因素。
一個不可靠的網絡是氣人的，當你正在檢查郵件或者網上沖浪的時候，尤其 是在分布式計算情況下會帶來更多麻煩。比如，如果一個順序處理程序當它在各 個計算節點上傳輸消息的時候丟失了消息，這些問題可以類比到延遲送貨和憤怒 的客戶。如果，當失敗發生的時候一個應用可以學習，那麼它可以采取補救措施 。
過去，一個應用的可靠需求指明了應用裡要使用的技術。例如，MSMQ提供不 同應用間的可靠傳輸。如果一個應用需要卡考消息傳輸，MSMQ是邏輯上的技術選 擇。實現MSMQ，相當坦率地說，需要MSMQ規范知識和MSMQ規范代碼。編寫這些代 碼和設置正確的運行環境需要知道MSMQ一些
不能與其他技術互用的MSMQ規范。本質上，在過去，從一個應用到另外一個 應用發送消息可靠的決心已經影響到了應用程序的代碼和需要編寫程序的知識。
WCF包括最多一次、最少一次、僅僅一次和有序傳遞的機制。WCF給應用系統 提供了活多或少的修訂。甚至更好的是，傳輸保證機制是傳輸的弱耦合的，因此 即使通過傳統的非安全傳輸也是可以保證消息傳遞。
備注：不要混淆可靠消息和持久化消息。從高層次看，持久化消息被處理的 時候會被存儲到非易失性介質中。如果應用程序粗意外終止和易失性內存被清空 ，消息依然在持久化介質中。
事務支持
在互聯的世界裡，處理收到消息的工作涉及後續的發送給其他應用系統的消 息。優勢這些工作需要執行在事務的范圍內。簡單地說，事務是一個可以確保所 有或沒有任何工作可以被執行完成。WCF支持跨越多個系統的事務范圍。
互操作性
WCF設計出來完全是為了與其他系統的交互。這包括可以運行在其他操作系統 和平台上的應用。因為WCF專注在消息本性使得這個成為可能。
創新的是，建立在WCF之上的應用可以通過TCP, HTTP, Named Pipes, 和MSMQ 與其他支持WS-*、Basic Profile (BP)、XML消息的應用。開發者可以自由編寫 擴展WCF功能的組件，這包括編寫定制擴展功能，允許WCF與那些需要使用二進制 消息編碼的系統通信（像大型機應用系統）。
傳統上，與其他平台（像java）的交互需求已經很大程度上規定了我們的應 用系統設計。過去，如果我們想與另外的平台通信，我們要麼使用ASMX要麼編寫 自己的交互層。WCF就不同。從交互的角度來看，WCF是個單一的技術，它能夠可 以與早期的幾種不同的技術交互。WCF 通過兼容WS-*、支持Rest架構和POX消息 風格兌現了真正的互操作的承諾。
性能
分布式應用一般都會有性能成本；這個成本一般會由這個技術的特性來低效 。比如，對於2個.NET Framework應用來說，.NET Remoting是個相對高效的通信 方式。但是他不能與非.NET Framework應用交互。ASMX，換句話說，沒有 Remoting那麼高效，但它可以與非.NET Framework的應用交互。從端對端的角度 來說，MSMQ效率不高，但是隊列的特性可以彌補發送消息的應用的效率問題。換 個方式，產生、發送、傳輸和接受一個MSMQ消息總時間成本是可以忽略不計的， 但是MSMQ的持久性和可靠性讓發送消息的應用可以保證程序不需要產生和發送消 息，並且等待消息或者接受消息。在發送消息的應用裡，網絡影響是總體在吞吐 量上總體增加。這個技術的缺點就是它不能與其它的消息隊列系統交互。（有一 個方式連接MSMQ和IBM 的MQSeries）。總體來看，分布式系統使用的分布式技術 已經影響到系統的性能。
相反地，WCF應用可以提供不同層次的互操作習慣和性能。例如，與基於Java 的Web服務通信相比，WCF應用與其他WCF應用通信的時候可以更高效。
擴展性
公共語言運行時（CLR）深藏奧妙。例如，JIT編譯器，驗證子系統和垃圾收 集器幾乎是不可復制的。微軟已經發布了部分關於這些子系統工作的信息。但是 子系統不可以被第三方系統取代。例如，所有的.NET Framework程序都受到垃圾 收集器的管理。我們可以而且應該知道如何編寫代碼才能高效地利用垃圾收集器 的特性。然而，沒有微軟之外的人可以寫出使用帶自己編寫的垃圾收集器的CLR 的.NET Framework應用程序。
相反地，WCF沒有什麼神奇的。不要讓這個歪曲了你對這個平台能力的認識。 與之相反，在大的標准衡量它的可擴展的設計，WCF都是異常強大和符合預期的 。WCF被設計來與自定義的傳輸、通道、綁定、編碼和架構模式一起工作。第4章 ，“WCF 101”描述許多WCF的擴展點。
配置性
一個值得炫耀的WCF特性就是它可支持XML文件的完善的配置功能。使用這個 特性，可以在XML文件裡配置傳輸、地址、行為和綁定。如果配置文件更新，可 以不需要修改任何代碼就可以改變 WCF應用的行為。從管理的角度來看非常有吸 引力，因為這可以讓非開發人員來移植、維護和修改應用的行為而不需要卷入到 開發工作中。合理的使用，會大大減少開發團隊的壓力和工作負荷。如果濫用， 會帶來無法預期的後果。
本章小結
WCF為分布式應用開發提供了突破性的功能。WCF讓我們比以前更加快速地設 計、構建、調試和維護分布式系統，並且比以前具有更多的特性。它完全支持 SOAP和WS-*規范，但是它同樣可以發送POX消息，並且適應Rest架構。它集成了 不同的分布式技術：RPC, COM+, Remoting, ASMX, WSE, 和 MSMQ。WCF也是高可 擴展的。這個擴展性為了2個目的：第一個就是，提供給WCF團隊可以容易地改變 WCF的能力。其次就是，它提供給公司更多的可以根據自身需求采用WCF的靈活性 ，WCF API相當復雜但是非常強大。因為描述WCF所有不同的使用方式實際是不可 能的，這本書關注在WCF的內部實現上。我的觀點，這個方法可以幫助應用系統 開發者和framework 的開發者使用WCF解決他們的分布式計算任務。
【地址】：http://www.cnblogs.com/frank_xl/
