ASP.NET框架至今为止已经存在了数十年了，大量的网站使用ASP.NET框架进行开发。随着网站应用开发技术的进步,  许多网站应用开发框架有了新的流行趋势

• 轻量化
• 模块化
• 可移植

ASP.NET框架在新的流行趋势下，显得非常臃肿，主要原因就是ASP.NET的基础是System.Web程序集，它里面集成了各种网站开发需要的组件，不管你需不需要，他都集成在当中，大量组件耦合在一起，很难分离开来。这与微软之前大而全的思想非常匹配，只要你使用我的ASP.NET框架，所有的网站开发都可以在一个框架中完成。

而且System.Web程序集是.NET Framework的一部分，这就导致他只能跟随.NET Framework的年度更新而更新，这与当前快速迭代的网站应用开发技术不太匹配。

最严重的是System.Web极度依赖IIS服务器，使得ASP.NET只能在Windows服务器上部署，在Linux, Mac等其他服务器上就没有办法施展拳脚。

ASP.NET MVC和ASP.NET Web Api

微软在发现这个问题之后，开始了自己的变革，微软希望将ASP.NET改造成一个可插拔组件集合，而非一个单独的框架。

微软首当其冲的就是将组件移出.NET框架发布。在随后推出的ASP.NET Mvc中微软进行了首次尝试，参考Ruby on Rail, 微软实现了自己的MVC框架，分离了前台页面和后台业务逻辑，并且ASP.NET Mvc是独立于.NET Framework进行发布，这极大的加快了这个框架的迭代速度。

随着网站应用开发技术的继续发展，大量后端的任务前移，静态页面 + Ajax动态填充内容成为流行，微软又推出了自己的轻量级Web服务框架ASP.NET Web Api。这个新生的框架是独立于System.Web程序集的。而且他还首次支持了Custom Host, 使得ASP.NET Web Api可以脱离IIS，在其他地方进行托管（命令行程序，Windows Service）。

Owin的诞生

微软受启于Ruby社区中的思想， 开始对Web服务器和Web框架组件进行解耦，创建了一系列的抽象接口，使Web框架组件不在依赖具体的服务器，而是依赖于这些新的接口，这样就解除了服务器与组件的耦合，所有实现接口的服务器程序，都可以作为组件的托管服务器。

所谓的Owin其实就是抽象接口的统称（The Open Web Interface for .NET）。

Owin的诞生使得Web组件更容易开发，更容易使用，而且对于使得ASP.NET的网站应用可以迁移到所有潜在的系统（Linux, Mac等）中。

Owin的2个核心元素

环境字典

IDictionary<string, object>

环境字典定义了兼容Owin的Web服务器需要在Http请求中读取的数据，以及在Http响应中需要更新或呈现的数据

例：需要从请求中读取的数据

Key Name	Value Description
“owin.RequestBody”	请求体内容
“owin.RequestHeader”	请求头部信息
“owin.RequestMethod”	Http请求的方法（Get,Post..）
“owin.RequestPath”	请求地址
“owin.RequestPathBase”	请求地址
“owin.RequestProtocol”	请求使用的协议
“owin.RequestQueryString”	请求Url中的参数
“owin.RequestSchema”	请求的Url Schema, http或者https

环境字典对应的应用委托字典

Func<IDictionary<string, object>, Task>

该字典中保存了对每个环境字典Key所做对应操作方法，这些方法的输入参数是环境字典Key, 然后返回一个Task

从实现的角度讲，Owin是一个标准，他的目标不是下一代Web开发框架，而是一个Web框架和Web服务器交互的标准

Katana

Katana是武士刀的意思，微软官方依据Owin标准实现的一组Owin组件，这些组件中集成了基础组件（托管程序和服务器）和一些功能组件（授权组件），同时也支持SignalR和ASP.NET Web Api

下面我们以一个Hello World程序为例

首先我们创建一个空的ASP.NET项目

下一步，我们安装Microsoft.Owin.Host.SystemWeb程序集，这个程序集提供了一个运行ASP.NET请求管道的Owin服务器

Install-Package Microsoft.Owin.Host.SystemWeb

安装完成之后, 添加Owin启动类，设置对所有的请求返回文本Hello World

public class Startup

{

public void Configuration(IAppBuilder app)

{

app.Run(context =>

{

context.Response.ContentType = "text/plain";

return context.Response.WriteAsync("Hello World!");

});

}

}

按F5运行之后之后，你会发现他还是使用了默认的IIS Express来运行程序，因为这里使用的兼容System.Web的服务器，默认就是用IIS托管。

切换服务器

然后我们来尝试一下，使用非IIS服务器托管这个Web应用

首先我们需要安装程序集OwinHost, OwinHost是Katana提供的使用HttpListener为基础的服务器，他同样实现了之前的环境字典标准

Install-Package OwinHost

安装完成之后，使用命令行运行OwinHost，启动完毕之后，打开浏览器输入localhost:5000(5000是默认端口), 你就能看到对应的内容。

Katana的架构

Katana从架构上来说分4层，由上到下一次是应用层，中间件层，服务器层，托管层，每一层都可以*选择使用的组件

托管层

Katana的托管层负责开启Web应用并维护该应用进程，有3种可选的实现

• IIS/ASP.NET – 使用IIS托管
• Custom Host – 自定义托管，Web应用可以托管在命令行或者Windows服务当中
• OwinHost – Katana提供的托管

服务器层

服务器负责监听请求，发送响应。 当前Katana提供的服务器组件有2个

• Owin.Host.SystemWeb
• Owin.Host.HttpListener

中间件层

中间件层负责注入Owin组件管道中使用的组件，Web API, SignalR等都是在这里进行注入启用，这里也是最长扩展的一个部分，开发人员可以自己定义常用的中间件。所有的中间件都必须继承OwinMiddleware抽象类，后续我会写一些中间层扩展的例子

后记

Owin定义一系列规范，来解除服务器和应用之间的耦合，使的整个ASP.NET框架变得越来越轻量化，并提供了一定的可移植性，为后续微软研发ASPNETCore提供了基础，按照官网文档的说明ASPNETCore使用了Owin的规范，但是据先驱者透漏ASPNETCore已经和Owin没有关系了（有待考究），只是沿用了思想，ASPNETCore使用了新的Kestrel服务器，等于说是Owin基本被放弃了。但是如果对于不使用ASPNETCore开发的程序员，学习Owin还是对开发很有帮助的。