WCF学习笔记（一）：WCF简介

MSDN上关于WCF给出如下注解：

设计 Windows Communication Foundation (WCF) 的目的是为分布式计算提供可管理的方法，提供广泛的互操作性，并为服务定位提供直接的支持。 

说的很清楚，同一管理分布式通信，广泛的互操作，服务定位。这是WCF出现的目的。 说到底，微软还是想简化开发方法，(MSMQ)、COM+、ASP.NET Web 服务这些散沙将会在齐聚WCF旗下，成为微软的又一片统一天地。

老翁自2007年看的第一本<asp.net揭秘>就跟微软在走，对新技术也算的上是痴迷，然而工作繁忙，最近赋闲在家，可以好好看看WCF这位少侠了。 

总览：

两个应用程序之间的通信有很多种方式，比如，我们可以使用XML与Webservice通信,使用消息与MSMQ互通，使用XML或二进制流与.NetRemoting通信等等。但是如果一个应用程序需要同时使用这几种来完成功能的话将给维护带来相当大的麻烦，WCF的出现则统一了这种局面，WCF 通过一种面向服务的新型编程模型简化了关联应用程序的开发。通过提供分层的体系结构，WCF 支持多种风格的分布式应用程序开发。 WCF 通道体系结构在底层提供了异步的非类型化消息传递基元。 而建立在此基础之上的是用于进行安全可靠的事务处理数据交换的各种协议功能，以及广泛的传输协议和编码选择。

概念:

WCF的全名是：Windows Communication Foundation ,是一个运行库和一组 API，用于创建在服务与客户端之间发送消息的系统。 它使用相同的基础结构和 API 来创建应用程序，这些应用程序可与同一计算机系统上或驻留在另一家公司内并通过 Internet 访问的系统上的其他应用程序进行通信。

1.消息和终结点

WCF 建立在基于消息的通信这一概念基础之上，也就是说只要应用程序能够建模为消息，都可以在WCF中统一表示，这样的话就可以使用WCF提供的统一API。

消息在终结点之间发送。 终结点是发送或接收消息（或执行这两种操作）的场所，它们定义消息交换所需要的所有信息。 服务公开一个或多个应用程序终结点（以及零个或更多个基础结构终结点），而客户端生成一个与服务的其中一个终结点兼容的终结点。

“终结点”以基于标准的方式描述消息应发送到的位置、消息应如何发送以及消息应具有的形式。 服务可以将这些信息作为元数据加以公开，而客户端可以处理这些元数据以生成适当的 WCF 客户端和通信堆栈。

2.通信协议

通信堆栈的一个必要元素是传输协议。 可以使用常用传输协议（如 HTTP 和 TCP）通过 Intranet 和 Internet 发送消息。 也可以使用其他支持与 Microsoft 消息队列 (MSMQ) 应用程序和对等网络网格上的节点进行通信的传输协议。 使用 WCF 的内置扩展点可以添加更多传输机制。

通信堆栈中的另一个必要元素是指定如何将任意给定消息格式化的编码。WCF 提供了下列编码：

• 文本编码，一种可互操作的编码。

• 消息传输优化机制 (MTOM) 编码，该编码是一种可互操作的方法，用于高效地将非结构化二进制数据发送到服务或从服务接收这些数据。

• 用于实现高效传输的二进制编码。

使用 WCF 的内置扩展点可以添加更多编码机制（如压缩编码）。

3.消息模式

WCF 支持多种消息模式，包括请求-回复、单向和双工通信。 不同传输协议支持不同的消息模式，因而会影响它们所支持的交互类型。 WCF API 和运行库还能帮助您安全而可靠地发送消息。

其他相关术语

消息

消息是一个独立的数据单元，它可能由几个部分组成，包括消息正文和消息头。

服务

服务是一个构造，它公开一个或多个终结点，其中每个终结点都公开一个或多个服务操作。

终结点

终结点是用来发送或接收消息（或执行这两种操作）的构造。 终结点包括一个定义消息可以发送到的目的地的位置（地址）、一个描述消息应如何发送的通信机制规范（绑定）以及对于可以在该位置发送或接收（或两者皆可）的一组消息的定义（服务协定）— 该定义还描述了可以发送何种消息。WCF 服务作为一个终结点集合向外界公开。

应用程序终结点

一个终结点，由应用程序公开并对应于该应用程序实现的服务协定。

基础结构终结点

一个终结点，由基础结构公开，以便实现与服务协定无关的服务需要或提供的功能。 例如，服务可能拥有一个提供元数据信息的基础结构终结点。

地址

