Getting up to speed with Katana

You may have heard some talk about OWIN and the Katana Project over the past few years. Let's get the (kind of boring and abstract) definitions out of the way, then talk about why they're exciting and how you can learn more.

OWIN (Open Web Interface for .NET) defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

The Katana Project provides a set of OWIN implementations for Microsoft servers and frameworks.

In case it's not immediately obvious why those things are actually useful, let's throw some colorful pictures at the problem. Here's how ASP.NET has always worked:

Traditional ASP.NET Hosting Model

In this model, you work in a sandbox that provided you some known extension points. Creating a new ASP.NET application creates a special .NET project which has been tightly wired to the ASP.NET runtime, which in turn is pretty tightly wired to IIS. ASP.NET can be extended via with handlers and modules and the various ASP.NET frameworks (ASP.NET Web Forms, ASP.NET MVC, ASP.NET Web API, etc.) provide hooks that let you override or configure the way things work (IIS provides some extensibility points as well) but you're always aware that you're being hosted by ASP.NET and IIS.

OWIN defines a flexible, pluggable stack with a lightweight interface for web applications.

ASP.NET hosting under OWIN and Katana

Each component in the stack just needs to implement a function which accepts a dictionary (holding the application state) and returning a task. This flexible interface between layers provides a lot of benefits:

  • Fast - This is a really lightweight interface that doesn't need to bring along the whole ASP.NET / IIS party to every request, so it's really tight and can run really, really fast.
  • Pluggable - The middleware section in the above diagram shows more than one component. You can easily plug in lightweight components which modify your how your application runs. Middleware can handle all kinds of scenarios, including authentication and security, optimization, response modification, etc.
  • Flexible - You can mix and match anything that implements the OWIN spec, meaning you could drop ASP.NET applications with Katana on another server or host as well as host other .NET web frameworks (e.g. NancyFx, ServiceStack, Fubu, etc.) on any OWIN compatible server, with the flexibility to use any OWIN compatible middleware.

The Katana team is working to enable several really exciting scenarios, including hosting ASP.NET applications on OWIN hosts and plugging in OWIN middleware to existing ASP.NET applications.


Great, because I've got a bunch of fresh, new recommendations on where you can find out more.

Whitepaper: An Overview of Project Katana

We just published a new whitepaper by Howard Dierking on the ASP.NET site: An Overview of Project Katana

Howard goes into a lot more detail about why Project Katana was started, how Project Katana implements OWIN, and how you can get started with Project Katana (complete with a nice walkthrough).

Video overview on Web Camps TV

Brady Gaster and Cory Fowler just interviewed Howard on Web Camps TV (Channel 9) last week. In this 45 minute video, Howard talks about Katana Project, builds out an application showing OWIN self hosting with an ASP.NET Web API application, and explains what's next for Project Katana.

The Katana Project - OWIN for ASP.NET


We just interviewed Louis DeJardin (Principal SDE on the Katana team, @loudej, blog) on the Herding Code podcast last month. Detailed show notes are available here.

Download / Listen

Herding Code 164: OWIN and Katana with Louis DeJardin

What are you still doing here?

Go read, watch, and listen!


  • @foofoodog - best way to test that is to grab the bits and try it out. If you discover either smoke or mirrors, let us know so that we can fix things.

  • This looks really great. I watched the Ch9 video a couple of weeks ago and the idea of the pipeline described in the video was great, particularly the way I could have a single authentication component at the start of the pipeline to cover all of the various bits (ASP.Net WebAPI, SignalR, etc).

    It seems the new ASP.Net stuff is ready for this but not the "older" stuff (eg WebForms & MVC). I'm about to go read the whitepaper so maybe it's explained in there.

    Thanks for posting this info.


  • Just looks like an excuse to ditch type safety and play around with building frameworks. Nothing in the linked article actually proves this will perform better, scale better, or be more flexible than what we've already got.

Comments have been disabled for this content.