WCF入门教程(二)

一、概念

WCF能够建立一个跨平台的安全、可信赖、事务性的解决方案，是一个WebService，.Net Remoting，Enterprise Service，WSE，MSMQ的并集，有一副很经典的对比图如下：

二、WCF中的 “A”,“B”,“C”

生活中的例子，某一天，公司的领导让你去送一份合同文件，送文件的过程你可以选择的交通方式为“打车”、“公交”、“地铁”，当然费用是根据发票来报销的，到了对方公司后你要找到某经理，并且要一份收到合同文件的回执和相关文件。

要完成这项工作任务我们执行以下几个主要的步骤：

1. 首先要知道对方公司的地址，引出WCF中的"A"。

   A(Address)：英文理解为"地址"，在计算机中是通过一个URL唯一地址标识，通过这个地址我们可以找到我们要调用的WCF服务。

   A解决了：Where to locate the WCF Service？

2. 选择我们的交通方式，每种交通方式达到的结果不一样。如：打车费用较贵、但是过程舒服些，时间上视道路情况而定。公交最便宜，并且可选择多条线路。地铁最方便，但是偶尔会很挤，一般都没座等等，引出WCF中的"B".

   B(Binding)：英文理解为"捆绑，绑定"， Binding实现在Client和Service通信的所有底层细节。如：我们在客户端与服务端传输的时候采用的是什么样的编码，XML？Text？二进制？…采用哪种传输协议进行传输，TCP？Http？以及采用什么样的机制解决安全问题，SSL？加密？…

   B解决了：How to communicate with service？

3. 到了对方公司之后我们能做哪些事？I.送合同，II.拿回执。我们不能要求对方公司给我们其他的东西，引出WCF中的"C"。

   C(Contract)：英文理解为"合同"，合同是什么？告诉我们哪些事能做，哪些事不能做。 Contract的主要的作用是暴露某个WCF Service所提供的所有有效的方法。Contract实际上是把每个方法的转化成为相对应的消息。

   C解决了：What functionalities do the Service provide？

三、Endpoint(终结点)

WCF实现了网络系统的各个应用程序的通信。各个应用程序的通信是以“终结点(Endpoint)”的来实现的。我们在上面讲的实际例子中的A、B、C即是Endpoint 的组成部分，他是服务器间通信调用的入口。

四、应用程序间通信

我们在第二和第三项中讲了A、B、C与Endpoint，现在正式进入应用程序间的通信。我们还是以刚才送合同的过程为例

员工A手里有一张便签，标记着：地址、绑定、合同…而合作方手里也有一张便签，标记着同样的内容，并且一直得在等待员工A的出现。只有当便签上的内容一样时，合作方A才会签署合同回执。

当我们寄宿WCF服务的时候，我们必须定义一个或是多个终结点，然后Serivce端通过监听这些终结点来处理Client发来的请求。由于应用程序之间是靠Endpoint来通信，那么我们在Client端也必须定义终结点，只有当Client与Service的终结点完全匹配的时候才能进行通信。

如上图所示：只有EndpointA中的A、B、C与EndPointB中的A、B、C完全匹配时才能通信。EndPointE与EndpointD也是一样的。

五、实例

之前我们主要使用了IIS做为宿主，客户端调用WCF服务的是Winform应用程序。今天主要以介绍WCF中传输的配置为主，以体现出"Endpoint"与"A、B、C"。

由于之前的案例没有手写任何配置的代码，Client端的App.config与Service端的Web.config都是自动生成的，当我们添加服务引用时,IDE自动将客户端的配置文件中Endpoint与引用的服务的Endpoint匹配了。如下代码所示：

客户端App.config：

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
    </startup>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_ICalcService" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:54544/CalcService.svc" binding="basicHttpBinding"              bindingConfiguration="BasicHttpBinding_ICalcService" contract="ServiceCalc.ICalcService"
                name="BasicHttpBinding_ICalcService" />
        </client>
    </system.serviceModel>
</configuration>

服务端Web.config代码：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.6.1" />
    <httpRuntime targetFramework="4.6.1"/>
  </system.web>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_ICalcService" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:54544/CalcService.svc" binding="basicHttpBinding"              bindingConfiguration="BasicHttpBinding_ICalcService" contract="ServiceCalc.ICalcService"
                name="BasicHttpBinding_ICalcService" />
        </client>
    </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <!--若要在调试过程中浏览 Web 应用程序根目录，请将下面的值设置为 True。在部署之前将该值设置为 False 可避免泄露 Web 应用程序文件夹信息。-->
    <directoryBrowse enabled="true"/>
  </system.webServer>
</configuration>

由上面的两个配置文件我们发现，客户端system.serviceModel节点有我们刚才讲的endpoint，而服务端为什么没有？这不是和我们刚才讲的有违背吗？好吧，我们承认IDE生成的Web.config中endpoint很隐晦。那么我们看下面手工修改后[把对看起来很复杂并且对当前的学习无用的配置节删掉]的配置文件的代码(我将服务端和客户端放在一块了)：

修改之后的服务端Web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.6.1" />
  </system.web>
  <system.serviceModel>
    <services>
      <service name="WCFService">
        <endpoint address="http://localhost:54544/CalcService.svc" binding="basicHttpBinding"              
         contract="ServiceCalc.ICalcService"
         />
      </service>
    </services>
  </system.serviceModel>
</configuration>

发现WCF服务依然执行成功！这次的配置文件够明显了吧，不论是在服务端还是在客户端，endpoint中的A、B、C都是完全一样的。也就是终结点完全匹配！

那么第一次的配置文件为什么能执行呢？答案是我们把WCF寄宿在IIS上，而IIS默认监听的就是Http协议[B确定了]并且地址也是相对于IIS上的文件地址[A确定了]，合同更不用说了，找到User.svc什么都有了[C确定了]，所以在服务端就没有必要显示的写出system.serviceModel，不信你试试，把服务端的配置文件中system.serviceModel节删除，程序一样可以运行！服务器端的endpoint确定了，客户端的endpoint自然要和服务端去对应，所以IDE在生成客户端的配置文件里endpoint写的很详细的，而服务端却没有endpoint。