安全性能对于每个人来说都是很重要的，一个项目首要考虑的就是安全性能，下面就来简述一下WCF安全性方面的一些概念。例如，安全方面的需求往往会最早被提出，安全方面Bug的优先级和危害程度往往都被定为***。有时候为了提高WCF安全性，还需要牺牲一定的性能或者其他因素。因为性能，往往可以通过一些别的方式，例如添加一台服务器作负载均衡来解决（顺便插一句，我现在觉得对于企业来说，能够用钱解决的往往就不是问题了），或者在之后的版本中进行优化；但是如果出了安全性方面的漏洞，很可能就已经造成了无法弥补的损失。试想，如果Windows Live Passport出现了安全上的漏洞导致用户信息泄露，这将会引出多大的风波，对于微软来说会造成多少名誉上的损害。但是如果性能上出现了问题——这方面例如Windows Live Space或Hotmail的早期版本都不怎么样，但是在优化之后还是吸引了大量的用户群体。
#T#安全性是如此的重要，自然WCF也会为它提供了良好的支持，否则也无法称之为一个成熟的模型了（我认为，微软希望，也正在把WCF变成.NET或者说Windows平台下分布式通信的事实标准）。但是虽然WCF提出了丰富而强大的安全性支持，但是如果使用不当，依旧会产生安全方面的问题（同样的例子还有Sql注入，要保证安全型还是必须通过良好的编程实践来达成），甚至还不如不依赖WCF安全性的功能，直接使用传统的方式，例如使用硬件或软件防火墙来阻止非法的连接。反过来说，选择什么样的安全实践也是要考虑到项目的实际情况。例如有的时候我们的确可以使用传统的方式来保证安全性，再今后的版本中再采用高级的实践——尤其我们现在有了WCF提供的模型，我们的优化可能只是部署一个新的程序集，然后更新一下配置而已。
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的优秀范例。不过这已经是题外话了，有机会我们可以另起一个话题再说。
