WCF采用基于消息交换的通信方式，而绑定则实现了所有的通信细节。绑定通过创建信道栈实现了消息的编码与传输，以及对WS-*协议的实现。在这一节中，我们就来着重介绍WCF中的信道和信道栈。在正式开始对信道和信息栈的介绍之前，我们先来介绍两个重要的类型：CommunicationObject和DefaultCommunicationTimeouts。
我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。 一、Session 管理提供的具体功能 我们的例子实现了下面一些Session Management相关的功能： Start/End Session：可以调用service
服务契约 [ServiceContract] public interface IService { [OperationContract] string GetData(int value); [OperationContract] string GetString(string value); [OperationContract] void Upload(Request request)
我们想对WCF具有一定了解的人都会知道：在客户端通过服务调用进行服务调用过程中，服务代理应该及时关闭。但是如果服务的代理不等得到及时的关闭，到底具有怎样的后果？什么要关闭服务代理？在任何时候都需要关闭服务代理吗？是否有一些例外呢？本篇文章将会围绕着这些问题展开。
在上一篇文章中，我们通过一个直接借助BasicHttpBinding对象实现Client和Server端进行通信的例子，对WCF channel layer进行了一个大致上的介绍。由此引出了一些列通信相关的概念和对象，比如Channel，Output channel， Input channel，Request channel, Reply Channel，Duplex channel， Channel Shape，Channel manager，Channel factory, Channel liste
信道管理器是信道的创建者，一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能，将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈，由于信道本身是由信道管理器创建的，所以信道对应的信道管理器也构成一个信道管理器栈，栈中信道管理器的顺序决定由它所创建信道的顺序。 对于WCF的信道层来说，信道管理器在服务端和客户端扮演着不同的角色，服务端的信道管理器在于监听来自客户端的请求，而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此，客户端的消息管理器又称为信道监听器（Channel
由于信道管理器在客户端和服务端所起的不同作用，分为信道监听器和信道工厂。和服务端的信道监听其相比，处于客户端的信道工厂显得简单。从名称就可以看得出来，信道工厂的作用就是单纯的创建用于消息发送的信道。我们先来看看与信道工厂相关的一些接口和基类的定义。 一、信道工厂相关的接口和基类 对于信道监听器，WCF定义了两个接口：IChannelListener和IChnnelListener<TChannel>。与之相对地，WCF也为信道工厂定义了两个接口：IChannelFactory和IChannelFactor
转载：http://www.cnblogs.com/xienb/p/3443282.html
更新说明：对文章排版以及内容格式做了调整。 更新时间：2022-05-04 今天重新学习之前写了半截的项目，其中提到了jsonp，当时也是查了很多资料，做了很多笔记，但是最近在写一个项目的时候，竟然遗忘了很多，所以特此做个总结，在下次再遇到jsonp的时候，可以有一个清晰的认识。 jsonp原理介绍 jsonp就是为了解决前端的跨域问题而进行的一项设计，jsonp之所以能实现跨域，是因为它发送的不是ajax请求，它动态创建了script标签，script标签是不受同源策略限制的，将script
最近在项目中采用 Windows service 作为WCF services的宿主, 在服务和客户端的调用上没有发生如何的异常和错误,但是经常发生下述错误： “System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded b
在之前的2019-1-31-wcf入门（12） - huangtengxiao博客介绍了wcf的异步，但是发现一些小伙伴没有注意到的问题。因此做一些补充实验
通过前面一系列的博文（《WCF 并发（Concurrency）的本质》、《并发中的同步》、《实践重于理论》、《并发与实例上下文模式》、《回调与并发》、《ConcurrencyMode.Multiple 模式下的WCF服务就一定是并发执行的吗[上篇]》、《ConcurrencyMode.Multiple 模式下的WCF服务就一定是并发执行的吗[下篇]》、《控制并发访问的三道屏障[上篇]》和《控制并发访问的三道屏障[下篇]》）,我对WCF的并发体系进行了深入的剖析,在接下来的博文中,我只要专注于WCF的可靠会话
几个星期之前写了一篇关于如何通过WCF进行 双向通信的文章（[原创]我的WCF之旅（3）：在WCF中实现双向通信（Bi-directional Communication） ），在文章中我提供了一个如果在Console Application 调用Duplex WCF Service的Sample。前几天有个网友在上面留言说，在没有做任何改动得情况下，把 作为Client的Console Application 换成Winform Application，运行程序的时候总是出现Timeout的错误。我觉得这
WCF寄宿方式是一种非常灵活的操作，可以在IIS服务、Windows服务、Winform程序、控制台程序中进行寄宿，从而实现WCF服务的运行，为调用者方便、高效提供服务调用。本文分别对这几种方式进行详细介绍并开发例子进行说明，以求大家对WCF寄宿的方式进行全面的认识和了解。 1、 WCF服务的IIS服务寄宿 我在我前面几篇WCF开发框架的介绍文章中，介绍过了WCF常用的一种寄宿方式，IIS服务寄宿。这种寄宿方式是最为方便的方式，而且由于服务只需要IIS运行就能自动运行起来，因此广为使用。 创建这种方式IIS
1当客户端调用未返回结果时，服务不可用（网络连接中断，服务关闭，服务崩溃等） 客户端抛出异常 异常类型：CommunicationException InnerException: Message：
本篇文章介绍可以算是WCF 4.0基于限流（Throttling）的新特性，是在修订《WCF技术剖析（卷1）》的时候编写演示实例的时候发现的。这个特性没有出现在官方文档上面，至少在MSDN上的相关介绍依然是错误的。 一、流量限制简介 WCF是一个基于多线程的消息监听、接收和处理框架体系，能够同时应付来自相同或者不同客户端的服务调用请求，并提供完善的同步机制确保状态的一致性。一方面，我们期望WCF服务端能够处理尽可能多的并发请求，但是资源的有限性决定了并发量有一个最大值。如果WCF不控制进入消息处理系统的并发
由于WCF的机制，连接池会在连接建立一定时间后超时，即使设置了超时时间非常长，也可能被服务端系统主动回收。之前做项目时碰到了这个问题，所以项目上考虑采用长连接，自动管理连接池，当连接超时后，自动重建，保持会话，这样在业务层就不需要再去处理连接超时的问题。具体的思路是，在程序启动时，先将需要使用长连接的连接放到长连接容器中，并设置连接的最大数量，在使用时，轮询使用连接，当使用时捕获到异常时，自动切换到下一个连接，并重建上一个连接。代码如下：
对WCF的可靠会话编程有一定了解的人应该知道，我们可以使用 DeliveryRequirementsAttribute 可以指示WCF确认绑定提供服务或客户端实现所需的功能。如果在从应用程序配置文件加载服务说明或在代码中以编程方式生成服务说明时检测到 DeliveryRequirementsAttribute 属性，则 WCF 会验证所配置的绑定，并支持该属性指定的所有功能。例如，您的服务可能要求绑定支持队列。使用 DeliveryRequirementsAttribute 可以让WCF 确认是否满足下列要
本文参考自:http://www.cnblogs.com/wangweimutou/p/4414393.html,纯属读书笔记,加深记忆 一、简介 当我们打开WCF基础客户通道,无论是显示打开还是通过调用操作自动打开、使用客户端或者通过对象调用操作,或者关闭基础客户端通道,都会在客户端应用程序中出现异常,WCF是基于网络的通讯服务,错误异常也是要基于消息传递的,在WCF中提供了一个错误消息处理的类FaultException,WCF客户端可以通过它,来接收服务端传递回来的异常信息。 二、WCF异常类型 1、
其实这样使用看起来是没什么问题的，而且也能顺利使用，在项目开发阶段完全没出现什么问题。不过，由于wcf客户端都有一个超时时间，可能静止过了一段时间，你在界面刷新数据的时候，你会发现出现下面的错误："通信对象System.ServiceModel.Channels.ServiceChannel 无法用于通信，因为其处于“出错”状态。"，当然还有可能出现另外的其他的奇怪的错误提示。
--通常，可以通过使用ServiceModel Metadata Utility Tool(Svcutil.exe)完成此操作
线上正式环境调用WCF服务正常，但是每次使用本地测试环境调用WCF服务时长就是出现：套接字连接已中止。这可能是由于处理消息时出错或远程主机超过接收超时或者潜在的网络资源问题导致的。本地套接字超时是“00:05:30” 这个问题，查阅了网上很多资料各种说法的都有，有的说是什么请求站点不在同一个域下，有的说什么应为datatable中有一个属性没有赋值各种答非所问的问题。其实从错误信息中就可以看出来其实就是调用超时了。
在.NET 1.x中，我们基本是通过ADO.NET实现对不同数据库访问的事务。.NET 2.0为了带来了全新的事务编程模式，由于所有事务组件或者类型均定义在System.Transactions程序集中的System.Transactions命名空间下，我们直接称基于此的事务为System.Transactions事务。System.Transactions事务编程模型使我们可以显式（通过System.Transactions.Transaction）或者隐式（基于System.Transactions.T
在WCF事务编程模型下，通过服务契约确定事务流转的策略（参阅《上篇》），通过事务绑定实施事务的流转（参阅《中篇》）。但是，对于事务绑定接收到并成功创建的事务来说，服务操作的执行是否需要自动登记到该事务之中，以及服务操作采用怎样的提交方式，这就是服务端自己说了算了。正因为如此，WCF通过服务（操作）行为的形式定义事务的登记和提交（完成）方式。 一、事务的自动登记（Enlistment）与提交（完成） 在OperationBehaviorAttribute特性（其本身是一个操作行为）中定了两个与事务管理相关
WCF的服务调用有3种模式：请求答复模式（Request-Repley），单向模式（One-Way），双工模式（Duplex）
在asp.net 应用程序和WCF服务之间共享FormsAuthentication，默认是不支持的，设置一下非常的简单，只需要两步就可以了： 1、在web.config的system.serviceModel增加一个配置： <system.serviceModel> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> </system.serviceModel> 2、为WCF打上标签 [AspNetCompatibilityReq
其中<service>节点中的name属性,是实现了服务契约的类型名,类型名必须是完整的,要包括名称空间 <endpoint>节点的address属性为空,说明使用基地址. behaviorConfiguration属性与behavior节点的name属性相匹配 binding属性说明WCF服务使用什么协议,这里是HTTP协议 contract属性是描述契约的接口名称,也必须是完整的.如果没有接口直接写实现契约的类型名也可以(我这里就是这样).
在《WCF 并发的本质》中，我们谈到了WCF提供的三种不同的并发模式，使开发者可以根据具体的情况选择不同的并发处理的策略。对于这三种并发模式，Multiple采用的并行的执行方式，而Single和Reentrant则是采用串行的执行方式。串行执行即同步执行，在WCF并发框架体系中，这样的同步机制是如何实现的呢？ 一、Concurrency.Single模式下的同步实现 实际上，WCF并发框架体系下针对Concurrency.Single模式的实现非常简单，其本质就是对InstanceContext进行加锁
在一个分布式的环境中，我们往往需要根据具体的情况采用不同的方式进行数据的传输。比如在一个Intranet内，我们一般通过TCP进行高效的数据通信；而在一个Internet的环境中，我们则通常使用Http进行跨平台的数据交换。而这些通信方式具有一个显著的特点，那就是他们是基于Connection的，也就是说，交互双方在进行通信的时候必须保证有一个可用的Connection存在于他们之间。而在某些时候，比如那些使用拨号连接的用户、以及使用便携式计算机的用户，我们不能保证在他们和需要访问的Server之间有一个的可靠的连接，在这种情况下，基于Messaging Queue的连接就显得尤为重要了。我们今天就来谈谈在WCF中如何使用MSMQ。
在《实例篇》中，我通过可靠会话成功地进行了美女图片的传输，相信大家在保了眼福之余，会对WCF的可靠会话的功用具有一个深刻的认识。实际上，这涉及到WS中一个重要的概念——可靠消息传输（RM：Reliable Messaging）。如果想对可靠会话有一个深入的认识，对可靠消息传输的了解是必须的。 一、可靠消息传输（Reliable Messaging） 我们可以将一个通过WCF构建的分布式应用划分为两个部分，即客户端应用和服务端应用，它们之间的交互方式即采用某种MEP的消息交换。在这里，我们需要通过可靠消息传输
[续《上篇》]TransactionFlow选项通过TransactionFlowAttribute这个操作契约写入绑定上下文，由事务绑定创建的事务信道获取该选项并以此作为首否对事务实施传播（发送或者接收）的依据。客户端事务信道通过TransactionFormatter对当前事务按照指定的事务处理协议进行格式化，并嵌入出栈消息；通过TransactionFormatter则从入栈消息中提取相应的数据重建事务。这就是事务流转实现的本质。整个WCF事务还有一个重要的步骤需要实现：如何将通过OperationB
引言 服务（Service）的本质就是提供服务消费者期望的某种功能，服务的价值体现在两个方面：服务本身的质量和寄宿服务的平台应付消费者的数量，并发（Concurrency）的关注的是第二个要素。WCF服务寄宿于资源有限的环境中，要实现服务效用的最大化，需要考虑如何利用现有的资源实现最大的吞吐量（Throughput）。提高吞吐量就某个寄宿的服务实例（Service Instance）来说，一个重要的途径就是让它能够同时处理来自各个客户端（服务代理）的并发访问。WCF实现了一套完整的并发控制体系，为你提供了不
WinForm企业应用框架设计【一】界限划分与动态创建WCF服务（no svc!no serviceActivations!）
在《上篇》中，我通过一个具体的实例演示了WCF服务宿主的同步上下文对并发的影响，并简单地介绍了同步上下文是什么东东，以及同步上下文在多线程中的应用。那么，同步上下文在WCF并发体系的内部是如何影响服务操作的执行的呢？这实际上涉及到WCF的一个话题，即线程的亲和性（Thread Affinity），本篇文章将为你剖析WCF线程亲和机制的本质。 一、WCF线程亲和性（Thread Affinity） 对于服务端来说，WCF消息监听和接收体系通过IO线程池并发的处理来自客户端的服务调用请求，所以并发抵达的服务
之前在介绍2019-1-24-wcf入门（3） - haungtengxiao请求答复模式时，提到了异步服务操作。
在《实例篇》给出的例子中，我实际上是通过对终结点的绑定进行相应的配置让整个消息的交换过程在一个可靠会话中进行，进而实现可靠消息传输的目的。由于整个可靠会话的机制是完全在信道层实现的，而整个信道层的最终缔造者就是绑定，所以可靠会话编程是围绕着绑定进行的。而从结构组成的角度讲，绑定本质上就是一组绑定元素的有序集合，没有个为了实现各自的目的对传入信道栈的消息进行消息的处理。在这里，实现可靠会话是一个特殊的绑定元素：ReliableSessionBindingElement. 一、从ReliableSession
在这篇文章中，我们对信道分发器本身作一个深入的了解，首先来看看它具有哪些可供扩展的组件，以及我们可以针对信道分发器对WCF实现哪些可能的扩展。 目录： ErrorHandler & ServiceThrottle ChannelInitializer IncludeExceptionDetailInFaults ManualAddressing MaxPendingReceives ReceiveSynchronously
在[上篇]中，我们分别站在消息交换和编程的角度介绍了SOAP Fault和FaultException异常。在服务执行过程中，我们手工抛出FaultException异常，WCF服务端框架会对该异常对象进行序列化病最终生成Fault消息。当WCF客户端框架介绍到该Fault消息之后，会做一项相反的操作：对Fault消息中进行解析和反序列化，重新生成并抛出FaultException异常。WCF框架自动为我们作了这么多“幕后”工作，使得开发人员可以完全采用编写一般的.NET应用程序的模式进行异常的处理：在错误
在[第2篇]中，我们深入剖析了单调（PerCall）模式下WCF对服务实例生命周期的控制，现在我们来讨轮另一种极端的服务实例上下文模式：单例（Single）模式。在单例模式下，WCF通过创建一个唯一的服务实例来处理所有的客户端服务调用请求。这是一个极端的服务实例激活方式，由于服务实例的唯一性，所有客户端每次调用的状态能够被保存下来，但是当前的状态是所有客户端作用于服务实例的结果，而不能反映出具体某个客户端多次调用后的状态。WCF是一个典型的多线程的通信框架，对并发的服务调用请求是最基本的能力和要求，但是服务
创建单向模式的操作很简单，只要在OperationContract中将IsOneWay设置成True即可
WCF是一个具有极高扩展度的分布式通信框架，无论是在信道层（Channel Layer）还是服务模型层（Service Model），我们都可以自定义相关组件通过相应的扩展注入到WCF运行环境中。在WCF众多可扩展点中，ICallContextInitializer可以帮助我们在服务操作执行前后完成一些额外的功能，这实际上就是一种AOP的实现方式。比如在《通过WCF Extension实现Localization》中，我通过ICallContextInitializer确保了服务操作具有和客户端一样的语言文
如今的云应用程序、移动设备、流数据处理和 IoT 技术等等都非常依赖于可靠的系统连通性。不过现实是：基础系统可能出现操作失败，网络波动时有发生：或中断、或延时、或瞬时波动、或峰值负载 —— 这些都对100%的系统连通性造成挑战。
开发者预览版.net 4.5 .NET for Metro style apps Metro风格的应用程序是利用Windows操作系统的强大功能设计的特殊表单元素。 一个称之为.NET APIs fo
对于任何一个企业级应用来说，安全（Security）都是一个不可回避的话题。如何识别用户的身份？如何将用户可执行的操作和可访问的资源限制在其允许的权限范围之内？如何记录用户行为，让相应的操作都有据可查？这些都是应用的安全机制或者安全框架需要考虑的典型问题，它们分别对应着三个安全行为：认证（Authentication）、授权（Authorization）和审核（Auditing）。 除了这些典型的安全问题，对于一个以消息作为通信手段的分布式应用，还需要考虑消息的保护（Message Protection）
在上面的内容中，先后介绍了信道、信道管理器、信道监听器和信道工厂。从对象的创建来讲，信道管理器是信道的创建者。说的再具体点，客户端的信道通过信道工厂创建，服务端的信道通过信道监听器创建。但是信道工厂和信道监听器又是如果被创建出来的呢？ 我们在一开始就已经说过，作为终结点三要素的绑定对象实现了所有的通信细节，并且通过创建信道栈实现了消息的传递。从这一点来说，绑定对象无疑是信道层所有通信对象的最终缔造者，所以信道工厂和信道监听器最终的创建都是靠绑定对象实现的。关于这个创建过程又和另一个重要的对象密切相关，那就
最近，项目中使用到了ActiveMQ获取第三方推送过来的数据。具体背景是：公司需要监控全国各地车辆实时运行的GPS数据，但监控本身不是公司做的，而是交给第三方公司做，第三方采集GPS数据后推送给我们。全国各地，近万台车辆，每台车辆每隔几秒就发送一次GPS位置数据，如果我们提供API给第三方公司去调用，显然无论是第三方还是我们这边，服务器都是是扛不住的，这么做也是不合理的，于是，便采取了消息队列，第三方采集到的数据直接推送到消息队列代理服务器，而己方从消息队列服务器取数据处理。以下对项目实践及其中遇到的一些问题及解决进行概要总结。
在[第1篇]中，我们介绍了WCF关于实例管理一些基本的知识点，包括InstanceContext、InstanceContextMode、已经如何通过ServiceBehaviorAttribute应用不同的实例上下文模式给不同的服务。在[第1篇]中，对WCF采用的三种不同实例上下文模式进行了简单的比较，本篇的重点方法对单调（PerCall）模式为进行详细介绍。 在单调（Per-Call）实例上下文模式下，WCF总是创建一个新的服务实例上下文处理接收到的每一个服务调用请求，并在服务操作执行结束后，回收服务上
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
