摘要： 前面两篇我们分别介绍了可被发现服务如何被发布，以及客户端如果探测可用的服务。接下来我们通过一个简单的例子来演示如果创建和发布一个可被发现的服务，客户端如何在不知道服务终结点地址的情况下动态探测可用的服务并调用之。 阅读全文

摘要： 在《服务如何能被”发现”》中我们着重讨论了可被发现的服务（Discoverable Service）如何通过ServiceDiscoveryBehavior行为的服务通过标准终结点DiscoveryEndpoint发布出来。现在我们来谈服务发现的另一个方面：客户端如何动态地探测可用的目标服务？ 阅读全文

摘要： 要让作为服务消费者的客户端能够动态地发现可用的服务，首先的要求服务本身具有可被发现的特性。那么到底一个可被发现的服务和一个一般的服务有何不同呢？或者说如何让一个一般的服务在寄宿的时候能够被它潜在的消费者“探测”到呢？ 阅读全文

摘要： 我们传统的服务调用的模式都是这样的：客户端在设计时就预先知道目标服务的地址，并基于这个地址创建客户端终结点对服务进行调用。而我们即将介绍的新特性则是你在预先不知道目标服务的地址的情况下，可以动态地探测可用的服务并调用之。WCF-Discovery并不是微软在.NET平台下的闭门造车，而是基于一个开放的标准，即我们接下来着重介绍的WS-Discovery。也就是说，如果JAVA平台的Web服务也是基于相同的WS-Discovery标准，那么它们也可以被WCF客户端“发现”。 阅读全文

摘要： 今天写《WCF技术剖析（卷2）》关于“队列服务”部分，看了《WCF服务编程》相关的内容。里面介绍一个关于“终结点不能共享相同的消息队列”说法，个人觉得这值得商榷。撰写此文，希望对此征求大家的意见。 阅读全文

摘要： 在《来源于WCF的设计模式：可扩展对象模式》我通过一个简单的例子介绍了基于IExtensibleObject和IExtension这两个接口为核心的“可扩展对象模式”。我之前是通过编程的方式来应用扩展对象的。其实，如何能够通过配置的方式来定义扩展，这个所谓的“可扩展对象模式”将会发挥更大的威力。 阅读全文

摘要： 我一直很喜欢剖析微软一些产品、框架的底层实现。在我看来，这不但让我们可以更加深入地了解其运作的原理，同时也能提高设计/架构的技能。因为对于这些框架或者产品来说，高质量的设计是它们能够成功的一个最基本的因素。这些应用在这些产品和框架上的设计其实是最值得我们学习的设计案例。比如说，今天我们介绍的“可扩展对象模式”就来源于WCF。 阅读全文

摘要： 为了解决EntLib的EHAB只能在异常类型级别控制异常处理策略的局限，我在很久之前曾经自定义了一个特殊的异常处理器来提供“细粒度”异常策略的定义。我个人觉得具有一定的实用价值，今天特意对其进行了重构，并将其放到了我在CodePlex上新创建的项目EntLib Extensions。 阅读全文

摘要： 在本篇文章中，我们将通过一个具体的实例来演示如何通过路由服务。在这个例子中，我们会创建连个简单的服务HelloServie和GoodbyeService。假设客户端不能直接调用这两个服务，需要使用到路由服务作为两者之间的中介。 阅读全文

摘要： 在一个典型的服务调用场景中，具有两个基本的角色，即服务的消费者和服务的提供者。从消息交换的角度讲前者一般是消息的最初发送者，而后者则是消息的最终接收者。在很多情况下，由于网络环境的局限，消息的最初发送者和最终接收者不能直接进行消息交换，这就需要一个辅助实现消息路由的中介服务，这就是我们接下来要介绍的路由服务。 阅读全文

摘要： 今天介绍WCF 4.0的另外两个新特性：标准终结点和无(.SVC)文件服务激活。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 阅读全文

