ASP.NET Web API消息处理管道：Self Host下的消息处理管道[下篇]

ASP.NET Web API消息处理管道：Self Host下的消息处理管道[下篇]

我们知道ASP.NET Web API借助于HttpSelfHostServer以Self Host模式寄宿于当前应用程序中。而通过《上篇》的介绍我们知道Self Host下请求的监听、接收和响应是利用HttpBinding实现的，那么HttpSelfHostServer与上面介绍的HttpBinding又有何关系？HttpSelfHostServer与ASP.NET Web API的消息处理管道又是如何集成的呢？[本文已经同步到《How ASP.NET Web API Works?》]

如下面的代码片断所示，HttpSelfHostServer其实是HttpServer的子类，所以在Self Host模式下HttpSelfHostServer本身就是消息管道的组成部分。换句行话说，以HttpSelfHostServer为“龙头”的消息处理管道本身具有了请求监听、接收、处理和响应的能力。

public sealed class HttpSelfHostServer : HttpServer
{
    public HttpSelfHostServer(HttpSelfHostConfiguration configuration);
    public HttpSelfHostServer(HttpSelfHostConfiguration configuration, HttpMessageHandler dispatcher);

    public Task OpenAsync();
    public Task CloseAsync();

    protected override void Dispose(bool disposing);
}

Self Host模式下的消息处理管道通过创建HttpSelfHostServer时指定的HttpSelfHostConfiguration对象进行配置，其中就包括监听监听的地址。

HttpSelfHostConfiguration

如下面的代码片断所示，HttpSelfHostConfiguration直接继承自HttpConfiguration。我们在创建一个HttpSelfHostConfiguration对象的时候需要指定一个Uri对象作为监听基地址，这个地址通过只读属性BaseAddress返回。

public class HttpSelfHostConfiguration : HttpConfiguration
{
    public HttpSelfHostConfiguration(Uri baseAddress);

    public Uri                     BaseAddress { get; }
    public HostNameComparisonMode  HostNameComparisonMode { get; set; }
    public TransferMode            TransferMode { get; set; }

    public int     MaxBufferSize { get; set; }
    public int     MaxConcurrentRequests { get; set; }
    public long    MaxReceivedMessageSize { get; set; }

    public TimeSpan ReceiveTimeout { get; set; }
    public TimeSpan SendTimeout { get; set; }

    public HttpClientCredentialType     ClientCredentialType { get; set; }
    public UserNamePasswordValidator    UserNamePasswordValidator { get; set; }
    public X509CertificateValidator     X509CertificateValidator { get; set; }
}

由于Self Host模式下请求的监听、接收和响应基本上全部是通过HttpBinding实现的，所以定义在HttpSelfHostConfiguration中的众多属性实际上基本用于对创建的HttpBinding进行相应配置。从如下给出的代码片断可以看出HttpBinding类型与HttpSelfHostConfiguration具有类似的属性定义。

public abstract class Binding : IDefaultCommunicationTimeouts
{
    //其他成员
    public TimeSpan ReceiveTimeout { get;  set; }
    public TimeSpan SendTimeout { get;  set; }
}

public class HttpBinding : Binding, IBindingRuntimePreferences
{
    //其他成员
    public HostNameComparisonMode HostNameComparisonMode { get; set; }
    public TransferMode           TransferMode { get; set; }

    public long     MaxBufferPoolSize { get; set; }
    public int      MaxBufferSize { get; set; }
    public long     MaxReceivedMessageSize { get; set; }    

    public HttpBindingSecurity Security { get; set; }
}

由于Binding在WCF是一个核心组件，其设计本身相对复杂，要深入了解定义在HttpBinding中的这些属性需要相关的背景知识。篇幅所限，我们不能因为这些属性将Binding相关的内容全部搬过来，所以在这里我们仅仅通过如下的表格对它们进行概括性的介绍。

