文本参考自:http://www.cnblogs.com/wangweimutou/p/4365260.html 简介:WCF作为分布式开发的基础框架,在定义服务以及消费服务的客户端时可以通过配置文件的方式,来进行设置,这充分的体现了WCF的伸缩性和自定义性。当然WCF也提供硬编程的方式，通过在代码中直接设置相关对象的属性来完成服务端与客户端的配置，然而这种方式并不利于后期程序的更改和扩展。 一、WCF配置文件结构如下图所示,包含三个部分,services(服务)、bindings(绑定)、behavior
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟。为此我们我们写了一个简单的方法，用于列出一个具体的绑定对象所有的绑定元素，在介绍一个个具体的系统绑定中，我会使用该方法： 1: static void ListAllBindingElements(Binding binding) 2: { 3: BindingElementC
在设计和实现服务协定后，即可配置服务。在其中可以定义和自定义如何向客户端公开服务，包括指定可以找到服务的地址、服务用于发送和接收消息的传输和消息编码，以及服务需要的安全类型。
绑定是用于配置wcf如何进行endpoint的对象，其包括协议配置（如2019-2-12-wcf入门（14） - huangtengxiao用到的可靠会话配置），消息编码方式（如文本编码，二进制编码），底层传输方法（如tcp）。
protobuf是google提供的一个开源序列化框架，类似于XML，JSON这样的数据表示语言，其最大的特点是基于二进制，因此比传统的XML表示高效短小得多。虽然是二进制数据格式，但并没有因此变得复杂，开发人员通过按照一定的语法定义结构化的消息格式，然后送给命令行工具，工具将自动生成相关的类，可以支持java、c++、python等语言环境。通过将这些类包含在项目中，可以很轻松的调用相关方法来完成业务消息的序列化与反序列化工作。 protobuf在google中是一个比较核心的基础库，作为分布式运算涉及到
在《实例篇》给出的例子中，我实际上是通过对终结点的绑定进行相应的配置让整个消息的交换过程在一个可靠会话中进行，进而实现可靠消息传输的目的。由于整个可靠会话的机制是完全在信道层实现的，而整个信道层的最终缔造者就是绑定，所以可靠会话编程是围绕着绑定进行的。而从结构组成的角度讲，绑定本质上就是一组绑定元素的有序集合，没有个为了实现各自的目的对传入信道栈的消息进行消息的处理。在这里，实现可靠会话是一个特殊的绑定元素：ReliableSessionBindingElement. 一、从ReliableSession
题外话：本以为我会WCF了，精通WCF了，毕竟刚做过一个WCF的项目，不就是写写契约接口，然后实现接口，改下配置。最后用控制台或者服务发布一下，不就能用了。不就是简单ABC吗？不是So Easy吗？做第二个项目的时候我悲剧了，被碰的头破血流！忽然发现什么什么都不会（第一个项目比照网上教程一步一步弄的），连写一个简单hello world都写不出来。我之前还以为自己很懂了…… 一、WCF文件配置 为了不重蹈覆辙，这次争取把他整懂整透（当然这才是入门而已）。WCF很强大，它的强大跟它的配置有很大的
转眼微软的WCF已走过十个年头，它是微软通信框架的集大成者，将之前微软所有的通信框架进行了整合，提供了统一的应用方式。记得从自己最开始做MFC时，就使用过Named Pipe命名管道，之后做Winform时，使用过Remoting，再之后做B/S架构时，就会经常使用.NET平台下的Web Service，直到使用上WCF。看上去有了一些WCF的使用经验，实则不然，比如对安全、分布式事务、可靠会话等主题仍然接触甚少，因而决定重新回顾学习一下相关知识，尤其是对WCF框架的理解（已于2015年开源，可下载源码，h
在这篇文章中，我们对信道分发器本身作一个深入的了解，首先来看看它具有哪些可供扩展的组件，以及我们可以针对信道分发器对WCF实现哪些可能的扩展。 目录： ErrorHandler & ServiceThrottle ChannelInitializer IncludeExceptionDetailInFaults ManualAddressing MaxPendingReceives ReceiveSynchronously
通过《实现篇》对WSDL元素和终结点三要素的之间的匹配关系的介绍，我们知道了WSDL的Binding元素来源于终结点的绑定对象，那么这些基于Binding的元数据以及相应的策略断言是如何被写入WSDL的呢？WSDL导出扩展（WSDL Export Extension）和策略导出扩展（Policy Export Extension）就是为此设计的。 一、WSDL导出扩展（WSDL Export Extension） 终结点的绑定本质上就是相关的绑定元素（BindingElement）的有序组合（关于绑定的
老的Windows通讯开发平台有：WebService和.net Remoting等。
WCF在跨域传输使用了两种模型的方法调用：一种是同步模型，这种模型显然对那些需要大量操作时间的方法调用（如从数据库中获取大量数据时）是一种痛苦的选择。另一种是异步模型的方法调用，这种模型是一种非阻塞方法，其方法调用期间并不等到方法调用结束获得结果才返回，而是方法调用一经开始就马上返回，程序可以继续向前执行，被调用方法和主程序同时执行，在调用方法结束才返回结果。显然这种模型给了我们很好的编程和使用体验。 基于WCF在普通的编码是以文本编码方式在信道之间传输信息的，这种编码会把所有的二进制信息以字节数组的形式存
WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的，所以我们有必要在对服务描述进行简单的介绍。 目录： 一、从服务描述（Service Description）谈起
我们想对WCF具有一定了解的人都会知道：在客户端通过服务调用进行服务调用过程中，服务代理应该及时关闭。但是如果服务的代理不等得到及时的关闭，到底具有怎样的后果？什么要关闭服务代理？在任何时候都需要关闭服务代理吗？是否有一些例外呢？本篇文章将会围绕着这些问题展开。
前面一篇文章《WCF 学习总结1 -- 简单实例》一股脑儿展示了几种WCF部署方式，其中配置文件(App.config/Web.config)都是IDE自动生成，省去了我们不少功夫。现在回过头来看看IDE提供的Wcf Service Library项目模板中的默认服务端配置文件——App.config里面究竟有什么秘密。 服务端的配置文件主要是对services、bindings、behaviors的配置。在默认的App.config中，使用的是WCF Framework定义好的wsHttpBinding默
WCF（Windows Communication Foundation）是由微软开发的一系列支持数据通信的应用程序框架，可以翻译为Windows 通讯开发平台。整合了原有的windows通讯的 .net Remoting，WebService，Socket的机制，并融合有HTTP和FTP的相关技术。是Windows平台上开发分布式应用最佳的实践方式。 WCF是.Net框架中的技术，用来创建面向服务的应用程序，交换不同通信方案里的消息，以及执行服务操作生成的工作流。WCF应用程序由三部分组成 - WCF服务，WCF服务主机和WCF服务客户端。WCF平台有时也被称为服务模型。WCF的基本特征是互操作性。这是微软用于构建面向服务的应用程序的最新技术之一。根据基于消息的通信的概念中，一个HTTP请求可以被均匀地表示，WCF是一个统一的API而不管不同的传输机制。
对于传统的WCF配置系统，无论是绑定的配置还是行为（服务行为和终结点行为）都必须具有一个名称。而正是通过整个配置名称，它们才能被应用到目标对象（终结点或者服务）上。而在实际的项目开发中，绝大部分服务或者终结点都具有相同的绑定和行为，如果能够定义一种默认的绑定和行为，这无疑会简化我们的配置。WCF4.0为此提供了一个新的特性以支持默认绑定和行为的配置。 一、 默认绑定配置 在传统的配置方式下，如果我们需要对终结点的绑定（不论是系统绑定还是自定义绑定）进行定制，我们都需要配置一个“具名”的绑定，然后将这个名称指
WCF系统内置绑定列表 绑定 配置元素 说明 传输协议 编码格式 BasicHttpBinding <basicHttpBnding> 一个绑定，适用于与符合 WS-Basic Profile的Web服务（例如基于 ASP.NET Web 服务（ASMX）的服务）进行的通信。 此绑定使用HTTP作为传输协议，并使用文本/XML作为默认的消息编码 HTTP/HTTPS Text，MTOM WSHttpBinding <wsHttpBinding> 一个安全且可互操作的绑定，适合于非双工服务约定 HTTP
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。 在这个例子中，我们将实现一个简单的计算服务（CalculatorService），提供基本的加、减、乘、除的运算。和传统的分布式通信框架一样，WCF本质上提供一个跨进程、跨机器以致跨网络的服务调用。在本例中，客户端和服务通过运行在相同的同一台机器上不同进程模拟，图1体现了客户端
作为一个通信基础平台,WCF必须保证通信的可靠性。由于消息交换是WCF采用的通信手段，通信可靠性的保障体现在确保消息的可靠传输。WCF本质上是一个消息处理框架，作为整个消息交换系统的两个终端，即发送端和接收端。换句话说，WCF仅仅负责对消息的发送和接收，一旦消息通过WCF的信道层进入了网络，就脱离了WCF的控制范围。但是，由于网络环境的限制，网络层不能百分之百地确保对消息的有效交付。如何克服中间环节的制约，确保从一端发送的消息能够被有效地交付给另一端，这就是可靠消息传输（Reliable Messaging
在上面的内容中，先后介绍了信道、信道管理器、信道监听器和信道工厂。从对象的创建来讲，信道管理器是信道的创建者。说的再具体点，客户端的信道通过信道工厂创建，服务端的信道通过信道监听器创建。但是信道工厂和信道监听器又是如果被创建出来的呢？ 我们在一开始就已经说过，作为终结点三要素的绑定对象实现了所有的通信细节，并且通过创建信道栈实现了消息的传递。从这一点来说，绑定对象无疑是信道层所有通信对象的最终缔造者，所以信道工厂和信道监听器最终的创建都是靠绑定对象实现的。关于这个创建过程又和另一个重要的对象密切相关，那就
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。
对WCF的可靠会话编程有一定了解的人应该知道，我们可以使用 DeliveryRequirementsAttribute 可以指示WCF确认绑定提供服务或客户端实现所需的功能。如果在从应用程序配置文件加载服务说明或在代码中以编程方式生成服务说明时检测到 DeliveryRequirementsAttribute 属性，则 WCF 会验证所配置的绑定，并支持该属性指定的所有功能。例如，您的服务可能要求绑定支持队列。使用 DeliveryRequirementsAttribute 可以让WCF 确认是否满足下列要
[续《上篇》]通过将TransactionFlowAttribute特性应用在服务契约的某个操作之上，并指定相应的TransactionFlowOption枚举直，仅仅定义了事务流转的策略而已。或者说，通过这种方式确定对事物流转的一种意愿，客户端是否愿意将当前事务流出，服务端是否愿意接受流入的事务，可以通过TransactionFlowAttribute特性进行控制。所以说，服务操作上定义个TransactionFlowAttribute特性是是否进行事务流转的总开关，真正的事务传播是建立在Transact
很多WCF的初学者是从之前的Web服务上转移过来的，他们非常怀念.asmx Web服务无配置的服务寄宿方式。你只需要在定义Web服务的时候再表示服务操作的方法上应用WebMethodAttribute特性就可以了，完全可以不需要手工进行相应的配置，因为Web服务运行时会自动为你添加默认的配置。但是对于WCF来说，在进行服务寄宿的时候，你必须以编程或者配置的方式为服务添加至少一个终结点，而终结点需要具备基本的ABC三要素。 对于最新版本的WCF编程人员来说，你也可以采用无配置的服务寄宿了，这主要得益于WCF提
在上一篇文章中，我们详细地介绍了BasicHttpBinding具有怎样的安全模式的支持，已经在各种安全模式下分别可以采用怎样的客户端凭证。接下来我们来进一步分析另外三个基于HTTP的绑定，即WSHttpBinding、WS2007HttpBinding和WSDualHttpBinding。考虑到它们之间在安全设置方面的相关性，在这里我们先来介绍WSDualHttpBinding。 一、WSDualHttpBinding 我们在前面提到过，WCF所有基于HTTP的绑定的Transport安全模式都是通过TL
本系列适合新手，从0学起。共同学习，共同探讨。 基础概念 SOA：就是采用Web服务的架构 它有一些特性，需要了解： 1、自治的：不依赖于访问它的客户端和其他服务，可以独立的进行部署和实施版本策略和安全策略。 2、依赖于开放的标准：让不同的厂商开发的服务能够进行互操作。 3、支持跨平台 4、鼓励创建可组合的服务 5、鼓励服务的复用 6、强调松耦合：契约的实现 WCF应用实例，帮助理解WCF服务的基本结构 过程： 1、构建解决方案 Contracts：定义服务的契约（接口部分） Services：定义服务的实
在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址。 一、服务端的物理地址 在默认的情况下，终结点的逻辑地址和物理地址是同一个URI。换句话说，终结的逻辑地址是必须的，如何物理地址没有指定的，默认使用逻辑地址作为物理地址。对于消息接收方的终结点来讲，物理地址就是监听地址，通过ServiceEndpoint的ListenUri表示：
1、创建WCF客户端应用程序需要执行下列步骤 (1)、获取服务终结点的服务协定、绑定以及地址信息 (2)、使用该信息创建WCF客户端 (3)、调用操作 (4)、关闭WCF客户端对象 二、操作实例 1、
由于WCF采用.NET托管语言（C#和NET）作为其主要的编程语言，注定以了基于WCF的编程方式不可能很复杂。同时，WCF设计的一个目的就是提供基于非业务逻辑的通信实现，为编程人员提供一套简单易用的应用编程接口（API）。WCF编程模式的简单性同样体现在异常处理上面，本篇文章的主要目的就是对WCF基于异常处理的编程模式做一个简单的介绍。 一、当异常从服务端抛出 对于一个典型的WCF服务调用，我个人倾向于将潜在抛出的异常费为两种类型：应用异常（Application Exception）和基础结构（Infr
Windows® Communication Foundation (WCF) 提供了许多扩展点，供开发人员自定义运行时行为,从而实现服务调度和客户代理调用。您可以通过编写能以声明方式应用到服务中的自定义行为来使用这些扩展点。本月将为您介绍这一流程的工作原理。 WCF 可扩展性 在上期专栏中，我重点介绍了 WCF 绑定概念，您可以为 WCF 服务上的各个终结点指定绑定。绑定控制该终结点的消息传递详细信息（发生在网络上的情况）。这是 WCF 建立一个能够在字节流（网络上的消息）和 WCF 消息间转换的通道堆栈
在《基于IIS的WCF服务寄宿（Hosting）实现揭秘》中，我们谈到在采用基于IIS（或者说基于ASP.NET）的WCF服务寄宿中，具有两种截然不同的运行模式：ASP.NET并行（Side by Side）模式和ASP.NET兼容模式。对于前者，WCF通过HttpModule实现了服务的寄宿，而对于后者，WCF的服务寄宿通过一个HttpHandler实现。只有在ASP.NET兼容模式下，我们熟悉的一些ASP.NET机制才能被我们使用，比如通过HttpContext的请求下下文；基于文件或者Url的授权；H
服务通过 ServiceHost 进行寄宿。可以添加终结以暴露可被调用寻址和调用的资源。
首先修改服务端的app.config 配置文件，先使用basicHttpBinding
本篇文章来源于几天前一个朋友向我咨询的问题。问题是这样的，他说他采用ASP.NET应用程序的方式对定义的WCF服务进行寄宿（Hosting），并使用配置的方式对服务的BaseAddress进行了设置，但是在创建ServiceHost的时候却抛出InvalidOperationException，并提示相应Address Scheme的BaseAddress找不到。我意识到这可能和WCF中用于判断服务寄宿方式的逻辑有关，于是我让这位朋友将相同的服务寄宿代码和配置迁移到GUI程序或者Console应用中，看看是
在上一篇"x.509证书在WCF中的应用(CS篇)"里，我们知道了如何在应用程序中，利用x.509证书来验证WCF的消息安全(没看过的朋友建议先看下,地址https://cloud.tencent.com/developer/article/1028346),这一篇我们将尝试把x.509证书放到IIS里来验证WCF。 WCF宿主在IIS和普通应用程序里，原理虽然没什么不同，但在实际测试中发现，如果服务端与客户端都采用x.509证书来验证，服务端设置的自定义验证客户端证书的方法总是不起作用，无奈之下，只能在客
本文参考自http://www.cnblogs.com/wangweimutou/p/4367905.html Visual studio 针对服务配置提供了一个可视化的配置界面(Microsoft
上面一部分我们站在信道层的角度剖析了WCF为了实现可靠会话在信道层进行的一系列消息交换，或者说客户端和服务端的RS信道为了实现可靠消息传输所进行一轮又一轮的握手。这一切都是基于这样一个假设：两个RS信道均可以在适当的时机向对方发送消息，或者说两个RS信道之间是一个双工的通道。 如果我们站在传输层看待这个问题，该假设对于TCP传输是成立的，但是对于HTTP来说就有点问题了。HTTP本身就是一个基于请求|回复消息交换模式的应用层网络协议，并不能对双工通信提供支持。而WCF通过WSDualHttpBinding
最近系统上线完修改完各种bug之后，功能上还算是比较稳定，由于最近用户数的增加，不知为何经常出现无法登录、页面出现错误等异常，后来发现是由于WCF服务时不时的就死掉了。后来就开始分析问题。得到的初步解决方案如下：
服务是一个构造，它公开一个或多个终结点，其中每个终结点都公开一个或多个服务操作。
到目前为止，对于WCF安全传输的三个方面，我们已经对认证进行了详细的介绍，现在我们来关注另外两个话题：消息的一致性和机密性，两者又统称为消息保护（Message Protection）。消息的安全等级指的是对整个消息或者消息的某个部分事实安全保护采用的等级。按照级别的由低到高，WCF支持如下三种不同的安全等级。在WCF的应用编程接口中，消息保护级别通过如下定义的ProtectionLevel枚举表示。 None:不采用任何措施来保护消息的一致性和机密性； Sign:通过对整个消息或者消息的某个部分进行数字
客户端调用WCF服务可以通过添加服务引用的方式添加，这种方式使用起来比较简单，适合小项目使用。服务端与服务端的耦合较深，而且添加服务引用的方式生成一大堆臃肿的文件。
其实不太了解为什么第21集才讲这个Binding，下面都是一些概念性的东西，不过作为一个入门视频，了解一下也无妨吧。
在前面一片文章（服务代理不能得到及时关闭会有什么后果?）中，我们谈到及时关闭服务代理（Service Proxy）在一个高并发环境下的重要意义，并阐明了其根本原因。但是，是否直接调用ICommunic
步骤: 1.把同样的WCF服务，在多个端口上"启动"(即同时运行多个wcf的实例，但每个实例都监听不同的端口) 2.用svcutil.exe生成的代理类，里面有N多构造函数的重载版本，观察一下类似下面的这个版本 public AstroServiceClient(string endpointConfigurationName) : base(endpointConfigurationName) { } 即传入配置名生与代码类的实例,我们在web.config中的
本次课程的主要内容包括以下四格部分：DataContractSerializer、序列化、反序列化、XmlSerializer
其中应用在ServiceContractAttribute服务契约特性上的特性[AttributeUsage(AttributeTargets.Class)]表示服务契约特性只能应用于类或接口。
我们知道，WCF是MS基于SOA建立的一套在分布式环境中各个相对独立的Application进行Communication的构架。他实现了最新的基于WS-*规范。按照SOA的原则，相对独自的业务逻辑以service的形式封装，调用者通过Messaging的方式调用Service。对于承载着某个业务功能的实现的Service应该具有Context无关性、甚至是Solution无关性，也就是说个构成Service的operation不应该绑定到具体的调用上下文，对于任何调用，具有什么样的输入，就会有与之对应的输出。因为SOA的一个最大的目标就是尽可能地实现重用，只有具有Context无关性/Solution无关性，Service才能实现最大限度的重用。此外Service的Context无关性/Solution无关性还促进了另一个重要的面向服务的特征的实现：可组合性，把若干相关细粒度的Service封装成一个整体业务流程的Service。
今天介绍WCF 4.0的另外两个新特性：标准终结点（Standard Endpoint）和无(.SVC)文件服务激活（File-Less Activation）。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 一、标准终结点 我们知道，绑定的本质就是一系列相关绑定元素的有序集合，而系统绑定就是基于若干典型的通信场景对相关绑定元素的整合。WCF通过系统绑定对绑定元素进行了定制，那么能否在终结点级别对组成该终结点的ABC（地址、绑定和契约）也进行相应的定
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