摘要： 对于传统的WCF配置系统，无论是绑定的配置还是行为（服务行为和终结点行为）都必须具有一个名称。而正是通过整个配置名称，它们才能被应用到目标对象（终结点或者服务）上。而在实际的项目开发中，绝大部分服务或者终结点都具有相同的绑定和行为，如果能够定义一种默认的绑定和行为，这无疑会简化我们的配置。WCF4.0为此提供了一个新的特性以支持默认绑定和行为的配置。 阅读全文

摘要： 很多WCF的初学者是从之前的Web服务上转移过来的，他们非常怀念.asmx Web服务无配置的服务寄宿方式。你只需要在定义Web服务的时候再表示服务操作的方法上应用WebMethodAttribute特性就可以了，完全可以不需要手工进行相应的配置。WCF 4.0通过默认终结点添加机制为你提供无配置服务寄宿的支持。 阅读全文

摘要： WCF从第一个版本的推出到现在，整个架构体系基本上没有出现大的变化。在我看来，可扩展性的设计是WCF的架构体系能够在一段不短的时期内保持稳定的一个最主要的原因。而反观于WCF几乎同时推出的WF,各个版本演进的历史，你会发现几乎WF推出的每一个版本都是“革新性”的改变。正是因为WCF具有极大的扩展性，WCF新的版本的功能本身就可以通过这些丰富的扩展点来实现，而作为最终使用者的我们也可以实现我们自己的扩展，使WCF能够按照我们希望的方式来运作。 阅读全文

摘要： 今天写《WCF技术剖析（卷2）》关于《WCF扩展》一章，举了“如何通过WCF扩展实现与IoC框架（以Unity为例）集成”（《通过自定义ServiceHost实现对WCF的扩展[实例篇]》）的例子。为了展示Unity如何实现几种典型的注入方式（构造器注入、属性注入和方法注入），我写了一个简单的小程序。如果读者对Unity或者IoC没有太多概念，我觉得这个小程序对于你初步地认识它们具有一定的帮助意义。如果你对Unity或者IoC有深入的认识，请忽略本文。 阅读全文

摘要： 在《原理篇》中我们谈到了通过自定义ServiceHost对WCF进行扩展的本质，以及在IIS/WAS寄宿情况下ServiceHostFactory的作用。接下来通过一个具体的例子来演示如何通过WCF扩展实现以Unity为代表的IoC框架的集成，以及应用该扩展的ServiceHost和ServiceHostFactory如何定义。 阅读全文

摘要： 在创建ServiceHost的时候，WCF会加载服务相关的配置并将其作为服务的描述信息附加到ServiceHost对象上，我们也可以在开启ServiceHost之前对其服务描述信息进行相应的修改。ServiceHost在开启之前具有的服务描述信息将会决定在开启之后创建的服务端运行时框架。所以如果我们通过自定义ServiceHost对象并根据具体应用场景的具体需求对其服务描述进行定制，同样可以起到对WCF服务端进行扩展的目的。 阅读全文

摘要： 为了让读者对如何利用相应的行为对WCF进行扩展有个深刻的认识，在这里我提供一个简单的实例演示。本实例模拟的场景是这样的：我们创建一个支持多语言的资源服务，该服务旨在为调用者提供基于某种语言的文本型资源。但是，我们不希望客户端在每次调用服务的时候都显式地制定具体的语言，而是根据客户端服务调用线程表示语言文化的上下文来自动识别所需的语言。 阅读全文

摘要： 作为最为常用的扩展方式，WCF的四大行为的使用主要体现在两个方面：其一、WCF自身提供的很多特性和功能是通过行为的方式来实现的；其二、作为使用WCF的应用，可以通过自定义的行为来实现解决具体问题的扩展。本篇文章为你讲述WCF四大行为（服务行为、终结点行为、契约行为和操作行为）的本质。 阅读全文

摘要： 当基于某个终结点创建的ChannelFactory被开启的之后，位于服务模型层的客户端运行时框架被成功构建。站在编程的角度看ChannelFactory，它就是一个创建用于服务调用的服务代理对象的工厂。由于服务调用需要借助于服务代理来完成，我们很有必要从整个客户端运行架构层面来了解服务代理和基于服务代理的服务调用是如何实现的。 阅读全文

