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

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

#T#傳統(tǒng)上，與其他平臺（像java）的交互需求已經(jīng)很大程度上規(guī)定了我們的應用系統(tǒng)設(shè)計。過去，如果我們想與另外的平臺通信，我們要么使用ASMX要么編寫自己的交互層。WCF就不同。從交互的角度來看，WCF是個單一的技術(shù)，它能夠可以與早期的幾種不同的技術(shù)交互。WCF 通過兼容WS-*、支持Rest架構(gòu)和POX消息風格兌現(xiàn)了真正的互操作的承諾。

性能

分布式應用一般都會有性能成本；這個成本一般會由這個技術(shù)的特性來低效。比如，對于2個.NET Framework應用來說，.NET Remoting是個相對高效的通信方式。但是他不能與非.NET Framework應用交互。ASMX，換句話說，沒有Remoting那么高效，但它可以與非.NET Framework的應用交互。從端對端的角度來說，MSMQ效率不高，但是隊列的特性可以彌補發(fā)送消息的應用的效率問題。換個方式，產(chǎn)生、發(fā)送、傳輸和接受一個MSMQ消息總時間成本是可以忽略不計的，但是MSMQ的持久性和可靠性讓發(fā)送消息的應用可以保證程序不需要產(chǎn)生和發(fā)送消息，并且等待消息或者接受消息。在發(fā)送消息的應用里，網(wǎng)絡(luò)影響是總體在吞吐量上總體增加。這個技術(shù)的缺點就是它不能與其它的消息隊列系統(tǒng)交互。（有一個方式連接MSMQ和IBM 的MQSeries）?？傮w來看，分布式系統(tǒng)使用的分布式技術(shù)已經(jīng)影響到系統(tǒng)的性能。

相反地，WCF應用可以提供不同層次的互操作習慣和性能。例如，與基于Java的Web服務通信相比，WCF應用與其他WCF應用通信的時候可以更高效。

擴展性

公共語言運行時（CLR）深藏奧妙。例如，JIT編譯器，驗證子系統(tǒng)和垃圾收集器幾乎是***的。微軟已經(jīng)發(fā)布了部分關(guān)于這些子系統(tǒng)工作的信息。但是子系統(tǒng)不可以被第三方系統(tǒng)取代。例如，所有的.NET Framework程序都受到垃圾收集器的管理。我們可以而且應該知道如何編寫代碼才能高效地利用垃圾收集器的特性。然而，沒有微軟之外的人可以寫出使用帶自己編寫的垃圾收集器的CLR的.NET Framework應用程序。

相反地，WCF沒有什么神奇的。不要讓這個歪曲了你對這個平臺能力的認識。與之相反，在大的標準衡量它的可擴展的設(shè)計，WCF都是異常強大和符合預期的。WCF被設(shè)計來與自定義的傳輸、通道、綁定、編碼和架構(gòu)模式一起工作。第4章，“WCF 101”描述許多WCF的擴展點。

配置性

一個值得炫耀的WCF特性就是它可支持XML文件的完善的配置功能。使用這個特性，可以在XML文件里配置傳輸、地址、行為和綁定。如果配置文件更新，可以不需要修改任何代碼就可以改變 WCF應用的行為。從管理的角度來看非常有吸引力，因為這可以讓非開發(fā)人員來移植、維護和修改應用的行為而不需要卷入到開發(fā)工作中。合理的使用，會大大減少開發(fā)團隊的壓力和工作負荷。如果濫用，會帶來無法預期的后果。