地址指定接收消息的位置。 地址以统一资源标识符 (URI) 的形式指定。 URI 架构部分指定用于到达该地址的传输机制，如 HTTP 和 TCP。 URI 的层次结构部分包含一个唯一的位置，其格式取决于传输机制。

使用终结点地址可以为服务中的每个终结点创建唯一的终结点地址，或者在某些特定条件下在终结点之间共享一个地址。 HTTPS://cohowinery:8005/ServiceModelSamples/CalculatorService

绑定

绑定定义终结点与外界进行通信的方式。 它由一组称为绑定元素的要素构造而成，这些元素“堆叠”在一起以形成通信基础结构。 绑定最起码应定义传输协议（如 HTTP 或 TCP）和所使用的编码（如文本或二进制）。

绑定元素

绑定元素表示绑定的特定部分，如传输协议、编码、基础结构级协议（如 WS-ReliableMessaging）的实现以及通信堆栈的其他任何要素。

行为

行为是控制服务、终结点、特定操作或客户端的各种运行时方面的要素。 行为按照范围进行分组：常见行为在全局范围内影响所有终结点，服务行为仅影响与服务相关的方面，终结点行为仅影响与终结点相关的属性，操作级行为影响特定操作。 例如，有一种服务行为是遏制，它指定当过多的消息可能超出服务的处理能力时，服务应该如何反应。 另一方面，终结点行为仅控制与终结点相关的方面，如查找安全凭据的方式和位置。

系统提供的绑定

WCF 包含许多系统提供的绑定。 这些绑定是针对特定方案进行优化的绑定元素的集合。 例如，WSHttpBinding 是为了与实现各种 WS* 规范的服务进行互操作而专门设计的。 通过仅提供那些可以正确应用于特定方案的选项，这些预定义的绑定可以节省时间。 如果预定义的绑定不能满足您的要求，则可以创建您自己的自定义绑定。

配置与编码

可以通过编码、配置或将两者结合在一起来完成对应用程序的控制。 配置的优点在于，它使除开发人员以外的其他人员（如网络管理员）可以在代码编写完成后对客户端和服务参数进行设置，而不必重新编译。 使用配置不仅可以设置值（如终结点地址），还可以通过添加终结点、绑定和行为来实施进一步的控制。 使用编码，开发人员可以保持对服务或客户端的所有组件的严格控制，而且可以对通过配置完成的所有设置进行检查，并根据需要通过代码进行重写。

服务操作

服务操作是在服务的代码中定义的过程，用于实现某种操作的功能。 此操作作为一个 WCF 客户端上的方法向客户端公开。 该方法可能返回一个值，并可能采用数量可选的参数，或是不采用任何参数且不返回任何响应。 例如，一个实现简单的“Hello”的操作可以用作客户端存在通知，并可以开始一系列操作。

服务协定

服务协定将多个相关的操作联系在一起，组成单个功能单元。 协定可以定义服务级设置，如服务的命名空间、对应的回调协定以及其他此类设置。 在大多数情况下，协定是通过用您所选的编程语言创建一个接口并将 ServiceContractAttribute 属性应用于该接口来定义的。 通过实现该接口，可生成实际的服务代码。

操作协定

操作协定定义参数并返回操作的类型。 在创建定义服务协定的接口时，可以通过将 OperationContractAttribute 属性应用于协定中包含的每个方法定义来表示一个操作协定。 可以将操作建模为采用单个消息作为参数并返回单个消息，或者建模为采用一组类型作为参数并返回一个类型。 在后一种情况下，系统将确定需要为该操作交换的消息的格式。

消息协定

消息协定描述消息的格式。 例如，它会声明消息元素应包含在消息头中还是包含在消息正文中，应该对消息的何种元素应用何种级别的安全，等等。

错误协定

可以将错误协定与服务操作进行关联，以指示可能返回到调用方的错误。 一个操作可能具有零个或更多个与其相关联的错误。 这些错误是在编程模型中建模为异常的 SOAP 错误。

数据协定

服务使用的数据类型必须在元数据中进行描述，以使其他各方可以与该服务进行交互操作。 数据类型的说明称为数据协定，而这些类型可以在消息的任何部分使用（例如，作为参数或返回类型）。 如果服务仅使用简单类型，则无需显式使用数据协定。

宿主

服务必须承载于某个进程中。 “宿主”是控制服务的生存期的应用程序。 服务可以是自承载的，也可以由现有的宿主进程进行管理。

自承载服务

自承载服务是在开发人员创建的进程应用程序中运行的服务。 开发人员控制服务的生存期、设置服务的属性、打开服务（这会将服务设置为侦听模式）以及关闭服务。

