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

时间:2024-04-08 22:44:16

随着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规范的组件。

下一代Asp.net开发规范OWIN(1)—— 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"

string containing the HTTP request method of the request (e.g., "GET""POST").

"owin.RequestPath"

string containing the request path. The path MUST be relative to the "root" of the application delegate; see Paths.

"owin.RequestPathBase"

string containing the portion of the request path corresponding to the "root" of the application delegate; see Paths.

"owin.RequestProtocol"

string containing the protocol name and version (e.g. "HTTP/1.0" or "HTTP/1.1").

"owin.RequestQueryString"

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"

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 以上版本).