OWIN and Katana - How does it really work and how to use it?

Question

In recent times I have tried to understand better about OWIN in the aspects of why to use it, how it works and how to use it. About why to use I have asked here and already convinced myself that the biggest motivation is to be able to leave the components of ASP.NET (MVC, Webapi, etc) more modular and independent of Assembly System.Web.dll to increase performance.

What I still don’t understand is how it works and how to use it. From what I understand it basically has a IDictionary<string, object> called the Environment Dictionary and a delegate Func<IDictionary<string, object>, Task> which basically points to a function that receives the Environment Dictionary and returns a Task.

Hence I heard that this decouples the server application and allows the construction of complex execution pipelines. I really don’t understand how this works.

Also, to really use the OWIN, I know you use a class Startup with a configuration function that receives an object that implements IAppBuilder. What would be the role of this interface in all this? Besides, it seems that everything is connected with the use of the function Use of that interface. Again, what this function actually does and how we actually use it?

I know it allows us to integrate Webapi, Identity, etc. But I still can’t understand how it all works and how to use it.

Answer 1

The main goal of OWIN is to be able to develop applications and components that are easier to write and consume than in the traditional ASP.NET way, in addition to eliminating the dependency on using IIS, enabling the developer to use an alternative host freely developed by the community.

For this, OWIN makes wide use of dynamic structures, most present in modern languages and frameworks, such as Ruby on Rails along with Rack, and maximum simplification of environment and task execution.

This Environment Dictionary is the dictionary that configures the environment. Although ASP.NET MVC5 is a very intuitive and easy to develop development framework, its configuration becomes tremendously bureaucratic when it needs to admit a new topology of requests, such as the Web API 2 (Microsoft version for the REST API standard). That is, the application can have multiple environment dictionaries, each one being for a need (one for setting return in Razor, one for JSON, and so on).

Already the Application Delegate is actually a function signature, used as an interface between the components of a OWIN application. Since every application uses the same interface, it does not matter if the application will return at the end of the request an HTML page, a JSON or an XML (or another format that may appear in the future): the interface for processing and return of the request is the same.

The Katana is one of the proposals to implement the OWIN model, and possibly the poorest of examples (most of them only return text/plain, but There have been some attempts to integrate Katana with Razor).

Note that, until the publication of this reply, the handler de Razor was not exactly implemented by the official team. This answers the part of your question about the class Startup: it initializes handlers only, and are the handlers that make possible the use of mechanisms we know, like Razor. It would be a kind of "interface organizer": it records which technologies will be used to process the requests.

There are other projects more mature than the Katana. They are:

• Signaler
• Fubumvc
• Nancyfx

Over the course of the days I will improve this response with examples and I should put a little project on Github with a functional implementation of what would be an MVC application with Razor on top of OWIN, using Katana.

Answer 2

In this post of Eduardo Pires in The Future of ASP.NET vNext - MVC 6 it explains in a very simple way. In short in his words you can understand in the following way:

OWIN defines a standard interface between web servers and .NET. The goal of the OWIN interface is to decouple the server and the application, encourage the creation of simple modules for ASP.NET development, and, as an open standard, stimulate the open source ecosystem of tools. NET Development Web.

Briefly OWIN is an abstraction layer between the server and the application.

OWIN

The goal of OWIN is that new components can be easily developed and > consumed, but in an agnostic way, that is, they can run on other platforms such as Unix (Mac/Linux) and can be ported from one platform to another without the need for recompilation.

• It is a "standart" a specification.
• Does not exist exactly as code or component.
• It is the description of how ideally the behavior of its implementation should work.

And the katana:

Katana

It is a Microsoft implementation of the OWIN specification in ASP.NET. Microsoft bet on the OWIN proposal and implemented it in the ASP.NET Signalr and ASP.NET Webapi projects, this implementation is named Katana Project. Later ASP.NET Identity emerged implementing Katana Project libraries as well. In addition to Microsoft, other projects implement OWIN such as Nancyfx, Fubumvc, NOWIN etc.

And as a complement, you’ll still have the Helios

Helios

The implementation of OWIN through the Katana Project provided the creation of much lighter, performance, platform-independent and Selfhost ASP.NET components, but in case it is necessary to rely on some features that the classic ASP.NET Host (IIS) all this is the responsibility of the developer of the application.

Although IIS only works on the classic ASP.NET (System.Web) pipeline, it has a number of benefits that may not always be overlooked:

IIS handles application life management. It can suspend (rather than terminate) processes that are idle to help balance available system resources. IIS offers a built-in user-mode cache and can automatically compress the contents of Sponses if applicable. IIS supports request filtering and Transient worker process Identities. More than 10 years of implementations and security improvements. In the Self Host scenario you are responsible for many of the responsibilities that IIS takes care of, in addition it already exists for that why not use it? These are the motivators of Project Helios, but due to the need for IIS to work on the System pipeline.Web performance would be lost, so Project Helios only works with the "Core" of IIS using it as a kind of API, the "Core" IIS is extremely fast and powerful, as it only provides its functionality without relying on the classic ASP.NET pipeline (System.Web).

Project Helios supports projects developed in Katana (OWIN), but is not dependent on it to be used, it is possible to develop an application based only on Project Helios that will run only on the IIS standard and will not have Selfhost and cross-platform options, on an application architecture for Windows can be very advantageous as it is at least 96% faster than classic ASP.NET.

Take a look at the link, I’m sure you’ll like the news.