Thursday, January 16, 2014

Self Hosting ASP.Net Web Api Service with OWIN - Katana

In the previous post, we looked at hosting ASP.Net Web API application using Microsoft.Aspnet.WebApi.SelfHost package. With this post, we are going to start looking at how we can host the same service using Katana. It's an interesting name, isn't it? Already feeling like a Samurai :)

OWIN is a Microsoft's specification for web applications. Open Web Interface for .Net. OWIN specification provides layers of host, server, framework and your application. So the same host and server can be used to host a number of applications with different frameworks. They would be part of same pipeline. So we can also hookup infrastructure and security components on the front re-using them for all of these applications. Since this is a composable architecture, you are building the whole pipeline. This is unlike other hosting stories.

As stated by Microsoft, Katana is an OWIN implementation by Microsoft. It is an attempt to decouple web applications from servers. This should enable hosting of web applications including Web API, Signal R and front-end applications without requiring IIS. This should allow a combination of hosts and servers for hosting an application developed using a particular framework including ASP.Net Web API.

Let's create a console application for hosting InstituteService we have been continuously developing. We name the project as InstituteService.Host.Console.Owin. It's just a three steps process after this.

Step I: Let's first install the required Nuget package required for OWIN Self Hosting. Here we are installing Microsoft.AspNet.WebApi.OwinSelfHost package.

As is general with Nuget packages, it should install all the required Nuget packages for the package installation.

Although OWIN is specified as a specification, there is also Owin.dll. The assembly just contains IAppBuilder. In order to host it, we need to implement a type. Here we have a type named Startup. As a convention, the type needs to have a method Configuration with a single parameter of type IAppBuilder. This is Step II. Actually, you compose the whole application stack here. Here UseWebApi is an extension method defined for IAppBuilder. This is the whole idea, all application you want to host would involve a nuget package installation for the framework. The package would generally provide an extension method like we have UseWebApi here. The method is passed with an HttpConfiguration instance. We are configuring it for attribute routing.

For Step III, now we need to host the service. The package provides WebApp type. The type provides a generic method Start with a type parameter as the type declared above.

And that's it!!! Now we can run the application. It would host the service and wait for a key to be pressed, then it exits the application. It shows up as the following console screen:

Here we are accessing the service. Since we configured the application with Attribute Routing, it would determine the correct action based on controller's route prefixes. Since we have requested the response in text/json format, the content-negotiation with server with the server would result in the same format. Please remember that ASP.Net Web API JSON.Net for this purpose by default (if I remember it right).

Sunday, January 12, 2014

Self Hosting ASP.NET Web API Service

Windows Communication Foundation (WCF) services provide great flexibility of hosting. We have a number of options to host them. They are Managed Windows Service, Managed Application, Internet Information Services (IIS) and Windows Process Activation Service (WAS). Choosing WAS doesn't seem like an option as this is specially useful for non-HTTP based services, while ASP.NET Web API services are HTTP services.

I thought this would be a good idea to explore the number of different options to host ASP.NET Web API Service and when it would make more sense to choose one of them. In this post, we are going to look at Self Hosting of ASP.Net Web API service using Microsoft.Aspnet.WebApi.SelfHost nuget package. Please remember that this is not a recommended option (any more). For all new services, it is recommended to use Katana, which is an OWIN implementation.

Self Hosting is a generic term used to refer any application which provides its own code (non-declarative) for initializing the hosting environment and maintaining its lifetime[Bustamante, Michele Leroux - CODE Magazine - Jan / Feb 2007]. They can be either of Console, WPF or Windows Forms or a managed Windows Service.

In order to self host ASP.Net Web API Service, we need to install Microsoft.Aspnet.WebApi.SelfHost nuget package. This would install all the required assemblies needed to self host this type of services.

All the required nuget dependencies are also installed with this installation. We can have a look at the installed nuget packages using Package Visualizer. The tool draws a package dependencies graph for all projects in the solution.

Please note the weird dependency for Microsoft.AspNet.WebApi.Core 5.0.0 on Microsoft.AspNet.WebApi.Client 5.0.0. Mark Seemann has also tweeted about this recently. In case you are curious, D in SOLID is not Dependency Injection as I have found many to state that. This is Dependency Inversion Principle. has a wonderful explanation of the suite of principles for software design.

Now we just need to provide necessary configuration for hosting the service. Since we have already installed the nuget package, we have all the necessary types required for hosting the service. It also supports attribute routing for self hosting. Let's update the Main method in Program.cs as follows:

Now you might be wondering why in the world I have assigned the full name of InstituteController type to a local variable and haven't even used the variable. Actually I never intended to use the variable. We just need to load the assembly containing the controller type. If the assembly is not loaded, the controller type will not be loaded in the app domain resulting in the failure of resource request. You can find other solutions as well e.g. here someone has recommended a custom assembly resolver. Avoiding the load of assembly would result in a "Resource Not Found" response from the service.

You might have noticed HttpSelfHostConfiguration instead of HttpConfiguration to configure the service. Actually, the type inherits from that. The type is available in System.Web.Http.SelfHost namespace. The assembly is downloaded and referenced as part of the nuget package installation described above. HttpSelfHostServer is also available in the same namespace and assembly.

Now we just need to run and request a resource from a client. Let's run the console application. We can send a request using a browser. Here we are using one of the actions in InstituteController, which results in the following response: