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

Navigation
13

In recent times I've been trying to better understand OWIN in aspects of why use it, how it works, and how to use it. As for why I use it I've already asked here and I've already convinced myself that the biggest motivation is to get the more modular and independent components of ASP.NET (MVC, WebAPI, etc.) from the System.Web.dll assembly to increase performance.

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

Hence I have heard that this decouples the server application and allows the construction of complex execution pipelines. I really did not understand how this works.

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

I know it allows you to integrate WebAPI, Identity, etc. But I still can not understand how this works and how to use it.

    
asked by anonymous 16.05.2014 / 22:40

2 answers

10
The main goal of OWIN is to be able to develop applications and components that are easier to write and consume than traditional ASP.NET way, besides eliminating the dependency of the use of IIS, allowing the developer to use a host alternative developed freely by the community.

For this, OWIN makes extensive use of dynamic structures, more present in modern languages and Frameworks, such as Ruby on Rails along with Rack, and maximum simplification of the environment and execution of tasks.

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 is tremendously bureaucratic when it needs to support a new request topology, such as Web API 2 (Microsoft's version of the REST API) . That is, the application can have several environment dictionaries, each one being for one need (one for setting return on Razor, another for JSON, and so on).

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

The Katana is one of the implementation proposals for the OWIN model, and possibly the poorest of examples (most of them return only text/plain , but there are some attempts to integrate the Katana with Razor ).

Please note that until this response has been posted, handler of Razor has not been implemented exactly by the official team. This answers the part of your question about the Startup class: it initializes handlers only, and it's the handlers that makes it possible to use mechanisms we know, such as Razor. It would be a kind of "interface organizer": it records what technologies will be used to process requests.

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

In the course of the days I will improve this answer with examples and I should put a project in GitHub with a functional implementation of what would be an MVC application with Razor over OWIN, using Katana.

    
20.05.2014 / 07:14
8

In this post by Eduardo Pires in The Future of ASP .NET vNext - MVC 6 he explains very simply. In summary in his words you can understand this way:

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

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 agnostic, that is, that 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" specification.
    •   
  • Does not exist exactly as code or component.
    •   
  • Is the description of how ideally the behavior of its implementation   should work.
    •   

And the katana:

  

Katana

     

This 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 called the Katana Project. Later ASP.NET Identity came up with implementation of Katana Project libraries as well.   In addition to Microsoft, other projects implement OWIN such as NancyFx, FubuMVC, NOWIN etc.

And as a complement you will still have the Helios

  

Helios

     

The implementation of OWIN through the Katana Project has provided the creation of much lighter ASP, ASP.NET components, platform independent and SelfHost, but if you need some features that Classic ASP.NET Host (IIS) provides , all of this is left to the application developer.

     

IIS, despite working only in the classic ASP.NET (System.Web) pipeline, has a number of benefits that can not always be overlooked:

     

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

     

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 on Project Helios only that will only run in the IIS standard and will not have SelfHost and multiplatform options , in 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 enjoy the news.

    
20.05.2014 / 14:31
Java and Offline Databases Java / Android: How to display in StackTrace Log