WCF使用总结

前言&简介

一、回顾开发历史：

软件架构的设计经历了：从面向对象程序，到面向组件程序设计，再到面向服务程序设计。这三种方式都致力于同一个目标：封装和重用。

面向对象程序设计：类封装功能并提供代码重用。

面向组件程序设计：用以共享封装了可重用类的二进制文档。最初，这一点只是针对本机，随着COM,DCOM和.NET Remoting的问世，才发展到分布式环境。虽然这些分布式的方法不尽相同，但是都可以实现跨进程、跨机器。面向组件程序设计有很多局限性，最明显的局限是与一些特定技术的耦合过深。例如：JAVA客户端如何调用COM组件,.NET如何调用EJB，这些局限的产生均是协议和通信格式的问题。

面向服务（SOA）：解决了不同客户之间的通信，也就是不必担心彼此采用了不同的技术。

二、什么是WCF服务

WCF简介：即Windows Communication Foundation(Windows通信基础)的简称，是使用托管代码建立和运行面向服务（ServiceOriented）应用程序的统一框架。是微软分布式应用程序开发的集大成者，它整合了.Net平台下所有的和分布式系统有关的技术，如EnterpriseSevices(COM+).NetRemoting、WebService(ASMX)、WSE3.0和MSMQ消息队列。以通信(Communiation)范围而论，它可以跨进程、跨机器、跨子网、企业网乃至于Internet；以宿主程序而论，可以以ASP.NET，EXE，WPF，WindowsForms，NTService，COM+作为宿主(Host)。WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义，安全模式则包括SAML，Kerberos，X509，用户/密码，自定义等多种标准与模式。也就是说，在WCF框架下，开发基于SOA的分布式系统变得容易了，微软将所有与此相关的技术要素都包含在内，掌握了WCF，就相当于掌握了叩开SOA大门的钥匙。

WCF的优势：

1、统一性：WCF是对于.NET Remoting，Enterprise Service，MSMQ等技术的整合。
2、互操作性：由于WCF最基本的通信机制是SOAP协议，这就保证了系统之间的互操作性，即使是运行不同的上下文中。可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web Service。应用程序可以运行在Windows操作系统下，也可以运行在其他的操作系统。
3、兼容性：WCF充分的考虑到了与旧有系统的兼容性。安装WCF服务并不会影响原有的技术。
4、高效开发：维护性、操作性、生产效率提升，开发环境的无缝集成。

三、WebService和WCF的到底有什么区别

1、微软的Web服务实现称为ASP.NETWebService.它使用Soap简单对象访问协议来实现分布式环境里应用程序之间的数据交互。WSDL来实现服务接口相关的描述。后来微软做了ASP.NETWebService的安全，性能，数据加密、解密，托管宿主等多方面的扩展，称为WSE系列，这个是过度产品，最高到WSE3.0.后来就是WCF时代。

2、WCF其实一定程度上就是ASP.NET Web Service，因为它支持WebService的行业标准和核心协议，因此ASP.NETWebService和WSE能做的事情，它几乎都能胜任，跨平台和语言更不是问题（数据也支持XML格式化，而且提供了自己的格式化器）。

3、WCF 能够创建兼容 Web 服务的服务，也就是说可以创建能够与Web 服务互联互通的服务，他们两个并不能用简单包含或者等同关系来表述。WCF 是一套框架，用来创建各种服务。其中包括创建 Web服务（采用 basicHttpBinding绑定的服务就是一个Web 服务）。

四、WCF特性

WCF可以不依赖于IIS。
WCF可以配置成BasicHttpBinding来兼容（或者说变身成）WS。
WCF可以基于TCP或者MessegeQueue来传输数据。
WCF的可配置性比WS强，比如安全性。
WCF可以是有状态的，并支持事务。
WCF 支持多种通信协议 Http/Https 、TCP/UDP、MSMQ、命名管道、对等网、消息可达性、事务流等。
WCF 可以与ASP.NET 集成、共享一个上下文（HttpContext）。
WCF 支持多种消息传输格式 :text,binary,mtom,Json 等。
WCF 安全性要强：支持对称安全、非对称安全、消息安全、传输安全、SSL 流安全、Windows 流安全等。

