摘要： 在上篇中，我详细介绍了如何通过自定义ClientMessageInspector和ErrorHandler，实现WCF与微软企业库中的Exception Handling Application Block（EHAB）之间的集成。本篇中，我们对其加以改进，使你不需要再为每个操作应用相同的FaultContractAttribute。 阅读全文

摘要： 在《WCF技术剖析（卷1）》的最后一章，我给出了一个具体的应用WCF的分布式应用实例，我把这个实例命名为PetShop。看过本书的读者，一定还记得我还通过WCF扩展实现了于微软企业库（Enterprise Library）异常处理应用块（Exception Handling Application Block：EHAB）的集成,现在我们可以详细来讲述这是如何实现的。 阅读全文

摘要： 在[第2篇]中，我们深入剖析了单调（PerCall）模式下WCF对服务实例生命周期的控制，现在我们来讨轮另一种极端的服务实例上下文模式：单例（Single）模式。 阅读全文

摘要： 在[上篇]中，我们介绍了WCF关于实例管理一些基本的知识点，包括InstanceContext、InstanceContextMode、已经如何通过ServiceBehaviorAttribute应用不同的实例上下文模式给不同的服务。在[第1篇]中，对WCF采用的三种不同实例上下文模式进行了简单的比较，本篇的重点方法对单调（PerCall）模式为进行详细介绍。 在单调（Per-Call）实例上下文模式下，WCF总是创建一个新的服务实例上下文处理接收到的每一个服务调用请求，并在服务操作执行结束后，回收服务上下文和服务实例。换句话说，单调服务实例上下文模式使服务实例上下文的生命周期与服务调用本身绑定。我们首先来介绍单调模式下服务实例上下文具体有怎样的生命周期。 阅读全文

摘要： 最近，用户提出了一个要求：需要通过按键方式来控制容器控件竖直滚动条。具体来讲就是说，如果一个容器内容过多，用户可以通过按键PageUp和PageDown来控制上下的滚动。刚开始，我试图采用注册事件的方式来实现，但是效果不理想，一来是没有一个单一的地方来对所有相关空间进行事件注册操作，二来如果容器被子控件完全遮挡，容器空间的事件将不会正常出发。有个同事提示采用自定义MessageFilter的方式，我觉得可行，于是进行了一番尝试。 阅读全文

摘要： HP QC（Quantity Center）是一款不错的测试管理工具，最近把公司的操作系统从Windows XP升级到Windows 7之后，发现登录到QC Server的Addin页面，很多客户端组件不能正常下载，从而导致整个QC不能使用。通过Google找到了解决方案，特发出来与大家共享，希望那些在Windows 7上使用HP QC的朋友遇到该问题的时候，能过及时得到解决。 阅读全文

摘要： 服务调用的目的体现在对某项服务功能的消费上，而功能的实现又定义在相应的服务类型中。不论WCF服务端框架处理服务调用请求的流程有多么复杂，最终都落实在服务实例的激活和操作方法的执行上面。WCF中的实例管理（Instance Management）旨在解决服务实例的激活和服务实例生命周期的控制上。对实例管理合理利用，对于改善和提高WCF服务应用的可扩展性（Scalability）、性能（Performance）、吞吐量（Throughput）等具有决定性作用。 阅读全文

摘要： 今天在一个由矿大校友组成的QQ群里，有人发了一个视频连接链接（http://v.youku.com/v_show/id_XMTI2MTQwNzIw.html），点进去看，原来是一部由矿也大学投资拍摄的影片，名字叫做《我在这里》，是为了中国矿业大学百年校庆而拍摄。影片以中国矿业大学年轻学生的爱情故事为主轴，讲述了以庞小元、胡紫心为代表的新一代大学生的情感生活与奋斗历程。他们敢爱敢恨，经历困惑之后最终确立了人生的理想，将青春奉献给祖国最需要的地方，投身采矿事业。影片通过老、中、青三代矿大人的故事展现了矿大人爱国爱校、艰苦奋斗、无私奉献的精神。时长90多分钟的影片由青年导演武洪武先生执导，从我校南湖校区教学楼、行政楼、实验室、餐厅和学生宿舍等多个地点实地取景，以我校学生作为群众演员进行拍摄。 阅读全文

