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
在上世纪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应用程序如何在概念上组织在一起的
随着时间的前移，我希望看到这些产品在某些方面能够使用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特性对比
客观地说，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的应用系统可以通过消息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解决他们的分布式计算任务。
