基於OWin的Web服務器Katana發佈版本3

當 ASP.NET 首次在 2002 年發佈時，時代有所不一樣。 那時，Internet 仍處於起步階段，大約有 5.69 億用戶，每一個用戶平均天天訪問 Internet 的時間爲 46 分鐘，大約有 3 百萬個網站。 僅僅在 10 年以後，相同的測量指標揭示，大約有 22.7 億個 Internet 用戶，每一個用戶平均天天訪問 Internet 的時間爲 4 小時，大約有 5.55 億個網站。伴隨着網絡應用程序開發的不斷演進，ASP.NET也伴隨着產生了新的技術，好比ASP.NET MVC和ASP.NET WEB API。網絡應用程序開發的下一個方向是進入雲計算， Katana工程則爲ASP.NET提供了基礎的模塊，使網絡應用程序變得更靈活、更輕量級、更容易移植以及擁有更好的性能 - 也就是說，Katana工程可以優化你的asp.net程序。

Katana 項目實際能夠追溯到 Microsoft 外部一個名爲 Open Web Inter­face for .NET (OWIN) 的開放源代碼項目。OWIN 是一種定義 Web 服務器和應用程序組件之間的交互的規範（請參閱 owin.org）。 因爲這一規範的目的是發展一個廣闊且充滿活力的、基於 Microsoft .NET Framework 的 Web 服務器和應用程序組件生態系統，所以它能夠將服務器與應用程序之間的交互減小到一小部分類型和單個函數簽名，這個函數簽名被稱爲應用程序委託（即 AppFunc）：

using AppFunc = Func<IDictionary<string, object>, Task>;

基於 OWIN 的應用程序中的每一個組件都向服務器提供應用程序委託。 而後，這些組件連接成一個管道，基於 OWIN 的服務器將會向該管道推送請求。 爲了更有效地使用資源，管道中的全部組件都應該是異步的，這體如今返回 Task 對象的應用程序委託中。隨着版本3的發佈，Kanata目前已經完整地支持了.NET 4.5中新加入的異步編程模型。儘管ASP.NET從十年前就已經開始支持異步編程模型，但.NET 2.0中引入的IAsyncResult模型使用起來很是繁瑣，大多數開發者甚至都不知道它的存在。Node.js趁虛而入，它將本身稱爲高級異步web開發平臺，而微軟則但願經過在.NET 4.5中引入的async/await模型從新奪回這一稱號。

包括應用程序狀態、請求狀態和服務器狀態等在內的全部狀態都保存在應用程序委託上指定的 IDictionary<string, object> 對象中。 這種數據結構稱爲環境字典，隨着請求經過管道時會從一個組件傳遞到另外一個組件。 雖然任何鍵/值數據均可以插入到環境字典中，但 OWIN 規範爲某些 HTTP 核心元素定義了鍵.

HTTP 請求的必需環境字典鍵

鍵名稱	值說明
"owin.RequestBody"	一個帶有請求正文（若是有）的流。若是沒有請求正文，Stream.Null 能夠用做佔位符。
"owin.RequestHeaders"	請求標頭的 IDictionary<string, string[]>
"owin.RequestMethod"	一個包含請求的 HTTP 請求方法的字符串（例如 GET 和 POST）。
"owin.RequestPath"	一個包含請求路徑的字符串。 此路徑必須是應用程序委託的「根」的相對路徑。
"owin.RequestPathBase"	一個字符串，包含對應於應用程序委託的「根」的請求路徑部分。
"owin.RequestProtocol"	一個包含協議名稱和版本的字符串（例如 HTTP/1.0 或 HTTP/1.1）。
"owin.RequestQueryString"	一個字符串，包含 HTTP 請求 URI 的查詢字符串組成部分，不帶前導「?」（例如 foo=bar&baz=quux）。 該值能夠是空字符串。
"owin.RequestScheme"	一個字符串，包含用於請求的 URI 方案（例如 HTTP 或 HTTPS）。

定義一組基本的環境字典鍵/值對，使得許多不一樣的框架和組件做者能夠在一個 OWIN 管道中進行互操做，而沒必要強制實施對特定 .NET 對象模型的協議，例如針對 ASP.NET MVC 中的 HttpContextBase 或 ASP.NET Web API 中的 HttpRequestMessage/HttpResponseMessage 的協議。

