下一代Asp.net开发规范OWIN（1）—— OWIN产生的背景以及简单介绍

随着VS2013的发布，微软在Asp.Net中引入了不少新的特性，好比使用新的权限验证模块Identity, 使用Async来提升Web服务器的吞吐量和效率等。其中一个不得不提的是OWIN和Katana. OWIN的全称是Open Web Interface For .Net, OWIN是.Net开源社区借鉴Ruby而制定的.Net Web开发架构，有着很是简单的规范定义，同时极度下降了模块间耦合。OWIN并非一个具体的实现，而只是一个规范，用来指导如何构建一个符合OWIN标准的Web生态环境。微软引入并推广OWIN，同时依照OWIN规范，实现了Katana。

能够这么说，OWIN将会使Asp.net焕发第二春。下面，就让咱们一步一步走近OWIN和Katana，一睹芳容。

阅读目录:

一. 回顾Asp.net的发展历史

二. 解决问题的思路

三. OWIN介绍

四，OWIN前景以及预测

一， 回顾Asp.net的发展历史

不知不觉，Asp.net已经伴随咱们了10多个年头，渐渐步入中年。面对突飞猛进的Web开发变革，Asp.net已经显得有些力不从心。为何会出现这种状况，让咱们来回顾一下Asp.net的发展历史:

Asp阶段

最初开发Web，使用的是Asp, 这是一种嵌入在页面中的脚本语言。Asp的优点是简单，上手快，可是随着开发的日益复杂和Web程序的不断庞大，Asp这种逻辑代码和页面Html混在一块儿的开发方式已经不可以适应了。

Asp.net Web Form阶段

因为Asp的短板，升级Asp，打造一个新的Web开发平台已是必然的事情了。猜测微软可能想让Winform上的开发者方便地迁移到Web开发上来，因而打造了一个开发过程和Winform及其相似的开发方式，这就是Asp.Net.

Asp.net Web Form在当时无疑是先进的，可是随着时间的推移，它的一些问题也暴露出来:
Asp.net中大部分的核心类都包含在System.Web.dll中，而System.Web.dll是包含在.Net Framework中的，这就意味着若是要发布一个新版本的Asp.net必须伴随着新的.Net Framework一块儿发布，这致使了Asp.net更新频率下降。另外，System.Web.dll是和IIS耦合的，使得Asp.net程序没法迁移到其它服务器上。

积极的改变

新的Asp.net MVC改变了过去的缺点，它是做为独立于.Net Framework发布的。因此MVC的版本变化，是无需受制于.Net Framework. 开发MVC的项目组就能够自主的快速开发和发布新的版本的MVC.
更进一步，在开发和发布Web API的时候，甚至都没有用到任何包含在System.Web.dll中的类型，这意味着:

• Web API彻底是无外部依赖的，它经过Nuget快速的发布和更新。
• 不依赖于System.Web.dll, 也就意味着不依赖于IIS的服务，因此Web API是能够运行在其它宿主进程中的, 好比控制台程序，windows service等。

将来:更加灵活的框架

经过解构Asp.net开发中的一个一个框架组件，微软就可以更加快速的迭代和经过Nuget发布新的版本，添加新的加强功能。
将来更加灵活的框架就是咱们能够随意根据项目须要，组合这些组件，而后运行在支持的Host上。

二，解决问题的思路

在引入OWIN以前，咱们来对Web请求到响应的过程进行抽象:
一个Web请求的全过程是一个简单的输入和输出， 输入是request包含的头信息、cookie、数据等信息，输出是最后的Html. 这就好像是放进去面粉，最后出来的是作好的馒头。可是从面粉变成馒头却要经历不少工序，这一道一道的工序，就组成了整个流程。很是相似于装饰者模式，每个装饰者对象都遵循一样的接口，这样咱们就能够将不一样的装饰者拼接起来。

下图是借鉴的python中的WSGI规范(Python Web Server Gateway Interface)， 和下面将讲到的OWIN基本相似. Request通过一层层的洋葱皮，最后输出。这一层一层的洋葱皮就是咱们的符合OWIN规范的组件。

 

三，OWIN介绍

OWIN就是按照上面思路和目标制定的一个规范，不包含任何具体实现。其目的是在web服务器和应用程序之间隔离出一个抽象层，使它们之间解耦。
OWIN设计的2个目标:  简单，以及尽可能少的依赖其它的框架类型。
这样就可以:

• 新的组件可以很是简单的开发和应用
• 程序可以简便地在host和OS上迁移

OWIN核心定义

OWIN将web应用中的request, response, session, cookie等全部相关信息都简化成下面的字典。本质上来讲，这个字典就包含了一个web请求的全部上下文信息。
一个符合OWIN的web服务器，须要将请求信息包装成下面的字典类型，传递到下一层中。而下一层的组件或者应用程序，所要作的就是读取，修改这个字典的数据。最后，Web服务器获得这个层层处理过的字典，而后输出网页到客户端

IDictionary<string, object>

下面是具体的定义

Key Name	Value Description
"owin.RequestBody"	A Stream with the request body, if any. Stream.Null MAY be used as a placeholder if there is no request body. See Request Body.
"owin.RequestHeaders"	An IDictionary<string, string[]><string, string[]=""> of request headers. See Headers.
"owin.RequestMethod"	A string containing the HTTP request method of the request (e.g., "GET", "POST").
"owin.RequestPath"	A string containing the request path. The path MUST be relative to the "root" of the application delegate; see Paths.
"owin.RequestPathBase"	A string containing the portion of the request path corresponding to the "root" of the application delegate; see Paths.
"owin.RequestProtocol"	A string containing the protocol name and version (e.g. "HTTP/1.0" or "HTTP/1.1").
"owin.RequestQueryString"	A string containing the query string component of the HTTP request URI, without the leading “?” (e.g., "foo=bar&baz=quux"). The value may be an empty string.
"owin.RequestScheme"	A string containing the URI scheme used for the request (e.g., "http", "https"); see URI Scheme.

另一个核心是application delegate，这是全部运行在OWIN协议下的组件都须要遵循的接口

Func<IDictionary<string, object>, Task>;

这样定义的缘由是: 

• 因为依赖少，写一个component很是容易和简单
• 异步设计使得程序的运行效率更高，特别是在遇到一些I/O密集的操做时
• application delegate 是可执行的最小单元，OWIN components能够很是容易的互相链接组成一个Http处理管道

四，OWIN前景以及预测

因为使用OWIN规范，使得Asp.net进化的更加快，对于新的东西也可以快速响应。

OWIN的发展，未来会有愈来愈多的基于OWIN的应用框架出现（中间件），也将会由更多的OwinHost出现，其一就是微软先发制人Katana，它可以运行于Windows中，独立于IIS为支持OWIN协议的框架提供宿主支持；而另一款则是率先支持OWIN协议的运行于Linux以及FreeBSD的Jexus Web Server（须要Jexus 5.6 以上版本）.

尽管Asp.Net年纪很大，可是如今也愈来愈潮了，小伙子们有的东西，它也有了，并且之后对时尚的敏感度会更加敏锐。而它所具备的稳定，成熟气质，倒是其它小伙子难以具有的。这是.Net最好的时代，不是吗?