I originally thought about writing this as a blog post but it's more of a discussion point than anything else - plus Pete Smith (Roysvork) blogged about it yesterday - http://roysvork.wordpress.com/2014/02/18/are-we-gowing-in-the-right-direction/.
I arrived pretty late to the OWIN party and I'll admit I didn't see the benefit at first. OWIN states its goal as decoupling server and application. So now I can host a website in a windows service - that's pretty cool, although in reality it's unlikely I'll ever need to do this.
However, as I started to learn more about OWIN and see what Microsoft were doing (pushing more of their libraries up to the OWIN level) I could see the opportunities that OWIN opened up. If I write a library that does something in the request pipeline, I could write this as an OWIN Middleware Component (OMC) and now it would work regardless of the web framework you were using (providing it was OWIN compatible) - Web API, Nancy, Simple.Web etc.
A few weeks ago I blogged about a project I'm working on called SaasKit (http://ben.onfabrik.com/posts/saaskit-multi-tenancy-made-easy) - a toolkit to help build SAAS products and help with things like Multi-tenancy. It's something I've wanted to do for a while but it was hard to create a solution that worked for all web frameworks. Having written multi-tenant apps on various platforms I'd previously had to resort to using Http modules for ASP.NET MVC, Message Handlers in Web API and Pipeline hooks in Nancy. OWIN, it seemed, offered a "solution-for-all". So I wrote an OMC that handled tenant identification and resolution - happy days! (https://github.com/saaskit/saaskit)
The next part of multi-tenancy I wanted to tackle was tenant scoped dependencies. This meant I needed a way of creating some sort of IoC container for each tenant and make sure that web framework X used it when resolving dependencies.
Then I saw Tugberks post on this group about unified DI support for OWIN. It seemed the main issue people have is the sharing of state between OMC components/frameworks. This started a bit of Twitter flame with a few people saying this was an abuse of OWIN and not what it was intended for.
It's made me think seriously about what I was planning for SaasKit. Clearly my understanding of OWIN is incorrect and more so, the direction in which Microsoft is pushing OWIN is also wrong?
For me, the decoupling of application (my stuff) from framework (web api, nancy, mvc etc.) is much more powerful than application from server. Assume I'm writing a simple Documentation website that reads markdown files from cloud storage and spits them out as HTML. I don't want to add framework X,Y,Z to do this - really all I need is a markdown converter, a file system implementation, a router and maybe an asset pipeline for doing some CSS. Oh and maybe I want to secure the site.
All of the above can be achieved by pulling in the appropriate OWIN middleware. I don't need to pull in a full featured framework like ASP.NET MVC, Nancy, Web API etc. etc.
I can do this now, and it works! Yet, it is not what OWIN was intended for?
So what is the solution here? Do we ignore this potential because it violates the original spec or should we start putting our heads together to work on a OWIN compatible middleware component that provides this sort of pluggable pipeline - something that allows us to pull in the pipeline handlers we need without having to choose a specific web framework. IMO this seems a bit of a waste after all the work that's gone into making most web frameworks OWIN compatible, we'd have to go through that process again.
I strongly believe this is the future of ASP.NET, I'm just not sure how we get there?
A lot of what you are talking about can be done using platform-agnostic HTTP proxies, and it's as if OWIN is being used in order to simplify writing and chaining and deploying said series of proxies, by combining them all into a single application. Don't know if that helps at all. Is there an OWIN-based reverse proxy implementation anywhere?