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应用的行为。从管理的角度来看非常有吸引力，因为这可以让非开发人员来移植、维护和修改应用的行为而不需要卷入到开发工作中。合理的使用，会大大减少开发团队的压力和工作负荷。如果滥用，会带来无法预期的后果。
