下一代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最好的時代，不是嗎?