在上篇文章中，对OWIN进行了简单的介绍。本篇文章来介绍一下Katana项目。为了能更好地理解Katana项目，我建议先了解一下OWIN是什么。
假设你已经了解了OWIN，到目前为止，你应该知道OWIN是社区所有的规范，它并不属于微软。它不是任何形式的实现，只是一些定义了.NET web服务器和web程序之间标准接口的原则清单。
那么，Katana项目从何而来？
Katana项目
Katana项目是OWIN的微软实现。如你所知，OWIN将整个程序描述为四层，分别为主机、服务器、应用程序框架/中间件和应用程序。在Katana项目中，微软所做的就是遵循了OWIN规范。上面提到的每个层都有多个组件。核心的概念是，它们之间互不耦合。
你可能想知道这样解耦的原因。
为什么
也许你已经知道，ASP.NET早在2002年第一次发布了.NET1.0。
ASP.NET是作为.NET框架的一部分发布的。也就是说只有新的.NET框架发布的时候，新版本的ASP.NET才能可用。但问题是，Web发展如此迅速，ASP.NET已经不能赶上它的发展了。
另一件事就是ASP.NET中的一切都被捆绑进了System.Web程序集，由于ASP.NET和System.Web如此紧密的耦合，随着微软为ASP.NET更新或引入新功能导致System.Web程序集越来越大。
正是由于这种紧密耦合，导致了重大的性能影响。所有的选项都是默认启用的，然而用户需要花费金钱和时间处理不需要的选项。最重要的是，由于这种紧密耦合，程序只能托管到IIS上。
作为改变的第一步，2007/2008年，微软将ASP.NET MVC从.NET框架分离。ASP.NET MVC通过Nuget下载的方式进行发布，这给了微软比以前更频繁更新的灵活性。
在2012年，ASP.NET Web API发布。ASP.NET Web API被设计为不依赖于System.Web的任何东西，因此，也不依赖于IIS，并且ASP.NET Web API能运行在自定义的托管中（比如，控制台程序，Windows服务等等）。通过将一个框架组件从另一个解耦，然后通过Nuget发布，框架可以更加独立和快速地迭代。
Katana组件
如果你还记得OWIN将ASP.NET程序描述为四层：主机、服务器、应用程序框架/中间件和应用程序。那么，对应的Katana组件如下：
- 应用程序
- ASP.NET MVC应用程序
- 应用程序框架/中间件
- SignalR
- ASP.NET Web API
- 服务器
- SystemWeb
- HttpListener
- WebListener
- 主机
- IIS
- OwinHost.exe
- 自定义进程
