WCF之入门篇

通过学习蒋金楠的博文，对WCF有了新的认知，但是学习到现在对于wcf还不能说有了整体上的把握，有些概念了解的还是有点模糊。在此总结一下最近学习到的东西，部分内容摘自蒋金楠博文系列。

首先介绍一下WCF进行通信的过程：

WCF服务端框架：
请求消息的接收和回复消息的发送：服务端在传输层监听与接收来自客户的请求，并将经过编码后的回复消息通过传输层发送到客户端
请求消息的解码和回复消息的编码：将接收到的字节数组通过解码生成请求消息对象，并将回复消息通过编程转化成字节组。消息的编码和解码通过MessageEncoder完成，而MessageEncoderFactory负责创建该对象
请求消息的反序列化和回复消息的序列化：对请求消息进行反序列化，为服务操作的执行生成相应的输入参数，以及将服务操作执行的结果（返回值或者ref/out参数）序列化，并生成回复消息。序列化和反序列化通过DispatchMessageFormatter完成
服务对象的创建：创建或者激活服务对象实例，InstanceProvider用于服务对象的创建或获取
服务操作的执行：调用创建的服务对象的操作方法，并传入经过反序列化生成的输入参数。OperationInvoker完成对服务操作的最终执行
较之服务端的流程，客户端的流程显得相对简单，仅仅包含以下三个必需的阶段：
请求消息的序列化和回复消息的反序列化：生成请求消息并将输入参数序列化到请求消息中，以及对回复消息进行反序列化，转化成方法调用的返回值或者ref/out参数。序列化和反序列化通过ClienthMessageFormatter完成
请求消息的编码和回复消息的解码：对请求消息进行编码生成字节数组供传输层发送，以及将传输层接收到的字节数组解码生成恢复消息。消息的编码和解码通过MessageEncoder完成，而MessageEncoderFactory负责创建该对象
请求消息的发送和回复消息的接收：在传输层将经过编码的请求消息发送到服务端，以及将接收来自服务端的恢复消息
整个通信过程中客户端和服务端以数据契约、服务契约、消息契约为标准进行消息的编制与解析，就像是网络传输过程中遵守网络协议一样，这里的契约是开发者自己制定的一个简单的标准。

一直对面向服务这个概念很是疑惑，现在也没太搞明白。WCF就是面向服务的。WCF支持多种协议，可以寄宿于WAS、ASP.NET（并行模式或者兼容模式）。

先来描述一下IIS7.0与ASP.NET的结构：

WAS负责将监听到的请求加以配置并且进行进程管理，无论是从W3SVC接收到的HTTP请求，还是通过WCF提供的监听适配器接收到的请求，最终都会传递到WAS。如果相应的工作进程（或者应用程序池）尚未创建，其创建之；否则将请求分发给对应的工作进程进行后续的处理。WAS在进行请求处理过程中，通过内置的配置管理模块加载相关的配置信息对相关的组建进行配置，与IIS
5.x和IIS 6.0基于Metabase的配置信息存储不同的是，IIS
7.0大都将配置信息存放于XML形式的配置文件中。基本的配置存放在applicationHost.cofig中。



同时IIS7.0也与ASP.NET实现了整合，如下图，他给我们带来如下好处

允许我们通过本地代码（Native Code）和托管代码（Managed
Code）两种方式定义IIS Module，这些IIS Module注册到IIS中形成一个通用的请求处理管道。由这些IIS
Module组成的这个管道能够处理所有的请求，不论请求基于怎样的资源类型。比如，可以将FormsAuthenticationModule提供的Forms认证应用到基于.aspx，CGI和静态文件的请求。
将ASP.NET提供的一些强大的功能应用到原来难以企及的地方，比如将ASP.NET的URL重写功能置于身份验证之前；
采用相同的方式去实现、配置、检测和支持一些服务器特性（Feature），比如Module、Handler映射、错误定制配置（Custom
Error Configuration）等。



一个完整的网络响应过程是什么样子的呢？

在工作进程w3wp.exe中，利用Aspnet_ispai.dll加载.NET运行时（如果.NET运行时尚未加载）。一个工作进程对应着一个应用程序池。一个应用程序池可以承载一个或者多个Web应用，每个Web应用映射到一个IIS虚拟目录。每一个Web应用运行在各自的应用程序域中。

如果HTTP.SYS接收到的HTTP请求是对该Web应用的第一次访问，当成功加载了运行时后，会通过AppDomainFactory为该Web应用创建一个应用程序域（AppDomain）。随后，一个特殊的运行时IsapiRuntime被加载。IsapiRuntime定义在程序集System.Web中，对应的命名空间为System.Web.Hosting。IsapiRuntime会接管该HTTP请求。

IsapiRuntime会首先创建一个IsapiWorkerRequest对象，用于封装当前的HTTP请求，并将该IsapiWorkerRequest对象传递给ASP.NET运行时：HttpRuntime，从此时起，HTTP请求正式进入了ASP.NET管道。根据IsapiWorkerRequest对象，HttpRuntime会创建用于表示当前HTTP请求的上下文（Context）对象：HttpContext。

随着HttpContext被成功创建，HttpRuntime会利用HttpApplicationFactory创建新的或者获取现有的HttpApplication对象。实际上，ASP.NET维护着一个HttpApplication对象池，HttpApplicationFactory从池中选取可用的HttpApplication用户处理HTTP请求，处理完毕后将其释放到对象池中。HttpApplicationFactory负责处理当前的HTTP请求。

在HttpApplication初始化过程中，会根据配置文件加载并初始化相应的HttpModule对象。对于HttpApplication来说，在它处理HTTP请求的不同的阶段会触发不同的事件（Event），而HttpModule的意义在于通过注册HttpApplication的相应的事件，将所需的操作注入整个HTTP请求的处理流程。ASP.NET的很多功能，比如身份验证、授权、缓存等，都是通过相应的HttpModule实现的。

而最终完成对HTTP请求的处理实现在另一个重要的对象中：HttpHandler。对于不同的资源类型，具有不同的HttpHandler。比如.aspx页对应的HttpHandler为System.Web.UI.Page，WCF的.svc文件对应的HttpHandler为System.ServiceModel.Activation.HttpHandler。



WCF对于ASP的寄宿便是在HttpModule阶段进行插入，实现最终响应客户端的逻辑