隨著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的發展歷史

不知不覺，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>
      

下面是具體的定義

另外一個核心是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最好的時代，不是嗎?