當 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程序。css
Katana 項目實際能夠追溯到 Microsoft 外部一個名爲 Open Web Interface for .NET (OWIN) 的開放源代碼項目。OWIN 是一種定義 Web 服務器和應用程序組件之間的交互的規範(請參閱 owin.org)。 因爲這一規範的目的是發展一個廣闊且充滿活力的、基於 Microsoft .NET Framework 的 Web 服務器和應用程序組件生態系統,所以它能夠將服務器與應用程序之間的交互減小到一小部分類型和單個函數簽名,這個函數簽名被稱爲應用程序委託(即 AppFunc): html
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模型從新奪回這一稱號。web
包括應用程序狀態、請求狀態和服務器狀態等在內的全部狀態都保存在應用程序委託上指定的 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 的組件和框架集合。cookie
在新的功能特性方面,新版本主要關注於「企業級認證功能以及基於聲明的標識(claims-based identity)」。參與了Katana 3項目的Vittorio Bertocci特別提到了如下三種協議:網絡
Vittorio還寫道:數據結構
這個版本的發佈還解決了因爲Twitter和Google API發生變更所引發的問題。若是你在應用中使用了Google認證,而且打算升級到Katana版本3,請確保你已讀過這篇帖子!框架
Katana能夠做爲NuGet包得到。根據Katana網站描述顯示,取決於你所需的不一樣特性,共有總數超過20的包能夠選擇下載:(這一點和傳統的ASP.NET造成了鮮明的對比,後者的方式是將幾乎全部特性都堆積在一個龐大的程序集中。)