你或许可以使用某一技术实现某些功能，可以按着指定的要求，完成特定的功能，实现某一想要的效果，这表示你可以使用该技术，会使用该技术，但是我们不能停留在使用的层次上，还要了解它们的运行机制，可能有点深了，有点难度，或者可以浅一些了解程序运行自己的关系，尤其像WCF将各个技术集大成，它的各个术语的含义，以及它们是如何联系的，又是如何发挥作用的，怎样实现WCF这一技术的特性、优点的。我们不要只是可以简单的使用一项技术并使用的很好，当我们去讲述这些技术如何时？有什么好的优点、缺点，对于解决那些方面的问题真的起到很不错的作用，真的也很有发展前景，以及可以讲述这个技术一些功能点和技术特色。像大家所想的那样，我们不仅要知其然，还要知其所以然，不仅要会使用这些技术还有能够讲明白这些技术(技术优点、缺点、特性、适用场合、应用前景、以及各个功能点的细节等等)。凡事总是说起来容易，做起来难，但我们学这个的就欣然接受吧！程序员的我们要拥抱变化，要适应变化，要做好技术储备。学习编程，学技术，做开发，做软件，真的很累啊！不过，也挺快乐的，有接触新鲜事物的好奇，有解决一个问题的喜悦，有实现某个功能（小项目）的成就感。 像大家常说的干IT，老挨踢，加班赶工，又苦逼。很累也很快乐。让我们痛苦的幸福着吧！ (牢骚一下！)
本篇主要是自己对WCF服务编程的书籍的学习笔记或是简单的摘录吧！基本没代码，都是一些术语、各个技术点的联系、和各个技术点的优缺点。对于一个对分布式应用不太了解的菜鸟，去学习一门把Windows下分布式应用技术集大成的WCF了解、熟悉也是不错的吧！
对于WCF的更多使用和了解，推荐博客Artech：http://www.cnblogs.com/artech/
WCF服务编程 学习笔记
Windows Communication Foundation, WCF。集成分布式系统技术，包括 ASP.NET 服务、Web 服务增强（WSE）、.NET Remoting、消息传输/MSMQ以及企业服务/COM+等的实现。 WCF 内建的特性，例如服务托管、实例管理、并发管理、事务、离线队列调用以及安全。
WCF基础
1.什么是WCF
Windows 通信基础（Windows Communication Foundation，WCF）是基于 Windows平台下开发和部署服务的软件开发包（Software Development Kit，SDK）。WCF 的第一个版本为服务开发提供了许多有用的功能，包括托管（Hosting）、服务实例管理（Service Instance Management）、 异步调用、可靠性、事务管理、离线队列调用（Disconnected Queued Call）以及安全性。
2.服务
服务（Services）是公开的一组功能的集合。从软件设计的角度考虑，软件设计思想经历了从函数发展到对象，从对象发展到组件，再从组件发展到服务的几次变迁。面向服务 （Service-Orientation，SO）是一组原则的抽象，是创建面向服务应用程序的最佳实践。
服务可以是本地的，也可以是远程的，可以由多个参与方使用任意技术进行开发。服务与版本无关，甚至可以在不同的时区同时执行。服务内部包含了诸如语言、技术、平台、版本与框架等诸多概念，而服务之间的交互，则只允许指定的通信模式。
客户端与服务通过消息的发送与接收进行交互。消息可以直接在客户端与服务之间进行传递，也可以通过中间方进行传递。WCF 中的所有消息均为 SOAP 消息。注意 WCF 的消息与传输协议无关，这与 Web 服务不同。因此，WCF 服务可以在不同的协议之间传输，而不仅限于 HTTP。WCF 客户端可以与非 WCF 服务完成互操作，而 WCF 服务也可以与非WCF 客户端交互。不过，如果需要同时开发客户端与服务，则创建的应用程序两端都要求支持 WCF，这样才能利用 WCF 的特定优势。 因为服务的创建对于外界而言是不透明的，所以 WCF 服务通常通过公开元数据（Metadata）的方式描述可用的功能以及服务可能采用的通信方式。元数据的发布可以预先定义，它与具体的技术无关（Technology-Neutral），例如采用基于 HTTP-GET 方式的WSDL，或者符合元数据交换的行业标准。一个非 WCF 客户端可以将元数据作为本地类型导入到本地环境中。相似的，WCF 客户端也可以导入非 WCF 服务的元数据，然后以本地CLR 类与接口的方式进行调用。
3.服务的执行边界
WCF 不允许客户端直接与服务交互，即使它调用的是本地机器内存中的服务。相反，客户端总是使用代理（Proxy）将调用转发给服务。代理公开的操作与服务相同，同时还增加了一些管理代理的方法。
WCF 允许客户端跨越执行边界与服务通信。在同一台机器中（参见图 1-2），客户端可以调用同一个应用程序域中的服务，也可以在同一进程中跨应用程序域调用，甚至跨进程调用。WCF 允许客户端跨越执行边界与服务通信。在同一台机器中（参见图 1-2），客户端可以调用同一个应用程序域中的服务，也可以在同一进程中跨应用程序域调用，甚至跨进程调用。
4.WCF与位置透明度
过去，诸如 DCOM 或.NET Remoting 等分布式计算技术，不管对象是本地还是远程，都期望为客户端提供相同的编程模型。本地调用时，客户端使用直接引用；处理远程对象时，则使用代理。因为位置的不同而采用两种不同的编程模型会导致一个问题，就是远程调用远比本地调用复杂。复杂度体现在生命周期管理、可靠性、状态管理、可伸缩性（scalability）以及安全性等诸多方面。由于远程对象并不具备本地对象的特征，而编程模型却力图让它成 为本地对象，反而使得远程编程模型过于复杂。WCF 同样要求客户端保持一致的编程模型，而不用考虑服务的位置。但它的实现途径却大相径庭：即使对象是本地的，WCF 仍然使用远程编程模型的实例化方式，并使用代理。由于所有的交互操作都经由代理完成，要求相同的配置与托管方式，因而对于本地和远程方式而言，WCF 都只需要维持相同的编程模型。这就使得开发者不会因为服务位置的改变影响客户端，同时还大大地简化了应用程序的编程模型。
5.地址
WCF 的每一个服务都具有一个唯一的地址（Addresses）。地址包含两个重要元素：服务位置与传输协议（Transport Protocol），或者是用于服务通信的传输样式（Transport Schema）。服务位置包括目标机器名、站点或网络、通信端口、管道或队列，以及一个可选的特定路径或者 URI。URI 即统一资源标识（Universal Resource Identifier），它可以是任意的唯一标识的字符串，例如服务名称或 GUID。
WCF 1.0 支持下列传输样式：HTTP、TCP、Peer network（对等网）、IPC（基于命名管道的内部进程通信）、MSMQ 。 地址通常采用如下格式：[基地址]/[可选的 URI] 基地址（Base Address）通常的格式如下：[传输协议]://[机器名或域名][:可选端口]
下面是一些地址的示例：
http://localhost:8001
http://localhost:8001/MyService
net.tcp://localhost:8002/MyService
net.pipe://localhost/MyPipe
net.msmq://localhost/private/MyService
net.msmq://localhost/MyService
可以将地址http://localhost:8001 读作：“采用HTTP协议访问localhost机器，并在 8001端口等待用户的调用。”
如果URI为http://localhost:8001/MyService，则读作：“采用HTTP协议访问localhost机器，MyService服务在 8001 端口处等待用户的调用。”
(1).TCP地址
TCP 地址采用 net.tcp 协议进行传输，通常它还包括端口号，例如： net.tcp://localhost:8002/MyService 如果没有指定端口号，则 TCP 地址的默认端口号为 808： net.tcp://localhost/MyService 两个 TCP 地址（来自于相同的宿主，具体内容将在本章后面介绍）可以共享一个端口： net.tcp://localhost:8002/MyService net.tcp://localhost:8002/MyOtherService 本书广泛地使用了基于 TCP 协议的地址。 注意：我们可以将不同宿主的 TCP 地址配置为共享一个端口。
(2).HTTP地址
HTTP地址使用http协议进行传输，也可以利用https进行安全传输。HTTP地址通常会被用作对外的基于Internet的服务，并为其指定端口号，例如： http://localhost:8001 如果没有指定端口号，则默认为 80。与TCP地址相似，两个相同宿主的HTTP地址可以共享一个端口，甚至相同的机器。 本书广泛地使用了基于 HTTP 协议的地址。
(3).IPC地址
IPC 地址使用 net.pipe 进行传输，这意味着它将使用 Windows 的命名管道机制。在 WCF中，使用命名管道的服务只能接收来自同一台机器的调用。因此，在使用时必须指定明确的本地机器名或者直接命名为 localhost，为管道名提供一个唯一的标识字符串： net.pipe://localhost/MyPipe 每台机器只能打开一个命名管道，因此，两个命名管道地址在同一台机器上不能共享一个管道名。 本书广泛地使用了基于 IPC 的地址。
(4).MSMQ地址
MSMQ 地址使用 net.msmq 进行传输，即使用了微软消息队列（Microsoft Message Queue，MSMQ）机制。使用时必须为 MSMQ 地址指定队列名。如果是处理私有队列，则必须指定队列类型，但对于公有队列而言，队列类型可以省略： net.msmq://localhost/private/MyService net.msmq://localhost/MyService 本书第 9 章将专门介绍队列调用。
(5).对等网地址
对等网地址（Peer Network Address） 使用 net.p2p 进行传输，它使用了 Windows 的对等网传输机制。如果没有使用解析器（Resolver），我们就必须为对等网地址指定对等网名、唯一的路径以及端口。对等网的使用与配置超出了本书范围，但在本书的后续章节中会简略地介绍对等网。
6.契约
WCF 的所有服务都会公开为契约（Contract）。契约与平台无关，是描述服务功能的标准方式。
WCF 定义了四种类型的契约：
(1).服务契约（Service Contract）
服务契约描述了客户端能够执行的服务操作。
(2).数据契约（Data Contract）
数据契约定义了与服务交互的数据类型。WCF 为内建类型如 int 和 string 隐式地定义了契约；我们也可以非常便捷地将定制类型定义为数据契约。
(3).错误契约（Fault Contract）
错误契约定义了服务抛出的错误，以及服务处理错误和传递错误到客户端的方式。
(4).消息契约（Message Contract）
消息契约允许服务直接与消息交互。消息契约可以是类型化的，也可以是非类型化的。如果系统要求互操作性，或者遵循已有消息格式，那么消息契约会非常有用。由于 WCF 开发者极少使用消息契约，因此本书不会介绍它。
7.服务契约
ServiceContract 特性可以将一个 CLR 接口（或者通过推断获得的接口，后面将详细介绍）映射为与技术无关的服务契约。ServiceContract 特性公开了 CLR 接口（或者类）作为 WCF契约。WCF 契约与类型的访问限定无关，因为类型的访问限定属于 CLR 的概念。即使将ServiceContract 特性应用在内部（Internal）接口上，该接口同样会公开为公有服务契约，以便于跨越服务边界实现服务的调用。如果接口没有标记 ServiceContract 特性，WCF 客户端则无法访问它（即使接口是公有的）。这一特点遵循了面向服务的一个原则，即明确的服务边界。为满足这一原则，所有契约必须明确要求：只有接口（或者类）可以被标记为ServiceContract 特性，从而被定义为 WCF 服务，其他类型都不允许。
即使应用了 ServiceContract 特性，类型的所有成员也不一定就是契约中的一部分。我们必须使用 OperationContractAttribute 特性显式地标明哪些方法需要暴露为 WCF 契约中的一部分。WCF 只允许将 OperationContract 特性应用到方法上，而不允许应用到同样属于 CLR 概念的属性、索引器和事件上。WCF 只能识别作为逻辑功能的操作（Operation）。通过应用 OperationContract 特性，可以将契约方法暴露为逻辑操作，使其成为服务契约的一部分。接口（或类）中的其他方法如果没有应用 OperationContract 特性，则与契约无关。这有利于确保明确的服务边界，为操作自身维护一个明确参与（Opt-In）的模型。此外，契约操作不能使用引用对象作为参数，只允许使用基本类型或数据契约。
8.应用Service Contract特性
WCF 允许将 ServiceContract 特性应用到接口或类上。当接口应用了 Service-Contract特性后，需要定义类实现该接口。
一个单独的类通过继承和实现多个标记了 ServiceContract 特性的接口，可以支持多个契约。
然而，服务类还有一些实现上的约束。我们要避免使用带参构造函数，因为 WCF 只能使用默认构造函数。同样，虽然类可以使用内部（internal）的属性、索引器以及静态成员，但WCF 客户端却无法访问它们。
WCF 允许我们直接将 ServiceContract 特性应用到服务类上，而不需要首先定义一个单独的契约。通过服务类的定义，WCF 能够推断出契约的定义。至于 OperationContract 特性，则可以应用到类的任何一个方法上，不管它是私有方法，还是公有方法。
警告：应尽量避免将 ServiceContract 特性直接应用到服务类上，而应该定义一个单独的契约，这有利于在不同场景下使用契约。
9.名称与命名空间
可以为契约定义命名空间。契约的命名空间具有与.NET 编程相同的目的：确定契约的类型范围，以降低类型的冲突几率。可以使用 ServiceContract 类型的 Namespace 属性设置命名空间。
若非特别指定，契约的默认命名空间为http://tempuri.org 。对外服务的命名空间通常使用公司的URL；至于企业网（Intranet）内部服务的命名空间，则可以定义有意义的唯一名称，例如MyApplication。
在默认情况下，契约公开的名称就是接口名。但是也可以使用ServiceContract特性的Name属性为契约定义别名，从而在客户端的元数据（Metadata）中公开不同的名称。相似的，操作公开的名称默认为方法名，但我们同样可以使用 OperationContract 特性的Name 属性设置别名，从而公开不同的操作名。
10.托管(寄宿)
WCF 服务类不能凭空存在。每个 WCF 服务都必须托管（Hosting） 在 Windows 进程中，该进程被称为宿主进程（Host Process）。单个宿主进程可以托管多个服务，而相同的服务类型也能够托管在多个宿主进程中。WCF 没有要求宿主进程是否同时又是客户端进程。显然，一个独立的进程有利于错误与安全的隔离。谁提供进程或是提供何种类型的进程并不重要。宿主可以由 IIS 提供，也可以由 Windows Vista 的 Windows 激活服务（Windows Activation Service，WAS）提供，或者开发者直接将它作为应用程序的一部分。
注意：一种特殊的托管方式称为进程内托管（In-Process Hosting），简称 in-proc。服务与客户端驻留在相同的进程中。通过定义，开发者能够提供进程内托管。 (1).IIS 托管
在微软的 Internet 信息服务器（Internet Information Server，IIS）中托管服务，主要的优势是宿主进程可以在客户端提交第一次请求的时候自动启动，还可以借助 IIS 管理宿主进程的生命周期。IIS 托管的主要缺点在于只能使用 HTTP 协议。如果是 IIS 5，还要受端口限制，要求所有服务必须使用相同的端口号。 在 IIS 中托管服务与经典的 ASMX Web 服务托管相似，需要在 IIS 下创建虚拟目录，并提供一个.svc 文件。.svc 文件的功能与.asmx 文件相似，主要用于识别隐藏在文件和类后面的服务代码。例 1-2 展示了.svc 文件的语法结构。(此文件是通过创建网站WCF服务，创建文件，IIS宿主。)
例 1-2：.svc 文件 <%@ ServiceHost Language= "C#" Debug = "true" CodeBehind = "~/App_Code/MyService.cs" Service = "MyService" %> 注意：我们甚至可以将服务代码注入到.svc 文件中，但这样的做法并不明智。这与 ASMX Web 服务的要求相同。
使用 IIS 托管，服务的基地址必需与.svc 文件的地址保持一致。
Web.Config文件 Web 站点的配置文件（Web.Config）必须列出需要公开为服务的类型。类型使用类型全名，如果服务类型来自于一个没有被引用的程序集，则还要包括程序集名。
(2).自托管
所谓自托管（Self-Hosting） ，就是由开发者提供和管理宿主进程的生命周期。自托管方式适用于如下场景：需要确定客户端与服务之间的进程（或机器）边界时；使用进程内托管，即服务与客户端处于相同的进程中时。进程可以是任意的 Windows 进程，例如 Windows窗体应用程序、控制台应用程序或 Windows NT 服务。注意，进程必须在客户端调用服务之前运行，这意味着通常必须预先启动进程。但 NT 服务或进程内托管不受此限制。宿主程序的实现只需要简单的几行代码，就能够实现 IIS 托管的一部分特性。
与 IIS 托管相似，托管应用程序的配置文件（App.Config）必须列出所有希望托管和公开的服务类型。
此外，宿主进程必须在运行时显式地注册服务类型，同时为客户端的调用打开宿主，因此，我们才要求宿主进程必须在客户端调用到达之前运行。创建宿主的方法通常是在 Main()方法中调用 ServiceHost 类。
创建 ServiceHost 对象时，需要为 ServiceHost 的构造函数提供服务类型，至于默认的基地址则是可选的。可以将基地址集合设置为空。如果提供了多个基地址，也可以将服务配置为使用不同的基地址。ServiceHost 拥有基地址集合可以使得服务能够接收来自于多个地址和协议的调用，同时只需要使用相对的 URI。注意，每个 SeriviceHost 实例都与特定的服务类型相关，如果宿主进程需要运行多个服务类型，则必须创建与之匹配的多个ServiceHost 实例。在宿主程序中，通过调用 Open()方法，可以允许调用传入；通过调用Close()方法终结宿主实例，完成进程中的调用。此时，即使宿主进程还在运行，仍然会拒绝客户端的调用。而在通常情况下，执行关闭操作会停止宿主进程。
打开宿主时，将装载 WCF 运行时（WCF runtime），启动工作线程监控传入的请求。由于引入了工作线程，因此可以在打开宿主之后执行阻塞（blocking）操作。通过显式控制宿主的打开与关闭，提供了 IIS 托管难以实现的特征，即能够创建定制的应用程序控制模块，管理者可以随意地打开和关闭宿主，而不用每次停止宿主的运行。
(3).自托管与基地址
可以在启动服务宿主时，无需提供任何基地址。(即为创建ServiceHost对象时，只指定服务对象类型，不指定任何基址，但不能将其指定为null，会报错的。params参数是可选的。) 只要这些地址没有使用相同的传输样式（Transport Schema），我们也可以注册多个基地址，并以逗号作为地址之间的分隔符。 WCF 也允许开发者在宿主配置文件中列出基地址内容：
<system.serviceModel>
<services>
<service name = "MyNamespace.MyService">
<host>
<baseAddre sses>
<add baseAddress = "net.tcp://localhost:8001/"/>
<add baseAddress = "http://localhost:8002/"/>
</baseAddresses>
</host>
...
</service>
</services>
</system.serviceModel>
创建宿主时，无论在配置文件中找到哪一个基地址，宿主都会使用它，同时还要加上以编程方式提供的基地址。需要特别注意，我们必须确保配置的基地址的样式不能与代码中的基地址的样式重叠。 我们甚至可以针对相同的类型注册多个宿主，只要这些宿主使用了不同的基地址。(极为创建多个基址，创建多个host对象，指定不同的基址。) 然而，这并不包括第 8 章介绍的使用线程的情况，以这种方式打开多个宿主并无优势可言。此外，如果基地址是配置文件提供的，那么就需要使用 ServiceHost 的构造函数为相同的类型打开多个宿主。
(4).托管的高级特性
ServiceHost 实现的 ICommunicationObject 接口定义了一些高级特性，如例 1-4 所示。 如果打开或关闭宿主的操作耗时较长，可以采用异步方式调用 BeginOpen()和 BeginClose()方法。我们可以订阅诸如状态改变或错误发生等宿主事件，通过调用 State 属性查询当前的宿主状态。ServiceHost 类同样实现了 Abort()方法。该方法提供强行退出功能，能够及时中断进程中的所有服务调用，然后关闭宿主。此时，活动的客户端会获得一个异常。
(5).ServiceHost<T>类
ServiceHost<T>类能够改进 WCF 提供的 ServiceHost 类。 ServiceHost<T>简化了构造函数，它不需要传递服务类型作为构造函数的参数，还能够直接处理字符串而不是处理令人生厌的Uri值。在本书余下的内容中，对 Service-Host<T>进行了扩展，增加了一些特性，提高了它的性能。
(6).WAS托管
Windows 激活服务（WAS）是一个系统服务，只适用于 Windows Vista。WAS 是 IIS 7的一部分，但也可以独立地安装与配置。若要使用 WAS 托管 WCF 服务，必须提供一个.svc文件，这与 IIS 托管一样。IIS 与 WAS 的主要区别在于 WAS 并不局限于使用 HTTP，它支持所有可用的 WCF 传输协议、端口与队列。
WAS 提供了大量基于自托管的强大功能，包括应用程序池、回收机制、空闲时间管理（Idle Time Management）、身份管理（Identity Management）以及隔离（Isolation）；宿主进程可以根据情况选择使用这些功能。若需考虑可扩展性，就应该使用 Vista 服务器作为目标机器；如果只有少数客户端，则可以将 Vista 客户机作为服务器。
当然，自托管进程还提供了许多卓越特性，例如进程内宿主、匿名用户环境的处理，同时还为之前介绍的高级宿主特性提供了便捷地编程访问方式。
11.绑定
服务之间的通信方式是多种多样的，有多种可能的通信模式。
包括：同步的请求/应答（Request/Reply）消息，或者异步的“即发即弃（Fire-and-Forget）”消息；双向（Bidirectional）消息；即时消息或队列消息；以及持久（Durable）队列或者可变（Volatile）队列。
传递消息的传输协议包括：HTTP（或 HTTPS）、TCP、P2P（对等网）、IPC（命名管道）以及 MSMQ。
消息编码格式包括：保证互操作性的纯文本编码格式；优化性能的二进制编码格式；提供有效负载的 MTOM（消息传输优化机制，Message Transport Optimization Mechanism）编码格式。
消息的安全保障也有多种策略，包括：不实施任何安全策略；只提供传输层的安全策略；消息层的隐私保护与安全策略。
当然，WCF 还包括多种对客户端认证与授权的安全策略。消息传递（Message Delivery）可能是不可靠的，也可能是可靠的端对端跨越中间方，然后断开连接的方式。消息传递可能按照发送消息的顺序处理，也可能按照接收消息的顺序处理。服务可能需要与其他服务或客户端交互，这些服务或客户端或者只支持基本的 Web 服务协议，或者使用了流行的 WS-*协议，例如WS-Security 或者 WS-Atomic Transaction。服务可能会基于原来的 MSMQ 消息与旧的客户端（Legacy Client）交互，或者限制服务只能与其他的 WCF 服务或客户端交互。
若要计算所有可能的通信模式与交互方式之间的组合，数量可能达到上千万。在这些组合选项中，有的可能是互斥的，有的则彼此约束。显然，客户端与服务必须合理地组合这些选项，才能保证通信的顺畅。对于大多数应用程序而言，管理如此程度的复杂度并无业务价值。然而，一旦因此作出错误决定，就会影响系统的效率与质量，造成严重的后果。 为了简化这些选项，使它们易于管理，WCF 引入了绑定（Binding）技术将这些通信特征组合在一起。一个绑定封装了诸如传输协议、消息编码、通信模式、可靠性、安全性、事务传播以及互操作性等相关选项的集合，使得它们保持一致。理想状态下，我们希望将所有繁杂的基础功能模块从服务代码中解放出来，允许服务只需要关注业务逻辑的实现。绑定使得开发者能够基于不同的基础功能模块使用相同的服务逻辑。
在使用 WCF 提供的绑定时，可以调整绑定的属性，也可以从零开始定制自己的绑定。服务在元数据中发布绑定的选项，由于客户端使用的绑定必须与服务的绑定完全相同，因此客户端能够查询绑定的类型与特定属性。单个服务能够支持各个地址上的多个绑定。
(1).标准绑定
WCF定义了9种标准绑定：
<1>.基本绑定(Basic Binding)
由 BasicHttpBinding 类提供。基本绑定能够将 WCF 服务公开为旧的 ASMX Web 服务，使得旧的客户端能够与新的服务协作。如果客户端使用了基本绑定，那么新的 WCF 客户端就能够与旧的 ASMX 服务协作。
<2>.TCP绑定
由 NetTcpBinding 类提供。TCP 绑定使用 TCP 协议实现在 Intranet 中跨机器的通信。TCP绑定支持多种特性，包括可靠性、事务性、安全性以及 WCF 之间通信的优化。前提是，它要求客户端与服务都必须使用 WCF。
<3>.对等网络
由 NetPeerTcpBinding 类提供。它使用对等网进行传输。对等网允许客户端与服务订阅相同的网格（Grid），实现广播消息。因为对等网需要网格拓扑（Grid Topology）与网状计算策略（Mesh Computing Strategies）方面的知识，故而不在本书讨论范围之内。
<4>.IPC绑定
由 NetNamedPipeBinding 类提供。它使用命名管道为同一机器的通信进行传输。这种绑定方式最安全，因为它不能接收来自机器外部的调用。IPC 绑定支持的特性与 TCP 绑定相似。
<5>.WS Web 服务（WS）绑定
由 WSHttpBinding 类提供。WS 绑定使用 HTTP 或 HTTPS 进行传输，为基于 Internet 的通信提供了诸如可靠性、事务性与安全性等特性。
<6>.WS 联邦绑定（Federated WS Binding）
由 WSFederationHttpBinding 类提供。WS 联邦绑定是一种特殊的 WS 绑定，提供对联安全（Federated Security）的支持。联邦安全不在本书讨论范围之内。 <7>.WS双向绑定(Duplex WS Binding)
由 WSDualHttpBinding 类提供。WS 双向绑定与 WS 绑定相似，但它还支持从服务到客户端的双向通信，相关内容在第 5 章介绍。
<8>.MSMQ绑定
由 NetMsmqBinding 类提供。它使用 MSMQ 进行传输，用以提供对断开的队列调用的支持。相关内容在第 9 章介绍。
<9>.MSMQ 集成绑定（MSMQ Integration Binding）
由 MsmqIntegrationBinding 类提供。它实现了 WCF 消息与 MSMQ 消息之间的转换，用以支持与旧的 MSMQ 客户端之间的互操作。MSMQ 集成绑定不在本书讨论范围之内。
(2).格式与编码
每种标准绑定使用的传输协议与编码格式都不相同，如表 1-1 所示。 表 1-1：标准绑定的传输协议与编码格式（默认的编码格式为黑体） 文本编码格式允许 WCF 服务（或客户端）能够通过 HTTP 协议与其他服务（或客户端）通信，而不用考虑它使用的技术。二进制编码格式通过 TCP 或 IPC 协议通信，它所获得的最佳性能是以牺牲互操作性为代价的，它只支持 WCF 到 WCF 的通信。
(3).选择绑定
为服务选择绑定应该遵循图 1-4 所示的决策活动图表。 首先需要确认服务是否需要与非 WCF 的客户端交互。如果是，同时客户端又是旧的 MSMQ客户端，选择 MsmqIntegrationBinding 绑定就能够使得服务通过 MSMQ 与该客户端实现互操作。如果服务需要与非 WCF 客户端交互，并且该客户端期望调用基本的 Web 服务协议（ASMX Web 服务），那么选择 BasicHttpBinding 绑定就能够模拟 ASMX Web 服务（即 WSI-Basic Profile）公开 WCF 服务。缺点是我们无法使用大多数最新的 WS-*协议的优势。但是，如果非 WCF 客户端能够识别这些标准，就应该选择其中一种 WS 绑定，例如 WSHttpBinding、WSFederationBinding 或者 WSDualHttpBinding。
如果假定客户端为 WCF 客户端，同时需要支持脱机或断开状态下的交互，则可以选择NetMsmqBinding 使用 MSMQ 传输消息。如果客户端需要联机通信，但是需要跨机器边界调用，则应该选择 NetTcpBinding 通过 TCP 协议进行通信。如果相同机器上的客户端同时又是服务，选择 NetNamePipeBinding 使用命名管道可以使性能达到最优化。如果基于额外的标准，例如回调（选择 WSDualHttpBinding）或者联邦安全（选择WSFederationBinding），则应对选择的绑定进行微调。 注意：即使超出了使用的目标场景，大多数绑定工作仍然良好。例如，我们可以使用 TCP绑定实现相同机器甚至进程内的通信；我们也可以使用基本绑定实现 Intranet 中 WCF 对WCF 的通信。然而，我们还是应尽量按照图 1-4 选择绑定。
(4).使用绑定
每种绑定都提供了多种可配置的属性。绑定有三种工作模式。如果内建绑定符合开发者的需求，就可以直接使用它们。我们也可以对绑定的某些属性如事务传播、可靠性和安全性进行调整与配置，还可以定制自己的绑定。最常见的情况是使用已有的绑定，然后只对绑定的几个方面进行配置。应用程序开发者几乎不需要编写定制绑定，但这却是框架开发者可能需要做的工作。
（显得很枯燥，但是对于分布式应用很庞大，掌握是需要时间的，学习要循序渐进！痛苦并幸福着！）