OWIN and Katana - 1
翻译自 http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
十多年来，基于ASP.NET框架已经开发了无数的网站和网络服务。伴随着网络应用程序开发的不断演进，ASP.NET也伴随着产生了新的技术，比如ASP.NET MVC和ASP.NET WEB API。网络应用程序开发的下一个方向是进入云计算， Katana工程则为ASP.NET提供了基础的模块，使网络应用程序变得更灵活、更轻量级、更容易移植以及拥有更好的性能 - 也就是说，Katana工程能够优化你的asp.net程序。
我们为什么要Katana？
无论我们讨论的是一个开发框架还是一款用户终端产品，重要的一点是理解我们创造产品的动机是什么 - 也就是说我们的产品是为谁而创造的。
ASP.NET最初有两类使用者：第一类使用者是经典的ASP开发者，在那个古老年代，ASP是一款重要的开发工具用来产生动态的、数据驱动的的网站和应用程序。ASP的runtime库提供了服务器端脚本，这些脚本中的对象其实是底层http协议和web服务器核心功能的抽象，另外它还提供了诸如session、状态管理、缓冲等功能。ASP虽然强大，可是当网络程序越来越庞大，越来越复杂时，它就显得有点力不从心了。因为在脚本环境中，代码和标记的相互交错，使得程序很难有一个良好的架构。ASP.NET强化了经典ASP的优点，同时.NET框架作为一款面向对象语言，也能够克服经典的ASP开发者们面对的问题。
第二类使用者则是Windows桌面软件开发者，经典的ASP开发者习惯了HTML标记语言以及用代码创建HTML标记，而桌面软件开发者则不同，他们更习惯于在一块画布上用控件去设计界面。ASP.NET的第一个版本，也就是"Web Forms"提供了类似的界面设计体验，这些界面用服务器端事件模型和其他一些基础功能(比如ViewState)为程序开发者在客户端和服务端的开发上无缝连接。Web Forms用一个状态事件模型有效的隐藏了网络程序的无状态性，这种模型是winform的开发者们非常熟悉的。
革命性的变化：ASP.NET MVC 和 ASP.NET WEB API
网络开发发生了非常多的变化。网络程序越来越多被开发成一系列的小的、有专属性的模块。这些模块的数量以及发布他们的频率变得越来越多，越来越快。很显然，紧跟web开发的趋势需要我们的开发框架变得更小、更专注于某方面以及模块相互直接解耦，而不是大而全。ASP.NET项目组对ASP.NET进行了改进能够使其容纳插件，而不是只用一个单一的架构。
得益于类似Ruby on Rails的架构，早期的MVC架构变得很流行。这种风格的网络程序给了程序员极大的自由度去控制程序的标记语言同时保留脚本和商务逻辑之间的分离（这正是当初asp.net的卖点所在）。ASP.NET MVC并不伴随着.NET framework一起发布，而是独立发布，这样asp项目组能够有更大的自由度以及更快的去发布新的版本。
另一个大的变化是现在的网络开发从服务器生成整个网页转向静态的标记语言结合AJAX在客户端生成部分网页。这种架构促使ASP.NET WEB API 架构的产生。和ASP.NET MVC一样，ASP.NET WEB API 架构是另外一次使ASP.NET面向模块化发展的尝试。微软的工程师们抓住了这个机会，使得ASP.NET WEB API不依赖于System.Web.dll中的任何一个类型。这样的好处是：1. ASP.NET Web API可以以一个自给自足的方式通过Nuget让程序员下载。2. 由于没有了对System.Web.dll的依赖，也就没有了对IIS的依赖，因此ASP.NET WEB API可以在其他的服务中运行，比如一个控制台程序或者一个windows 服务等。
未来：一个敏捷的框架
通过将框架各个组件解耦，并且通过Nuget发布他们，这样框架能够独立的并且迅速的升级。另外，Web API的自我托管(self-hosting)被证明是一项对程序员非常有吸引力的功能 - 程序员希望他们的服务(services)能够被一个小的、轻量级的服务器托管。实际上，其他一些框架也想有此功能。于是一个新的挑战摆在面前：不同的框架运行在独立的进程中。一个现代化的网络应用程序应该既能支持静态文件服务，又能支持动态页面生成以及Web API和最近流行的实时推送服务。指望每个服务独立运行、独立管理（启动、停止等等）是不现实的。
因此，一个托管抽象层是非常有必要的，他能够让开发人员将不同的组件和框架组合成一个网络应用程序，并运行在一个host中。
The Open Web Interface for .NET (OWIN)
受Ruby社区的Rack（一个Ruby Webserver 接口）启发，.NET 社区的几个会员开始在web servers和框架(Framework components)之间创建一个抽象层--也就是OWIN。OWIN有两个设计目标：要简单，能够尽可能的少依赖其他组件。这两个目标保证了：
1. 新的组件能够更容易的开发和使用。
2. 程序能够更容易在不同的host或者整个操作系统中运行。
抽象层保护两个核心元素：
1. 第一个是environment dictionary（环境字典），即一个IDictionary<string, object>，这个dictionary中包含了处理一个HTTP request和response所必需的状态信息，比如相关的server的状态。一个和OWIN兼容的Web server（比如Asp.NET MVC 5框架）需要将这个environment dictionary 传递下去。