OWIN的理解和实践(二) – Host和Server的开发

对于开发人员来讲,代码就是最好的文档,如上一篇博文所说,下面咱们就会基于Kanata项目的一些具体调用代码,来进一步深刻理解OWIN的实现和做用.

今天咱们先针对Host和Server来实现一个简单的应用.

咱们的开发环境是:  VS2013 Update 3,  .Net Framework 4.5.1

Host开发

如上篇博文说起,Host具备以下特色:

• 实现一个宿主进程
• 负责Server的启动和关闭
• 负责Middleware和Application的装载

最简单的宿主进程就是Console Application,那么咱们从创建Console程序开始

 

注意这个程序和它的入口类(通常是Program.cs)就是咱们所说的Host宿主进程的实现.

而具体的Host和Server的实现咱们就须要借助Kanata项目的实现了.

首先经过Nuget获取Kanata的Host实现. 包名为: Microsoft.Owin.Hosting

 

注: 目前版本为3.0.1, Owin的2个核心组件:  Owin和Microsoft.Owin会被同时载入.

WebApp.Start

Host的主要用途是启动和关闭Server, 这个功能的实现类就是在Microsoft.Owin.Hosting下的WebApp类, 请看类结构:

 

咱们能够看到,WebApp只有若干个Start函数,辅助于StartOptions类,依靠这2个类,就能完成Host对Server的启动和关闭.

Start函数有好几个重载,咱们来看一个最为典型的实现. (其余实现大同小异,若是要使用请参阅相关文档)

public static System.IDisposable Start(Microsoft.Owin.Hosting.StartOptions options, System.Action<IAppBuilder> startup)

• Options参数定义了Server启动所需的参数.
• Startup参数是一个以Owin.IAppbuilder接口为参数的函数,经过这个函数,完成对Server所需Middleware的加载工做,这也是Host的关键做用之一!
• 函数返回一个实现IDisposable接口的类, 能够预见的是,当这个类Dispose的时候,被这个函数启动的Server也会同时关闭和消亡.

StartOptions

咱们先来看下这个StartOptions中2个比较关键的属性:

public System.Collections.Generic.IList<string> Urls { get; }

Urls参数是以http标准url为格式字符串来定义Server监听的HostName和Port.

标准格式是 http(s)://hostname:port ; 好比 http://localhost:8080 ;  https://192.168.1.1:9000;

注意,Urls能够加多个,表示支持不一样的hostname和port映射. 另外, 还支持http://*:9000 这样的格式,表示映射全部HostName,这个和IIS映射配置实际上是相似的.

public string ServerFactory { set; get; }

关键的来了,这个就是Server实现类的assembly name, 你们不难想到,经过这个属性,Host和Server是彻底解耦的. 咱们的这个Host能够和任何符合Owin接口的Server实现进行组合. 固然,目前仍是使用自家的Server实现,请看下节.

Server实现和引用

Http Server并非一两句代码能够实现的, 这里咱们仍是继续站在Kanata的肩膀上,借用它的Server实现.  他的Server实现包名为 :  Microsoft.Owin.Host.HttpListener (我认为这里的Host更名为Server更加贴切)

首先仍是使用Nuget获取该Server组件

 

 

安装,并引入项目,有了Server的实现,下面咱们来完成StartOptions的定义代码:

 

            //初始化StartOptions参数
            StartOptions options = new StartOptions();
            //服务器Url设置
            options.Urls.Add("http://localhost:9000");
            options.Urls.Add("http://192.168.1.1:8080");
            //Server实现类库设置
            options.ServerFactory = "Microsoft.Owin.Host.HttpListener";

 

须要注意的是,我这里特意放了2个port不一样的地址,这2个Url都能起到效果; 另外Microsoft.Owin.Host.HttpListener 实际上是默认的Host ServerFatory实现(最后一行代码能够省略); 但咱们必须理解,这里是能够解耦的,咱们彻底能够桥接其余的Server实现.

Startup函数和使用

Startup函数很是的简单,就是一个只有一个没有返回值的,只有一个Owin.IAppBuilder参数的函数(函数名任意,不必定要叫Startup). 如如下代码:

        private static void Startup(Owin.IAppBuilder app)
        {
            //这里经过app句柄,为当前Server加入全部须要的middleware
        }

 

 

在这个函数中,经过app参数提供的句柄,一步步的加入Server所须要的全部Middleware,固然这些Middleware都是可自由组合,自由拆卸的,很是的灵活.

Server的启动和关闭

有了Options和Startup函数,咱们就能够启动咱们的Server了,整合的代码以下:

        /// <summary>
        /// Owin Host 主进程入口函数
        /// </summary>

        static void Main()
        {
            //初始化StartOptions参数
            StartOptions options = new StartOptions();

            //服务器Url设置
            options.Urls.Add("http://localhost:9000");
            options.Urls.Add("http://192.168.1.1:8080");

            //Server实现类库设置
            options.ServerFactory = "Microsoft.Owin.Host.HttpListener";
   
            //以当前的Options和Startup启动Server
            using (WebApp.Start(options, Startup))
            {
                //显示启动信息,经过ReadLine驻留当前进程
                Console.WriteLine("Owin Host/Server started,press enter to exit it...");
                Console.ReadLine();
            }//Server在Dispose中关闭
        }

        private static void Startup(Owin.IAppBuilder app)
        {
            //这里经过app句柄,为当前Server加入全部须要的middleware
        }

 

 

Server的关闭很简单,当using的结尾触发Dispose时,该Server被自动关闭.

Server是独立线程运行的,因此宿主进程必须驻留,这里用Console.ReadLine()驻留当前线程,保证Server长期运行.

其余注意点

• 不少机器上出现权限不够状况,请用管理员帐号运行VS2013.
• 用浏览器访问2个地址时发现能够联通,但Reponse为空,这符合上一篇中说提到的: Server仅仅是一个空的实现,在没有任何Middleware装载的状况下(咱们的Startup函数为空),全部的Request都只能得到一个空的Response这一论点.
• 加入不一样的Middleware可以实现不一样的Reponse返回,这个将在之后的篇幅中继续讨论.
• 尽可能用Nuget获取咱们须要的组件包,以保证组件正确性和版本统一.

 

总结下,咱们开发了一个以Console Application为宿主进程的程序,经过Kanata的Host实现Microsoft.Owin.Hosting启动了它自身的Server实现 Microsoft.Owin.Host.HttpListener, 目前没有加入任何Middleware和Application实现.

这里再罗嗦一句, Kanata的Host和Server实现彻底能够被本身或者第三方的实现所取代,前提是,符合OWIN的标准.