OWIN
“OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application”
OWIN decouples the web server from the application frameworks .This may sound to be a simple principle ,and it is, but if it has many implications if we think about it. As the web server is decoupled from the application framework we can use the application with different web servers and other components.
Flexibility We have the option of selecting the different components and easily replacing one component with another one.We can mix and match different components as we see fit based on our requirement.
Portable Owin
It lets us us connect the existing components with new components which are not restricted to any particaular vendor.We can repalce the host,server or the middleware anytime.
Efficiency Owin
Updated on recommendation of Google Search Console.
It is Lightweight. Owin provides us the capability to add and use features we require .As there are different components to handle specific responsibilities we can use only the ones we require,rather than being forced to use something we never use.
OWIN is just a specification and there could be many different implementations of OWIN.Katana is an example of one such implementation.
An application built upon OWIN specification has the following layers,
- Host is responsible for starting the process. It also creates the pipeline by fetching the information from our application. It fetches the configuration information from our application to create the pipeline.
- Server binds to a port and listens for the requests. Once it receives the request it passes the request in the pipeline that our application has configured.IIS is an example of both Host and Server .
- Application framework provides a development model to our application.MVC is a an example of one such framework.
- Application is the application that we are developing.
The advantage of using this component based approach to decouple web server and our application is that it gives us multiple options to use any component for any of the different layers.This is in contrast to the coupling between System.Web and IIS.
OWIN components
There are only two main pieces in OWIN,
- An environment dictionary This dictionary is passed to our application by the server with request and response header and bodies.Our application works directly with this dictionary instead of communicating with the server.It is this dictionary which helps create the decoupled OWIN architecture.
- A generic Func delegate: This delegate takes as a parameter the above mentioned environment dictionary and returns a Task.We can plugin different middleware components using this.
The environment dictionary can contain only the designated keys.Some of the keys related to the Request are,
- owin.RequestBody:A Stream with the request body
- owin.RequestHeaders: A IDictionary<string, string[]> containing request headers.
- owin.RequestMethod: A string containing the HTTP method of the request (GET, POST etc. )
- owin.RequestPath: A string which contains the request path
- owin.RequestPathBase:A string which contains the portion of the request path corresponding to the "root" of the application delegate
- owin.RequestProtocol: A string which contains the protocol name and version (HTTP/1.0, HTTP/1.1 etc.)
Following happens when the host starts
The environment dictionary is created by the Host and passed to the server.Host also populates this ,prior to passing this to the server,to inform the server about itself.
Server populates this dictionary to announce its capabilities to other OWIN components, like our application and the server.
Host passes the dictionary to our application's setup code.
Our application creates the request pipeline and returns the generic Func delegate.
Host now starts the server by launching the server startup code with the dictionary and the delegate.
After the above steps have completed the server is ready accept the requests using the delegate passed to it by our application.