隨著時代的發展，Microsoft推出的WCF被我們越來越多的人使用，我們就WCF性能分析一下，設計、構建、維護和版本控制分布式應用時一個復雜的任務。安全性、可靠性、事務性和伸縮性的因素和任務變得更加復雜。因為問題的復雜性，所以WCF被設計來解決這些問題，WCF是相當復雜的技術。為了能看清WCF性能，我把主要的功能分為10個類別：獨立版本控制、異步只進消息、平臺統一、安全性、可靠性、事務支持、互操作性、性能、擴展性和配置性。

獨立版本控制

#T#應用系統版本控制已經成為一個頭疼的問題。如我之前提到的，面向組件的設計不能在分布式應用中很好地解決這些問題。任何技術如果在分布式世界里獲得認可，必須允許分布式應用的不同部分能夠獨立的版本控制。遵照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特性對比

客觀地說，WCF性能沒有提供給我們無約束連接的特性，但是確實提供給了我們比以更多的連接特性。