属性	描述
HostNameComparisonMode	如果请求URL没有指定服务器的IP地址而是主机名称，当从URL提取主机名称后会按照相应的比较模式来最终确定匹配的主机名。该属性的类型为HostNameComparisonMode枚举，用以确定在主机名比较模式。
TransferMode  MaxBufferSize	消息传输具有两种模式，即基于Streamed和Buffered，前者以流的形式进行消息传输，后者则将整个消息的内容先保存于内存缓冲区后一并传输。该属性类型为TransferMode枚举，用以控制针对请求消息和响应消息的传输模式。在默认情况下，请求消息和响应消息均以Buffered模式进行传输。MaxBufferSize在采用Buffered模式下消息最大缓冲大小，默认值为65536（0x10000）。
MaxConcurrentRequests  MaxReceivedMessageSize	这两个是针对请求的限制，分别表示运行的最大并发访问量和请求消息允许的最大尺寸。两者的默认值分别为100和65536（0x10000）。值得一提的是：MaxConcurrentRequests针对最大并发请求的限制是针对单个处理器设定的，对于多处理器或者多核处理来说，应该乘以处理器的数量。
ReceiveTimeout  SendTimeout	这两个属性分别表示接收请求消息和发送响应消息的超时时限，默认值分别为10分钟和1分钟。
ClientCredentialType  UserNamePasswordValidator X509CertificateValidator	这是三个与安全认证相关的属性。ClientCredentialType表示客户端采用的用户凭证类型，而UserNamePasswordValidator和X509CertificateValidator属性值分别在用户凭证为“用户名+密码”和“X.509证书”的情况下实施认证。

HttpSelfHostServer与消息处理管道

在对定义的Web API采用Self Host模式寄宿时，我们会根据指定的监听基地址创建一个HttpSelfHostConfiguration对象，然后据此创建一个HttpSelfHostServer对象。当我们调用方法OpenAsync时，HttpSelfHostServer会创建一个HttpBinding对象，并根据指定的HttpSelfHostConfiguration对其作相应的设置。随后HttpBinding会针对指定的监听地址创建一个ChannelListener，并调用其BeginOpen方法以异步的方式开启。除了OpenAsync方法外，HttpSelfHostServer还定义了一个CloseAync方法使我们可以以异步的方式关闭已经开启的ChannelListener。

一旦ChannelListener被成功开启后，它便绑定到指定的监听地址进行请求的监听。一旦抵达的请求被探测到，它会利用创建的信道栈来接收该请求。通过上面对HttpBinding的介绍我们知道，接收到的二进制数据经过解码之后会生成一个HttpMessage对象，后者是对一个HttpRequestMessage的封装。

接下来HttpSelfHostServer从生成的HttpMessage中提取被封装的HttpRequestMessage对象，直接分发给消息处理管道作进一步处理。对于最终从管道传递回来的HttpResponseMessage对象，HttpSelfHostServer将其封装成一个HttpMessage对象并利用创建的信道栈返回给客户端。在通过传输层发送响应消息之前，HttpMessage会先编码。通过上面的介绍我们知道整个编码工作完全是针对被HttpMessage封装的HttpResponseMessage对象进行的，在HttpResponseMessage中保存的响应内容就是客户端接收到的内容。左图基本揭示了Self Host寄宿模式下整个消息处理管道的结构。

实例演示：创建自定义HttpServer模拟HttpSelfHostServer的工作原理

通过上面的介绍，我想读者朋友们应该对Self Host模式下消息处理管道如何进行请求的监听、接收、处理和响应已经有了全面的了解。如果我们能够创建一个自定义的HttpServer来模拟HttpSelfHostServer的工作原理，我想读者朋友们对此的印象一定更加深刻。在本章内容即将完结之前，我们就来完成这么一个演示实例。

我们通过继承HttpServer创建如下一个用于模拟HttpSelfHostServer的MyHttpSelfHostServer类型。两者对于请求的监听、接收和响应的实现原理是一致的，不同之处在于HttpSelfHostServer基本采用异步的操作方式，处于简单简洁考虑，MyHttpSelfHostServer采用同步编程方式。

public class MyHttpSelfHostServer: HttpServer
{
    public Uri BaseAddress { get; private set; }
    public IChannelListener<IReplyChannel> ChannelListener { get; private set; }

    public MyHttpSelfHostServer(HttpConfiguration configuration, Uri baseAddress) : base(configuration)
    {
        this.BaseAddress = baseAddress;
    }

    public void Open()
    {
        HttpBinding binding = new HttpBinding();
        this.ChannelListener = binding.BuildChannelListener<IReplyChannel>(this.BaseAddress);
        this.ChannelListener.Open();

        IReplyChannel channnel = this.ChannelListener.AcceptChannel();
        channnel.Open();

        while (true)
        {
            RequestContext requestContext = channnel.ReceiveRequest(TimeSpan.MaxValue);
            Message message = requestContext.RequestMessage;
            MethodInfo method =  message.GetType().GetMethod("GetHttpRequestMessage");
            HttpRequestMessage request =  (HttpRequestMessage)method.Invoke(message, new object[] {true});
            Task<HttpResponseMessage> processResponse = base.SendAsync(request,  new CancellationTokenSource().Token);
            processResponse.ContinueWith(task =>
                {
                    string httpMessageTypeName = "System.Web.Http.SelfHost.Channels.HttpMessage,  System.Web.Http.SelfHost";
                    Type httpMessageType = Type.GetType(httpMessageTypeName);
                    Message reply = (Message)Activator.CreateInstance( httpMessageType, new object[] { task.Result });
                    requestContext.Reply(reply);
                });
        }
    }