摘要： 在[上篇]中，我们分别站在消息交换和编程的角度介绍了SOAP Fault和FaultException异常。在服务执行过程中，我们手工抛出FaultException异常，WCF服务端框架会对该异常对象进行序列化病最终生成Fault消息。当WCF客户端框架介绍到该Fault消息之后，会做一项相反的操作：对Fault消息中进行解析和反序列化，重新生成并抛出FaultException异常。WCF框架自动为我们作了这么多“幕后”工作，使得开发人员可以完全采用编写一般的.NET应用程序的模式进行异常的处理：在错误的地方抛出相应异常，对于潜在出错的方法调用进行相应的异常捕获和处理。所以，WCF的异常处理框架的核心功能就是实现FaultException异常和Faul 阅读全文

摘要： 对于上一篇文章 （WCF基本异常处理模式：[上篇]、[中篇]、[下篇]）,主要是站在最终开发者的角度对WCF关于异常处理编程模式进行了介绍,接下来，我们需要将我们的目光转移到WCF框架内部，深入剖析整个WCF异常处理流程。 阅读全文

摘要： 从FaultContractAttribute的定义我们可以看出，该特性可以在同一个目标对象上面多次应用（AllowMultiple = true）。但是，如果你在同一个操作方法上面应用了多了FaultContractAttribute特性的时候，需要遵循怎样的规则呢，这是本篇文章着重要介绍的内容。 阅读全文

摘要： 通过WCF基本的异常处理模式[上篇]， 我们知道了：在默认的情况下，服务端在执行某个服务操作时抛出的异常（在这里指非FaultException异常），其相关的错误信息仅仅限于服务端可见，并不会被WCF传递到客户端；如果将开启了IncludeExceptionDetailInFaults的ServiceDebug服务行为通过声明（通过在服务类型上应用ServiceBehaviorAttrite特性）或者配置的方式应用到相应的服务上，异常相关的所有细节信息将会原封不动地向客户端传送。 这两种方式体现了两种极端的异常传播（Exception Propagation）机制，对于基于服务操作执行过程中抛出的异常的错误细节，要么完全对客户端屏蔽，要么全部暴露于客户端。 阅读全文

摘要： 由于WCF采用.NET托管语言（C#和NET）作为其主要的编程语言，注定以了基于WCF的编程方式不可能很复杂。同时，WCF设计的一个目的就是提供基于非业务逻辑的通信实现，为编程人员提供一套简单易用的应用编程接口（API）。WCF编程模式的简单性同样体现在异常处理上面，本篇文章的主要目的就是对WCF基于异常处理的编程模式做一个简单的介绍。 阅读全文

摘要： 任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个运行环境。服务寄宿的手段是为一个WCF服务类型创建一个ServiceHost对象（或者任何继承于ServiceHostBase的对象）。无论采用哪种寄宿方式，在为某个服务创建ServiceHost的过程中，WCF框架内部会执行一系列的操作，其中最重要的步骤就是为服务创建服务描述（Service Description）。在本篇文章中，我们将对服务描述进行全面的介绍。 阅读全文

摘要： 通过上篇的介绍，我们知道了WCF所有与编码与解码相关的功能都实现在相应的XmlDictionaryWriter和XmlDictionaryReader中。但是在真正的WCF处理框架中，却并不直接使用XmlDictioanryWriter和XmlDictionaryReader对象，而通过相应的消息编码器（MessageEncoder）对其进行进一步封装，专门用于消息的编码和解码。 阅读全文

摘要： 消息作为WCF进行通信的唯一媒介，最终需要通过写入传输层进行传递。而对消息进行传输的一个前提或者是一项必不可少的工作是对消息进行相应的编码。WCF提供了一系列可供选择的编码方式，它们分别在互操作和性能各具优势。在本篇文章我们将对各种编码方式进行消息的讨论。 阅读全文

