WCF读书笔记（3）

绑定

基本绑定：由BasicHttpBinding类提供

TCP绑定：由NetTcpBinding类提供

其他还有几种不常用的

终结点

　　服务于地址、绑定以及契约有关。地址定义了服务的位置，绑定定义了服务通信的方式，契约则定义了服务的内容。总结点就是地址、契约与绑定的混成品。

◆WCF总结点是真正意义上的接口，因为它包含了一个对象的接口所需的全部信息。WCF中，地址与绑定并非与生俱来的，需要进行配置。

可靠性：WCF与其他面向服务技术之间最大的区别在于传输可靠性与消息可靠性。传输可靠性在网络数据包层提供了点对点保证传递，以确保数据包的顺序无误。消息可靠性负责处理消息层的可靠性，它与传递消息的数据包数量无关，消息可靠性提供了端对端保证传递，确保消息的顺序无误。

WCF服务必须依存一个运行着的进程（宿主），服务寄宿就是为服务指定一个宿主的过程。

WCF是一个基于消息的通信框架，采用基于终结点的通信手段。

总结点(Endpoint)=ABC(Address,Binding,Contract)组成，即地址、绑定、契约

地址：决定了服务的位置，解决了服务寻址的问题。

绑定：实现了通信的所有细节，包括网络传输、消息编码，以及其他为实现某种功能对消息进行的相应处理

契约：服务操作的抽象，也是对消息交换模式及消息结构的定义。

松耦合是SOA的一个基本特征，WCF应用中客户端和服务端的松耦合体现在客户端只须要了解WCF服务基本的描述，而无需知道具体的实现细节，就可以实现正常的服务调用。

WCF：在Windows 平台下解决通信的基础框架。

终结点（地址、绑定、契约），真正意义上的接口，包括了交互所需要的一切。

终结点的通信功能：服务提供者通过一个或多个终结点发布给潜在的服务消费者，服务消费者则通过与之匹配的终结点对服务进行消费。

地址在通信中的作用

定位服务的位置？（是服务提供者的地址还是服务消费者的地址）（对应终结点的URI属性）

提供寻址（Addressing）的辅助信息？？？？（对应终结点的Headers属性）

表示服务的真实身份？？？？（对应终结点的Identity属性）

地址的三个作用对应终结点的三个属性

URI

可能是部署服务真正的物理地址，也可能是逻辑地址。

URI的传输协议：

HTTP\TCP\ICP（同一台机器上的不同进程间通信采用的传输协议）\ MSMQ

物理地址：服务真正被部署的地址

逻辑地址：我们自己指定的地址（有些情况下，服务的真实地址是私有地址或者动态地址时，这时我们必须将服务的地址指定成一个固定的共有地址，在真正需要进行消息交换时，再通过消息交换的时候，再通过一些路由机制将消息发送到真正的目标地址）

AddressHeader

　　服务提供者与服务消费者之间一般是通过基于SOAP的消息进行通信（也有REST/POX），而soap是自描述的实体，由消息主体(Body)（服务的内容）和若干报头(Header)（存放控制信息）组成。

         对于物理地址与逻辑地址不一样时，往往需要手工寻址的方式进行消息的发送、接收、处理和转发。终结点的AddressHeader就是为此设计的；并且它可以在服务端用来进行基于终结点地址的消息筛选功能。

EndpointIdentity

应用与分布式应用环境中的身份验证或识别。（暂时不需深入了解）

如何指定地址呢？

　　首先，在服务端：如果是本地寄宿，可以通过编程添加终结点（一个或多个）从而来指定地址，也可以通过配置来添加终结点来指定地址，要注意一点，一般来说，监听地址和终结点地址是统一的，当终结点的物理地址和逻辑地址不统一时，需指定不同于终结点地址的的监听地址。如果是通过IIS寄宿，则服务地址就是.svc文件，无需配置终结点地址。

         当地址是用相对地址方式给定时，由于基地址和本地地址的匹配关系是根据绑定对象采用的传输协议确定的，所以对于一个确定的传输协议，最多只能有一个基地址。

地址的跨终结点共享问题：

         若给一个服务（一个服务只实现唯一一个契约的情况）指定了若干个终结点，由于这些终结点都共享一个服务契约，因此，这些终结点的地址是不能共享的，它们所对应的地址必须不同。但是对一个服务实现了多个契约的情况，若干个终结点可以共享相同的绑定和地址。

绑定对象的根本功能是提供基于通信的实现，WCF系统通过绑定对象构建一个信道栈创建了一座通信的桥梁。

在客户调用服务端，一般来说客户端的终结点地址由自动生成的代理类负责，当然也可以通过ChannelFactory<TChannel>（代理基类的一个Channel属性）来制定，当然自动生成的代理类实际上也是通过调用代理基类实现的。

　　如果说地址是服务被部署和被调用的地方，那AddressHeader就是用来控制识别服务端与客户端交换soap消息时的寻址、安全凭证等问题的。这首先也要对WCF的消息交换做一个了解，WCF 是一个基于消息的通信框架，具有一个消息处理的管道，消息流到该管道不通的位置，需对消息做不同的处理，因此对于基于消息的通信方式来说，首要的便是寻址问题，一般来说寻址问题都是用AddressHeader 来进行解决，类似数据包前面的控制信息。

同样，我们可以通过编程或配置的方式来指定这些控制信息——AddressHeader。使用时，服务端和客户端的控制信息必须完全匹配，才能进行通信、也就是信息交换。

端口共享问题帮我们更好的了解进程之间的通信问题和WCF的通信问题。

　　在基于TCP/IP的对等网络通信下，相互通信的应用程序运行于各自的应用进程中，处于应用层的进程将数据封装成数据包，并通过传输层的TCP/UDP进行网络通信，而TCP/UDP则通过一个16位的端口来识别不同的应用程序。

对于WCF来讲，当我们将某个服务寄宿于一个进程中，实际上就是通过该进程监听和处理客户端的Socket请求。

WCF的寻址：

　　服务提供者与服务消费者类似于服务器客户端模式，从面向服务的观点（SOA），任何向外界提供某项独立功能的对象都可以称为服务。

消息筛选问题：

服务，信道分发器与终结点分发器的关系：

服务（服务提供者）——》信道分发器（真正的监听地址，即物理地址）——》终结点分发器（提供给服务消费者的终结点）

         信道分发器类似于中介，负责接收服务消费者的请求消息并转发给对应的服务提供者，或者将服务终结点通过筛选分发各个对应的服务消费者。

         信道分发器的存在很大一部分是由于逻辑地址和物理地址的存在，当不指定监听地址（物理地址）时，监听地址与逻辑地址相同；而逻辑地址就是我们用代码或配置指定的地址。

         消息筛选则是解决信道分发器到终结点分发器的路由选择问题，也就是解决提供给服务消费者的终结点选择确定。信道分发器负责进行请求监听（监听请求信息，也就是利用监听地址监听客户端的请求信息）和消息接收（接收客户端的请求信息），而终结点分发器完成最后对消息的处理。消息筛选就是对接收到的请求消息，通过遍历存储在自身的终结点分发器属性，匹配后发往真正的目标终结点（就是服务暴露给客户端调用的终结点）。

服务终结点就是服务端，也是我们熟悉的客户服务器模式中的服务器端。