WCF系统之WCF应用的通信过程

一、概述

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

WCF与其他分布式技术对比表

二、WCF中的 "A","B","C" 介绍

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

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

(1)我们首先要知道对方公司的地址,引出WCF中的"A"。

A(Address):英文理解为"地址",在计算机中是通过一个URI唯一地址标识,通过这个地址我们可以找到我们要调用的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服务的是Web应用程序。今天这个小节主要以介绍WCF中传输的配置为主,我们把上一节的内容稍做改动,以体现出"Endpoint"与"A、B、C"。

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

客户端Web.config:

<?xml version="1.0" encoding="utf-8"?>

<!--
  有关如何配置 ASP.NET 应用程序的详细消息,请访问
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->

<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.0" />
    </system.web>

    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IUser" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost/User.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IUser" contract="WCFService.IUser"
                name="BasicHttpBinding_IUser" />
        </client>
    </system.serviceModel>
</configuration>

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

服务端Web.config代码:

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- 为避免泄漏元数据信息,请在部署前将以下值设置为 false 并删除上面的元数据终结点 -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- 要接收故障异常详细信息以进行调试,请将以下值设置为 true。在部署前设置为 false 以避免泄漏异常信息 -->
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
 <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>

</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。

六、总结

这节教程主要描述了应用程序间的通信过程,Endpoint和ABC非常重要,也比较好理解,所以建议尽量的熟练。

七、版权

转载请注明出处:http://www.cnblogs.com/iamlilinfeng

时间: 2024-10-12 17:12:04

WCF系统之WCF应用的通信过程的相关文章

【转】WCF入门教程二[WCF应用的通信过程]

一.概述 WCF能够建立一个跨平台的安全.可信赖.事务性的解决方案,是一个WebService,.Net Remoting,Enterprise Service,WSE,MSMQ的并集,有一副很经典的对比图如下: WCF与其他分布式技术对比表 二.WCF中的 "A","B","C" 介绍 我们先看个生活中的例子,某一天,公司的领导让你去送一份合同文件,送文件的过程你可以选择的交通方式为"打车"."公交".&

二、WCF应用的通信过程

注:本文为学习摘抄,原文地址:http://www.cnblogs.com/iamlilinfeng/archive/2012/09/26/2703759.html 一.概述 WCF能够建立一个跨平台的安全.可信赖.事务性的解决方案,是一个WebService,.Net Remoting,Enterprise Service,WSE,MSMQ的并集,有一副很经典的对比图如下: WCF与其他分布式技术对比表 二.WCF中的 "A","B","C"

WCF入门教程二[WCF应用的通信过程]

一.概述 WCF能够建立一个跨平台的安全.可信赖.事务性的解决方案,是一个WebService,.Net Remoting,Enterprise Service,WSE,MSMQ的并集,有一副很经典的对比图如下: WCF与其他分布式技术对比表 二.WCF中的 "A","B","C" 介绍 我们先看个生活中的例子,某一天,公司的领导让你去送一份合同文件,送文件的过程你可以选择的交通方式为“打车”.“公交”.“地铁”,当然费用是根据发票来报销的,到了

无废话WCF入门教程二[WCF应用的通信过程]

一.概述 WCF能够建立一个跨平台的安全.可信赖.事务性的解决方案,是一个WebService,.Net Remoting,Enterprise Service,WSE,MSMQ的并集,有一副很经典的对比图如下: WCF与其他分布式技术对比表 二.WCF中的 "A","B","C" 介绍 我们先看个生活中的例子,某一天,公司的领导让你去送一份合同文件,送文件的过程你可以选择的交通方式为“打车”.“公交”.“地铁”,当然费用是根据发票来报销的,到了

WCF通信过程

无废话WCF入门教程二[WCF应用的通信过程] 一.概述 WCF能够建立一个跨平台的安全.可信赖.事务性的解决方案,是一个WebService,.Net Remoting,Enterprise Service,WSE,MSMQ的并集,有一副很经典的对比图如下: WCF与其他分布式技术对比表 二.WCF中的 "A","B","C" 介绍 我们先看个生活中的例子,某一天,公司的领导让你去送一份合同文件,送文件的过程你可以选择的交通方式为“打车”.“公

[老老实实学WCF] 第五篇 再探通信--ClientBase

原文:[老老实实学WCF] 第五篇 再探通信--ClientBase 老老实实学WCF 第五篇 再探通信--ClientBase 在上一篇中,我们抛开了服务引用和元数据交换,在客户端中手动添加了元数据代码,并利用通道工厂ChannelFactory<>类创建了通道,实现了和服务端的通信.然而,与服务端通信的编程模型不只一种,今天我们来学习利用另外一个服务类ClientBase<>来完成同样的工作,了解了这个类的使用方法,我们对服务引用中的关键部分就能够理解了. ClientBase

WCF系列之WCF的通信模式

一.概述 WCF在通信过程中有三种模式:请求与答复.单向.双工通信.以下我们一一介绍. 二.请求与答复模式 描述: 客户端发送请求,然后一直等待服务端的响应(异步调用除外),期间处于假死状态,直到服务端有了答复后才能继续执行其他程序,如下图所示(图中的粗红线在此时代表顺序并不代表调用): 请求与答复模式为WCF的默认模式,如下代码所示: [OperationContract] string ShowName(string name); 即使返回值是void 也属于请求与答复模式. 缺点:如果用W

WCF入门教程[WCF基本应用]

一.概述 Windows Communication Foundation(WCF)是由微软发展的一组数据通信的应用程序开发接口,可以翻译为Windows通讯接口,它是.NET框架的一部分.由 .NET Framework 3.0 开始引入. WCF的最终目标是通过进程或不同的系统.通过本地网络或是通过Internet收发客户和服务之间的消息. WCF合并了Web服务..net Remoting.消息队列和Enterprise Services的功能并集成在Visual Studio中. WCF

WCF系列之WCF宿主

一.WCF服务应用程序与WCF服务库 我们在平时开发的过程中常用的项目类型有"WCF 服务应用程序"和"WCF服务库". WCF服务应用程序,是一个可以执行的程序,它有独立的进程,WCF服务类契约的定义,可以直接看到运行的效果.此项目模板基于IIS托管的程序,如本系列的第一节所示.在开发基于IIS托管的WCF服务程序时,比较多见,自学的时候也可以使用这种类型,简单易懂. WCF服务库,可以认为是一个包含WCF服务以及契约定义的类库.不能直接运行,你可以在其他项目里引