新建WCF服务

1、WCF采用基于契约的交互方式实现了服务的自制。服务契约：是相关操作的集合。契约就是双方或多方就某个关注点达成的一种共识，是一方向另一方的一种承诺。签署了某个契约就意味着自己有义务履行契约中的各项规定，一旦违约势必影响契约双方的正常交互。我们主张通过抽象将接口和实现相互分离，鼓励接口的依赖，避免基于实现的依赖。接口是稳定的，而实现则是易变的，基于接口的服务调用能够更有效地应对实现的变化带来的影响。接口从本质上讲就是一种契约，当某个类实现了某个接口，就相对于签署了一份契约。所以契约关心的是“我能做到”，不在于“我如何做到”。所以，服务契约是以接口的形式进行定义的。

2、下面的代码中，定义了一个接口，通过在接口上应用System.ServiceModel命名空间下的ServiceContract Attribute特性将ICalculateService接口定义成服务契约。在应用ServiceContract  Attribute特性的同时，还可以指定服务契约的名称和命名空间。每个服务契约都有一个确定的名称，当在一个接口上应用了该属性以后，默认的名称就是接口的名称。我们可以通过Name属性显示地指定需要的名称，如：[ServiceContract(Name = "CalculateService")]。
NameSpace:服务契约的命名空间，其作用是解决命名冲突的问题，提倡将你所在的公司名称或项目名称的URN作为命名空间。WCF默认的命名空间是:http://tempuri.org/。

3、服务契约是一组相关服务操作的集合，当我们在一个接口上应用了ServiceContract Attribute，便赋予了服务契约的属性。但是，对于这样一个类型，它的成语并不会自动成为契约的服务操作，只有应用了OperationContract Attribute特性后，相应的方法成员才能成为能够通过服务调用方式访问的服务操作。

定义宿主寄宿WCF服务

WCF服务不能孤立地存在，必须要寄宿于一个运行着的进程中，我们把承载WCF服务的进程称为宿主，为服务指定宿主的过程称为服务寄宿（Service Hosting）。服务寄宿的目的就是开启一个进程，为WCF服务提供一个运行的环境。WCF服务典型的宿主包括以下四种：
"Self-Hosting" in a Managed Application（自托管宿主）
Managed Windows Services（Windows Services宿主）
Internet Information Services（IIS宿主）
Windows Process Activation Service（WAS宿主）

1、以自托管宿主的方式寄宿。

1.1 通过代码的方式配置WCF服务

利用WCF提供的ServiceHost<T>提供的Open()和Close()方法，可以便于开发者在控制台、Windows应用程序乃自于ASP.NET应用程序中托管服务，不管自宿主的环境是何种应用程序，实质上托管服务的方式都是一致的。例如在控制台应用程序中：

 

WCF服务寄宿通过一个特殊的对象完成：ServiceHost。在上面的例子中，基于WCF服务的类型(typeof(CalculateService))创建了ServiceHost对象，并添加了一个终结点，终结点地址为http://127.0.0.1:9099/CalculateWcfService,采用了BasicHttpBinding的绑定方式，并指定了服务契约的类型ICalculateService。

由于ServiceHost实例是被创建在应用程序域中，因此我们必须保证宿主进程在调用服务期间不会被关闭，因此我们利用Console.Read()来阻塞进程，以使得控制台应用程序能够一直运行，直到认为地关闭应用程序。如果是Windows应用程序，则可以将创建ServiceHost实例的代码放在主窗体的相关代码中，保证服务宿主不会被关闭。

