OWIN and Katana: First Look
Take a look at the current situation with the web technologies from Microsoft. Since 1998, ASP .Net is the main development tool. This is a classic: rich functionality, separation of logic from markup, .net, a new model for developing web applications. There are many pros and cons too: All logically heterogeneous components are closely related to one single System.Web assembly (HTTP core objects, webforms, etc.). To all this, ASP .net is included in the large NET Framework, which means the time between releases can be several years. And it does not allow ASP .NET to keep up with the times and keep up with web technologies. The monolithic architecture makes all this wealth sluggish and inert, and any changes affect many components.
Over time, the situation on the market is changing: ASP .NET gets the MVC framework and Ajax already in the form of separate modules that are not part of the main assembly, and this allows the developers of these components to speed up the release of new versions and respond to the situation in the web development sphere in a timely manner. ASP .NET becomes a family of connected components, rather than a single structure.
The MVC framework was created by Microsoft with an eye on Ruby on Rails. Logical and modern step. This product gave developers more control over markup, while maintaining its separation from the business of logic.
The next important step for Microsoft in web development was the release of WebApi, which has no dependency on System.Web. Applications increasingly began to use not dynamically generated server pages, but static ones using Ajax. New versions are delivered very quickly through the use of NuGet. The power and flexibility of the Web API, as well as the possibility of self-hosting turned out to be very attractive for web developers, so attractive that many other frameworks also became self-hosting. And here comes a new problem. The average modern web application can support: static web pages, dynamic page generation, Web Api, real-time / push notifications. To expect that each of these services should be launched, and managed separately is simply unrealistic. There is a need for a new level of abstraction between hosting and applications, in order to connect all the modules and at the same time does not care about the details of hosting implementation, the so-called middleware. And RoR already had a similar abstraction - Rack.
')
Inspired by Rack , several .NET developers decided to create their own abstraction between the web server and the infrastructure components. The developers pursued two goals:
And that's what happened.
OWIN (The Open Web Interface for .NET) is a specification that defines an interface and describes the interaction between all components.
The basis of the work of OWIN is the IDictionary <string, object>, which is used to gain access to HTTP requests, request header and host environment. All keys are described in the OWIN specification.
Owin-compatible server is responsible for filling this dictionary data.
The following element is the owin This is the delegate:
It accepts the above-described dictionary as input, and returns a Task object upon completion of the process.
The Owin.dll library (available in NuGet) contains only one IAppBuilder interface:
This interface connects all modules developed according to the OWIN specification. Each individual module has no external dependency, one of such components are SignalR, and WebAPI which are fully OWIN-compatible.
Using OWIN, we are free to connect only those components that we need right here and now, whether it is an authorization module, the same SignalR, static pages, etc. And unlike IIS, for example, our server will not be overloaded with unnecessary functionality, which means it will be more productive.
Katana is an OWIN-compatible host written by Microsoft. In addition to implementing the OWIN specification, Katana contains various helper classes and wrappers to simplify development, contained in the Owin.Types library. For example, two adapter classes that simplify work with the dictionary: OwinRequest and OwinResponse, the WebSocket implementation for Owin is OwinWebSocket, the auxiliary class for working with headers and other query parameters is OwinHelpers.
Important point: Katana is not tied to the use of any interfaces or basic types; instead, agreements are defined that developers must follow.
As a task for practice, we implement WebApi based on OWIN. First we need to decide on how to start Katana. Let's try to do this self-host. Let's create a simple console project WebApiOwinSelfHostDemo We need the appropriate implementation of WebApi. We put through NuGet.
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost -Pre
This command will install all the required OWIN libraries.
Next, add a new Startup class to our project. And write the following code:
Creating this class, we follow one of the Katana conventions: when launching the Katana web application, it looks for the Startup class and calls its Configuration () method to create and configure the message processing pipeline.
Next, add a simple WebApi controller:
Our application is ready, now you need to start the OWIN host and send a request using the HttpClient:
After starting the application we get the following output.
All perfectly!
All this is nice, but it would be nice to run all this on a real server, and not just in a console application.
The Microsoft.Owin.Host.SystemWeb library implements Owin for IIS, this is what we need.
Create an empty ASP .NET project. Why ASP .net? This will give us the project already configured to run in IIS express.
Add WebAPI:
Add the OWIN implementation for IIS:
You can also use Katana Tooling . This is a template containing all the necessary libraries. And by default, in this template, the project is launched under IIS, but the bundle includes a script to customize the launch on the Owin host OwinHost.exe. But it does not matter.
The rest is absolutely the same. The Startup class and the controller class from the self-host project.
Remark: on the latest version of Katana Tooling Web Api it was not possible to start normally, it crashes into an error, I haven’t found out the reason yet. Maybe I just have crooked hands.
I described only the basic things to get acquainted with the new OpenSource technology from Microsoft. Below are links to materials used in the article as well as more detailed examples for those interested.
http://owin.org/ - actually OWIN.
An Overview of Project Katana - an article about Katana from one of the developers. Everything is very cool and understandable, I freely translated most of the moments from this article here.
Hosting nancy with Owin
Katana Project
OWIN and Katana - this blog describes in detail how to work with Katana and how to launch it, and how to create your own OWIN modules in details. In general, I strongly recommend this blog, a lot of useful, constantly read.
Over time, the situation on the market is changing: ASP .NET gets the MVC framework and Ajax already in the form of separate modules that are not part of the main assembly, and this allows the developers of these components to speed up the release of new versions and respond to the situation in the web development sphere in a timely manner. ASP .NET becomes a family of connected components, rather than a single structure.
The MVC framework was created by Microsoft with an eye on Ruby on Rails. Logical and modern step. This product gave developers more control over markup, while maintaining its separation from the business of logic.
The next important step for Microsoft in web development was the release of WebApi, which has no dependency on System.Web. Applications increasingly began to use not dynamically generated server pages, but static ones using Ajax. New versions are delivered very quickly through the use of NuGet. The power and flexibility of the Web API, as well as the possibility of self-hosting turned out to be very attractive for web developers, so attractive that many other frameworks also became self-hosting. And here comes a new problem. The average modern web application can support: static web pages, dynamic page generation, Web Api, real-time / push notifications. To expect that each of these services should be launched, and managed separately is simply unrealistic. There is a need for a new level of abstraction between hosting and applications, in order to connect all the modules and at the same time does not care about the details of hosting implementation, the so-called middleware. And RoR already had a similar abstraction - Rack.
')
Owin
Inspired by Rack , several .NET developers decided to create their own abstraction between the web server and the infrastructure components. The developers pursued two goals:
- New components will be easy to design and use.
- Applications can be easily transferred from host to host, perhaps even across platforms.
And that's what happened.
OWIN (The Open Web Interface for .NET) is a specification that defines an interface and describes the interaction between all components.
The basis of the work of OWIN is the IDictionary <string, object>, which is used to gain access to HTTP requests, request header and host environment. All keys are described in the OWIN specification.
Owin-compatible server is responsible for filling this dictionary data.
The following element is the owin This is the delegate:
Func<IDictionary<string, object>, Task>; It accepts the above-described dictionary as input, and returns a Task object upon completion of the process.
The Owin.dll library (available in NuGet) contains only one IAppBuilder interface:
public interface IAppBuilder { IDictionary<string, object> Properties { get; } IAppBuilder Use(object middleware, params object[] args); [SuppressMessage("Microsoft.Naming", "CA1716:IdentifiersShouldNotMatchKeywords", MessageId = "New", Justification = "By design")] IAppBuilder New(); } This interface connects all modules developed according to the OWIN specification. Each individual module has no external dependency, one of such components are SignalR, and WebAPI which are fully OWIN-compatible.
Owin hosting
Using OWIN, we are free to connect only those components that we need right here and now, whether it is an authorization module, the same SignalR, static pages, etc. And unlike IIS, for example, our server will not be overloaded with unnecessary functionality, which means it will be more productive.
Katana is an OWIN-compatible host written by Microsoft. In addition to implementing the OWIN specification, Katana contains various helper classes and wrappers to simplify development, contained in the Owin.Types library. For example, two adapter classes that simplify work with the dictionary: OwinRequest and OwinResponse, the WebSocket implementation for Owin is OwinWebSocket, the auxiliary class for working with headers and other query parameters is OwinHelpers.
Important point: Katana is not tied to the use of any interfaces or basic types; instead, agreements are defined that developers must follow.
Practice
As a task for practice, we implement WebApi based on OWIN. First we need to decide on how to start Katana. Let's try to do this self-host. Let's create a simple console project WebApiOwinSelfHostDemo We need the appropriate implementation of WebApi. We put through NuGet.
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost -Pre
This command will install all the required OWIN libraries.
Next, add a new Startup class to our project. And write the following code:
Creating this class, we follow one of the Katana conventions: when launching the Katana web application, it looks for the Startup class and calls its Configuration () method to create and configure the message processing pipeline.
Next, add a simple WebApi controller:
Our application is ready, now you need to start the OWIN host and send a request using the HttpClient:
After starting the application we get the following output.
All perfectly!
Startup option on IIS server
All this is nice, but it would be nice to run all this on a real server, and not just in a console application.
The Microsoft.Owin.Host.SystemWeb library implements Owin for IIS, this is what we need.
Create an empty ASP .NET project. Why ASP .net? This will give us the project already configured to run in IIS express.
Add WebAPI:
Install-Package Microsoft.AspNet.WebApi.Owin -Pre Add the OWIN implementation for IIS:
Install-Package Microsoft.Owin.Host.SystemWeb You can also use Katana Tooling . This is a template containing all the necessary libraries. And by default, in this template, the project is launched under IIS, but the bundle includes a script to customize the launch on the Owin host OwinHost.exe. But it does not matter.
The rest is absolutely the same. The Startup class and the controller class from the self-host project.
Remark: on the latest version of Katana Tooling Web Api it was not possible to start normally, it crashes into an error, I haven’t found out the reason yet. Maybe I just have crooked hands.
I described only the basic things to get acquainted with the new OpenSource technology from Microsoft. Below are links to materials used in the article as well as more detailed examples for those interested.
http://owin.org/ - actually OWIN.
An Overview of Project Katana - an article about Katana from one of the developers. Everything is very cool and understandable, I freely translated most of the moments from this article here.
Hosting nancy with Owin
Katana Project
OWIN and Katana - this blog describes in detail how to work with Katana and how to launch it, and how to create your own OWIN modules in details. In general, I strongly recommend this blog, a lot of useful, constantly read.
Source: https://habr.com/ru/post/202018/
All Articles