Show pageOld revisionsBacklinksBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. # IT:AD:OWin # <callout type="Navigation" class="small"> * [[../|(UP)]] {{indexmenu>.#2|nsort tsort}} * See also: * [[IT/AD/ASP.NET/Identity/]] * [[IT/AD/Katana/]] * [[IT/AD/SignalR/]] </callout> <panel title="Summary"> Owin is a *Standard*, whereas [[IT/AD/Katana/|Katana]] -- and [[IT/AD/ASP.NET/Core/|ASP.NET Core]] are *implementations* of [[IT/AD/Owin/|Owin]]. Owin stands for *"Open Web INterface"*. </panel> ## Notes ## ### Why OWIN * A reason for Owin existence is Microsoft's admitting((http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana)) 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. ### Design 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. ## Resources ## * 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 /home/skysigal/public_html/data/pages/it/ad/owin/home.txt Last modified: 2023/11/04 03:28by 127.0.0.1