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的方法。