WCF(Windows Communication Foundation)服务是一种基于 SOAP(简易对象访问协议)的服务,它允许在不同的应用程序之间进行通信。WCF 服务通常由一个接口和一个实现组成。
在 WCF 服务中,构造函数是允许的,但是需要注意以下几点:
在 WCF 服务中,构造函数主要用于初始化服务实例的状态。如果需要在服务实现中使用构造函数,请确保遵循以上几点。
推荐的腾讯云相关产品和产品介绍链接地址:
和传统的分布式远程调用一样,WCF的服务调用借助于服务代理(Service Proxy)。而ChannelFactory<T>则是服务代理的创建者。WCF采用基于终结点(Endpoint)服务消费方式:WCF服务通过一个或者多个终结点暴露给潜在的服务消费者,服务的消费中通过与之匹配的终结点与之交互。在客户端,我们具有两种典型的服务代理创建方式,其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理(一个继承自ClientBase<T>的类型)代码和相关配置;其二是直接通过相应的终结
在.NET中,所有的集合都实现了IEnumerable接口,比如Array、Hashtable、ArrayList、Stack、Queue等。有的集合要求元素具有相同的类型,这种集合一般通过泛型的方式定义,它们实现另一个接口IEnumerable<T>(IEnumerable<T>本身继承自IEnumerable),这样的集合有List<T>、Dictionary<TKey,TValue>、Stack<T>、Queue<T>等。基于集合类型的序列化具有一些特殊的规则和行为,在上篇中我们详细介绍了基于泛型数据
形如:http://localhost/XL.Service/Sys-MenuService
在《原理篇》中我们谈到了通过自定义ServiceHost对WCF进行扩展的本质,以及在IIS/WAS寄宿情况下ServiceHostFactory的作用。接下来通过一个具体的例子来演示如何通过WCF扩展实现以Unity为代表的IoC框架的集成,以及应用该扩展的ServiceHost和ServiceHostFactory如何定义。[源代码从这里下载] 目录 一、IoC/DI简介 步骤一、自定义InstanceProvider:UnityInstanceProvider
本次课程的主要内容包括以下四格部分:DataContractSerializer、序列化、反序列化、XmlSerializer
最近跟高老师讨论nginx跟tomcat集群做负载均衡方案。感觉很有意思。想到自己项目中服务用的WCF技术,于是就想WCF如何做负载均衡,Google了一会,发现wcf4.0的路由服务好像可以实现。不过在研究路由服务期间,我有了个自己的方案,哈哈。
步骤: 1.把同样的WCF服务,在多个端口上"启动"(即同时运行多个wcf的实例,但每个实例都监听不同的端口) 2.用svcutil.exe生成的代理类,里面有N多构造函数的重载版本,观察一下类似下面的这个版本 public AstroServiceClient(string endpointConfigurationName) : base(endpointConfigurationName) { } 即传入配置名生与代码类的实例,我们在web.config中的
但是作为入门教程,建议大家创建一个.NET Framework 的控制台应用,然后一步步进行开发。
由于绑定对象由一系列有序的绑定元素组成,绑定元素最终决定着信道栈中信道的组成,而信道的组成最终又决定了信道栈对消息进行处理的方式和能力,所有要确定绑定的特性和能力,我们可以通过查看其绑定元素的构成来一窥究竟。为此我们我们写了一个简单的方法,用于列出一个具体的绑定对象所有的绑定元素,在介绍一个个具体的系统绑定中,我会使用该方法: 1: static void ListAllBindingElements(Binding binding) 2: { 3: BindingElementC
最近系统上线完修改完各种bug之后,功能上还算是比较稳定,由于最近用户数的增加,不知为何经常出现无法登录、页面出现错误等异常,后来发现是由于WCF服务时不时的就死掉了。后来就开始分析问题。得到的初步解决方案如下:
如图所示在创建双工模式的协定时,我们需要定义两个接口IDuplex用于客户端向服务端发送消息(或者称之为调用服务端方法),IDuplexCallback用于服务端向客户端发送消息(或者称之为调用客户端方法)
如果在 WPF 需要用多进程通信,一个推荐的方法是 WCF ,因为 WCF 是 RPC 计算。先来讲下 RPC (Remote Procedure Call) 远程过程调用,他是通过特定协议,包括 tcp 、http 等对其他进程进行调用的技术。详细请看百度
在[第2篇]中,我们深入剖析了单调(PerCall)模式下WCF对服务实例生命周期的控制,现在我们来讨轮另一种极端的服务实例上下文模式:单例(Single)模式。在单例模式下,WCF通过创建一个唯一的服务实例来处理所有的客户端服务调用请求。这是一个极端的服务实例激活方式,由于服务实例的唯一性,所有客户端每次调用的状态能够被保存下来,但是当前的状态是所有客户端作用于服务实例的结果,而不能反映出具体某个客户端多次调用后的状态。WCF是一个典型的多线程的通信框架,对并发的服务调用请求是最基本的能力和要求,但是服务
今天写《WCF技术剖析(卷2)》关于《WCF扩展》一章,举了“如何通过WCF扩展实现与IoC框架(以Unity为例)集成”(《通过自定义ServiceHost实现对WCF的扩展[实例篇]》)的例子。为了展示Unity如何实现几种典型的注入方式(构造器注入、属性注入和方法注入),我写了一个简单的小程序。如果读者对Unity或者IoC没有太多概念,我觉得这个小程序对于你初步地认识它们具有一定的帮助意义。如果你对Unity或者IoC有深入的认识,请忽略本文。[源代码从这里下载] 首先创建一个控制台程序,并添加如下
本文仅提供通过设置SoapHeader来控制非法用户对WebService的调用,如果是WebService建议使用WSE3.0来保护Web服务,如果使用的是Viaual Studio 2008可以使用WCF,WCF里面提供了更多的服务认证方法。以下提供一种基于SoapHeader的自定义验证方式。
本文参考自:http://www.cnblogs.com/wangweimutou/p/4422883.html,纯属读书笔记,加深记忆 一、服务协定简介: 1、WCF所有的服务协定层里面的服务接口,
动手了,WCF 开发WCF服务的终结点需要涉及下面几个任务: 开发服务契约:指定终结点可用的WCF服务的操作。 开发绑定:绑定指点终结点与外界通信的协议。 添加,删除,更新和配置端点:在配置文件中添加和绑定终结点(当然也可以用编码的形式,但是不推荐。) 添加行为:一个行为就是一个组件,能增强服务,终结点,和操作的运行时行为。 定义契约 契约就是一个用元数据属性[ServiceContract]修饰的.NET接口或类。每个WCF服务可以有一个或多个契约,每个契约是一个操作集合。请注意:[ServiceCont
大部分的系统都是以数据为中心的(Data Central),功能的实现表现在对相关数据的正确处理。而数据本身,是有效信息的载体,在不同的环境具有不同的表示。一个分布式的互联系统关注于数据的交换,而数据正常交换的根本前提是参与数据交换的双方对于数据结构的一致性理解。这就为数据的表现提出了要求,为了保证处于不同平台、不同厂商的应用能够正常地进行数据交换,交换的数据必须采用一种大家都能够理解的展现方式。在这方面,XML无疑是最好的选择。所以WCF下的序列化(Serialization)解决的就是如何将数据从对象的
本系列适合新手,从0学起。共同学习,共同探讨。 基础概念 SOA:就是采用Web服务的架构 它有一些特性,需要了解: 1、自治的:不依赖于访问它的客户端和其他服务,可以独立的进行部署和实施版本策略和安全策略。 2、依赖于开放的标准:让不同的厂商开发的服务能够进行互操作。 3、支持跨平台 4、鼓励创建可组合的服务 5、鼓励服务的复用 6、强调松耦合:契约的实现 WCF应用实例,帮助理解WCF服务的基本结构 过程: 1、构建解决方案 Contracts:定义服务的契约(接口部分) Services:定义服务的实
今天第20集了。这个视频系列里面有6集和异常相关,这集是最后一集。前面几集讲了服务端遇到普通的 .net exception时候,要转换城Soap Fault,用fault Exception 或 FaultException<T>来处理。 上一集的例子中用了在主方法体上加大的try catch块来捕获异常,然后throw成FaultExcepiton,这个有个坏处,我们不可能在所有的方法上都加上这么一段,因为不仅代码上显得臃肿,而且加起来麻烦,到处的try-catch。这集就通过IErrorHandler接口来提供一种相对优雅很多的方法。
客户端调用WCF服务的方式不外乎有两种:其一、通过代码生成工具(比如SvcUtil.exe)导入服务的元数据生成服务代理相关的类型;其二、通过ChannelFactory<TChannel>创建服务代理对象。对于前者,生成的服务代理是一个继承自ClientBase<TChannel>的类型。对于这样一个服务代理对象,其内部本质上还是借助于ChannelFactory<TChannel>创建真正用于进行服务调用的代理对象。对于WCF客户端应用编程接口来说,ChannelFactory<TChannel>是一个
除了采用自定义特性声明(服务行为、契约行为和操作行为)或者配置的方式(服务行为和终结点行为)应用自定义的行为之外,我们还可以通过自定义ServiceHost来应用这些自定义的行为。自定义ServiceHost是对WCF的服务端进行扩展的一种常用的方式。 在创建ServiceHost的时候,WCF会加载服务相关的配置并将其作为服务的描述信息附加到ServiceHost对象上,我们也可以在开启ServiceHost之前对其服务描述信息进行相应的修改。ServiceHost在开启之前具有的服务描述信息将会决定在开
由于信道管理器在客户端和服务端所起的不同作用,分为信道监听器和信道工厂。和服务端的信道监听其相比,处于客户端的信道工厂显得简单。从名称就可以看得出来,信道工厂的作用就是单纯的创建用于消息发送的信道。我们先来看看与信道工厂相关的一些接口和基类的定义。 一、信道工厂相关的接口和基类 对于信道监听器,WCF定义了两个接口:IChannelListener和IChnnelListener<TChannel>。与之相对地,WCF也为信道工厂定义了两个接口:IChannelFactory和IChannelFactor
在《WCF技术剖析(卷1)》的最后一章,我给出了一个具体的应用WCF的分布式应用实例,我把这个实例命名为PetShop。在这个例子中,我利用WCF的扩展实现了一些设计、架构模式,比如AOP、IoC等。看过本书的读者,一定还记得我还通过WCF扩展实现了于微软企业库(Enterprise Library)异常处理应用块(Exception Handling Application Block:EHAB)的集成。当时由于缺乏相应的背景知识,不可能介绍具体的实现,现在我们可以详细来讲述这是如何实现的。 (Sourc
Protocol Buffers 是在一个很理想的结构化数据的语言中立的序列化格式。你可以考虑一下XML或JSON,但更轻,更小的协议缓冲区。 这种格式的广应用于谷歌不同的系统之间交换数据。 由于其结构化数据的最佳表现,protocol buffers 是一个代表RESTful服务处理的数据很好的选择。要遵循REST的原则, protocol buffers 应作为一个新的超媒体类型的代表。 在当前版本(.NET 4) 的Windows通讯基础(WCF),包含一个新的媒体类型,需要相当数量的努力。 幸运的是
WinForm企业应用框架设计【一】界限划分与动态创建WCF服务(no svc!no serviceActivations!)
服务通过 ServiceHost 进行寄宿。可以添加终结以暴露可被调用寻址和调用的资源。
其实针对安全主体的授权实现的原理很简单,原则上讲,只要你能在服务操作执行之前能够根据本认证的用户正确设置当前的安全主体就可以了。如果你了解WCF的整个运行时框架结构,你会马上想到用于授权的安全主体初始化可以通过自定义CallContextInitializer来实现。[源代码从这里下载] 目录: CallContextInitializer简介 步骤一、自定义CallContextInitializer 步骤二、创建服务行为 步骤三、使用服务行为进行授权
在一个典型的服务调用场景中,具有两个基本的角色,即服务的消费者和服务的提供者。从消息交换的角度讲前者一般是消息的最初发送者,而后者则是消息的最终接收者。在很多情况下,由于网络环境的局限,消息的最初发送者和最终接收者不能直接进行消息交换,这就需要一个辅助实现消息路由的中介服务,这就是我们接下来要介绍的路由服务。 目录 一、路由服务就是一个WCF服务 路由服务契约的定义 路由服务契约的定义 二、基于消息内容的路由策略
信道管理器是信道的创建者,一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能,将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈,由于信道本身是由信道管理器创建的,所以信道对应的信道管理器也构成一个信道管理器栈,栈中信道管理器的顺序决定由它所创建信道的顺序。 对于WCF的信道层来说,信道管理器在服务端和客户端扮演着不同的角色,服务端的信道管理器在于监听来自客户端的请求,而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此,客户端的消息管理器又称为信道监听器(Channel
ASP.NET的输出缓存(Output Caching)机制允许我们针对整个Web页面或者页面的某个部分(主要针对用户控件)最终呈现的HTML进行缓存。对于后续针对相同资源的请求,只需要直接将缓存的HTML予以回复而无须按照页面处理生命周期对每次请求进行重复处理。WCF通过操作行为AspNetCacheProfileAttribute利用ASP.NET的输出缓存提供一种针对于某个操作的声明式缓存机制。[源代码从这里下载] 一、AspNetCacheProfileAttribute WCF对ASP.NET缓存
在上一篇文章中,我们通过一个直接借助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四大契约(服务契约、数据契约、消息契约和错误契约)之一的消息契约(Message Contract)。服务契约关注于对服务操作的描述,数据契约关注于对于数据结构和格式的描述,而消息契约关注的是类型成员与消息元素的匹配关系。 我们知道只有可序列化的对象才能通过服务调用在客户端和服务端之间进行传递。到目前为止,我们知道的可序列化类型有两种:一种是应用了System.SerializableAttribute特性或者实现了System.Runtime.Serialization.I
本文参考自http://www.cnblogs.com/wangweimutou/p/4517951.html,纯属读书笔记,加深记忆 一、理解WCF实例化机制 1、WCF实例化,是指对用户定义的服务
如果一个类型,不一定是数据契约,和给定的数据契约具有很大的差异,而我们要将该类型的对象序列化成基于数据契约对应的XML。反之,对于一段给定的基于数据契约的XML,要通过反序列化生成该类型的对象,我们该如何实现这样的场景? 比如下面定义了两个类型Contact和Customer,其中Customer是数据契约,Contact的Sex属性相当于Customer的Gender属性,而Contact的FullName可以看成是Customer的FirstName和LastName的组合。现在我们要做的是将一个Co
WCF客户端和服务端的框架体系相互协作,使得开发人员可以按照我们熟悉的方式进行异常的处理:在服务操作执行过程中抛出异常(FaultException),在调用服务时捕获异常,完全感觉不到“分布式”的存在,如同典型的“本地”操作一般。为了实现这样的效果,WCF在内部为我们作了很多。 消息交换是WCF进行通信的唯一手段,消息不仅仅是正常服务调用请求和回复的载体,服务端抛出的异常,甚至是服务的元数据都是通过消息的形式传向客户端的。所以,实现异常与消息之间的转换是整个异常处理体系的核心,而WCF的异常处理框架就着
服务调用的目的体现在对某项服务功能的消费上,而功能的实现又定义在相应的服务类型中。不论WCF服务端框架处理服务调用请求的流程有多么复杂,最终都落实在服务实例的激活和操作方法的执行上面。WCF中的实例管理(Instance Management)旨在解决服务实例的激活和服务实例生命周期的控制。 会话(Session)的目的在于保持来自相同客户端(服务代理)多次服务调用之间的状态。从消息交换的角度来讲,会话通过消息识别机制判断调用某个服务的消息来源,从而将来自相同客户端的所有消息关联在一起。所以,会话实现了消息
终结点是整个WCF的核心,由经典的ABC三要素组成。作为表示地址的EndpointAddress,很多人仅仅将其看成是一个表示标识服务并且表示服务所在地址的Uri,其实服务标识和定位服务仅仅是EndpointAddress一个基本的功能,它不仅仅是Uri那么简单。 一、EndpointAddress的三个功能 作为终结点的三要素之一的地址(Address),在基于WCF的通信中不仅仅定位着服务的位置,而且还提供额外的寻址信息。除此之外,终结点地址还和安全有关系,因为它包含着用于进行服务认证的服务身份信息。这
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
对于上一篇文章 (WCF基本异常处理模式:[上篇]、[中篇]、[下篇]),主要是站在最终开发者的角度对WCF关于异常处理编程模式进行了介绍,接下来,我们需要将我们的目光转移到WCF框架内部,深入剖析整个WCF异常处理流程。在基于SOAP的消息交换过程中,异常最终通过Fault消息承载,所以很自然地,接下来的介绍从SOAP Fault说起。 一、 从SOAP Fault说起(基于SOAP 1.2) 服务调用的最终实现通过消息交换完成,WCF本质上可以看成是一个消息处理的框架。消息,不但承载着正常服务调用的请
细算起来,已经有好几个月没有真正的写过文章了。近半年以来,一直忙于我的第一本WCF专著《WCF技术剖析》的写作,一直无暇管理自己的Blog。到目前为止《WCF技术剖析(卷1)》的写作暂告一段落,初步预计于下个月由武汉博文视点出版。在《WCF技术剖析》写作期间,对WCF又有了新的感悟,为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充,会对书中的一些内容进行展开讲述,同时会囊括很多由于篇幅的原因忍痛割弃的内容。 本系列的第一篇,我将会对WCF的基本架构作一个大致的讲解。不过,一改
通过《上篇》介绍,我们知道了如何通过编程和配置的方式设置相应的最大并发量,从而指导WCF的限流体系按照你设定的值对并发的服务调用请求进行限流控制。那么,在WCF框架体系内部,整个过程是如何实现的呢?这就是本篇文章需要为你讲述的内容。实际上,整个限流控制体系,主要涉及到两个对象:信道分发器(ChannelDispatcher)和ServiceThrottle。 一、信道分发器(ChannelDispatcher)与ServiceThrottle 从服务端整个消息监听、接收、分发和处理框架体系角度来讲,限流控
Microsoft技术栈最近有大量的变迁,这使得开发人员和领导者都想知道他们到底应该关注哪些技术。Microsoft自己并不想从官方层面上反对Silverlight这样的技术,相对而言他们更喜欢让这种技术慢慢淡出人们的视线,否则局面可能会更加混乱。如果你想了解该问题的答案,那么可以查看“.NET业务应用程序技术指南”这个小有名气的文档。该文档发布于去年早些时候,它深入探讨了Microsoft打算在哪些领域付出努力,我们应该回避哪些技术等内容。 下面这个概要图是我们探索Microsoft及其相关技术的一个很好
元数据的导出就是实现从ServiceEndpoint对象向MetadataSet对象转换的过程,在WCF元数据框架体系中,元数据的导出工作由MetadataExporter实现。MetadataExporter是一个抽象类型,定义了导出元数据的基本行为。WCF定义一个具体的MetadataExporter:WsdlExporter,将基于某个终结点的元数据导出生成基于WSDL的MetadataSet。我们先来认识MetadataExporter和MetadataSet。 一、MetadataExporte
REST服务采用面向资源的架构,而资源通过URI进行标识和定位,所以URI在REST中具有重要的地位。对于WCF来说,服务调用请求的URI映射为某个具体的操作,所以服务端需要解决的是如何根据请求URI选择出对应的操作。如果采用SOAP,操作的选择是根据消息的<Action>报头来实现的,那么REST服务又采用怎样的操作选择机制呢? 目录 一、URI模板 二、UriTemplate 三、UriTemplateTable 四、WebHttpDispatchOper
领取专属 10元无门槛券
手把手带您无忧上云