随笔分类 - [01] 技术剖析
摘要：
在《上篇》中，我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭。对于《WCF技术剖析（卷1）》的读者，应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题，现在我们来讨论这个解决方案。
阅读全文
在《上篇》中，我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭。对于《WCF技术剖析（卷1）》的读者，应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题，现在我们来讨论这个解决方案。
阅读全文
摘要：在进行基于会话信道的WCF服务调用中，由于受到并发信道数量的限制，我们需要及时的关闭信道；当遇到某些异常，我们需要强行中止（Abort）信道。在真正的企业级开发中，正如我们一般不会让开发人员手工控制数据库连接的开启和关闭一样，我们一般也不会让开发人员手工去创建、开启、中止和关闭信道，这些工作是框架应该完成的操作。这篇文章，我们就来介绍如果通过一些编程技巧，让开发者能够无视“信道”的存在，像调用一个普通对象一样进行服务调用。
阅读全文
在进行基于会话信道的WCF服务调用中，由于受到并发信道数量的限制，我们需要及时的关闭信道；当遇到某些异常，我们需要强行中止（Abort）信道。在真正的企业级开发中，正如我们一般不会让开发人员手工控制数据库连接的开启和关闭一样，我们一般也不会让开发人员手工去创建、开启、中止和关闭信道，这些工作是框架应该完成的操作。这篇文章，我们就来介绍如果通过一些编程技巧，让开发者能够无视“信道”的存在，像调用一个普通对象一样进行服务调用。
阅读全文
摘要：我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactory创建服务代理对象。在这篇文章中，我们采用一种独特的方式进行服务的调用。
阅读全文
我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactory创建服务代理对象。在这篇文章中，我们采用一种独特的方式进行服务的调用。
阅读全文
摘要：元数据的发布方式决定了元数据的获取行为，WCF服务元数据架构体系通过ServiceMetadataBehavior实现了基于WS-MEX和HTTP-GET的元数据发布，针对这两种不同的协议，元数据获取的实现方式也是不同的,本片文章中通过自己的方式进行元数据获取，可以看成是对WCF客户端元数据框架的模拟。
阅读全文
元数据的发布方式决定了元数据的获取行为，WCF服务元数据架构体系通过ServiceMetadataBehavior实现了基于WS-MEX和HTTP-GET的元数据发布，针对这两种不同的协议，元数据获取的实现方式也是不同的,本片文章中通过自己的方式进行元数据获取，可以看成是对WCF客户端元数据框架的模拟。
阅读全文
摘要：在上篇文章中，我通过程序模拟了基于WS-MEX模式下元数据的发布，现在我们来模拟另外一中元数据发布模式：HTTP-GET，这两个模拟程序不仅仅会帮助你深刻地理解WCF的元数据发布机制，对你进一步认识WCF服务端的分发体系具有重要的帮助。
阅读全文
在上篇文章中，我通过程序模拟了基于WS-MEX模式下元数据的发布，现在我们来模拟另外一中元数据发布模式：HTTP-GET，这两个模拟程序不仅仅会帮助你深刻地理解WCF的元数据发布机制，对你进一步认识WCF服务端的分发体系具有重要的帮助。
阅读全文
摘要：通过《如何将一个服务发布成WSDL[编程篇]》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。
阅读全文
通过《如何将一个服务发布成WSDL[编程篇]》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。
阅读全文
摘要：对于WCF服务端元数据架构体系来说，通过MetadataExporter将服务的终结点导出成MetadataSet，仅仅是完成了一半的工作。被成功导出的以MetadataSet对象表示的元数据需要最终作为可被访问的网络资源发布出来，才能被服务消费者获取，进而有效地帮助他们进行服务调用。元数据的发布最终是通过ServiceMetadataBehavior这样一个服务行为实现的。
阅读全文
对于WCF服务端元数据架构体系来说，通过MetadataExporter将服务的终结点导出成MetadataSet，仅仅是完成了一半的工作。被成功导出的以MetadataSet对象表示的元数据需要最终作为可被访问的网络资源发布出来，才能被服务消费者获取，进而有效地帮助他们进行服务调用。元数据的发布最终是通过ServiceMetadataBehavior这样一个服务行为实现的。
阅读全文
摘要：通过《实现篇》对WSDL元素和终结点三要素的之间的匹配关系的介绍，我们知道了WSDL的Binding元素来源于终结点的绑定对象，那么这些基于Binding的元数据以及相应的策略断言是如何被写入WSDL的呢？WSDL导出扩展（WSDL Export Extension）和策略导出扩展（Policy Export Extension）就是为此设计的。
阅读全文
通过《实现篇》对WSDL元素和终结点三要素的之间的匹配关系的介绍，我们知道了WSDL的Binding元素来源于终结点的绑定对象，那么这些基于Binding的元数据以及相应的策略断言是如何被写入WSDL的呢？WSDL导出扩展（WSDL Export Extension）和策略导出扩展（Policy Export Extension）就是为此设计的。
阅读全文
摘要：元数据的导出就是实现从ServiceEndpoint对象向MetadataSet对象转换的过程，在WCF元数据框架体系中，元数据的导出工作由MetadataExporter实现。MetadataExporter是一个抽象类型，定义了导出元数据的基本行为。WCF定义一个具体的MetadataExporter：WsdlExporter，将基于某个终结点的元数据导出生成基于WSDL的MetadataSet。我们先来认识MetadataExporter和MetadataSet。
阅读全文
元数据的导出就是实现从ServiceEndpoint对象向MetadataSet对象转换的过程，在WCF元数据框架体系中，元数据的导出工作由MetadataExporter实现。MetadataExporter是一个抽象类型，定义了导出元数据的基本行为。WCF定义一个具体的MetadataExporter：WsdlExporter，将基于某个终结点的元数据导出生成基于WSDL的MetadataSet。我们先来认识MetadataExporter和MetadataSet。
阅读全文
摘要：在[WS标准篇]中我花了很大的篇幅介绍了WS-MEX以及与它相关的WS规范：WS-Policy、WS-Transfer和WSDL，因为WCF元数据结构体系完全是基于WS-MEX等相关的规范之上。熟悉这些基本的WS规范，对于我们全面、深刻的理解WCF整个元数据架构体系具有十分重要的意义。接下来我们具体来介绍基于MetadataSection和MetadataSet基于两个类型的元数据表示。
阅读全文
在[WS标准篇]中我花了很大的篇幅介绍了WS-MEX以及与它相关的WS规范：WS-Policy、WS-Transfer和WSDL，因为WCF元数据结构体系完全是基于WS-MEX等相关的规范之上。熟悉这些基本的WS规范，对于我们全面、深刻的理解WCF整个元数据架构体系具有十分重要的意义。接下来我们具体来介绍基于MetadataSection和MetadataSet基于两个类型的元数据表示。
阅读全文
摘要：
微软EnterLib的PIAB是一个比较好用的轻量级的AOP框架，自身也提供了一系列的CallHandler，其中CachingCallHandler直接利用HttpRuntime的Cache实现了基于方法级别的缓存。但是，PIAB发布到现在，CachingCallHandler就一直存着一个问题：如果目标方法具有Out参数并且返回类型不是void，会抛出IndexOutOfRangeException，如果返回类型为void，out参数也不会被缓存。不知道微软对此作何考虑，反正我觉得这是一个不可原谅的Bug。
阅读全文
微软EnterLib的PIAB是一个比较好用的轻量级的AOP框架，自身也提供了一系列的CallHandler，其中CachingCallHandler直接利用HttpRuntime的Cache实现了基于方法级别的缓存。但是，PIAB发布到现在，CachingCallHandler就一直存着一个问题：如果目标方法具有Out参数并且返回类型不是void，会抛出IndexOutOfRangeException，如果返回类型为void，out参数也不会被缓存。不知道微软对此作何考虑，反正我觉得这是一个不可原谅的Bug。
阅读全文
摘要：在《WCF技术剖析（卷1）》中，我多次向读者强调WCF进行通信的本质：终结点是客户端和服务端进行通信的手段。服务的提供者通过一个或者多个终结点将服务发布出来；服务的消费者则通过创建于之匹配的终结点进行服务的调用。站在服务消费者的角度，这样一个“匹配”的终结点该如何创建呢？或者说客户端基于何种信息创建能够有效调用目标服务的终结点呢？这就是元数据需要解决的问题。
阅读全文
在《WCF技术剖析（卷1）》中，我多次向读者强调WCF进行通信的本质：终结点是客户端和服务端进行通信的手段。服务的提供者通过一个或者多个终结点将服务发布出来；服务的消费者则通过创建于之匹配的终结点进行服务的调用。站在服务消费者的角度，这样一个“匹配”的终结点该如何创建呢？或者说客户端基于何种信息创建能够有效调用目标服务的终结点呢？这就是元数据需要解决的问题。
阅读全文
摘要：通过上一篇了解了模块内基本的层次划分之后，接下来我们来聊聊PetShop中一些基本基础功能的实现，以及一些设计、架构上的应用如何同WCF进行集成。本篇讨论两个问题：实现分布式的Membership和客户端到服务端上下文（Context）的传递。
阅读全文
通过上一篇了解了模块内基本的层次划分之后，接下来我们来聊聊PetShop中一些基本基础功能的实现，以及一些设计、架构上的应用如何同WCF进行集成。本篇讨论两个问题：实现分布式的Membership和客户端到服务端上下文（Context）的传递。
阅读全文
摘要：
在上篇中我们谈到：将一个生命周期较短的对象（对象A）注册到一个生命周期较长（对象B）的某个事件（Event）上，两者便无形之间建立一个引用关系（B引用A）。这种引用关系导致GC在进行垃圾回收的时候不会将A是为垃圾对象，最终使其常驻内存（或者说将A捆绑到B上，具有了和B一样的生命周期）。这种让无用的对象不能被GC垃圾回收的现象，在托管环境下就是一种典型的内存泄漏问题。我们今天将会着重解释其背后的原因。
阅读全文
在上篇中我们谈到：将一个生命周期较短的对象（对象A）注册到一个生命周期较长（对象B）的某个事件（Event）上，两者便无形之间建立一个引用关系（B引用A）。这种引用关系导致GC在进行垃圾回收的时候不会将A是为垃圾对象，最终使其常驻内存（或者说将A捆绑到B上，具有了和B一样的生命周期）。这种让无用的对象不能被GC垃圾回收的现象，在托管环境下就是一种典型的内存泄漏问题。我们今天将会着重解释其背后的原因。
阅读全文
摘要：最近这两天一直在忙着为一个项目检查内存泄漏（Memory Leak）的问题，对相关的知识进行了一下简单的学习和探索，其间也有了一些粗浅的经验积累，今天特意写一篇相关的文章与大家分享。那些对内存泄漏稍微有点了解的人，对于本篇文章的标题，相信不会觉得是在危言耸听。就我查阅的资料，已经这两天的发现也证实了这一点：觉得部分的内存泄漏问题与事件（Event）有关。本篇文章将会介绍其原理，以及如何发现和解决由事件导致的内存泄漏问题。
阅读全文
最近这两天一直在忙着为一个项目检查内存泄漏（Memory Leak）的问题，对相关的知识进行了一下简单的学习和探索，其间也有了一些粗浅的经验积累，今天特意写一篇相关的文章与大家分享。那些对内存泄漏稍微有点了解的人，对于本篇文章的标题，相信不会觉得是在危言耸听。就我查阅的资料，已经这两天的发现也证实了这一点：觉得部分的内存泄漏问题与事件（Event）有关。本篇文章将会介绍其原理，以及如何发现和解决由事件导致的内存泄漏问题。
阅读全文
摘要：上一篇文章主要讨论的是PetShop的模块划分，在这一篇文章中我们来讨论在一个模块中如何进行层次划分。模块划分应该是基于功能的，一个模块可以看成是服务于某项功能的所有资源的集合；层次划分侧重于关注点分离（SoC：Separation of Concern ），让某一层专注于某项单一的操作，以实现重用性、可维护性、可测试性等相应的目的。
阅读全文
上一篇文章主要讨论的是PetShop的模块划分，在这一篇文章中我们来讨论在一个模块中如何进行层次划分。模块划分应该是基于功能的，一个模块可以看成是服务于某项功能的所有资源的集合；层次划分侧重于关注点分离（SoC：Separation of Concern ），让某一层专注于某项单一的操作，以实现重用性、可维护性、可测试性等相应的目的。
阅读全文
摘要：在《WCF技术剖析（卷1）》的最后一章，我写了一个简单基于WCF的Web应用程序，该程序模拟一个最简单的网上订购的场景，所以我将其命名为PetShop。PetShop的目在于让读者体会到在真正的项目开发中，如何正确地、有效地使用WCF。在这个应用中，还会将个人对设计的一些总结融入其中，希望能够对读者有所启发。
阅读全文
在《WCF技术剖析（卷1）》的最后一章，我写了一个简单基于WCF的Web应用程序，该程序模拟一个最简单的网上订购的场景，所以我将其命名为PetShop。PetShop的目在于让读者体会到在真正的项目开发中，如何正确地、有效地使用WCF。在这个应用中，还会将个人对设计的一些总结融入其中，希望能够对读者有所启发。
阅读全文
摘要：服务端只有抛出FaultException异常才能被正常地序列化成Fault消息，并实现向客户端传播。对于一般的异常（比如执行Divide操作抛出的DivideByZeroException），在默认的情况下，异常信息无法实现向客户端传递。但是，倘若为某个服务应用了ServiceDebugBehavior这么一个服务行为，并开启了IncludeExceptionDetailInFaults开关，异常信息将会原封不动地传播到客户端。WCF内部是如何处理抛出的非FaultException异常的呢？
阅读全文
服务端只有抛出FaultException异常才能被正常地序列化成Fault消息，并实现向客户端传播。对于一般的异常（比如执行Divide操作抛出的DivideByZeroException），在默认的情况下，异常信息无法实现向客户端传递。但是，倘若为某个服务应用了ServiceDebugBehavior这么一个服务行为，并开启了IncludeExceptionDetailInFaults开关，异常信息将会原封不动地传播到客户端。WCF内部是如何处理抛出的非FaultException异常的呢？
阅读全文
摘要：WCF客户端和服务端的框架体系相互协作，使得开发人员可以按照我们熟悉的方式进行异常的处理：在服务操作执行过程中抛出异常（FaultException），在调用服务时捕获异常，完全感觉不到“分布式”的存在，如同典型的“本地”操作一般。为了实现这样的效果，WCF在内部为我们作了很多。
阅读全文
WCF客户端和服务端的框架体系相互协作，使得开发人员可以按照我们熟悉的方式进行异常的处理：在服务操作执行过程中抛出异常（FaultException），在调用服务时捕获异常，完全感觉不到“分布式”的存在，如同典型的“本地”操作一般。为了实现这样的效果，WCF在内部为我们作了很多。
阅读全文
摘要：从整个基础构架的层次结构上讲，WCF可以分成两个部分：服务模型层（Service Mode Layer）和信道层（Channel Layer）。服务模型层建立在信道层之上，提供了一个统一的、可扩展的编程模型。信道层则通过绑定（Binding）建创的信道栈为消息通信提供了一个传输、处理的通道。
阅读全文
从整个基础构架的层次结构上讲，WCF可以分成两个部分：服务模型层（Service Mode Layer）和信道层（Channel Layer）。服务模型层建立在信道层之上，提供了一个统一的、可扩展的编程模型。信道层则通过绑定（Binding）建创的信道栈为消息通信提供了一个传输、处理的通道。
阅读全文