IT:AD:OWin

• A reason for Owin existence is Microsoft's admitting¹⁾ that:

  • Web development is tied to System.Web, which has issues including:
    • only updated when a new Framework version is distributed (ie, years apart – which is too slow in order to keep up with web development)
    • System.Web has a strong dependency on IIS, hence not making inroads on other web servers, other Mono capable environments.

  * Making ASP.NET more nimble has been in the works for years:

  • It started with ASP.MVC being made out of band, then
  • moving to Nuget distribution for even faster updates.
  • MVC Controllers moving towards APIControllers (ie infrastructure to move away from Server side development)
    • Engineers took the opportunity to build it with no dependencies on System.Web.
    • WebAPI could then be Self-Hosted – even in a lightweight Console app.

It's that last part – the attractiveness of the ability to host services in a variety of different lightweight hosts – that surfaced another problem: lots of different hosts are more difficult to start/stop/manage idependently, than one general management system. Like IIS. Just wasn't a realistic roadmap.

What was needed was a single hosting abstraction that would enable a developer to compose an application from a variety of different components and frameworks, and then run that application on a supporting host. Whether IIS, or not.

Hence OWIN.

To be portable, the resulting abstraction is almost comically rudimentary. All it consists of of are two core elements: * An IDictionary<string,object> environment dictionary.

• An OWIN-compatible Web server is responsible for:
  • populating the environment dictionary with data such as the body streams and header collections for an HTTP request and response.
  • It is then the responsibility of the application or framework components to populate or update the dictionary with additional values and write to the response body stream (in the dictionary).

* Func<IDictionary<string, object>, Task>;, the application delegate.

• This is a function signature which serves as the primary interface between all components in an OWIN application.
• The application delegate is simply an implementation of the Func delegate type where the function accepts the environment dictionary as input and returns a Task.

This simplicity of the OWIN design has several implications for developers:

• There are a very small number of type dependencies required in order to write OWIN components.
• This greatly increases the accessibility of OWIN to developers.
• The asynchronous design enables the abstraction to be efficient with its handling of computing resources, particularly in more I/O intensive operations.
• Because the application delegate is an atomic unit of execution and because the environment dictionary is carried as a parameter on the delegate, OWIN components can be easily chained together to create complex HTTP processing pipelines.

* Good: http://coding.abel.nu/2014/05/whats-this-owin-stuff-about/ * http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana * http://www.asp.net/aspnet/overview/owin-and-katana/owin-startup-class-detection * http://owin.org/spec/spec/owin-1.0.0.html