Ok, so straying a bit away from the AngularJS posts I have been doing lately, I want to talk a bit about OWIN. Why? Well, I recently took a look at it, after putting it off WAY too long, and found it to be awesome! And the goal with this post is to explain what it is, why it is cool, and why Microsoft is putting it into ASP.NET MVC projects by default…
But let’s start with “what is OWIN”… Well, OWIN stands for “Open Web Interface for .NET” and you can find more about OWIN as such at http://owin.org/. And now that you are back from that site, you are probably not a whole lot more in tune with what OWIN is, and the reason for that is probably that the site contains very little information. And it contains that little information because OWIN _is_ really that small. It is just a definition of an interface used to decouple the web applications we build, from the servers that are hosting it…
OWIN sees web applications as 4 parts, the host, the server, middleware and the actual application. When running ASP.NET MVC in IIS, IIS would be the 2 first parts, the host and the server, the middleware would be our IHttpModules, and the application would be our MVC application.
In the world of OWIN, the host and the server are separate things. The host is just some form of process running on the computer. It in turn hosts a server. The host can be any .NET application you want. And the server can be any server that supports OWIN.
You as a middleware or application developer shouldn’t have to care about this…as long as the server adheres to the OWIN definition, you should be fine.
But before we start looking at some code, I just want to explain a little bit about what the server does when using OWIN, because it is a little different than you might be used to…
The server opens a port and starts listening for requests. As a request comes in, it breaks it down into pieces, and adds those pieces to an IDictionary<string,object>. The pieces are things like the scheme, path, querystring etc. However, it also puts other things into that dictionary. Things like what features the server supports, versions etc. This dictionary is then sent into the request pipeline, which handles the request and does whatever is needed.
The cool thing with this ridiculously simple dictionary solution is that it can be extended with whatever pieces of information you could ever need. And parts in the pipeline can use that information, as well as add other information to be used further down the pipeline. And since it is IDictionary<string,object>, it can even contain Action<> and Func<> and so on, making it possible to add more functionality.
OWIN has already specified a few extensions, which are implemented by adding data to the dictionary. For example a server can support sending files using the SendFile extension, or handle WebSocket connections using the WebSocket extension. They are both implemented by the server, and exposed to the application and middleware by putting definitions of the support in the dictionary, as well as a Func<> that can be used to use the functionality…
It might seem simple, and it is, but using a dictionary to store data like that is pretty brilliant. It is extensible to the end of the world. And extending the pipeline won’t require any changes to the interface. All you need to do as a dev is to interrogate the dictionary to see if the functionality is available or not.
Let’s look at a little code example. Let’s look at hosting a simple application inside and OWIN server in a Console application. To do this, I start off by creating a new Console Application project in VS, and adding a NuGet package called Microsoft.Owin.SelfHost to it.
This NuGet package will give us everything we need to host an OWIN application in whatever application we want by using an OWIN-based server built on top of an HttpListener.
Next, I created a class called Startup. This is the entry point for my application. OWIN expects there to be a class called Startup, and will call its Configuration() method when the application starts up. This is where we start our application.
I use the passed in IAppBuilder instance to add the functionality I need. In this case, that means telling it to return “Hello World” on every single request to the server using a Func<> to define the functionality.
Once my Startup class is done, I use the static class WebApp to start the server in the Main method of my Console application. Like this:
class Program
{
static void Main(string[] args)
{
using (WebApp.Start<Startup>("http://localhost:12345"))
{
Console.ReadLine();
}
}
}
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.Use((ctx, next) => Task.Run(() =>
{
ctx.Response.Write("Hello World");
}));
}
}
As you can see, I got a VERY simple application up and running with just a few lines of code.
No, it isn’t complicated, and all it does is to return “Hello World” when I browse to it. But that’s the whole idea! Getting started should be simple! It should be as simple to create a server like this using .NET as it is doing it using node.js.
But the greatness of this application isn’t just due to how simple it was to build. It is due to the WAY I built it. By calling the IAppBuilder.Use() method, I table to define exactly what should happen when a request comes in. In this case, I just returned “Hello World”. However, as you might have noticed, besides the”ctx” parameter, which contains the current requests “context”, I got a second parameter passed in as well. This is a reference to the next piece of code in the pipeline. In this case, there is no other code, but if there was, I could just pass execution on to the next piece of code, and turn it into a proper request pipeline. And this is what is called “middleware”. Middleware is code that sits in the pipeline and does “its thing”.
Ok, but that isn’t something new! We have been able to do this for ages using IHttpModule and IHttpHandler… Yes we have! However that is IIS specific…
Ok, so this isn’t IIS specific, but why would this be such a cool thing? We don’t normally build loads of IHttpModules and IHttpHandlers in our projects… No, we don’t! However, other people do! A lot of the functionality we get in ASP.NET, such as the security stuff, is actually built using IHttpModules…
I am not saying that we should start building applications like I just did! Not at all! But having an open pipeline like this in our applications makes it VERY easy to plug-in other things into it. Making it possible to mix and match functionality as we see fit…
How about an example of using a middleware? Why not try and plug Nancy into my application?
I just add another NuGet package called Nancy.Owin. Add a Nancy module to my application. And call IAppBuilder.UseNancy(), which is an extension method that we get from Nancy. inside that extension method, Nancy has functionality to plug itself into the request pipeline and make itself useful…
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.UseNancy();
}
}
public class MyModule : NancyModule
{
public MyModule()
{
Get["/"] = _ => "Hello World from Nancy";
}
}
I left the Main method out of it, cause that is identical. Remember, the server is ignorant about what is happening. All it want is a Startup class, and it is happy…
And with more and more projects supporting OWIN, there are more and more middleware available for us on the web and on NuGet. Another example is ASP.NET WebAPI, which using OWIN can be hosted pretty much anywhere. And it is pretty much as simple to set up as Nancy is. And you must admit that it wasn’t too hard to set up.
Ok, so that is a very simple explanation of what OWIN is. But what is it doing in my new ASP.NET MVC project? Has ASP.NET all of the sudden become some middleware thing for OWIN?
Well, if you create a new project in ASP.NET MVC 5, it is very likely that you will run across a Startup.cs file in the root of the application. You will also notice a whole heap of OWIN-based stuff if you look at the NuGet packages included… So what is OWIN doing there?
Well, first of all, ASP.NET MVC is not an OWIN middleware. Your ASP.NET MVC application will keep working as usual. There is no change there…yet at least. However, the security parts have moved to be OWIN middleware. So instead of using IHttpModules and stuff like that, they are now plugging into the request pipeline using OWIN instead. That is actually all there is to OWIN being in your MVC project at the moment… However, nothing stops you from plugging into that same pipeline and wreak havoc…
This is just another example how having this open pipeline makes things easier… If you look at the security code in a new MVC project, you will see how simple it is to plug-in different security providers. You don’t have to do a lot of things. They are pre-built for you. All you have to do is to configure them, and plug them into the pipeline, and they have access to everything they need to do their thing.
And this brings me to the relationship between Microsoft and OWIN… OWIN is a completely separate from Microsoft. However, Microsoft has seen the benefits of the OWIN idea, and decided to support it through something called project Katana. Project Katana is Microsoft’s implementation of OWIN. It includes 3 hosts, IIS/ASP.NET, self-hosted and OwinHost.exe. The first 2 are pretty self explanatory, but the last one might not be. OwinHost.exe is a pre-built host that can be run from a console, and given an assembly containing a Startup class. it will then host your application using an HttpListener server by default, but this, and a lot of other features can be configured.
The next question when it comes to Microsoft and OWIN is probably “why?”… Well, using this abstraction, and building things as middleware, means that they can release things faster. It means that they don’t need to wait for the next release of .NET, or the next release of ASP.NET MVC to get some new stuff out. Instead, they can release features per middleware. It also means that they can break their somewhat large ASP.NET platform into smaller, more manageable pieces and deliver them independently. And that my friend, is great news! On top of that, it also opens up all of their stuff to be used together with 3rd party middleware. Giving us as developers the ability to mix and match Microsoft-, OSS- and 3rd part-middleware to get the best pipeline for our solution.
Ok, that was a very quick intro to OWIN! I am pretty sure I will be playing a LOT more with OWIN stuff in the future. Not only because I will probably have to when building ASP.NET applications, but because I like the simplicity and quick startup. And I am pretty sure there will be one or more blog posts about my findings as well…
Cheers!