前言
对于一个应用程序来说，最重要的特性之一就是安全性。例如，安全方面的需求往往会最早被提出，安全方面Bug的优先级和危害程度往往都被定为最高。有时候为了提高安全性，还需要牺牲一定的性能或者其他因素。因为性能，往往可以通过一些别的方式，例如添加一台服务器作负载均衡来解决（顺便插一句，我现在觉得对于企业来说，能够用钱解决的往往就不是问题了），或者在之后的版本中进行优化；但是如果出了安全性方面的漏洞，很可能就已经造成了无法弥补的损失。试想，如果Windows Live Passport出现了安全上的漏洞导致用户信息泄露，这将会引出多大的风波，对于微软来说会造成多少名誉上的损害。但是如果性能上出现了问题——这方面例如Windows Live Space或Hotmail的早期版本都不怎么样，但是在优化之后还是吸引了大量的用户群体。
安全性是如此的重要，自然WCF也会为它提供了良好的支持，否则也无法称之为一个成熟的模型了（我认为，微软希望，也正在把WCF变成.NET或者说Windows平台下分布式通信的事实标准）。但是虽然WCF提出了丰富而强大的安全性支持，但是如果使用不当，依旧会产生安全方面的问题（同样的例子还有Sql注入，要保证安全型还是必须通过良好的编程实践来达成），甚至还不如不依赖WCF的功能，直接使用传统的方式，例如使用硬件或软件防火墙来阻止非法的连接。反过来说，选择什么样的安全实践也是要考虑到项目的实际情况。例如有的时候我们的确可以使用传统的方式来保证安全性，再今后的版本中再采用高级的实践——尤其我们现在有了WCF提供的模型，我们的优化可能只是部署一个新的程序集，然后更新一下配置而已。
近期因为项目原因重新阅读了各种资料，主要围绕着WCF在安全方面所提供的支持，同时准备在公司内部进行一些培训和交流。这一系列文章也就算是对于最近一段时间研究内容的总结吧。
Service Model和Channel Layer
WCF提出的通信模型主要可以分为两大部分：Service Model和Channel Layer。它们各司其职，“互不干涉内政”，因此能够自由地组合与扩展，使开发人员能够利用WCF提出的模型来轻松实现强大的通信功能。不过事实上，按照官方的说法，Channel Layer是Service Model的组成部分（而且官方的说法的确还是有道理啊），但是我在了解了这些内容之后还是认为将两者概念分开为好，希望能够就这方面的概念问题和大家讨论一下。
WSDL是描述一个服务的XML格式的语言。通过一个服务的WSDL我们可以得知这个服务的地址、服务使用的协议、以及服务中的各种具体定义（例如定义了哪些消息等等）。显然，如果每次生成服务时都要自己编写代码输出大段复杂的WSDL，或者在使用服务时都要解析WSDL并且在请求时还需要自己生成SOAP内容，这样的开发效率就实在是太低了。因此，成熟的框架会提供一种“抽象”机制，使开发人员能够轻松的定义服务，尽可能的将注意力集中在业务逻辑的实现上。例如使用ASP.NET释放Web Services，或者利用.NET Framework中的wsdl.exe根据某个服务的WSDL描述来生成代理。这些框架和工具都能够大大提高我们的开发效率。
WCF中的Service Model就是这样的一种抽象。简单地说，它可以被认作是一个与WSDL产生映射的模型。在Service Model中，与WSDL各部分相对应的概念被称作为address、binding和contract，这就是被各种资料中所提到的“A、B、C”。除了提供了“定义”这样的模型（用来与WSDL对应）之外，Service Model还负责了上述模型与外部请求或者回复信息的转化。
例如，我们的Host一旦接受到了一个请求，那么它会把这个请求内容反序列化成为一个Message类型的对象，并交给Service Model处理。此时Service Model开始工作，例如它会构造出处理这个请求的环境，识别出该用哪个类型来处理请求，选择或者创建一个类型的实例，确定应该调用的方法，随后调用方法，得到一个结果对象。然后Service Model同样负责将这个结果对象转化为一个Message类型的对象，最终将其序列化并输出（整个过程有十多个步骤，我这里只是提到了一些最重要并且最容易理解的环节。由此可见WCF的可扩展性是多么的强大）。如果使用WCF生成调用服务的代理，那么Service Model工作性质还是差不多，只是方向相反而已。
那么是由什么组件负责将一个外部的请求反序列化成为一个Message对象，待方法调用完成之后，又将表示结果的Message序列化成为输出的内容呢（如果使用WCF作为客户端代理，那么就变成将Message序列化为请求的内容，并且将收到的回复内容反序列化成Message对象）？这就是Channel Layer的作用。
Channel Layer定义个一个由一系列Channel组成的Stack，Message对象在穿越这个Channel Stack的时候会经过每个Channel的处理，一步步地“形变”，最终成为了我们需要“数据形态”。例如服务返回的Message对象在经过了功能为SOAP XML转化的Channel之后便成了SOAP XML的形式，然后再经由一个负责加密的Channel则成为了Encrypted数据（当然实际的步骤也没有那么简单），最终经由一个负责TCP/IP信道传送的Channel输送出去。试想，如果我们自定义一个Channel将Message转化为JSON格式，然后再使用一个Channel通过一个HTTP通道返回数据，那么不就能够支持ASP.NET AJAX的Web Service请求功能了吗？没错，的确可以这样。事实上在新的ASP.NET Futures类库中就提供了这样的组件，它们是学习如何扩展WCF的优秀范例。不过这已经是题外话了，有机会我们可以另起一个话题再说。
不过这里又要谈一下我个人的观点了，因为我对于Channel Stack的理解和官方说法有一定出入。无论从目前的官方文档，亦或是各类技术会议上谈到的Channel Layer，都是由一个一个Channel，“并列”地组合成一个Channel Stack。然后Message就像一个原材料通过生产线一样，最终得到了一个成品。
但是在我看来，Channel之间的关系不是并列的，而是使用了类似于“装饰模式”的嵌套的做法来实现的。在我看来，Channel与Channel之间是包含关系，Service Model将Message交给了最外层的Channel处理，而最外层的Channel根据它定义的某种逻辑，配合它邻近的那个下层的Channel处理的结果来操作这个Message对象，而不是简单地将处理的结果交给下一个Channel。这一点从自定义Channel的方式上就可以看出，基本上每个Channel内部都会用一个名为innerChannel的私有Field来保存下一个Channel，并且在自己的某些方法中使用innerChannel的方法。
根据我的理解可以得到一些推论，例如关闭一个Channel时，该Channel必须负责将它的innerChannel对象关闭；我们可以实现一个最简单同时无用的Channel，将所有的方法都直接委托给innerChannel，等等。而这些推论都是扩展Channel Layer的正确做法或结论，因此，我还是觉得自己的理解更加合理一些。当然，如果您在这方面有什么看法，也希望能够和您进行交流。
为什么要理解Service Model和Channel Layer？
似乎说了半天，我还没有涉及到WCF在安全方面的支持，却在大谈特谈一些“概念”。但是我认为，了解WCF的一些模型是掌握WCF的基础（我个人非常注重模型，也就是一个框架是如何抽象外部事物的，例如ASP.NET如何将HTTP请求抽象成WebForm）。只有了解了Service Model和Channel Layer的设计目的和功能，才能正确理解一些安全方面的做法是如何与这些模型结合的。例如，Channel Layer可以提供哪些安全上的保证，为什么Authentication操作是在Channel Layer中进行，而Authorization却是Service Model提供的呢？
WCF框架的设计并非随性而为，其中有着充分的理由，是那些世界顶级架构师们智慧和经验的结晶。当从“模型”的角度理解到这些内容之后，对于框架的使用往往就可以更上一层楼了。就拿我自己的经验来说，一开始必须“死记硬背”或者对照着Sample Code才能写出代码。而理解了模型之后，似乎代码或配置该怎么写，写在什么地方都是顺理成章的事情，在一些细节方面翻阅一下MSDN就能够解决开发中的大部分的问题。