Behind the Scenes of OWIN (Open Web Interface for .NET)

In this article, we will understand what OWIN is and its history of how it was created. The article will help to who are wondering behind it.

And we will understand how a group of people brought valuable ideas to the .NET community. Also important is the fact that Microsoft has embraced OWIN and ASP.NET Core is basically built on this idea.

Let’s get started!

In simple terms, OWIN is the acronym for Open Web Interface for .NET and it is a specification that provides to decouple web servers with web applications. This specification is an also open standard for all .NET ecosystems.

The official OWIN is — “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.”

The word “specification” can confuse you but it means standardized contracts/interfaces which provide how communication between web servers and applications should be. So, these things are not concrete implementations rather it is telling developers how to communicate between web servers and web applications.

The Story

The story of OWIN began (2010) with a group of people who were inspired by other programming language libraries and they were trying to create a library that provides HTTP abstraction between web servers and web applications/frameworks.

One day a group of people who were working on their own framework/library, Ryan Riley (the creator of Kayak) sent an email to others who were working on its framework/library about sharing knowledge and working together (because they were working on the same and different but complementary things).

September 7 (2010), The first email sent by Ryan Riley is shown below.

Then the group started discussing it together because the message made sense. And they started to collaborate through the Google group.

First of all, the group met to find solutions to the problems. The main problems were,

• ASP.NET was coupled to IIS (System.Web.* packages)
• ASP.NET was too heavy
• IIS was too slow (old versions)
• Hard to do REST (like minimal API — Sinatra -> DSL things)

In addition, the .NET community needed decoupled/independent, lightweight, and efficient web frameworks that worked with different lightweight web servers.

So, the group of people started to solve it with inspiration from Rack (Ruby) and WSGI(Python). In simple terms, Rack and WSGI define a common interface between a web server and a web application.

September 27 (2010), the first draft came from Benjamin van der Veen.

As you can see the idea stands on Responder, Request, and Response interfaces. (It provides certain abstraction from the server side and provides abstraction by Request and Response passed to the application side. The idea provides standardization with interfaces)

On November 29 (2010), one of the people (Scott Koon) from the group created a working group under the name “.NET HTTP Abstractions” (check it out Google group).

The group of people has come to a consensus about web server wrappers. At the same time, the Open Web Interface for .NET (OWIN) nomenclature was decided upon and the specification started to be written.

Also, at the beginning of the specification, the group of people declared goals.

• No dependencies
• Flexibility of style
• Server independence

Well, during the writing of the specification, some problems were of course encountered (I will skip this part, if you want more details you can check out the Google group and website links).

After some brainstorming and experimentation, the group of people found the following solutions, which are shown below.

They concentrated on “Delegate Of Doom” (informal term) which restricted patterns or techniques that provide minimal dependency and contract (standardization) for communication between web server and application. The idea was to create a communication contract + communication pipeline.

They had decided to create a gate reference (entry point) which represents a helper library for those who want to start using OWIN standard. And the library is open source in Github.

On July 25, 2011, the OWIN project was publicly announced, marking the beginning of a collaborative effort to create the specification.

And, finally, in December 2012 the OWIN project had been released its first official version 1.0.

OWIN

In this section, we will cover the general idea. The specification details will not be considered, click if you are interested in more details.

The image shown above gives a bird’s eye view of OWIN. As I said before, OWIN just provides decoupling communication between the web server and the web application. But take into account that OWIN is not a framework, library, or implementation. If you look at the OWIN specification you will get details of rules or samples of code on how web servers and applications communicate with each other.

To get into the details, it is necessary to start with the actors, which helps to understand the idea of OWIN.

• Web Framework: A self-contained component on top of OWIN exposing its own object model or API that applications may use to facilitate request processing. Web Frameworks may require an adapter layer that converts from OWIN semantics.
• Web Application: A specific application, possibly built on top of a Web Framework, which is run using OWIN compatible Servers.
• Middleware: Pass-through components that form a pipeline between a server and application to inspect, route, or modify request and response messages for a specific purpose.
• Server: The HTTP server that directly communicates with the client and then uses OWIN semantics to process requests. Servers may require an adapter layer that converts to OWIN semantics.
• Host: The process an application and server execute inside of, primarily responsible for application startup. Some Servers are also Hosts.

