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
Table of Contents
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.
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.
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.