标签：web服务器 started ast evo 流水线 i/o 自定义 程序开发 并且
Katana项目为ASP.NET应用程序提供了一组基础组件，使其能够灵活，便携，轻量化，并提供更好的性能 。
无论是讨论开发者框架还是最终用户产品，重要的是要了解创建产品的基本动机 - 其中的一部分包括知道产品是为谁创建的。ASP.NET最初是为两类客户创建的。
第一类客户是经典的ASP开发人员。当时，ASP是通过交织标记和服务器端脚本动态创建数据驱动的网站和应用程序的主要技术之一。ASP运行时提供的服务器端脚本具有一组抽象基础HTTP协议和Web服务器的核心方面的对象，并提供对其他服务（如会话和应用程序状态管理，缓存等）的访问。虽然经典的ASP应用程序功能强大，但随着规模和复杂程度的增长而面临挑战。这主要是由于在脚本环境中结构不足以发现和标记代码的交错产生的代码重复。
ASP.NET的第二组目标客户是Windows业务应用程序开发人员。与传统ASP开发人员不同的是，他们习惯于编写HTML标记和代码来生成更多的HTML标记，WinForms开发人员（或之前的VB6开发人员）习惯了实时设计体验，包括画布和丰富的用户界面控件。ASP.NET的第一个版本 - 也被称为“WebForm”，为用户界面组件和一组基础架构功能（如ViewState）提供了类似的实时设计体验以及服务器端事件模型，以创建无缝的开发人员体验在客户端和服务器端编程之间。Web窗体在WinForms开发人员熟悉的有状态事件模型下有效地隐藏了Web的无状态。
最终的结果应该是成熟的，功能丰富的运行时和开发人员编程模型。然而，由于功能丰富，出现了一些显著的挑战。首先，框架是单一的，逻辑上不同的功能单元在相同的System.Web.dll程序集中紧密耦合（例如，具有Web窗体框架的核心HTTP对象）。其次，ASP.NET作为较大的.NET Framework的一部分被包含在内，这意味着发布之间的间隔很长。这使得ASP.NET难以跟上快速发展的Web开发中发生的所有变化。最后，System.Web.dll本身以几种不同的方式耦合到特定的Web主机选项：Internet Information Services（IIS）。
Web开发中发生了许多变化！Web应用程序越来越多地被开发为一系列小型，集中的组件，而不是大框架。组件数量以及发布频率以更快的速度增长。很明显，跟踪Web将需要框架更小，分离和更集中，而不是更大和更多功能丰富，因此ASP.NET团队采取了几个进化步骤，使ASP.NET成为一个可插拔Web组件而不是单个框架。
早期的变化之一是由于诸如Ruby on Rails之类的Web开发框架，众所周知的模型视图 - 控制器（MVC）设计模式的受欢迎程度日益提高。这种构建Web应用程序的风格使开发人员更好地控制了应用程序的标记，同时仍保留了标记和业务逻辑的分离，这是ASP.NET的首要卖点之一。为了满足这种风格的Web应用程序开发的需求，微软通过开发ASP.NET MVC（并不包括在.NET Framework中），借此机会更好地为未来做好准备。ASP.NET MVC作为独立下载发布。这使工程团队灵活地提供比以前更可能的更频繁的更新。
Web应用程序开发的另一个主要转变是从动态的，服务器生成的网页转变为静态初始标记，其中页面的动态部分是通过AJAX请求与后端Web API通信的客户端脚本生成的。这种架构转变有助于推动Web API的兴起，以及开发ASP.NET Web API框架。如ASP.NET MVC一样，ASP.NET Web API的发布提供了另一个进一步将ASP.NET进一步演化为模块化框架的机会。工程团队充分利用了这个机会并构建了ASP.NET Web API，使其不依赖于System.Web.dll中的任何核心框架类型。这启用了两件事情：第一，这意味着ASP.NET Web API可以以完全自包含的方式发展（并且可以继续快速迭代，因为它是通过NuGet传递的）。第二，因为没有System.Web.dll的外部依赖，因此，不依赖于IIS，ASP.NET Web API包括在自定义主机中运行的功能（例如，控制台应用程序，Windows服务等） ）
通过将框架组件彼此解耦，然后在NuGet上发布它们，框架现在可以更独立更快地进行迭代。此外，Web API自主托管功能的强大功能和灵活性对于想要一个轻量级小型主机的开发人员来说非常有吸引力为他们的服务。事实证明，其他框架也希望能够实现这一功能，而且这个框架也出现了一个新的挑战，每个框架都在自己的主机进程中运行，并且需要被管理（启动，停止等）独立。现代Web应用程序通常支持静态文件服务，动态页面生成，Web API以及最近的实时/推送通知。期望这些服务应该独立运行和管理是不现实的。
需要的是一个单一的托管抽象，这将使开发人员能够从各种不同的组件和框架中组合应用程序，然后在支持的主机上运行该应用程序。
受到Rack在Ruby社区中取得的好处的启发，.NET社区的几个成员开始在Web服务器和框架组件之间创建抽象。OWIN抽象的两个设计目标是简单，并且对其他框架类型采用最少可能的依赖关系。这两个目标有助于确保：
最终的抽象由两个核心元素组成。第一个是环境字典。该数据结构负责存储处理HTTP请求和响应以及任何相关服务器状态所需的所有状态。环境字典定义如下：
IDictionary<string, object>
OWIN兼容的Web服务器负责使用诸如身体流和头部集合之类的数据来填充环境字典以用于HTTP请求和响应。应用程序或框架组件的责任就是使用附加值填充或更新字典，并写入响应主体流。
除了指定环境字典的类型外，OWIN规范还定义了核心字典键值对的列表。例如，下表显示了HTTP请求所需的字典键：
| 钥匙名称 | 价值说明 |
|---|---|
"owin.RequestBody" |
具有请求体的流，如果有的话。如果没有请求正文，Stream.Null可以用作占位符。见请求体。 |
"owin.RequestHeaders" |
一个IDictionary<string, string[]>请求头。见标题。 |
"owin.RequestMethod" |
A string包含请求的HTTP请求方法（例如"GET"，，"POST"）。 |
"owin.RequestPath" |
A string包含请求路径。路径必须相对于应用程序委托的“根”; 看路径。 |
"owin.RequestPathBase" |
A string包含与应用程序委托的“根”对应的请求路径部分; 看路径。 |
"owin.RequestProtocol" |
A string包含协议名称和版本（例如"HTTP / 1.0 "或"HTTP / 1.1 "）。 |
"owin.RequestQueryString" |
A string包含HTTP请求URI的查询字符串组件，没有前导“？” （例如，"foo=bar&baz=quux"）。该值可能是一个空字符串。 |
"owin.RequestScheme" |
A string包含用于请求的URI方案（例如"http"，，"https"）; 参见URI Scheme。 |
OWIN的第二个关键因素是应用程序委托。这是一个功能签名，用作OWIN应用程序中所有组件之间的主界面。应用程序委托的定义如下：
Func<IDictionary<string, object>, Task>;
然后，应用程序委托只是Func委托类型的一个实现，该函数接受环境字典作为输入并返回一个任务。这种设计对开发人员有几个影响：
从实现的角度来看，OWIN是一个规范（http://owin.org/html/owin.html）。其目标不是下一个Web框架，而是Web框架和Web服务器交互的规范。
如果您调查过OWIN或Katana，您可能还注意到Owin NuGet软件包和Owin.dll。该库包含一个单一的接口，IAppBuilder，它将OWIN规范第4部分描述的启动顺序进行形式化和编码。虽然为了构建OWIN服务器不是必需的，IAppBuilder接口提供了具体的参考点，由Katana项目组件使用。
而OWIN规范和Owin.dll都是社区所有和社区运行的开源工作，Katana项目代表了一组OWIN组件，虽然仍然是开放源代码，由Microsoft构建和发布。这些组件包括基础架构组件（如主机和服务器）以及功能组件，例如身份验证组件和绑定到框架（如SignalR和ASP.NET Web API）。该项目有以下三个高水平目标：
标签：web服务器 started ast evo 流水线 i/o 自定义 程序开发 并且
原文地址：http://www.cnblogs.com/Excelsior/p/7388069.html
