Introduction to OWIN

OWIN stands for Open Web Interface for .NET.  It is the new standard interface between web servers and web applications. OWIN is not a framework. It is a set of rules or specifications on how the web applications and web servers should interact with each other.

With OWIN ASP.NET is going to change a lot. We should see this change starting from the next Version of ASP.NET called ASP.NET/VNext

Introduction to OWIN
Introduction to OWIN

Why Change

The Current ASP.NET Application has a few limitations. System.web assembly has very rich features but tightly Integrated with the Framework and IIS.

Tied to IIS

ASP.NET runtime was built with dependencies on IIS.  This means ASP.NET can only be hosted in IIS. This limited the ability to run the ASP.NET applications on other platforms like Linux

Slower Releases

System.web assembly is part of the larger .NET Framework.  The issue with such an arrangement is that changes to System.Web cannot be released as a standalone release. The changes will have to be released along with the.NET Framework. The web technologies evolve very quickly, which means that Microsoft urgently needed a way to release new components quickly to stay relevant.

Bulky

ASP.NET is robust and feature-rich web framework. It was designed to compete with JAVA and It’s very powerful.  System.Web has a large no of components, some which we never use or require.  Whenever we write an MVC Application we get all the components. We don’t need all the components. The goal of OWIN is to break this into smaller components. Which means you can use those components you require.

How it works

The applications built on OWIN specifications are not aware of the Infrastructure that Hosts the application.  They will know only about the OWIN Interface.  The means ASP.NET MVC Page Cycle is going to change. It is replaced by the new  and simpler OWIN Pipeline as shown in the image below

OWIN Pipeline

The task of choosing which middleware to run now rests with the developer.  In fact, you can write your own middleware and plug it into the pipeline or you can replace the middleware with a better one. You can also get rid of those middleware’s which you don’t need to make the application lightweight and fast.

OWIN Pipeline
OWIN Pipeline

One Important point to note that one Middleware is responsible for invoking the next Middleware.  The Middleware must get the reference to the next Middleware from the Web Server.  When Middleware finishes its job it will call the next Middleware. This Cycle continues until it reaches the Application 

OWIN Specification

The OWIN Specification is listed in the following link http://owin.org/html/spec/owin-1.0.html

OWIN Architecture

The above OWIN specification describes the five parts (or roles) of the application called as software actors. They are Server, Web Framework, Web Application, Middleware, and Host.

OWIN Application Architect
OWIN Application Architect

Web Application

This is the web application that you are going to write. This Application is built using the web frameworks like ASP.NET,MVC, SignalR etc.

Web Framework

Web frameworks sit top of OWIN and may interact with the OWIN middleware. Web frameworks are ASP.NET, MVC, SignalR etc.

Middleware

Middleware runs on the Server. They are part of the OWIN Pipeline that is formed between server and application.  There could be more than one middleware’s which are linked together and process the requests. Middlewares exposes the application delegates.

OWIN Server

The server is responsible for the HTTP communication with the client. It must implement the OWIN specification to process the request.

Host

The host is the process under which the Server is run. It is responsible for creating the application and the server. It is responsible for managing the process lifetime. The host could be IIS, console application or a Custom Host.

Application Delegate

Every component in the OWIN pipeline must implement the following signature. A generic Func delegate which accepts the Environmental dictionary and returns a task. This is actually the reference to the next component in the request pipeline.

Func<IDictionary<string, object>, Task>

The above signature is also called as AppFunc. AppFunc takes one argument  IDictionary<string, object> which is called environment dictionary. It then uses the information available in this dictionary and process it and then returns a Task.

The Environment Dictionary

The Environment Dictionary (IDictionary<string, object>) is simply a dictionary collection of objects. This is basically a collection of key-value pair data. It contains the information about the request, response, capabilities of the Host, server and any other relevant information about the request.

The OWIN specification makes it obligatory to the implement the few minimum set of keys and values. They are mostly related to the Request/response data. The Specification currently lists following Key/Values

Request Data

owin.RequestBody

owin.RequestHeaders

owin.RequestMethod

owin.RequestPath

owin.RequestPathBase

owin.RequestProtocol

owin.RequestQueryString

owin.RequestScheme

Response data

owin.ResponseBody

owin.ResponseHeaders

owin.ResponseStatusCode

owin.ResponseReasonPhrase

owin.ResponseProtocol

Others

owin.CallCancelled

owin.Version    

You will notice that most of them nothing but plain old properties exposed by the ASP.NET Request and Response objects. You can find out about these from the specification from this link.

The Environment Dictionary is created and populated by the Host. The Host will add the relevant information about the request like any startup data and capabilities of the Host and forwards it to the Server.  Each layer in the OWIN architecture passes this dictionary to the next layer (Hosts, server, middleware, application) until it reaches the application.  Each layer can add additional data to the  Environment dictionary or modify the data in the dictionary 

Application startup

The following steps when an application startup.

Environment dictionary (IDictionary<string, object>) is created and populated by the Host.

The host then selects the OWIN Server. The host then starts the server and passes the Environment dictionary to it.  OWIN Server may add/modify the dictionary.

Host locates the application code and invokes it and passes the Environment dictionary to the application.

The application the constructs the request pipeline and returns the application delegate (AppFunc). The application may add/modify the dictionary.

Host invokes the server startup code with the given application delegate and Environment dictionary.

Server Configures itself and starts accepting the requests and invokes the application delegate to process those requests.

Advantages of Using OWIN

Portable

You can easily Port Web application to another web host which supports OWIN. 

Efficiency

OWIN is Lightweight. You can add only those features you need in your applications. This will make the application efficiently and fast.

Loose coupling

The Applications built using OWIN guidelines will have a loose coupling between the various components.  This means that you can easily replace the one component with another one.

Does OWIN replace IIS

OWIN does not replace IIS. You can use OWIN on IIS. 

KATANA

KATANA is the Microsoft’s implementation of the OWIN specification. Remember that the OWIN is just a specification.

KATANA Project is open source and you can find the project source from the location  http://katanaproject.codeplex.com/

 Conclusion

This ends our brief introduction to the OWIN.  In the next tutorial, we will show you how to build a Simple OWIN middleware in your application.

ASP.NET Identity Tutorial using OWIN

  1. Introduction to ASP.NET Identity
  2. NET Identity Tutorial – Getting Started
  3. NET Identity Tutorial -OWIN Authentication Middleware

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top