基于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的请求管道。