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的發展歷史
不知不覺，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最好的時代，不是嗎?
參考：http://www.csharpkit.com/2017-09-24_62916.html
OWIN產生的背景以及簡單介紹