OWIN/KATANA from A — Z — part 1

History of Microsoft web technologies:

  • 1996 — ASP (Active Server Pages)
  • 2002 — ASP.NET Web Forms
  • 2008 — ASP.NET MVC
  • 2010 — ASP.NET Web Pages
  • 2012 — ASP.NET WebAPI, SignalR
  • 2014 — ASP.NET vNext
  • 2015 — changing vNext to ASP.NET 5
  • 2016 — changing ASP.NET 5 to ASP.NET Core 1.0

What is OWIN?

  • Stands for: The Open Web Interface for .NET.
  • It’s only a specifications not code.
  • Microsoft built a project named KATANA and this project follow OWIN specifications to allow some Microsoft’s web features to take the benefits of using OWIN.
  • OWIN Inspired by Rack in the Ruby community.
  • OWIN creates an abstraction between Web servers and framework components.
  • It’s an open standard.
  • Authored by 2 MS guys: Benjamin Vanderveen and Louis Dejardin.

The formal OWIN definition in owin.org website is very clear:

OWIN 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.

Why the need for OWIN?

before we go deeply on to what is OWIN and KATANA and how to use them, we need to know some important points that take Microsoft to this way.

Microsoft through it’s development way in web industry and after ASP.NET Web Forms, the net result was a mature, feature-rich run-time and developer programming model but there are Challenges raised by the historical model:

  • Different features in one big DLL: System.Web.dll assembly (for example, the core HTTP objects with the Web forms framework).
  • ASP.NET was included as a part of the larger .NET Framework, which meant that the time between releases was on the order of years.
  • System.Web.dll itself was coupled in a few different ways to a specific Web hosting option: Internet Information Services (IIS).

Those challenges and the rapidly development in web industry let Microsoft to take evolutionary steps to enhance it’s web technology platform.

  • Two evolutionary steps: ASP.NET MVC and ASP.NET Web API
    Web applications were increasingly being developed as a series of small, focused components rather than large frameworks.
  • ASP.NET MVC was released as an independent download. This gave the engineering team the flexibility to deliver updates much more frequently than had been previously possible.
  • ASP.NET WebAPI Another major shift in Web application development due to the shift from dynamic, server-generated to static initial markup using AJAX .
    – Nugget so frequently updates.
    – No dependencies on System. Web so can hosted outside IIS.

So why OWIN?

What was needed was a single hosting abstraction that would enable a developer to compose an application from a variety of different components and frameworks, and then run that application on a supporting host.

Why not hosting on IIS only?

  • Use small, lightweight web server
  • Avoid IIS performance overhead
  • IIS might not be available…

What is KATANA?

Katana is « just » Microsoft implementation of OWIN rules!

So OWIN itself does not have any tools, libraries or anything else. It is just a specification.

Whereas both the OWIN specification and Owin.dll are community owned and community run open source efforts, the Katana project represents the set of OWIN components that, while still open source, are built and released by Microsoft.

These components include both infrastructure components, such as hosts and servers, as well as functional components, such as authentication components and bindings to frameworks such as SignalR and ASP.NET Web API.

OWIN/KATANA Goals

OWIN Goals:
creates an abstraction between Web servers and framework components

KATANA Goals:

Portable Components
Modular Components
Lightweight Components

Understanding the main OWIN Specifications parts:

Specifications on: http://owin.org

Specifications main parts:

  • Definition of Software Actors
  • Request execution
  • Application Delegate
  • Environment
  • Request data, Response data, Other data
  • Application Startup
  • URI and Paths
  • Error Handling
  • Versioning

So, any code will follow the OWIN specification will take many advantages. For example, this code will be modular snd plug-able in the way that you can easily use it many times in many projects and within different hosts.

Definition of Software Actors:

  • Host:
    The process that hosts the other parts( IIS , Windows service, Console application)
    It is responsible for starting every thing up.
  • Server:
    Responsible for binding to a TCP port, constructing the environment dictionary
    and processing requests through an OWIN pipeline.
    In IIS: Host == Server
  • Middleware:
    Is just a piece of code that the request passes on the way to and from the application
    They can be used to inspect & modify both the incoming requests & outgoing responses.
  • Pipeline of middlewares:
    As the server passes the request to the app using AppFunc, it send it through a pipeline of middlewares.
  • Application:
    Is the part that responsible for generating the actual response.
    Technically, no difference between application and middleware except the fact that the application short circuit the pipeline by generating a response but the middleware alter the pass the request or response.
  • Web Framework:
    Not part of actors but it’s a set of middleware that plug into the pipeline and expose their own set of APIs for developers to interact with.

Application Delegate (AppFunc):

  • The primary interface in OWIN is called the application delegate or AppFunc.
  • An application delegate takes the IDictionary<string, object> environment and returns a Task when it has finished processing.
// Use an alias for OWIN AppFunc
using AppFunc = Func&lt;IDictionary&lt;string,object&gt; // Environement Dictionary
,Task // Tell server to non block any process waiting request to finish
&gt;;
  • The application MUST eventually complete the returned Task, or throw an exception.
  • Returning Task tell server to non block any process waiting request to finish.

Environment:

  • The Environment dictionary stores information about the request, the response, and any relevant server state.
  • Server is responsible for initiating it, but the application is responsible for response data and response body.
  • The environment dictionary MUST be non-null, mutable and MUST contain the keys listed as required in the specifications.

Request data, Response data, Other data:

Here is an OWIN/KATANA training slides, which i introduced last month in the company that i worked in. I think it may be helpful.

Also this is an TXT file which contains some code snippets and cheat sheet for owin/katana which was related to slides.

https://github.com/deserthero/OWINKATANA-Training

That’s all till now.