摘要： [For Arnon Rotem-Gal-Oz’s Article:http://dobbscodetalk.com/index.php?option=com_myblog&show=CRUD-is-bad-for-REST.html&Itemid=29]In one of my previous posts (Rest: good, bad and ugly), I made a passing comment, about how I think using CRUD in RESTful service is a bad practice. I received a few comments / questions asking why do I say that – so what’s wrong with CRUD and REST? 阅读全文

摘要： 在本篇文章中，我们将讨论WCF四大契约（服务契约、数据契约、消息契约和错误契约）之一的消息契约（Message Contract）。服务契约关注于对服务操作的描述，数据契约关注于对于数据结构和格式的描述，而消息契约关注的是类型成员与消息元素的匹配关系...... 阅读全文

摘要： 《WCF技术剖析（卷1）》自出版近20天以来，得到了园子里的朋友和广大WCF爱好者的一致好评，并被卓越网计算机书店作为首页推荐，在这里对大家的支持表示感谢。同时我将一直坚持这个博文系列，与大家分享我对WCF一些感悟和学习经验。在《消息（Message）详解》系列的上篇和中篇，先后对消息版本、详细创建、状态机和基于消息的基本操作（读取、写入、拷贝、关闭）进行了深入剖析，接下来我们来谈谈消息的另一个重要组成部分：消息报头（Message Header）。 阅读全文

摘要： 在上篇中大体上围绕着Message的两个话题进行讲述：消息版本（Message Version）和采用五种不同的方式创建Message。本篇文章将会详细介绍Message的另外两个主题：和消息的基本操作，比如读、写、拷贝、关闭等，以及消息状态机（Message State Machine）。 阅读全文

摘要： 消息交换是WCF进行通信的唯一手段，通过方法调用（Method Call）形式体现的服务访问需要转化成具体的消息，并通过相应的编码（Encoding）才能通过传输通道发送到服务端；服务操作执行的结果也只能以消息的形式才能被正常地返回到客户端。所以，消息在整个WCF体系结构中处于一个核心的地位，WCF可以看成是一个消息处理的管道。接下来我将分上、中、a href="http://www.cnblogs.com/artech/archive/200 阅读全文

摘要： 数据契约是对用于交换的数据结构的描述，是数据序列化和反序列化的依据。在一个WCF应用中，客户端和服务端必须通过等效的数据契约方能进行有效的数据交换。随着时间的推移，不可避免地，我们会面临着数据契约版本的变化，比如数据成员的添加和删除、成员名称或者命名空间 阅读全文

摘要： 如果一个类型，不一定是数据契约，和给定的数据契约具有很大的差异，而我们要将该类型的对象序列化成基于数据契约对应的XML。反之，对于一段给定的基于数据契约的XML，要通过反序列化生成该类型的对象，我们该如何实现这样的场景？ 这就需要使用到一个特殊的对象：数据契约代理（DataContract Surrogate）。 阅读全文

摘要： 本书从WCF的终结点谈起，对终结点的三要素进行了全面而深入的介绍，帮助读者了解地址、绑定和契约的本质。通过本书对序列化的深入讲解，读者可了解WCF进行操作方法调用与消息之间转化的本质；深入剖析消息编码则会帮助读者从根本上把握WCF进行消息编码和解码的实现机制，以及不同编码方式在性能、互操作性及使用场景上的差异；同时本书从WCF的服务端框架和客户端框架进行深层次的剖析，介绍了服务寄宿和服务调用；对实例化和会话进行了讨论，从服务实例的激活和客户端状态保持两个侧面详细介绍WCF的实例上下文提供机制和基于会话信道的会话实现。最后，本书提供了一个完整的案例帮助读者掌握如何利用本书涉及的内容搭建一个基本的WCF分布式应用。本书不仅适合那些尚未接触过WCF，希望尽快入门并进行深入研究的开发人员，同样适合那些对WCF有一定了解的开发设计人员和架构师。 阅读全文

摘要： 在.NET中，所有的集合都实现了IEnumerable接口，比如Array、Hashtable、ArrayList、Stack、Queue等。有的集合要求元素具有相同的类型，这种集合一般通过泛型的方式定义，它们实现另一个接口IEnumerable（IEnumerable本身继承自IEnumerable），这样的集合有List、Dictionary、Stack、Queue等。基于集合类型的序列化具有一些特殊的规则和行为，在上篇中我们详细介绍了基于泛型数据契约的序列化规则，接下来我们介绍基于集合对象的序列化，以及基于集合类型的服务操作。 阅读全文

摘要： 在.NET Framework 2.0中，泛型第一次被引入。我们可以定义泛型接口、泛型类型、泛型委托和泛型方法。序列化依赖于真实具体的类型，而泛型则刻意模糊了具体类型概念。而集合代表一组对象的组合，集合具有可迭代（Enumerable）的特性，可以通过某个迭代规则遍历集合中的每一个元素。由于范型类型和集合类型在序列化和反序列化上具有一些特殊的行为和规则，在这篇文章中，我将会对此进行详细介绍。上篇先来说所泛型数据契约。 阅读全文

摘要： [爱心链接：拯救一个25岁身患急性白血病的女孩[内有苏州电视台经济频道《天天山海经》为此录制的节目视频（苏州话）]]DataContractSerializer承载着所有数据契约对象的序列化和反序列化操作。在上面一篇文章（《数据契约（Data Contract）和数据契约序列化器（DataContractSerializer）》）中，我们谈到DataContractSerializer基本的序列化规则；如何控制DataContractSerializer序列化或者反序列化对象的数量；以及如何在序列化后的XM 阅读全文

摘要： [爱心链接：拯救一个25岁身患急性白血病的女孩[内有苏州电视台经济频道《天天山海经》为此录制的节目视频（苏州话）]] 大部分的系统都是以数据为中心的（Data Central），功能的实现表现在对相关数据的正确处理。而数据本身，是有效信息的载体，在不同的环境具有不同的表示。一个分布式的互联系统关注于数据的交换，而数据正常交换的根本前提是参与数据交换的双方对于数据结构的一致性理解。WCF下的序列化（Serialization）解决的是如何将数据从对象的表现形式转变成XML表现形式，以确保数据的正常交换。从本章起，我将讲述WCF序列化的本质，首先从从数据契约谈起。 阅读全文

摘要： 说完了客户端的异步服务调用（参阅WCF技术剖析之十一：异步操作在WCF中的应用（上篇））,我们在来谈谈服务端如何通过异步的方式为服务提供实现。在定义服务契约的时候，相信大家已经注意到了OperationContractAttribute特性具有一个bool类型的AsynPattern。该属性可以将一个服务操作定义成异步实现模式，接下来的内容主要是着眼于介绍异步操作的定义和实现原理。 阅读全文

摘要： 按照操作执行所需的资源类型，我们可以将操作分为CPU绑定型（CPU Bound）操作和I/O绑定型（I/O Bound）操作。对于前者，操作的执行主要利用CPU进行密集的计算，而对于后者，大部分的操作处理时间花在I/O操作处理，比如访问数据库、文件系统、网络资源等。对于I/O绑定型操作，我们可以充分利用多线程的机制，让多个操作在自己的线程并发执行，从而提高系统性能和响应能力。服务调用就是典型的I/O绑定型操作，所以多线程在服务调用中具有广泛的应用。在本篇文章中，我们专门来讨论多线程或者是异步操作在WCF中的具体应用。 阅读全文

摘要： 在前面一片文章（服务代理不能得到及时关闭会有什么后果?）中，我们谈到及时关闭服务代理（Service Proxy）在一个高并发环境下的重要意义，并阐明了其根本原因。但是，是否直接调用ICommunicationObject的Close方法将服务代理关闭就万事大吉了呢？事情远不会这么简单，这其中还会涉及关于异常处理的一些操作，这就是本篇文章需要讨论的话题。 阅读全文

摘要： 我们想对WCF具有一定了解的人都会知道：在客户端通过服务调用进行服务调用过程中，服务代理应该及时关闭。但是如果服务的代理不等得到及时的关闭，到底具有怎样的后果？什么要关闭服务代理？在任何时候都需要关闭服务代理吗？是否有一些例外呢？本篇文章将会围绕着这些问题展开。 阅读全文

摘要： 和传统的分布式远程调用一样，WCF的服务调用借助于服务代理（Service Proxy）。而ChannelFactory则是服务代理的创建者。在客户端，我们具有两种典型的服务代理创建方式，其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理（一个继承自ClientBase的类型）代码和相关配置；其二是直接通过相应的终结点信息（通过代码指定或者配置）创建ChannelFactory对象，并借助该对象直接进行服务代理的创建。实际上，即使通过ClientBase对象进行服务调用，其内部也是调用ChannelFactory创建的服务代理。整个ChannelFactory的创建是一项相对复杂并且费时的工作，会涉及很多诸如反射、配置文件的读取等操作。为了提高服务调用的性能，在.NET 3.5中，WCF在ClientBase中引入了ChannelFac 阅读全文

摘要： 我不知道在博客园首页发布者这样一个帖子，对于一个技术论坛性质的网站是否适合，为此在发文之前特意征得了DUDU的同意。标题所说的那个女孩名称程婷，是我一个同事的女朋友，于一个月前诊断出得了M7型急性白血病。之前，没有任何征兆，仅仅是确诊当天刷牙流血不止。医院的诊断犹如晴天霹雳，给我的同事和他们的家庭以沉重的打击。这个同事同时也是我很好的朋友，我在第一时间得到这个消息，我当时都不敢相信这是真的。每天下班都见到的一个活泼可爱的女孩，怎么突然“身患绝症”画上等号？这些本以为在韩剧中才能见到的故事，怎么可能突然降临到你我的身边？ 阅读全文

摘要： 在这之前，我写过深入介绍MS EnterLib PIAB的文章（参阅《MS Enterprise Library Policy Injection Application Block 深入解析[总结篇]》），也写过WCF与PIAB的集成（参阅：《WCF后续之旅（8）：通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成》）、WCF与Unity的集成（参阅《WCF后续之旅（7）：通过WCF Extension实现和Enterprise Library Unity Container的集成》）以及Unity与PIAB的集成（参阅《Enterprise Library深入解析与灵活应用（1）：通过Unity Extension实现和Policy Injection Application Block的集成》、 阅读全文

摘要： 在EnteLib中，PIAB（Policy Injection Application Block）和Unity的定位是轻量级的AOP框架和IoC容器（Container）。通过PIAB，我们可以将一些业务无关的crosscutting concern定义于相应的CallHandler中，通过Attribute声明或者配置应用到承载业务逻辑的目标方法上。而通过Unity提供的IoC容器（或者DI容器），即UnityContainer，很好地实现了依赖的动态注入，从而实现了组件之间、模块之间或者服务之间的松耦合。在本篇文章中,我们将关注如何将两者有机地关联起来。 阅读全文

摘要： 本篇文章来源于几天前一个朋友向我咨询的问题。问题是这样的，他说他采用ASP.NET应用程序的方式对定义的WCF服务进行寄宿（Hosting），并使用配置的方式对服务的BaseAddress进行了设置，但是在创建ServiceHost的时候却抛出InvalidOperationException，并提示相应Address Scheme的BaseAddress找不到。我意识到这可能和WCF中用于判断服务寄宿方式的逻辑有关，于是我让这位朋友将相同的服务寄宿代码和配置迁移到GUI程序或者Console应用中，看看是否正常。结果如我所想，一切正常，个人觉得这应该是WCF的一个Bug。今天撰文与大家讨论，看看大家对这个问题有何见解。 阅读全文

摘要： 在《基于IIS的WCF服务寄宿（Hosting）实现揭秘》中，我们谈到在采用基于IIS（或者说基于ASP.NET）的WCF服务寄宿中，具有两种截然不同的运行模式：ASP.NET并行（Side by Side）模式和ASP.NET兼容模式。对于前者，WCF通过HttpModule实现了服务的寄宿，而对于后者，WCF的服务寄宿通过一个HttpHandler实现。只有在ASP.NET兼容模式下，我们熟悉的一些ASP.NET机制才能被我们使用，比如通过HttpContext的请求下下文；基于文件或者Url的授权；HttpModule扩展；身份模拟（Impersonation）等。 由于在ASP.NET兼容模式下，ASP.NET采用与.aspx Page完全一 阅读全文

摘要： 通过《再谈IIS与ASP.NET管道》的介绍，相信读者已经对IIS和ASP.NET的请求处理管道有了一个大致的了解，在此基础上去理解基于IIS服务寄宿的实现机制就显得相对容易了。概括地说，基于IIS的服务寄宿依赖于两个重要的对象：System.ServiceModel.Activation.HttpModule和System. ServiceModel.Activation.HttpHandler。 阅读全文

摘要： 在上面一篇文章中，我们对不同版本的IIS，以及ASP.NET得的实现机制进行了详细而深入的分析。在介绍IIS7.0的时候，我们谈到，HTTP.SYS+W3SVC实现了基于HTTP的请求监听，在此基础上引入了三组网络监听器（Listener）和监听适配器（Adapter），实现了基于TCP、Named Pipes和MSMQ的网络监听。由于IIS 7提供了基于非HTTP网络协议的监听支持，那么就意味着当我们当我们通过IIS进行WCF服务寄宿（Hosting）的时候，可以采用非HTTP的通信方式。在本篇文章中，我们将通过一个简单实例介绍进行非HTTP的IIS服务寄宿，Source Code下载a href ="http://fil 阅读全文