OWIN产生的背景以及简单介绍

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最好的时代，不是吗?

如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】按钮。
如果，您希望更容易地发现我的新博客，不妨点击一下右下角的【关注 Justrun】。
因为，我的写作热情也离不开您的肯定支持。

感谢您的阅读，这里还有你可能感兴趣的文章推荐博客文章。