WCF服务端运行时架构体系详解[上篇]

WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的，所以我们有必要在对服务描述进行简单的介绍。

目录：一、从服务描述（Service Description）谈起二、服务端架构体系概览三、终结点分发器选择机制

一、从服务描述（Service Description）谈起

当ServiceHost在被实例化的过程中，用于描述整个服务的ServiceDescription对象被创建出来。对于一个服务来说，它的核心包括：一组终结点列表和一组服务行为列表。这可以通过如下所示的ServiceDescription的定义看出来。

   1:publicclassServiceDescription

2:{

   3:     //其他成员

   4:     publicKeyedByTypeCollection<IServiceBehavior> Behaviors { get; }

   5:     publicServiceEndpointCollection Endpoints { get; }

6:}

而对于终结点来说，对于它的ABC三要素，即地址（Address）、绑定（Binding）和契约（Contract）早已了然于胸了。所以用于描述终结点的ServiceEndpoint类型具有Address、Binding和Contract三个核心属性。此外还有基于该终结点的行为列表，通过Behaviors属性表示。ServiceEndpoint的定义如下所示。

   1:publicclassServiceEndpoint

2:{

   3:     //其他成员

   4:     publicEndpointAddress Address { get; set; }

   5:     publicBinding Binding { get; set; }

   6:     publicContractDescription Contract { get; }

   7:     publicKeyedByTypeCollection<IEndpointBehavior> Behaviors { get; }

8:}

现在我们进一步分析用以描述服务契约的ContractDescription类型。由于服务契约本质上是一组相关操作的组合，所以ContractDescription的核心属性是如下所示的表示所有操作描述的Operations属性。除了操作描述列表之外，自然还有基于服务契约本身的行为列表。

   1:publicclassContractDescription

2:{

   3:     //其他成员

   4:     publicOperationDescriptionCollection Operations { get; }

   5:     publicKeyedByTypeCollection<IContractBehavior> Behaviors { get; }

6:}

至于对服务操作的描述，对应的类型为OperationDescription。OperationDescription中定义了一系列基于服务操作的属性，它们以及在之前的章节有过详细的介绍了，在这里我们主要关注的是用以表示操作行为列表的属性Behaviors。

   1:publicclassOperationDescription

2:{

   3:     //其他成员

   4:     publicKeyedByTypeCollection<IOperationBehavior> Behaviors { get; }

5:}

上述从服务ServiceDescription到ServiceEndpoint，从ServiceEndpoint到ContractDescription，最终到OperationDescription的层次结构基本上可以通过下图来表示。

clip_image002

在构建ServiceHost过程中创建的用于描述整个服务的ServiceDescription对象，最终成为了构建服务端运行时架构体系的基础。而该架构体系在ServiceHost开启的过程中被构建出来，这也是为什么在ServiceHost开启之后对服务描述所作的任何该表都是无效的根本原因。

二、服务端架构体系概览

为了让读者对服务端运行时架构体系的结构具有更加深刻的认识，我们针对一个具体的服务寄宿应用场景来进行介绍。假设我们采用如下的配置对服务CalculatorService进行寄宿。通过这段配置，三个基于WSHttpBinding的终结点被添加。

   1:<configuration>

   2:   <system.serviceModel>

   3:     <services>

   4:       <servicename="Artech.WcfServices.CalculatorService">

   5:         <endpointaddress      = "http://127.0.0.1:7777/CalculatorService"

   6:                   binding      = "wsHttpBinding"

   7:                   contract     = "Artech.WcfServices.ICalculator"

   8:                   listenUri    = "http://127.0.0.1:6666/CalculatorService"

   9:                   listenUriMode= "Explicit"/>

  10:         <endpointaddress      = "http://127.0.0.1:8888/CalculatorService"

  11:                   binding      = "wsHttpBinding"

  12:                   contract     = "Artech.WcfServices.ICalculator"

  13:                   listenUri    = "http://127.0.0.1:6666/CalculatorService"

  14:                   listenUriMode= "Explicit"/>

  15:         <endpointaddress      = "http://127.0.0.1:9999/CalculatorService"

  16:                   binding      =  "wsHttpBinding"

  17:                   contract     = "Artech.WcfServices.ICalculator"

  18:                   listenUri    = "http://127.0.0.1:6666/CalculatorService"

  19:                   listenUriMode= "Unique"/>

  20:       </service>

  21:     </services>

  22:   </system.serviceModel>

  23:</configuration>

如上面的配置片断所示，虽然这三个终结点具有不同的地址，但是它们却使用了相同的监听URI（通过listenUri属性设置）。进一步地，虽然三个终结点具有相同的监听U

补充：Web开发 , ASP.Net ,