在通常的企业应用中，我们很少会采用自宿主方式托管服务，这是因为这种方式必须要在应用程序运行下，客户端才能够调用服务，且并不便于随时启动和停止服务。除了不具有易用性与易管理性之外，在可靠性、性能等诸多方面受到很多限制。但由于它简单、易于实现，因而往往用于开发期间的调试或演示环境。

注意：自托管宿主支持所有的绑定。

1.2 通过配置文件的方式配置WCF服务

在进行真正的WCF应用开发时，一般不会直接通过编码的方式进行终结点的添加和服务行为的定义，而是通过配置文件的方式进行。

配置文件基本结构如下图所示：

 

WCF的配置文件共分为两部分：服务端配置与客户端配置。两者由于功能的不同，在配置文件的使用上也略有不同。

1.2.1 WCF的服务端配置

服务端的配置文件主要包括endpoint、binding、behavior的配置。一个标准的服务端配置文件所包含的主要xml配置节如下所示：
<system.ServiceModel>
   <services>
      <service>
         <endpoint/>
      </service>
   </services>

   <bindings>
   <!—定义一个或多个系统提供的binding元素，例如<basicHttpBinding> -->
   <!—也可以是自定义的binding元素，如<customBinding>. -->
      <binding>
      <!—例如<BasicHttpBinding>元素. -->
      </binding>
   </bindings>

   <behaviors>
   <!—一个或多个系统提供的behavior元素. -->
      <behavior>
      <!—例如<throttling>元素. -->
      </behavior>
   </behaviors>

</system.ServiceModel>

1.2.1.1 <services>配置节点

在<services>配置节中可以定义多个服务，每一个服务都被放到<service>配置节中，WCF的宿主程序可以通过配置文件找到这些定义的服务并发布这些服务。

<service>配置节包含name和behaviorConfiguration属性。其中，name配置了实现Service Contract的类型名。类型名必须是完整地包含了命名空间和类型名。而behaviorConfiguration的配置值则与其后的<behaviors>配置节的内容有关。<endpoint>是<service>配置节的主体，其中，<endpoint>配置节包含了endpoint的三个组成部分：Address、Binding和Contract。由于具体的binding配置是在<bindings>配置节中完成，因而，在<endpoint>中配置了bindingConfiguration属性，指向具体的binding配置。如下所示：
<services>
  <service name="CalculateWcfService.CalculateService" behaviorConfiguration="MyBehavior">
    <endpoint address=""
             binding="netTcpBinding"
             bindingConfiguration="DuplexBinding"
             contract="CalculateWcfService.ICalculateService" />
  </service>
</services>

1.2.1.2 <Endpoint>配置节点

终结点由地址（Address）、绑定（Binding）和契约（Contract）三要素组成。由于三要素应为首字母分别为ABC，所以终结点一般简称为ABC。

address:指定服务的统一资源标识符(URI)，它可以是一个绝对地址或者是一个相对于服务基址给定的地址。如果设置为空字符串，则表示在创建服务的ServiceHost时，终结点在指定的基址上可用。
binding:通常，指定一个类似WsHttpBinding的系统提供的绑定，但也可以指定一个用户定义的绑定。指定的绑定确定传输协议类型、安全和使用的编码，以及是否支持或启用可靠会话、事务或流。
bindingConfiguration:如果必须修改绑定的默认值，则可通过在bindings元素中配置相应的binding元素来执行此操作 此属性应赋予与用于更改默认值的binding 元素的name 属性相同的值。
contract:指定定义协定的接口。 这是在由service 元素的name 属性指定的公共语言运行库(CLR) 类型中实现的接口。

我们也可以在一个<service>节点中定义多个endpoint，例如：
<services>
  <service
      name="Microsoft.ServiceModel.Samples.CalculatorService"
      behaviorConfiguration="CalculatorServiceBehavior">
    <endpoint address=""
             binding="wsHttpBinding"
             contract="Microsoft.ServiceModel.Samples.ICalculator" />
    <endpoint address="mex"
             binding="mexHttpBinding"
             contract=" Microsoft.ServiceModel.Samples.IMetadataExchange" />
  </service>