應用程序委託和環境字典這兩個元素構成了 OWIN 規範。 Katana 項目是 Microsoft 建立和推出的基於 OWIN 的組件和框架集合。

在新的功能特性方面，新版本主要關注於「企業級認證功能以及基於聲明的標識（claims-based identity）」。參與了Katana 3項目的Vittorio Bertocci特別提到了如下三種協議：

• WS-Federation
• OpenId Connect (經過表單提交方式提供id_token以及id_token+code方式)
• 可在Web API中使用的OAuth2票據令牌認證

Vittorio還寫道：

這個版本的發佈還解決了因爲Twitter和Google API發生變更所引發的問題。若是你在應用中使用了Google認證，而且打算升級到Katana版本3，請確保你已讀過這篇帖子！

Katana能夠做爲NuGet包得到。根據Katana網站描述顯示，取決於你所需的不一樣特性，共有總數超過20的包能夠選擇下載：（這一點和傳統的ASP.NET造成了鮮明的對比，後者的方式是將幾乎全部特性都堆積在一個龐大的程序集中。）

• Microsoft.Owin – 提供了一組輔助類型，以及爲簡化建立OWIN組件而建的各類抽象類型。
• Microsoft.Owin.Diagnostics – 提供了各類中間件組件，以輔助開發基於OWIN的應用程序。
• Microsoft.Owin.FileSystems – 這個包裏提供了文件系統相關的抽象與實現。
• Microsoft.Owin.Testing – 提供了對OWIN組件進行單元測試的一些輔助類。
• Microsoft.Owin.SelfHost – 包含了爲在自行指定的進程中託管基於OWIN的應用程序所必需的一些組件。
• Microsoft.Owin.Hosting – 提供了託管與運行基於OWIN的應用程序所需的默認基礎框架類型。
• OwinHost – 提供了一個單獨的可執行程序（OwinHost.exe），經過它能夠託管一個基於OWIN的應用程序的運行。
• Microsoft.Owin.Cors – 這個包裏包含了一些可以在OWIN中間件中進行跨域資源共享（CORS）的組件。
• Microsoft.Owin.StaticFiles – 這個包裏包含了一些OWIN中間件，可以處理來自於文件系統資源的請求，包括文件與目錄。
• Microsoft.Owin.Security – 包含了一些各類不一樣的認證中間件組件所共享的 通用類型。
• Microsoft.Owin.Security.ActiveDirectory – 一組容許應用程序使用微軟技術進行認證的中間件。
• Microsoft.Owin.Security.Cookies – 容許應用程序使用基於cookie進行認證的中間件，相似於ASP.NET中的表單認證方式。
• Microsoft.Owin.Security.Facebook – 容許應用程序支持Facebook所使用的OAuth 2.0認證工做流的一些中間件。
• Microsoft.Owin.Security.Google – 包含了一組支持Google的OpenId及OAuth 2.0認證工做流的中間件。
• Microsoft.Owin.Security.Jwt – 一組容許應用程序保護及驗證JSON Web令牌的中間件。
• Microsoft.Owin.Security.MicrosoftAccount – 一組容許應用程序支持微軟賬號認證工做流的中間件。
• Microsoft.Owin.Security.OAuth – 容許應用程序支持任何標準OAuth 2.0認證工做流的中間件。
• Microsoft.Owin.Security.OpenIdConnect – 容許應用程序使用OpenIdConnect方式進行認證的中間件。
• Microsoft.Owin.Security.Twitter – 容許應用程序支持Twitter的OAuth 2.0認證工做流的中間件。
• Microsoft.Owin.Security.WsFederation – 容許應用程序使用WsFederation進行認證的中間件。
• Microsoft.Owin.Host.HttpListener – 基於.Net Framework中的HttpListener類建立的OWIN服務器，也是目前用於自託管的默認服務器。
• Microsoft.Owin.Host.SystemWeb – 也是OWIN服務器實現，但它容許基於OWIN的應用程序運行在IIS中，並可以使用ASP.NET的請求管道。