Microsoft’s ASP.NET stack has always been a powerful application framework, but it long suffered from a dependency on IIS to operate. Which was always a shame, because having an HTTP listener within a stateful application can be a very handy interface for configuration or control. For a long time, the only way you could make that happen would be to implement your own/use a 3rd party stack, or even worse, make use of the background worker that is available in ASP.NET applications. Enter the Open Web Interface for .NET (OWIN). The purpose of the OWIN project was, borrowing a page from the Rack/Rails playbook, to abstract the entire ASP.NET stack away from the web server. By open-sourcing the ASP.NET stack, and providing a standard, open interface through OWIN, any web server could be made to host an application.
Complementing OWIN was the Katana project, whose aim was to allow any application to host an OWIN-based application. Which is really cool. I can have a ASP.NET Web API implementation in my application, giving me a quick, yet full-featured, communications stack using standard protocols.
Implementing a listener in your application could not be simpler.
- Install the Nuget package Microsoft ASP.NET Web API 2.2 OWIN Self Host in your project
- Create a class that has this method signature:
Configuration(Owin.IAppBuilder) - Implement your API code (controllers, models, extensions, handlers, etc.) in the same namespace as the aforementioned class.
Starting your Web Application
As described in item #2, you will need an implementation to configure your web application. There are several examples online, and they all have a Configuration method similar to this:
public void Configuration(IAppBuilder builder)
{
var config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
builder.UseWebApi(config);
}
You can use the HttpConfiguration as you would in any ASP.NET application. I happen to prefer attribute-based routing in my MVC projects, but you could certainly go with the standard convention-based scheme of attribute routing. And you can also use the configuration to bind formatters, handlers, etc., to your listener. For the purposes of my application, a security layer is not necessary, but you can fairly easily implement any authorization and authentication providers that are available.
The listener is started via the Microsoft.Owin.Hosting.WebApp class. For example:
IDisposable reference = Microsoft.Owin.Hosting.WebApp.Start<TConfigType>(string uri);
TConfigType represents the type in which your configuration method is specified. It will use that to configure and start your listener. The value for uri is the address and port that should route to your listener (example: http://localhost:80).
Controlling Your Listener
You could very well make the HTTP listener you have implemented the only piece of your application, but the purpose of this article is to show the use of the API as an endpoint in a stateful application. Purposes range from providing a control mechanism for a Windows service, to providing information on an application’s operational status. The specific use case for the application I’m building is a worker that gathers data and transforms it, with an API interface to retrieve the transformations and spawn new gathering processes (yeah, a bit generic of a description, I know). By self-hosting an OWIN application, I could run stateful operations and share data in the same context as the API. Needless to say, I could not, then simply start the application and synchronously wait for a stop signal. Plus, I wanted to be able to drive the host control via configuration, and potentially implement multiple listeners in the same application.
I solved this in a very simple manner. I created an interface called IHostApp, with the following implementation contract:
string Url { get; }
void Start();
void Stop();
My concrete implementation also has a generic parameter, where its value would be the type containing your Configuration method. Keep an instance of this in memory, and the server will continue to run. Execute WebApp.Start<T>(url) in your Start method, storing the IDisposable you get back as a member, and dispose of that member in your Stop method. I typically use Microsoft Unity to resolve these IHostApp instances, using one for every address I wish to listen on.
Things to Consider
- You should probably think twice about exposing a self-hosted OWIN application on a public address. Security exploits are found all the time in mature web servers, and they have teams of people dedicated full-time to hardening their software against malicious attacks. So it would be naive to think you or I could do better on a part-time basis.
- You will need proper URL ACLs set to listen on any address other than localhost.
- This should generally be used for simple cases, like providing lightweight interfaces into an application. Remember, OWIN Self-Hosted is a relatively fledgling project, so there could be a lot of unknown gating factors to good performance.
Other Reading
Here are some other resources on the topic, all of them more well-written than mine. Really, these are where I learned how to run the self-hosting code. My meager addition was to make it a little more stateful and a little more DRY:
