在《WCF调用技巧一》中，我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭。对于《WCF技术剖析（卷1）》的读者，应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题，现在我们来讨论这个解决方案。 通过《WCF服务代理不及时关闭会有什么后果》 的介绍，我们知道了及时关闭服务代理的重要意义，并且给..
在进行基于会话信道的WCF服务调用中，由于受到并发信道数量的限制，我们需要及时的关闭信道；当遇到某些异常，我们需要强行中止（Abort）信道，相关的原理，可以参考我的文章《WCF服务代理不及时关闭会有什么后果》。 在真正的企业级开发中，正如我们一般不会让开发人员手工控制数据库连接的开启和关闭一样，我们一般也不会让开发人员手工去..
我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactoryTChannel创建服务代理对象。在这篇文章中，我们采用一种独特的方式进行服务的调用。从本质上讲，我们只要能够创建于服务端相匹配的终结点，就能够实现正常的服务调用。在WCF客户端元数据架构体系中，..
元数据的发布方式决定了元数据的获取行为，WCF服务元数据架构体系通过ServiceMetadataBehavior实现了基于WS-MEX和HTTP-GET的元数据发布，针对这两种不同的协议，元数据获取的实现方式也是不同的。我们首先来实现基于WS-MEX的元数据获取方式。 [Source Code从这里下载]一、 基于WS-MEX的元数据获取 ServiceMetadataBehavior通过创建MEX终结..
基于HTTP-GET的元数据发布方式与基于如何将一个wcf服务发布成WSDL-基于WS-MEX类似,但是ServiceMetadataBehavior需要做的更多额外的工作。原因很简单，由于在WS-MEX模式下，我们为寄宿的服务添加了相应的MEX终结点，那么当服务被成功寄宿后，WCF已经为元数据的消息交换建立了如图1所示的分发体系，我们需要做的仅仅是对MEX终结点的DispatchRu..
通过《如何将一个wcf服务发布成WSDL》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。一、 从WCF分发体系谈起..
对于WCF服务端元数据架构体系来说，通过MetadataExporter将服务的终结点导出成MetadataSet（参考《如何导出WCF服务的元数据(Metadata)实现》），仅仅是完成了一半的工作。被成功导出的以MetadataSet对象表示的元数据需要最终作为可被访问的网络资源发布出来，才能被服务消费者获取，进而有效地帮助他们进行服务调用。元数据的发布最终是通过..
通过如何导出WCF服务的元数据(Metadata)实现对WSDL元素和终结点三要素的之间的匹配关系的介绍，我们知道了WSDL的Binding元素来源于终结点的绑定对象，那么这些基于Binding的元数据以及相应的策略断言是如何被写入WSDL的呢？WSDL导出扩展（WSDL Export Extension）和策略导出扩展（Policy Export Extension）就是为此设计的。一、WSDL导出扩展..
元数据的导出就是实现从ServiceEndpoint对象向MetadataSet对象转换的过程，在WCF元数据框架体系中，元数据的导出工作由MetadataExporter实现。MetadataExporter是一个抽象类型，定义了导出元数据的基本行为。WCF定义一个具体的MetadataExporter：WsdlExporter，将基于某个终结点的元数据导出生成基于WSDL的MetadataSet。我们先来认识Metadat..
在[wcf元数据（Metadata）架构体系-WS标准篇]中 我花了很大的篇幅介绍了WS-MEX以及与它相关的WS规范：WS-Policy、WS-Transfer和WSDL，因为WCF元数据结构体系完全是基 于WS-MEX等相关的规范之上。熟悉这些基本的WS规范，对于我们全面、深刻的理解WCF整个元数据架构体系具有十分重要的意义。不仅仅是针对元数据， 对于后续章节陆续要介绍的内容..
元数据实际上是服务终结点的描述，终结点由地址（Address）、绑定（Binding）和契约（Contract）经典的ABC三要素组成。认真阅读过《WCF技术剖析（卷1）》的读者相对会对这三要素的本质有一个深刻的认识：地址决定了服务的位置并实现相应的寻址机制；契约描述了消息交换模式（Message Exchange Pattern： MEP）以及消息的结构（Schema）；绑定..
服务端只有抛出FaultException异常才能被正常地序列化成Fault消息，并实现向客户端传播。对于一般的异常（比如执行Divide操作抛出的DivideByZeroException），在默认的情况下，异常信息无法实现向客户端传递。但是，倘若为某个服务应用了ServiceDebugBehavior这么一个服务行为，并开启了IncludeExceptionDetailInFaults开关，异常信息将会原..
在WCF控制服务实例（Service Instance）生命周期二中， 我们深入剖析了单调（PerCall）模式下WCF对服务实例生命周期的控制，现在我们来讨轮另一种极端的服务实例上下文模式：单例（Single）模 式。在单例模式下，WCF通过创建一个唯一的服务实例来处理所有的客户端服务调用请求。这是一个极端的服务实例激活方式，由于服务实例的唯一性，所有..
在[WCF控制服务实例（Service Instance）生命周期一]中，我们介绍了WCF关于实例管理一些基本的知识点，包括InstanceContext、InstanceContextMode、已经如何通过ServiceBehaviorAttribute应用不同的实例上下文模式给不同的服务。在[WCF控制服务实例（Service Instance）生命周期一]中，对WCF采用的三种不同实例上下文模式进行了简单的比较，..
服务调用的目的体现在对某项服务功能的消费上，而功能的实现又定义在相应的服务类型中。 不论WCF服务端框架处理服务调用请求的流程有多么复杂，最终都落实在服务实例的激活和操作方法的执行上面。WCF中的实例管理（Instance Management）旨在解决服务实例的激活和服务实例生命周期的控制。 会话（Session）的目的在于保持来自相同客户端（..
WCF客户端和服务端的框架体系相互协作，使得开发人员可以按照我们熟悉的方式进行异常的处理：在服务操作执行过程中抛出异常（FaultException），在调用服务时捕获异常，完全感觉不到分布式的存在，如同典型的本地操作一般。为了实现这样的效果，WCF在内部为我们作了很多。 消息交换是WCF进行通信的唯一手段，消息不仅仅是正常服务调用请求..
在WCF底层异常处理框架实现原理一中， 我们分别站在消息交换和编程的角度介绍了SOAP Fault和FaultException异常。在服务执行过程中，我们手工抛出FaultException异常，WCF服务端框架会对该异常对象进行 序列化病最终生成Fault消息。当WCF客户端框架介绍到该Fault消息之后，会做一项相反的操作：对Fault消息中进行解析和反序列化，重新生成 并..
对于上一篇文章 （WCF基本异常处理模式：WCF异常处理模式一、WCF异常处理模式二、WCF异常处理模式三）, 主要是站在最终开发者的角度对WCF关于异常处理编程模式进行了介绍,接下来，我们需要将我们的目光转移到WCF框架内部，深入剖析整个WCF异常处理流 程。在基于SOAP的消息交换过程中，异常最终通过Fault消息承载，所以很自然地，接下来的介绍..
从FaultContractAttribute的定义我们可以看出，该特性可以在同一个目标对象上面多次应用（AllowMultiple = true）。这也很好理解：对于同一个服务操作，可能具有不同的异常场景，在不同的情况下，需要抛出不同的异常。 1: [AttributeUsage(AttributeTargets.Method, AllowMultiple = true, Inherited = false)] 2: public sealed class ..
通过WCF异常处理模式一， 我们知道了：在默认的情况下，服务端在执行某个服务操作时抛出的异常（在这里指非FaultException异常），其相关的错误信息仅仅限于服务端可 见，并不会被WCF传递到客户端；如果将开启了IncludeExceptionDetailInFaults的ServiceDebug服务行为通过声 明（通过在服务类型上应用ServiceBehaviorAttrite特性）或者配置的..
由于WCF采用.NET托管语言（C#和NET）作为其主要的编程语言，注定以了基于 WCF的编程方式不可能很复杂。同时，WCF设计的一个目的就是提供基于非业务逻辑的通信实现，为编程人员提供一套简单易用的应用编程接口（API）。 WCF编程模式的简单性同样体现在异常处理上面，本篇文章的主要目的就是对WCF基于异常处理的编程模式做一个简单的介绍。一、..
任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需 的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个..
通过wcf消息编码（Encoding）实现一的介绍，我们知道了WCF所有与编码与解码相关的功能都实现在相应的System.Xml.XmlDictionaryWriter和System.Xml.XmlDictionaryReader中。但是在真正的WCF处理框架中，却并不直接使用XmlDictioanryWriter和XmlDictionaryReader对象，而通过相应的消息编码器（System.ServiceModel.Channels.MessageEncoder）..
消息作为WCF进行通信的唯一媒介，最终需要通过写入传输层进行传递。而对消息进行传输的一个前提或者是一项必不可少的工作是对消息进行相应的编 码。WCF提供了一系列可供选择的编码方式，它们分别在互操作和性能各具优势。在本篇文章我们将对各种编码方式进行消息的讨论。 从互操 作性的角度来看，编码方法很大程度上决定了跨平台支持的能..
服务契约关注于对服务操作的描述，数据契约关注于对于数据结构和格式的描述，而消息契约关注的是类型成员与消息元素的匹配关系。 我们知道只有可序列化的对象才能通过服务调用在客户端和服务端之间进行传递。到目前为止，我们知道的可序列化类型有两种：一种是应用了System.SerializableAttribute特性或者实现了System.Runtime.Serializa..
在《消息（Message）详解》系列的wcf使用消息（Message）一和wcf使用消息（Message）二，先后对消息版本、详细创建、状态机和基于消息的基本操作（读取、写入、拷贝、关闭）进行了深入剖析，接下来我们来谈谈消息的另一个重要组成部分：消息报头（Message Header）。 按 照SOAP1.1或者SOAP1.2规范，一个SOAP消息由若干SOAP报头和一个SOAP..
在wcf使用消息（Message）一中 大体上围绕着Message的两个话题进行讲述：消息版本（Message Version）和采用五种不同的方式创建Message。本篇文章将会详细介绍Message的另外两个主题：和消息的基本操作，比如读、写、拷贝、关 闭等，以及消息状态机（Message State Machine）。 知道了消息是如何创建的，我们接着讨论消息的一些基本的操作..
消息交换是WCF进行通信的唯一手段，通过方法调用（Method Call）形式体现的服务访问需要转化成具体的消息，并通过相应的编码（Encoding）才能通过传输通道发送到服务端；服务操作执行的结果也只能以消 息的形式才能被正常地返回到客户端。所以，消息在整个WCF体系结构中处于一个核心的地位，WCF可以看成是一个消息处理的管道。 尽管消息在..
数据契约是对用于交换的数据结构的描述，是数据序列化和反序列化的依据。在一个WCF应 用中，客户端和服务端必须通过等效的数据契约方能进行有效的数据交换。随着时间的推移，不可避免地，我们会面临着数据契约版本的变化，比如数据成员的添加 和删除、成员名称或者命名空间的修正等，如何避免数据契约这种版本的变化对客户端现有程序造成影响..
如果一个类型，不一定是数据契约，和给定的数据契约具有很大的差异，而我们要将该类型的对象序列化成基于数据契约对应的XML。反之，对于一段给定的基于数据契约的XML，要通过反序列化生成该类型的对象，我们该如何实现这样的场景？ 比如下面定义了两个类型Contact和Customer，其中Customer是数据契约，Contact的Sex属性相当于Customer的 ..