摘要： 对于一般的编程人员来说，进行WCF的服务调用之需要通过添加服务引用通过获取元数据生成服务代理类型，或者直接通过ChannelFactory创建用于服务调用的代理对象即可。但是比是否知道当我们创建、开启ChannelFactory的时候，以及用它来创建服务代理的是否WCF内部为我们作了哪些工作？对于一个简单的服务调用，WCF客户端又是采用怎样的处理流程？本篇文章将会给你答案。 阅读全文

摘要： 对于需要进行大规模数据传输的WCF应用来说，对于请求消息和回复消息进行传输前的压缩，不但可以降低网络流量，也可以提高网络传输的性能。由于WCF的扩展性，我们可以采用不同的方式实现对消息的压缩，本文提供一种比较简单的实现方式。 阅读全文

摘要： 终结点分发器在自己的运行时中对请求消息的处理最终肯定体现在相应操作的执行。如果从服务描述的角度来看，操作是一个OperationDescription对象。而服务端分发运行时中的操作则代表的是一个DispatchOperation对象。作为服务描述的一部分，服务所有终结点的所有操作描述（OperationDescription）在ServiceHost创建过程中被创建。而当ServiceHost被正常开始时，这些操作描述最终转换成分发操作（DispatchOperation）。而DispatchRuntime的Operations属性代表了对应终结点的所有分发操作。 阅读全文

摘要： 作为WCF中一个核心概念，终结点在不同的语境中实际上指代不同的对象。站在服务描述的角度，我们所说的终结点实际上是指ServiceEndpoint对象。如果站在WCF服务端运行时框架来说，终结点实际上指代的是终结点分发器（EndpointDispatcher）。两者是一一匹配的，并且前者是创建后者的基础。而终结点分发器具有自己的运行，即分发运行时（DispatchRuntime）。 阅读全文

摘要： 在这篇文章中，我们对信道分发器（ChannelDispatcher）本身作一个深入的了解，首先来看看它具有哪些可供扩展的组件，以及我们可以针对信道分发器对WCF实现哪些可能的扩展。 阅读全文

摘要： WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的。 阅读全文

摘要： 对于WCF服务来说，一个服务具有若干操作，而这些操作由于提供的功能或者内部访问的资源不同，需要进行不同的权限设置。借助于.NET安全相关的应用编程接口，我们可以通过声明的方式将某个服务操作与调用该操作应当具有的权限集进行关联。在运行时，当调用某个服务操作的用户被成功认证后，它具有的权限集被获取出来并绑定到当前安全上下文。WCF框架本身在试图执行目标操作之前可以根据当前安全上下文确定该用户是否有权限执行该服务操作。 阅读全文

摘要： 在《模拟（Impersonation）与委托（Delegation）》一文中，我们对模拟和委托这两个概念以及相关编程实现进行了详细说明。如果将模拟使用在WCF上面，就意味着WCF可以模拟客户端身份（而不是启动寄宿进程的Windows帐号）执行服务操作。这篇文章主要介绍WCF关于模拟的编程。 阅读全文

摘要： 在《原理篇》中，我们谈到WCF自定义授权体系具有两个核心的组件：AuthorizationPolicy和ServiceAuthorizationManager，已经它们是如何写作最终提供一种基于声明的授权实现。为了让自定义授权有深刻的理解，我们来进行一个简单实例来演示如何通过自定义这两个组件实现“非角色授权策略”。 阅读全文

摘要： 到目前为止，我么介绍的授权策略都是围绕着安全主体进行的，基本上都是基于角色的授权。虽然角色是定义权限最为常用的形式，但是它解决不了授权的所有问题。有时候授权需要通过一个复杂的表达式来表示，而且其中会涉及诸多元素，比如身份、角色和组织等。一句话，如果简单的基于角色的授权不能解决我们的问题，我们需要自定义授权策略。 阅读全文

