Recently I’ve been thinking about options for exposing an application automation API for inter process integration scenarios. For example, a desktop application that exposes the ability for other applications to programmatically query information from it and/or invoke commands. I also had a few requirements. Whatever I choose should:

• Let me inject core application services (or higher level aggregated services, or ANYTHING I WANT) by pulling them out of my IoC container
• Not require the service to run in a new AppDomain
• Be easy to use, configure, and integrate into my application
• Be testable

I’m going down the path of exposing a Web API (I would call it a RESTful service, but really it’s not). Of course my first stop was to investigate hosting ASP.NET MVC in a desktop application (which really just means hosing ASP.NET). There are a few articles out there about how to do this, and for the “intended” scenario, it’s pretty easy.

Unfortunately the “intended” scenario is web hosting, which loads everything into a new AppDomain. And aside from some of the outer classes and factories, everything is marked private or internal so I can’t get at it without doing a bunch of reflection. Bah.

I’ve ended up taking a long look at OpenRasta. OpenRasta was written with DI/IoC in mind, and it actually uses an internal IoC container for configuring the framework. More on that in a future post. It also has it’s own hosting support and API that have out-of-the-box implementations for ASP.NET, HttpListener, and “In Memory”. But you could always implement your own hosting code and integrate it.

The key word in that entire paragraph was “HttpListener”. That’s built-in .NET support for for web request processing that is baked into Windows via the kernel-mode http.sys driver. It’s relatively easy to use, and it’s wonderful. OpenRasta integrates with my existing application infrastructure, and marries it up with support for a REST-style web API, enabling me to very quickly expose a web API that allows third parties to integrate with my application. This is going to be more and more important as things like Windows Gadgets are implemented which are restricted in terms of the kinds of ways they can communicate (web requests) and with whom they can communicate (localhost, etc.)

Unfortunately OpenRasta doesn’t support Ninject, which I use, so I’m implementing the support for it and will submit the patch soon.

So far I’m extremely happy with the solution as I think developer productivity will be through the roof (compared to other more invasive solutions like WCF) and client-side integrations won’t be that difficult (POX). For my scenario, it’s all right up my alley. The internetz work for ME now!