OWIN and Katana Interfaces of ASP.Net

I have been trying to learn these concepts for a long time. I have read many good articles and their definitions but could not make much sense of them. Finally, I decided to write my understanding that I have got from these resources. So let's start with their basic definitions first.

What OWIN is

O.W.I.N. stands for Open Web Interface for .Net. Note that this is just a specification and not any technology or framework. It's official definition is quite simple and easy to understand. It says: OWIN defines a standard interface between .Net web servers and web applications. The goal of the OWIN interface is to decouple the server and applications, 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.

Let's try to understand what this definition is trying to convey here. Until now the developers have mainly focused on decoupled application code by creating multiple layers in the applications that interact with the use of interfaces, use design patterns, S.O.L.I.D. principles and so on. But O.W.I.N. is a step above the code decoupling. It is aimed at decoupling the application and the web-server, that hosts the application. Using such kinds of decoupled architecture allows:

1. Creating middleware components that can be replaced in or added into the application without affecting the other components in the application
2. Remove the dependency of the web server to host a component, by promoting the use of self-hosting

We will explain these points, later in the discussion.

What Katana is

The next the question is, what is Katana and how is it related to OWIN? The answer is that if OWIN is a specification (and not any technology or framework), than Katana is an open source project by Microsoft based on the OWIN. One such example is the ASP.Net Web API, based on the OWIN specifications, that supports the concept of self-hosting for hosting, by using the OWIN custom hosts (we will see the custom host concept in further discussion) and eliminating the dependency on IIS for hosting.

So to conclude this part of the discussion, OWIN is a specification and Katana is Microsoft's open source project that uses these specifications.

So moving on, let's discuss in detail about OWIN. But before that, a very important point to be mentioned is that we will make further understanding easier. For this, I would like to quote a very good explanation about what OWIN is, from the link here. It says: the OWIN introduction allowed any OWIN-compatible application to talk through OWIN to a web server that has an OWIN-compatible hosting layer. Microsoft wrote Katana as one OWIN implementation that could host ASP.NET Web API, ASP.NET SignalR and many third-party frameworks on top of several servers, including IIS (and IIS Express), Katana's self-host server and custom hosts (in other words run Katana's host in a custom app).

This means that Microsoft's Katana project allows the use of the OWIN specifications by providing not only new servers like Katana's self host server, custom host server (like any Windows service or console application) but also with existing web servers like IIS & IIS express.

In any normal ASP.Net application architecture, we have various layers categorized as host, server and the main application. In such a case, IIS acts as the server as well as the host. But in the case of an OWIN based structure, we can have 4 different layers. Three of these layers are web servers, OWIN compatible applications like SignalR and Web API and OWIN compatible hosting layer. The 4th one is our main application that could be any application based on web-forms or MVC framework. So the structure defined above is layered as:



Let's discuss these layers in detail now.

The Host layer: In any OWIN specifications based application, this layer can consist of either of the following 3 acting as the host:

• IIS: This includes the use of IIS as the host for any application. In such a case, Microsoft.Owin.Host.SystemWeb is to be used as the server. This will allow the addition of any OWIN compatible component or middleware to be easily added or remove from the pipeline.
  
  
• Custom Host: This involves creating a Windows service or a console application and using it to host your OWIN compatible applications like SignalR or Web API. An example is self-hosting the Web API in a Console or Windows application. See an example here.
  
  
• OwinHost.exe: This is an executable file named OWIN.exe. It can be directly run and used as a host for any application.

The Server Layer: Next we have the server layer that will listen to any incoming requests and manage the requests in the pipeline. This layer can be based on:

• Microsoft.Owin.Host.SystemWeb: System.Web is used when we are using IIS as the host. In that case, IIS also acts as the server. So in order to easily plug in the OWIN components in the pipeline, we can use this server layer. A definition from one of the reference links defines its role as the following.

The Katana SystemWeb host registers an ASP.NET HttpModule and HttpHandler to intercept requests as they flow through the HTTP pipeline and send them through the user-specified OWIN pipeline.

• Microsoft.Owin.Host.HttpListener: This involves the use of .Net Framework's HttpListener class to open a port and manage the request pipeline.

Using these two layers, suppose we add a new empty application project and try to create an application based on this structure. In this case we have the following two options:

• Using Microsoft.Owin.Host.SystemWeb as the server implementation, we make use of IIS as the host as well as the server.
• Using Microsoft.Owin.Host.HttpListener as the server implementation, we can use any custom host like a Windows or console application as the host or even the OWIN.exe executable as the host.

Middleware Components: These are the OWIN compatible components like SignalR and Web API and even static HTML pages. These are added to the system as plug and play components and can be easily added or removed without affecting the other modules. When the server receives a request from the client, it is passed through these components.

Applications: This could be any of your ASP.Net, MVC or any other applications.

Now let's try to create a sample using the preceding concepts. So we will use:

1. A custom host in the form of a Console application.
2. Microsoft.Owin.Host.HttpListener for the server implementation.
3. Web API and an HTML page as the middleware components in the system. An option could have been using any MVC or ASP.Net page as a separate application instead of the HTML page. Then it would have acted as the 4th layer of the system, in other words the Main Application. Another important point is, using any ASP.Net or MVC would not have been a good option since this would then not be hosted using a custom host or using the Microsoft.Owin.Host.HttpListener server implementation. This is the reason I have highlighted it to be used as a separate application.

Start by adding a new console application. This will be the first layer or the custom hosting the system, instead of IIS. Add the references to the Microsoft.Owin.Host.HttpListener using the Nuget Package Manager. This would then meet the requirements of a server implementation.



So we have the host and server in place. Next, we need to add the middleware component Web API. So we add a reference to the WebAPI 2.2 OWIN package, using the Nuget Package Manager and OWIN hosting libraries.

 

Next, we add another middleware component. This time, its libraries to add support for hosting HTML pages. Yes that's correct. We will host HTML pages in a console application. So let's see how to do this.

Now we have all the required references in the project and just need to configure the components to be used. Before that, we add a Web API controller and an HTML page into a folder named Pages. So our complete solution structure will like the following:



So now let's configure these components one by one. First, add a simple method in the Web API controller that returns the current date-time string. This will be called from the HTML that we added previously.



Next, we will register our middleware components, in other words Web API, and the HTML file in the WebAPIConfig.cs. This will make the hosting of the Web API and the HTML file possible. See the code below:



Next, let's start the server and host the application. For this, add the following code to the Main function in Program.cs:



The final step is to add some HTML to the HTML page and call the Web API method to get the date from the server.



All done. Now start the console application and you can then browse the HTML page on the same URL as that of the Web API. Click the button and your request will be sent to the Web API.



So now you can host the HTML page in the console application as well. Further if tomorrow you need to add the SignalR functionality, simply add the references and configure it in the WebAPIConfig.cs file like we did for the Web API and the static files.

Further, if we need to provide the Service API to any third-party then we simply host that in the console application or Windows service. No dependency on IIS.

The following are some of the reference links you may find useful:

• Basic concept of Host, servers and middleware
• Use IIS as host and SystemWeb as the server for OWIN implementation
• http://stackoverflow.com/questions/25431750/asp-net-vnext-is-host-agnostic-what-does-it-deeply-mean.

I hope you will find this article helpful and enjoyed reading it. This is a new concept to be learned. So I would love to hear about your feedback/additions to this concept. The source code for this article is also attached here. Happy coding!