OWIN has been floating around for the last few years. It is not
bleeding edge anymore, but if you are just starting to look at it now,
it can seem a little daunting.

What is it?

OWIN is an interface definition between .NET web servers and web
applications.

OWIN’s primary goal is to abstract the hosting process away from the
application. Historically, ASP.Net applications were required to run on
IIS, due to the coupling that exists between ASP.Net and IIS. The
introduction of OWIN makes your application, host-independent. It would
be possible to port your application between hosts and potentially
platforms/operating systems.

Another goal of OWIN is to allow the easy creation of host-independent
framework components. These are commonly known as Middleware.
Middleware will be covered in more detail in a later part of the series.

Why do I care?

It might not immediately be clear as to why you would want to do this,
and maybe you don’t. Maybe you have an application that you know is
only ever going to be run on IIS and you have no interest in running in
different hosts. That is absolutely fine and Microsoft have you covered
for that scenario. However, the new MVC and WebApi project
templates shipped inside Visual Studio, are now using OWIN. So at
the very least it would help to understand what is going on.

A quick look at the OWIN definition

The OWIN specification is actually very small. It only really defines
the following two items.

Environment Dictionary
Application Delegate

Environment Dictionary

This is simply an IDictionary<string, object>. It contains
data that is required for request and response processing. The host is
responsible for populating the dictionary with values from the request
(eg. Request Headers, Request Body etc)and the application or Middleware is responsible for adding or altering values to be used in the response.

There are a number of required entries into this dictionary as defined
by the specification. These are shown below and taken directly from the
specification.

--------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------- **Key** **Description** **Request Data** “owin.RequestBody” A Stream with the request body, if any. Stream.Null MAY be used as a placeholder if there is no request body. “owin.RequestHeaders” An IDictionary<string, string\[\]> of request headers. “owin.RequestMethod” A string containing the HTTP request method of the request (e.g., "GET", "POST"). “owin.RequestPath” A string containing the request path. The path MUST be relative to the "root" of the application delegate. “owin.RequestPathBase” A string containing the portion of the request path corresponding to the "root" of the application delegate. “owin.RequestProtocol” A string containing the protocol name and version (e.g. "HTTP/1.0" or "HTTP/1.1"). “owin.RequestQueryString” A string containing the query string component of the HTTP request URI, without the leading “?” (e.g., "foo=bar&baz=quux"). The value may be an empty string. “owin.RequestScheme” A string containing the URI scheme used for the request (e.g., "http", "https"). **Response Data** “owin.ResponseBody” A Stream used to write out the response body, if any. “owin.ResponseHeaders” An IDictionary<string, string\[\]> of response headers. --------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------

Application Delegate

This is simply a function signature which is used as the primary
interface between all components. The signature is
Func<IDictionary<string, object, Task>.

This may seem complex, but lets break it down.

All application components must implement the function signature. These components could be as small as a piece is middleware or an entire framework such as WebApi.
The function must accept the Environment Dictionary from earlier as a parameter.
The function must return a Task.

Summing up the architecture

In defining the architecture, we have used a lot of complex words and
definitions. I want to really crystalise the idea in your mind.

The idea is to think of everything in your application as a
component. Everything from a small piece of middleware to a large
framework piece such as *WebApi. * Your application may exist as a
single component or it could be a series of components.

You should think of your application as a pipeline of components too.
Each component passing the Environment Dictionary to the next.

The key point is that if we can standardise all components to a single
interface, then suddenly they become extremely portable and
independent. That is how I like to think of Owin.

The image is not quite accurate. The “performs logic” step is
misleading, because you can actually perform logic anywhere. You can
perform logic before you send the request on or after you receive the
response back from the next component in line.

Conclusion

We have talked about some fairly abstract concepts here an I know that
most of you would prefer to look at code. I am going to get much more
concrete over the next few posts, so please go ahead and give them a
read.

Menu

OWIN Series: Part 1: Introduction