Mainly, the actors must-have for any web applications. So, OWIN dictate to all of them to achieve goals.

Note that for understandable explanation I will describe all processes with runtime things. Some parts of the explanation may be outside the scope of OWIN.

The communication between a web server and a web application (top of the web framework). For that reason, these actors also have a huge computational logic. The idea brought the pipeline for handling web requests and responses lifecycle. This also relies on Pipeline architecture which provides to achieve cross-cutting concerns between web servers and web applications.

Everything starts with a host which creates the needed environment and configuration things. In runtime, it should consist of a built-in web server and application which is top of a framework. So, basically web server listens to HTTP requests populates things and some data structures, and sends them to the communication pipeline.

The idea of building a pipeline starts with middleware, which is a chain or filter for all its parts. The middleware provides some cross-cutting concerns and helps to handle requests and responses lifecycle. When requests are coming from the server send them to the first chain/filter (middleware) and then requests will continue one by one with each other. And end of the pipeline requests are handled with the application and generate the response, the same things happen with response in a back way.

So far we have explained the general idea, you can look at the specification for more details.

The solution of OWIN starts with.

using Environment = IDictionary<string, object>
using AppFunc = Func<Environment, Task>

Hmm, it’s a little easier than you think!

• Environment is the key-value pair that contains all needed data including request and response objects. So, it makes sense when the server and application communicate with each other!
• AppFunc is the delegate that handles requests.

Basically, how AppFunc handle requests on an Application side? The code is shown below.

using System.IO;
using System.Text;
using Headers = IDictionary<string, string[]>;
var app = AppFunc(env =>
{
    var bytes = Encoding.UTF8.GetBytes("Hello, OWIN!");
    var length = bytes.Length.ToString();
    var headers = env["owin.ResponseHeaders"];
    headers.Add("Content-Type", new[] { "text/plain" });
    headers.Add("Content-Length", new[] { length });
    var stream = (Stream)env["owin.ResponseBody"];
    return stream.WriteAsync(bytes, 0, bytes.Length);
});

For building the pipeline we need to create the idea of Middlewares. It can be achieved with the Chain Of Responsibility pattern.

The code above AppFunc is middleware and it can encapsulate the next element of the chain (which is middleware). And it calls the next one, repeating in the same way as the others, like a nested chain.

So, it can be implemented as a Class and Function. But I will just show the Class sample.

public class LoggingMiddleware
{
    private AppFunc _next;
    public LoggingMiddleware(AppFunc next)
    {
        this._next = next; 
    }
    public Task LogBefore(Environment env)
    {
        // Implementation
    }
    public Task LogAfter(Environment env)
    {
        // Implementation
    }
    public async Task Invoke(Environment env)
    {
        LogBefore(env);
        await _next(env);
        LogAfter(env);
    }
}

That was the middleware side.

Also has an IAppBuilder interface for the pipeline side. Its main purpose is to provide the contract for configuring the middleware pipeline that handles HTTP requests and responses.

• Originally intended to provide the delegate signatures
• IAppBuilder was later added and left as the only interface

public interface IAppBuilder
{
    IDictionary<string, object> Properties { get; }
    IAppBuilder Use(object middleware, params object[] args);
    object Build(Type returnType);
    IAppBuilder New();
}

As you can see, the OWIN solution has minimal dependency by simply relying on the FCL. These basic things help OWIN to achieve its goal.

P.S. Microsoft implemented the OWIN idea, it's Katana, but this is another topic.

Conclusion

OWIN is a specification that provides the rules for decoupling between web servers and web applications. Also, it helps to achieve modular architecture between web servers and applications. The idea behind it is used in many other web technology environments. OWIN is a powerful idea that helped to .NET community by providing an alternative to traditional IIS and ASP.NET (old) hosting models, addressing their limitations.

Stay tuned!