</services>

如果address值为空，那么endpoint的地址就是默认的基地址（Base Address）。例如ICalculator服务的地址就是http://localhost/servicemodelsamples/service.svc，而IMetadataExchange服务的地址则为http://localhost/servicemodelsamples/service.svc/mex。这里所谓的基地址可以在<service>中通过配置<host>来定义：
<service
      name="Microsoft.ServiceModel.Samples.CalculatorService"
      behaviorConfiguration="CalculatorServiceBehavior">
<host>
    <baseAddresses>
        <add baseAddress=
"http://localhost/ServiceModelSamples/service.svc"/>
    </baseAddresses>
</host>
<endpoint … />
</service>

1.2.1.3 <behaviors>配置节点

    当我们在定义一个实现了Service Contract的类时， binding和address信息是客户端必须知道的，否则无法调用该服务。然而，如果需要指定服务在执行方面的相关特性时，就必须定义服务的behavior。在WCF中，定义behavior就可以设置服务的运行时属性，甚至于通过自定义behavior插入一些自定义类型。例如通过指定ServiceMetadataBehavior，可以使WCF服务对外公布Metadata。配置如下：
<behaviors>
    <serviceBehaviors>
    <behavior name="metadataSupport">
      <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>
    </behavior>
    <serviceBehaviors>
<behaviors>

在WCF中，behavior被定义为Attribute，其中，System.ServiceModel.ServiceBehaviorAttribute和System.ServiceModel.OperationBehaviorAttribute是最常用的behavior。虽然，behavior作为Attribute可以通过编程的方式直接施加到服务上，但出于灵活性的考虑，将behavior定义到配置文件中才是最好的设计方式。
利用ServiceBehavior与OperationBehavior可以控制服务的如下属性：
1、 对象实例的生命周期；
2、 并发与异步处理；
3、 配置行为；
4、 事务行为；
5、 序列化行为；
6、 元数据转换；
7、 会话的生命周期；
8、 地址过滤以及消息头的处理；
9、 模拟（Impersonation）；

例如，通过ServiceBehavior设置对象实例的生命周期：
<behaviors>
    <serviceBehaviors>
    <behavior name="metadataSupport">
      <instanceContextMode httpGetEnabled="true" httpGetUrl=""/>
    </behavior>
    <serviceBehaviors>
<behaviors>

除了直接手动修改配置文件以外，还可以直接使用VS提供的配置工具。可以通过VS的工具（Tools）菜单，选择“WCF 服务配置编辑”子项，开启这样的一个配置编辑器

或者在配置文件上直接点右键，选择“编辑WCF配置”打开WCF配置编辑器，如下图所示：

如果采用了配置文件的方式，服务寄宿代码将会得到极大的精简，只需包含下面几行代码：

 

 

 

 

自己写的Gsoap与Wcf互为服务端和客户端心得

1、本解决方案要实现Gsoap与Wcf互为服务端和客户端，这时在写gsoap作为服务端的工程时定义的.h接口文件必须加上命名空间，否则用soapcpp2.exe工具生成的服务端框架代码会与用WCF做服务端，gsoap做WCF客户端时用soapcpp2.exe工具生成的客户端代码的文件名相同从而导致无法将两部分文件加入到同一解决方案中。

 

 

WCF使用注意事项

1、创建C#的控制台应用程序然后添加WCF服务与直接新建WCF服务应用程序有什么区别？（自己是通过前者来完成）

2、wcf与wcf通信连wsdl文件都不需要，可谓是非常的方便。

3、一个宿主提供多个WCF服务，当多个服务端发出请求的时候会不会出现问题。

 

注：
由于笔者水平有限，若博文中存在错误或不周之处，还望各位大牛多多指教，有新的经验的时候也会及时更新本博文，谢谢！
本篇博文为自己学习过程的心得笔记，如有内容雷同，还请见谅，谢谢！