宿主进程

宿主进程是专为承载服务而设计的应用程序。 这些宿主进程包括 Internet 信息服务 (IIS)、Windows 激活服务 (WAS) 和 Windows 服务。 在这些宿主方案中，由宿主控制服务的生存期。 例如，使用 IIS 可以设置包含服务程序集和配置文件的虚拟目录。 在收到消息时，IIS 将启动服务并控制服务的生存期。

实例化

服务具有一个实例化模型。 有三种实例化模型：“单个”，在这种模型中，由单个 CLR 对象为所有客户端提供服务；“每个调用”，在这种模型中，将创建一个新的 CLR 对象来处理每个客户端调用；“每个会话”，在这种模型中，将创建一组 CLR 对象，并且为每个独立的会话使用一个对象。 实例化模型的选择取决于应用程序要求和服务的预期使用模式。

客户端应用程序

客户端应用程序是与一个或多个终结点交换消息的程序。 客户端应用程序通过创建一个 WCF 客户端实例并调用该 WCF 客户端的方法来开始工作。 需要注意的是，单个应用程序既可以充当客户端，也可以充当服务。

通道

通道是绑定元素的具体实现。 绑定表示配置，而通道是与该配置相关联的实现。 因此，每个绑定元素都有一个相关联的通道。 通道堆叠在一起以形成绑定的具体实现：通道堆栈。

WCF 客户端

WCF 客户端是一个将服务操作作为方法公开的客户端应用程序构造（用您所选的 .NET Framework 编程语言编写，如 Visual Basic 或 Visual C#）。 任何应用程序都可以承载 WCF 客户端，包括承载服务的应用程序。 因此，可以创建一个包含其他服务的 WCF 客户端的服务。

通过使用 ServiceModel Metadata Utility Tool (Svcutil.exe) 并使其指向正在运行的发布元数据的服务，可以自动生成 WCF 客户端。

元数据

服务的元数据描述服务的特征，外部实体需要了解这些特征以便与该服务进行通信。 ServiceModel Metadata Utility Tool (Svcutil.exe) 可以使用元数据生成 WCF 客户端以及客户端应用程序可用来与服务进行交互的伴随配置。

服务所公开的元数据包括 XML 架构文档（用于定义服务的数据协定）和 WSDL 文档（用于描述服务的方法）。

启用元数据后，WCF 通过检查服务及其终结点自动生成服务的元数据。 若要发布服务的元数据，必须显式启用元数据行为。

安全

WCF 中的安全包括保密性（为防止偷听而进行的消息加密）、完整性（用于检测对消息所做篡改的方法）、身份验证（用于验证服务器和客户端的方法）以及授权（资源访问控制）。 通过利用现有安全机制（如 TLS over HTTP，也称为 HTTPS）或通过实现各种 WS-* 安全规范中的一个或多个规范，可以提供这些功能。

传输安全模式

可以通过以下三种模式之一来保证安全：传输模式、消息安全模式和使用消息凭据的传输模式。 传输安全模式指定由传输层机制（如 HTTPS）提供保密性、完整性和身份验证。 在使用像 HTTPS 这样的传输协议时，此模式的优点在于性能出色，而且由于它在 Internet 上非常流行，因此很容易理解。 其缺点在于，这种安全分别应用于通信路径中的每个跃点，这使得通信容易遭受“中间人”攻击。

消息安全模式

消息安全模式指定通过实现一个或多个安全规范来保证安全，如名为“Web Services Security: SOAP Message Security”（Web 服务安全：SOAP 消息安全）的规范（可在 http://go.microsoft.com/fwlink/?LinkId=94684 获得）。 每个消息都包含必要的安全机制，用于在消息传输过程中保证安全，并使接收方能够检测到篡改和对消息进行解密。 从这种意义上说，安全被封装在每个消息中，从而提供了跨多个跃点的端到端安全。 由于安全信息成为消息的一部分，因此可以在消息中包含多种凭据（这些凭据称为“声明”）。 这种方法还具有这样一个优点，即使得消息可以通过任意传输（包括在其起点和终点之间的多个传输）安全地传送。 这种方法的缺点在于所使用的加密机制具有较高的复杂性，从而使性能受到影响。

使用消息凭据的传输安全模式

此模式使用传输层来提供消息的保密性、身份验证和完整性，并且每个消息都可以包含消息接收方所要求的多个凭据（声明）。

WS-*

一组不断增加的、在 WCF 中予以实现的 Web 服务 (WS) 规范（如 WS-Security、WS-ReliableMessaging 等）的简写。