摘要： 在《原理篇》中我们谈到：如果采用自定义安全主体权限模式，我们可以通过自定义AuthorizationPolicy或者ServiceAuthorizationManager实现对基于当前认证用于相关的安全主体的提供，进而达到授权的目的。为了让大家对此有个更加深刻的认识，在这篇文章中我们会提供一个具体的例子。 阅读全文

摘要： 在《通过扩展自行实现服务授权》一文中，我通过自定义CallContextInitializer的方式在操作方法之前之前根据认证用户设置了当前线程的安全主体，从而实现授权的目的。实际上，WCF的安全体系本就提供相应的扩展，使你能够自由地实现安全主体的提供方式。具体来说，安全主体的提供可以通过自定AuthorizationPolicy或者ServiceAuthorizationManager来实现。 阅读全文

摘要： 其实针对安全主体的授权实现的原理很简单，原则上讲，只要你能在服务操作执行之前能够根据本认证的用户正确设置当前的安全主体就可以了。如果你了解WCF的整个运行时框架结构，你会马上想到用于授权的安全主体初始化可以通过自定义CallContextInitializer来实现。 阅读全文

摘要： 为了让读者对基于ASP.ENT Roles授权方式有一个全面的认识，我们现在来做一个实例演示。在这个实例中，我们将采用不同的认证方式，包括Windows认证和证书认证（ASP.NET Membership + Roles为常见的组合方式，在这里就不多作演示）。 阅读全文

摘要： 在采用Windows认证的情况下，使用基于Windows用户组安全主体权限模式是一个不错的选择,但是采用ASP.NET Roles却可以使用与任何类型的客户端凭证和认证模式。甚至可以这么说，绝大部分基于角色的授权都可以通过ASP.NET Roles来实现。 阅读全文

摘要： 由于服务操作是在寄宿进程中执行，在默认的情况下，服务操作是否具有足够的权限访问某个资源（比如文件）决定于执行寄宿进程Windows帐号的权限设置，而与作为客户端的Windows帐号无关。在有多情况下，我们希望服务操作执行在基于客户端的安全上下文中执行，以解决执行服务进行的帐号权限不足的问题。这就涉及到一个重要的话题——模拟与委托。 阅读全文

摘要： 为了让读者对基于Windows用户组的授权具有深刻的认识，接下来我们通过一个简单的事例来讲解在真正的应用中该授权模式如何使用。对于接下来演示的事例，我们将采用Windows认证和授权。至于授权的最终实现，我们采用的是在服务方法上面应用PrincipalPermissionAttribute特性方式的声明式授权。 阅读全文

摘要： Windows用户组安全主体权限模式，顾名思义，就是将利用Windows安全系统将对应的Windows帐号所在的用户组作为该用户权限集的授权方式。认证和授权密不可分，但是对于认证和授权在WCF安全体系中的实现来说，它们则是相对独立的。认证属于安全传输的范畴，是在信道层实现的，而授权则是在服务模型层实现的。但是对于基于Windows用户组的授权来说，最终体现出来的授权行为却和采用何种认证具有密切的关系。 阅读全文

摘要： 前面的两篇文章主要探讨基于安全主体的授权。通过这些介绍我们知道：如果我们在实施授权的时候，当前线程的安全主体能够被正确设置，我们就可以正确地完成授权。安全主体具有两个基本的要素：身份与权限。身份在客户端经过认证之后已经确立下来，现在需要解决的问题就是如何获取被认证用户的权限。为了解决这个问题，WCF为我们提供了三种不同的方案。 阅读全文

摘要： 毫不夸张地说，安全主体（Principal）是整个授权机制的核心。我们可以简单地将将安全主体定义成能够被成功实施授权的主体。一个安全主体具有两个基本的要素：基于某个用户的安全身份和该用户具有的权限。绝大部分的授权都是围绕着“角色”进行的，我们将一组相关的权限集和一个角色绑定，然后分配给某个用户。所以在基于角色授权环境下，我们可以简单地将安全主体表示成：身份 + 角色。 阅读全文