• A reason for Owin existence is Microsoft's admitting1) 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.