from：http://msdn.microsoft.com/zh-cn/library/vstudio/ms731082(v=vs.90).aspx
Web 服务中包含了用于应用程序间通信的标准协议，它在全球范围内的广泛采纳改变了软件开发。例如，如今 Web 服务提供的功能包括安全性、分布式事务协调和可靠的通信。Web 服务所发生的这些改变的效益应反映在开发人员所使用的工具和技术方面。设计 Windows Communication Foundation (WCF) 的目的是为分布式计算提供可管理的方法，提供广泛的互操作性，并为服务定位提供直接的支持。
WCF 通过一种面向服务的新型编程模型简化了关联应用程序的开发。通过提供分层的体系结构，WCF 支持多种风格的分布式应用程序开发。WCF 通道体系结构在底层提供了异步的非类型化消息传递基元。而建立在此基础之上的是用于进行安全可靠的事务处理数据交换的各种协议功能，以及广泛的传输协议和编码选择。
类型化编程模型（称为“服务模型”）设计用来降低分布式应用程序的开发难度，并为 ASP.NET Web 服务、.NET Framework 远程处理和企业服务领域的专业开发人员，以及将要从事 WCF 开发的人员提供熟悉的开发体验。该服务模型的特点在于它将 Web 服务的概念直接映射到 .NET Framework 公共语言运行库 (CLR) 中的对应内容，包括将消息灵活且可扩展地映射到用诸如 Visual C# 或 Visual Basic 等语言实现的服务。该服务模型提供支持松散耦合和版本管理的序列化功能，并提供与诸如消息队列 (MSMQ)、COM+、ASP.NET Web 服务、Web 服务增强 (WSE) 等现有 .NET Framework 分布式系统技术以及很多其他功能的集成和互操作性。
问题示例
下面的示例阐释了 WCF 处理的一些问题。一家汽车租赁公司决定创建一个新的应用程序，用于汽车预定。该租车预定应用程序的创建者知道，应用程序所实现的业务逻辑必须能够让公司内外运行的其他软件访问。因此，他们决定以面向服务的方式来创建此应用程序，并通过定义完善的一组服务，将此应用程序的逻辑公开给其他软件。为了实现这些服务并使之与其他软件进行通信，这一新应用程序将使用 WCF。
在租车预定应用程序的生存期内，可能会有一系列其他应用程序访问此应用程序。但是在设计期间设计者知道，将有其他三种软件访问该租车预定应用程序的业务逻辑（如上图所示）：
- 运行在 Windows 桌面上的呼叫中心客户端应用程序，它由该组织的呼叫中心员工使用。此应用程序是专门针对新的预定系统创建的，也可以使用 Microsoft .NET Framework 和 WCF 来构建。此应用程序与新的租车预定应用程序并不泾渭分明，因为它的唯一用途是作为该新系统的客户端。从面向服务的角度来看，它只是该预定系统的业务逻辑的另一个客户端。
- 基于 J2EE 服务器构建、在非 Windows 系统上运行的现有预定应用程序。由于最近与另一家汽车租赁公司合并，此现有系统必须能够访问新应用程序的逻辑，以便为合并后公司的客户提供一致的体验。
- 运行在各种平台上的合作伙伴应用程序，每个应用程序分别位于一个与该汽车租赁公司有业务合作的公司内。合作伙伴可能包括旅行社、航空公司，以及具有租车预定业务需求的其他组织。
处理好对新租车预定应用程序的众多通信要求并非易事。例如，为了与呼叫中心客户端应用程序进行交互，性能十分重要，而互操作性则较为简单，因为二者都是建立在 .NET Framework 之上。然而，要与基于 J2EE 的现有预定应用程序以及各种合作伙伴应用程序进行通信，互操作性又成为最重要的目标。而从基于 Windows 的本地应用程序，到基于 J2EE 的运行在另一种操作系统上的应用程序，再到 Internet 上的各种合作伙伴应用程序，它们对安全性的要求也大为不同。甚至事务性要求也可能不同，例如只允许内部应用程序发出事务性请求。业务和技术要求如此繁杂，新应用程序的创建者在满足这些要求时何以避免难以处理的复杂性？
WCF 就是针对这种繁杂却又切实存在的情况而设计的，是公开和访问服务的 Windows 应用程序的首选技术。本主题将对 WCF 进行介绍，讲解它提供的功能并演示它的用法。介绍全文将以前面描述的应用场景为例。目的在于阐明什么是 WCF，指出它所解决的问题，并演示它如何解决这些问题。
处理问题
基于 Windows 的新应用程序的基础是 .NET Framework。因此，WCF 主要作为 .NET Framework CLR 上面的一组类来实现。WCF 扩展了开发人员熟悉的开发环境，这让目前使用 .NET Framework 创建面向对象的应用程序的开发人员也能够以自己熟悉的方式创建面向服务的应用程序。
该图显示了 WCF 客户端和服务。二者使用 SOAP（WCF 本机消息表示形式）进行交互，因此虽然该图显示二者都是建立在 WCF 之上，但这并不是必需的。WCF 建立在 .NET Framework 2.0 之上。
如前述应用场景所指出的，WCF 能够解决应用程序通信所面临的一系列挑战。而其中发挥最重要作用的是 WCF 的三个突出特点：
- 对多种现有 .NET Framework 通信技术的统一。
- 对跨供应商互操作性的支持，包括可靠性、安全性和事务。
- 显式的服务定位。
对 Microsoft 分布式计算技术的统一
如果没有 WCF，实现租车应用程序的开发团队将需要从 .NET Framework 提供的多种选项中选择合适的分布式技术。然而考虑到此应用程序的复杂要求，没有一种单独的技术能够满足这些要求。因而，应用程序可能要使用多种现有的 .NET Framework 技术，例如下列技术：
- ASP.NET Web 服务 (ASMX)。这种技术用于与基于 J2EE 的现有预定应用程序，以及与 Internet 上的合作伙伴应用程序进行通信。因为目前大多数平台都支持基本的 Web 服务，所以在 WCF 发布之前，这是实现跨供应商互操作性的最直接的方法。
- .NET Framework 远程处理。这种技术可用于与呼叫中心应用程序进行通信，因为二者都是建立在 .NET Framework 之上的。远程处理专门为紧密耦合的 .NET 到 .NET 通信而设计，因此它为本地网络中的应用程序提供了无缝而直接的开发体验。
- 企业服务。租车预定应用程序使用该技术来管理对象生存期和定义分布式事务。在与此应用场景中的任何其他应用程序通信和集成时，这些功能会很有用，但是企业服务仅支持有限的一组通信选项。
- WSE。可与 ASMX 一起使用，以便与基于 J2EE 的预定应用程序以及合作伙伴应用程序进行通信。它实现了最新定义的一些 Web 服务协议（统称 WS-* 规范），因此只要相关所有应用程序都支持这些新规范的兼容版本，WSE 就可提供更加灵活的 Web 服务安全性。
- Microsoft 消息队列 (MSMQ)。用于与基于 Windows 的合作伙伴应用程序进行通信，这些应用程序对数据传送、工作量分离以及应用程序生存期均要求有保证。消息队列提供持久稳定的消息传送，这通常是间歇式连接的应用程序的最佳解决方案。
由于建立在 .NET Framework 之上，该租车预定应用程序必须使用这些通信技术中的多种技术才能满足其要求。尽管这在技术上是可行的，但最终的应用程序实现起来将会很复杂，而且维护起来也很困难。
使用 WCF，该解决方案的实现就容易得多了。如图中所示，WCF 可用于前述所有情况。因此，租车预定应用程序使用这一种技术就可以实现其所有应用程序间的通信。下面说明 WCF 是如何满足所有这些要求的：
- WCF 可使用 Web 服务进行通信，因此与同样支持 SOAP 的其他平台（例如基于 J2EE 的主流应用程序服务器）间的互操作性就变得简单明了。
- 还可以对 WCF 进行配置和扩展，以便与使用并非基于 SOAP 的消息（例如像 RSS 这种简单的 XML 格式）的 Web 服务进行通信。
- 性能是大多数业务中至关重要的考虑事项。开发 WCF 的目标就是要使之成为 Microsoft 所开发的速度最快的分布式应用程序平台之一。有关 WCF 和其他 Microsoft .NET 分布式通信技术之间的高级性能比较，请参见 http://go.microsoft.com/fwlink/?LinkId=94274（可能为英文网页）。
- 当通信双方都建立在 WCF 上时，为获得最理想的性能，本例中使用的线上编码是 XML 信息集的一个优化的二进制版本。消息仍遵循 SOAP 消息的数据结构，但其编码使用该数据结构的二进制表示形式，而不是 XML 1.0 文本编码的标准尖括号加文本格式。使用此选项的意义体现在与呼叫中心客户端应用程序的通信中，因为该应用程序也是建立在 WCF 上，并且性能是一个重要的考虑事项。
- 管理对象生存期、定义分布式事务以及企业服务的其他方面的功能现在可以由 WCF 来提供。任何基于 WCF 的应用程序都可以使用这些功能，这意味着租车预定应用程序可以针对与之通信的任何其他应用程序使用这些功能。
- WCF 支持一个大的 WS-* 规范集，因此可在与同样支持这些规范的任何其他平台进行通信时帮助提供可靠性、安全性和事务。
- 建立在消息队列上的 WCF 排队消息选项使应用程序能够使用持久的排队，而无需使用另外一组应用程序编程接口。
这种统一性的结果是获得了更强的功能，并显著降低了复杂性。
与使用其他技术构建的应用程序的互操作性
WCF 不仅为分布式应用程序引入了新的开发环境，它的设计使其同样能够与非 WCF 应用程序进行良好的互操作。WCF 互操作性有两个重要方面：与其他平台的互操作性，以及与 WCF 之前的 Microsoft 技术的互操作性。下面一节将介绍这两种互操作性。
与其他 Web 服务平台的互操作性
如今，企业的系统和应用程序通常是从不同的供应商那里购买的。例如，在租车应用程序中，需要与其他各种使用不同语言编写、运行在各种操作系统上的软件应用程序进行通信。
WCF 的基本通信机制是基于 SOAP 的 Web 服务，因此基于 WCF 的应用程序可以与运行在各种不同环境中的软件进行通信。构建于 WCF 上的应用程序可以与下列应用程序进行交互：
- 运行在同一台 Windows 计算机上的不同进程中、基于 WCF 的应用程序。
- 运行在另一台 Windows 计算机上的基于 WCF 的应用程序。
- 基于 J2EE 应用程序服务器等其他技术构建的、支持标准 Web 服务的应用程序。这些应用程序可以运行在 Windows 计算机上，也可以运行在采用其他操作系统的计算机上。
为实现基本通信以外的功能，WCF 还实现 WS-* 规范所定义的 Web 服务技术。所有这些规范最初都是由 Microsoft、IBM 和其他供应商共同制定的。随着规范趋于稳定，所有权通常会移交给标准机构，例如万维网联合会 (W3C) 或结构化信息标准促进组织 (OASIS)。这些规范所处理的问题包括以下一些方面：基本消息传送、安全性、可靠性、事务以及使用服务的元数据等。有关更多信息，请参见互操作性和集成。有关 高级 Web 服务规范的更多信息，请参见 （可能为英文网页）。
将这些规范按功能分组，包括以下几组：
- 消息传递：SOAP 是 Web 服务的基础，它定义包含标头和正文部分的基本信封。WS-Addressing 定义在 SOAP 标头上附加的用于对 SOAP 消息进行寻址的内容，这部分附加内容使 SOAP 无需依赖基础传输协议（例如 HTTP）就可以传送寻址信息。消息传输优化机制 (MTOM) 根据 XML 二进制优化打包 (XOP) 规范，为具有大量二进制数据内容的 SOAP 消息定义一种优化的传输格式。
- 元数据：Web 服务描述语言 (WSDL) 定义一种标准语言，用于指定服务和有关如何使用这些服务的各个方面。WS-Policy 提供了一套规范，描述服务行为中无法用 WSDL 表达的更为动态的方面，例如首选安全选项。WS-MetadataExchange 允许客户端使用 SOAP 直接请求关于服务的描述性信息，例如服务的 WSDL 和服务策略。
- 安全性：WS-Security、WS-SecureConversation、WS-Trust 和 WS-Federation 都定义 SOAP 消息的附加部分，用来提供身份验证、数据完整性、数据保密和其他安全功能。
- 可靠性：WS-Reliable Messaging 定义 SOAP 标头的附加部分，它能够实现可靠的端对端通信，即使在必须穿越一个或多个 Web 服务媒介的情况下也是如此。
- 事务：WS-Atomic Transaction 建立在 WS-Coordination 之上，它允许在 Web 服务对话的上下文中协调两阶段提交事务。
租车预定应用程序将很可能使用这些更高级的技术中的一些技术。例如，只要在不是 HTTP 的传输机制中使用 SOAP，那么 WS-Addressing 就是必不可少的，与基于 .NET Framework 的呼叫中心客户端应用程序进行通信可能就属于这种情况。WCF 依靠 WS-Policy 和 WS-Metadata Exchange 来发现与之通信的系统是否也在使用 WCF 以及其他方面的信息。大多数情况下，可靠的通信都是十分重要的，因此很可能需要使用 WS-Reliable Messaging 来与此应用场景中的诸多其他应用程序进行交互。同样，您可能还要使用 WS-Security 和相关规范来保证与一个或多个应用程序通信的安全，因为所有通信都要求具有某种保护，以防止未经授权的访问或消息修改及侦听。对于需要与租车预定系统进行事务集成的应用程序，WS-Atomic Transaction 是必需的。最后，如果必须为二进制数据使用优化的连网格式（例如舰队图片示例），并且通信的双方都支持 MTOM，那么就可能需要使用 MTOM。
关键之处在于，WCF 实现了可互操作的 Web 服务，同时提供了跨平台安全性、可靠性、事务和其他服务。为了获得最大的吞吐量，可以对 WCF 到 WCF 的通信进行大幅度优化，但让所有其他通信使用标准的 Web 服务协议。事实上，一个应用程序可以将其服务同时公开给这两种客户端。
与 Microsoft 技术的互操作性
许多 Microsoft 客户在 WCF 所包含的 .NET Framework 技术方面投资巨大。因而保护这些投资就成了 WCF 设计者的重要目标。安装 WCF 不会破坏现有的技术，因此组织不需要改变现有的应用程序就可以使用它。但是，提供了一个明确的升级途径，并且只要可能，WCF 都会与那些早期的技术进行互操作。
例如，WCF 和 ASMX 都使用 SOAP，因此基于 WCF 的应用程序可以直接与使用 ASMX 构建的应用程序进行互操作。现有的企业服务应用程序也可以与 WCF 接口一起包装，从而可以与在 WCF 上构建的应用程序进行互操作。因为 WCF 中的持久排队依赖于 MSMQ，所以基于 WCF 的应用程序可以直接与使用本机 MSMQ 接口构建的非基于 WCF 的应用程序进行互操作。在租车预定应用程序中，使用任何这些早期技术构建的软件都可以直接连接到新系统的基于 WCF 的服务并使用这些服务。
但是，并不是在任何情况下都可实现互操作性。例如，虽然 WSE 1.0 和 WSE 2.0 实现的某些 WS-* 规范与 WCF 相同，但这些早期技术所实现的是这些规范的早期版本。WSE 的 3.0 版的确允许与 WCF 进行互操作，但早期版本则不允许。有关互操作性的更多信息，请参见将 WSE 3.0 Web 服务迁移到 WCF。
与其他 XML 协议的互操作性
Internet 的未来是无法预言的，今天使用的技术也许会不断发展，也许会被替代。目前，构建以 Web 为中心的应用程序有一个流行的趋势（许多人称之为“Web 2.0”），就是采用一种应用程序模型：该模型基于仅使用简单 XML 格式的通信，而这种简单的 XML 格式不基于 SOAP，而只依赖于 HTTP 作为传输协议和应用程序协议。例如，“表现性状态传输”(REST) 体系结构样式不会使用用户定义的操作来处理数据。而是应用程序状态与 HTTP URL 和 HTTP 方法（例如 PUT、POST、DELETE 和 GET）关联。这种方法与企业环境中多数开发人员所熟知的创建用户定义的过程或函数形成对照。但是，在服务必须作为 Web 2.0 应用程序后端的情况下，REST 方法仍是有价值的。
REST 只是 Web 2.0 技术演进的一个示例。在这个试验性的编程模型以及不断重新诠释和改进标准的环境中，需要以灵活性来应对不可预见的变化。WCF 是灵活的。例如，当 WCF 使用 SOAP 作为基础结构时，并不一定要将 SOAP 用于网络通信。事实上，可以对 WCF 进行配置，使其处理不包装在 SOAP 信封中的“明文”XML 数据。还可以对 WCF 进行扩展，以支持特定的 XML 格式，例如 ATOM（一种广泛使用的 RSS 标准），甚至还可以支持非 XML 格式，例如 JavaScript 对象符号 (JSON)。这种灵活性可以确保即便协议发生了改变或被替代，当前编写的代码在将来同样有效。可以说，WCF 是为今天和将来而设计的。
