什麼是OWIN
OWIN是Open Web Server Interface for .NET的首字母縮寫,他的定義如下:
OWIN在.NET Web Servers與Web Application之間定義了一套標準介面,OWIN的目標是用於解耦Web Server和Web Application。基於此標準,鼓勵開發者開發簡單、靈活的模組,從而推進.NET Web Development開源生態系統的發展。
正如你看到的這樣,OWIN是介面、契約,而非具體的程式碼實現,僅僅是規範(specifications),所以要實現自定義基於OWIN的Web Server必須要實現此規範。
歷時兩年(2010-2012),OWIN的規範終於完成並且當前版本是1.0,在OWIN的官網上可以看到更具體的資訊。
為什麼我們需要OWIN
過去,IIS作為.NET 開發者來說是最常用的Web Server(沒有之一),源於微軟產品的緊耦合關係,我們不得不將Website、Web Application、Web API等部署在IIS上,事實上在2010年前並沒有什麼不妥,但隨著近些年來Web的發展,特別是移動網際網路飛速發展,IIS作為Web Server已經暴露出他的不足了。主要體現在兩個方面,ASP.NET (System.Web)緊耦合IIS,IIS緊耦合OS,這就意味著,我們的Web Framework必須部署在微軟的作業系統上,難以跨平臺。
ASP.NET 和 IIS
我們知道,不管是ASP.NET MVC 還是ASP.NET WEB API 等都是基於ASP.NET Framework的,這種關係從字首就可以窺倪出來。而ASP.NET的核心正是System.Web這個程式集,而且System.Web緊耦合IIS,他存在於.NET Framework中。所以,這導致了Web Framework嚴重的侷限性:
- ASP.NET 的核心System.Web,而System.Web緊耦合IIS
- System.Web 是.NET Framework重要組成,已有15年以上歷史,沉重、冗餘,效能差,難於測試,約2.5M
- System.Web要更新和釋出新功能必須等待.NET Framework釋出
- .但NET Framework是Windows的基礎,往往不會隨意更新。
所以要想獲取最新的Web Framework是非常麻煩的,幸運的事,微軟已經意識到了問題的嚴重性,最新的Web Framework都是通過Nuget來獲取。
當然這是一部分原因,還有一層原因是ASP.NET & IIS實在太過於笨重,如何講呢?
複雜的生命週期已成為累贅?簡單來說,當請求到達伺服器時,Windows核心元件HTTP.SYS元件捕獲請求,他會分析請求並決定是否交給IIS來處理,當請求到達IIS之後,IIS會根據處理程式對映來匹配請求並交給對應的程式集(實現了ISAPI介面,比如我們熟知的aspnet_isapi.dll是專門用來處理ASP.NET Application)處理,最後載入了CLR執行環境,將請求交給aspnet_wp.exe去處理,這時複雜的ASP.NET生命週期往往令人頭大,但事實上有很多時候我們並不需要他。
如下圖所示ASP.NET Architecture:
開啟IIS,你會發現他提供了非常豐富的功能:快取、身份驗證、壓縮、加密等。但隨著移動網際網路蓬勃的發展,特別是HTML 5越來越成熟的今天,我們看到越來越多的操作發生在客戶端,而不是沉重的從伺服器產生HTML返回,更多的是通過非同步AJAX返回原生的資料。同理,對於 APP來說我們只需要Mobile Service返回資料。顯然IIS顯得笨重了點,而且IIS作為微軟產品系的一環,耦合程度太高。所以我們迫切需要輕量、快速、可擴充套件的宿主來承載Web Application和Web Service。
IIS 和 OS
IIS必須是安裝並執行在Windows作業系統中,這是微軟產品的一貫風格,環環相套,但不得不考慮他們的限制和侷限性:
- IIS往往和作業系統(Windows Server)繫結在一起,這意味著對於一些新功能如WebSocket Protocol ,我們不得不等待作業系統Windows Sever 2012、Windows 8的釋出(IIS 8.0)。
- 為了使用WebSocket這類新特性,他僅被IIS 8.0支援,如下所示:
這時你不得不去升級IIS,但升級作業系統可能會引發舊系統的不穩定性,所以要想平穩的升級IIS並不是簡單的。
- IIS作為經典的Web Server必須安裝在Windows系統中,Windows Server需要授權使用。
正是由於微軟產品系緊耦合的關係,才造成跨平臺上的不足,這也是被飽受詬病。所以我們需要OWIN來解耦,在物件導向的世界裡,介面往往是解耦的關鍵,如下圖所示:
使用OWIN,Web Framework不再依賴IIS和OS,這意味著你能使用任何你想的來替換IIS(比如:Katana或者Nowin),並且在必要時隨時升級,而不是更新作業系統。當然,如果你需要的話,你可以構建自定義的宿主和Pipeline去處理Http 請求。
這一切的改變都是由於OWIN的出現,他提供了明晰的規範以便我們快速靈活的去擴充套件Pipeline來處理Http請求,甚至可以不寫任何一句程式碼來切換不同的Web Server,前提是這些Web Server 遵循OWIN規範。
OWIN的規範
現在我們已經瞭解了什麼是OWIN已經為什麼需要OWIN,現在是時候來分析一下OWIN的規範了。
OWIN Layers
實際上,OWIN的規範非常簡單,他定義了一系列的層(Layer),並且他們的順序是以堆(Stack)的形式定義,如下所示。OWIN中的介面被稱之為應用程式委託或者AppFunc,用來在這些層之間通訊。
OWIN定義了4層:
Host:主要負責應用程式的配置和啟動程式,包括初始化OWIN Pipeline、執行Server。
Server:這是實際的Http Server,繫結套接字並監聽的HTTP請求然後將Request和Response的Body、Header封裝成符合OWIN規範的字典併傳送到OWIN Middleware Pipeline中,最後Application為Response Data填充合適的欄位輸出。
Middleware:稱之為中介軟體、元件,位於Server與Application之間,用來處理髮送到Pipeline中的請求,這類元件可以是簡單的Logger或者是複雜的Web Framework比如Web API、SignalR,只要Sever連線成功,Middleware中介軟體可以是任何實現應用程式委託的元件。
Application:這是具體的應用程式程式碼,可能在Web Framework之上。對於Web API、SignalR這類Web Framework中介軟體而言,我們僅僅是改變了他們的託管方式,而不是取代ASP.NET WEB API、SignalR原先的應用程式開發。所以該怎麼開發就怎麼開發,只不過我們將他們註冊到OWIN Pipeline中去處理HTTP 請求,成為OWIN管道的一部分,所以此處的Application即正在意義上的處理程式程式碼。
Application Delegate
OWIN規範另一個重要的組成部分是介面的定義,用於Server和Middleware的互動。他並不是嚴格意義上的介面,而是一個委託並且每個OWIN中介軟體元件必須提供。
從字面上理解,每個OWIN中介軟體在必須有一個方法接受型別了IDictionary<string,object>的變數(俗稱環境字典),然後必須返回Task來非同步執行。
Environment Dictionary
環境字典包含了Request、Response所有資訊以及Server State。通過Pipeline,每個中介軟體元件和層都可以新增額外的資訊,但環境字典定義了一系列強制必須存在的Key,如下所示:
Request Data:
|
|
Value Description |
|
|
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. |
|
|
An IDictionary<string, string[]> of request headers. See Headers. |
|
|
A |
|
|
A |
|
|
A |
|
|
A |
|
|
A |
|
|
A |
Response Data:
|
|
Value Description |
|
|
A Stream used to write out the response body, if any. See Response Body. |
|
|
An IDictionary<string, string[]> of response headers. See Headers. |
|
|
An optional |
|
|
An optional |
|
|
An optional |
Other Data:
|
|
Value Description |
|
|
A CancellationToken indicating if the request has been cancelled/aborted. See Request Lifetime. |
|
|
The string |
小結
這些規範看起來可能簡單到微不足道,但OWIN的思想就是簡單、靈活——通過要求OWIN中介軟體只依賴AppFun型別,為開發基於OWIN的中介軟體提供了的最低門檻。同時,通過使用環境字典在各個中介軟體之間進行資訊的傳遞,而非傳統ASP.NET(System.Web)中使用HttpContext貫穿ASP.NET整個生命週期來傳遞。
既然OWIN是規範,而非真正實現,所以是無法使用在專案中的,若要使用OWIN,必須要實現他,所以這也是接下來我想聊的,OWIN的實現:Katana 。