    public void Close()
    {
        if (null != this.ChannelListener && this.ChannelListener.State ==  CommunicationState.Opened)
        {
            this.ChannelListener.Close();
        }
    }
}

MyHttpSelfHostServer的只读属性BaseAddress表示监听基地址，该属性直接在构造函数中指定。与HttpSelfHostServer不同的是，用于创建MyHttpSelfHostServer提供的配置对象是一个HttpConfiguration对象而不再是HttpSelfHostConfiguration。

在Open方法中，我们根据提供的监听基地址利用HttpBinding对象创建一个ChannelListener对象，MyHttpSelfHostServer的只读属性ChannelListener引用的也正是这个对象。在开启该ChannelListener之后，我们调用其AccpetChannel方法创建信道栈，最终返回位于栈顶的Channel。在该Channel开启的情况下，我们在一个“永不终止”的While循环中调用其ReceiveRequest方法进行请求的监听。

当信道栈成功接收请求消息后（通过前面的介绍我们知道这是一个HttpMessage对象），我们从中提取出被封装的HttpRequestMessage对象，并将其作为参数调用SendAsync方法，表示请求的HttpReuqestMessage自此进入了消息处理管道这个流水车间。

调用SendAsync方法返回的是一个Task<HttpResponseMessage>对象，我们对此作这样的后续操作：提供作为响应消息的HttpResponseMessage对象，并通过反射的形式将其封装成HttpMessage对象，最终将此对象通过信道栈对请求予以最终的响应。

HttpSelfHostServer定义了OpenAsync和CloseAsync方法开启和关闭监听器，与之相匹配，我们也为Open方法定义了匹配的Close方法来关闭已经开启的ChannelListener。

为了验证我们自定义的MyHttpSelfHostServer是否能够替代“原生”的HttpSelfHostServer，我们在一个控制台中定义了如下一个ContactsController。它具有两个重载的Action方法Get，前者用于返回所有的联系人列表，后者返回指定ID的某个联系人信息。

public class ContactsController : ApiController
{
    private static List<Contact> contacts = new List<Contact>
    {
        new Contact{ Id="001", Name = "张三",  PhoneNo="123",  EmailAddress="zhangsan@gmail.com"},
        new Contact{ Id="002", Name = "李四",  PhoneNo="456",  EmailAddress="lisi@gmail.com"}
    };

    public IEnumerable<Contact> Get()
    {
        return contacts;
    }

    public Contact Get(string id)
    {
        return contacts.FirstOrDefault(c => c.Id == id);
    }
}

public class Contact
{
    public string Id { get; set; }
    public string Name { get; set; }
    public string PhoneNo { get; set; }
    public string EmailAddress { get; set; }
}

在作为入口的Main方法中我们编写了如下一段简单的“寄宿”程序。我们根据创建的HttpConfiguration对象和指定的监听基地址（“http://127.0.0.1:3721”）创建了一个MyHttpSelfHostServer对象。在调用Open方法开始监听之前，我们注册了一个URL模板为“http://127.0.0.1:3721”的HttpRoute。

class Program
{
    static void Main(string[] args)
    {
        using (MyHttpSelfHostServer httpServer = new MyHttpSelfHostServer( new HttpConfiguration(), new Uri("http://127.0.0.1:3721")))
        {
            httpServer.Configuration.Routes.MapHttpRoute(
                name              : "DefaultApi",
                routeTemplate     : "api/{controller}/{id}",
                defaults          : new { id = RouteParameter.Optional });

            httpServer.Open();
            Console.Read();
        }
    }
}

运行该程序之后，这个“宿主”程序便开始进行请求的监听。现在我们直接利用浏览器对定义在ContactsController中的两个Action方法Get发起请求，通过注册的HttpRoute和请求的HTTP方法直接作为Action名称的原理，我们使用的URL分别为“http://127.0.0.1:3721/api/contacts”和“http://127.0.0.1:3721/api/contacts/001”。如右图所示，我们期望的联系人信息直接以XML的形式显示在浏览器中，由此可见我们自定义的MyHttpSelfHostServer“不辱使命”。