WCF應用還是很廣泛的，我們在不知不覺中就會用到這門技術，現在我們就它的一些性能分析一下吧。WCF設計出來完全是為了與其他系統的交互。這包括可以運行在其他操作系統和平臺上的應用。因為WCF專注在消息本性使得這個成為可能。

創新的是，建立在WCF之上的應用可以通過TCP, HTTP, Named Pipes, 和MSMQ與其他支持WS-*、Basic Profile (BP)、XML消息的應用。開發者可以自由編寫擴展WCF功能的組件，這包括編寫定制擴展功能，允許WCF與那些需要使用二進制消息編碼的系統通信（像大型機應用系統）。

#T#傳統上，與其他平臺（像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應用的行為。從管理的角度來看非常有吸引力，因為這可以讓非開發人員來移植、維護和修改應用的行為而不需要卷入到開發工作中。合理的使用，會大大減少開發團隊的壓力和工作負荷。如果濫用，會帶來無法預期的后果。