OWIN and Katana: First Look
Take a look at the current situation with web technologies from Microsoft. Since 98, the main development tool is of course ASP .Net. This is a classic: rich functionality, separation of logic from markup, .net, a new model for developing web applications. There are many pluses and minuses, too: All logically heterogeneous components are closely connected into one single System.Web assembly (HTTP kernel objects, webforms, etc.). To all this, ASP .net is included in the large NET Framework, which means that the time between individual releases can be several years. And this does not allow ASP .NET to keep up with the times and keep up with web technologies. Monolithic architecture makes all this wealth slow and inert, and any changes affect many components.
Over time, the market situation changes: ASP .NET receives the MVC framework and Ajax already in the form of separate modules that are not included in the main assembly, and this allows developers of these components to accelerate the release of new versions and respond to the situation in the field of web development in a timely manner. ASP .NET is becoming a family of plug-in components, not a single structure.
The MVC framework was created by Microsoft with an eye on Ruby on Rails. A logical and modern step. This product gave developers more control over the markup, while keeping it separate from business logic.
Microsoft’s next major step towards web development was the release of WebApi, which is not dependent on System.Web. Applications increasingly began to use not dynamically generated server pages, but static ones using Ajax. New versions are delivered very quickly thanks to 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 a new problem pops up. The average modern web application can support: static web pages, dynamic page generation, Web Api, real-time / push notifications. It is simply unrealistic to expect that each of these services should be running, and managed separately. There is a need for a new level of abstraction between hosting and applications in order to bind all the modules and at the same time does not care about the details of the 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 infrastructure components. The developers had two goals:
And that’s what happened.
OWIN (The Open Web Interface for .NET) is a specification defining an interface and describing the interaction between all components.
The basis of OWIN is the IDictionary, which is used to access HTTP requests, the request header, and the host environment. All keys are described in the OWIN specification .
An Owin-compliant server is responsible for populating this dictionary with data.
The following OWIN element. This is the delegate:
As input, it takes the dictionary described above, and returns a Task object at the end of the process.
The Owin.dll library (available on NuGet) contains just one IAppBuilder interface :
This interface connects all modules developed according to the OWIN specification. Each individual module has no external dependency, one of these components is 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 working with the dictionary: OwinRequest and OwinResponse, the WebSocket implementation for Owin is OwinWebSocket, and the auxiliary class for working with headers and other request parameters is OwinHelpers.
An 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. To begin with, we need to decide on how to launch Katana. Let's try to do this self-host. Let's create a simple console project WebApiOwinSelfHostDemo We need an appropriate implementation of WebApi. We put it through NuGet.
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost -Pre
This command installs all the necessary OWIN libraries.
Next, we add a new Startup class to our project. And we write the following code:
When creating this class, we follow one of the Katana conventions: when starting a web application, Katana looks for the Startup class and calls its Configuration () method to create and configure a message processing pipeline.
Next, add a simple WebApi controller:
Our application is ready, now we need to start the OWIN host and send a request using HttpClient:
After starting the application, we get the following output.
Everything is fine!
All this is certainly good, 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 an already configured project to run in IIS express.
Add WebAPI:
Add 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 script for setting up the launch on the Owin host OwinHost.exe is included. But this is not important.
The rest is absolutely the same. Startup class and controller class from self-host project.
Remark: on the latest version of Katana Tooling Web Api it was not possible to start normally, it falls out in an error, the reason has not yet been determined. Maybe I just have crooked hands.
I described only the basic things to familiarize myself with Microsoft's new OpenSource technology. 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 clear, most of the points from this article I freely translated here.
Hosting nancy with OWIN
Katana Project
OWIN and Katana - this blog describes in detail how to work with Katana and how to start it, as well as how to create your own OWIN modules in detail. In general, I strongly recommend this blog, a lot of useful things, I constantly read.
Over time, the market situation changes: ASP .NET receives the MVC framework and Ajax already in the form of separate modules that are not included in the main assembly, and this allows developers of these components to accelerate the release of new versions and respond to the situation in the field of web development in a timely manner. ASP .NET is becoming a family of plug-in components, not a single structure.
The MVC framework was created by Microsoft with an eye on Ruby on Rails. A logical and modern step. This product gave developers more control over the markup, while keeping it separate from business logic.
Microsoft’s next major step towards web development was the release of WebApi, which is not dependent on System.Web. Applications increasingly began to use not dynamically generated server pages, but static ones using Ajax. New versions are delivered very quickly thanks to 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 a new problem pops up. The average modern web application can support: static web pages, dynamic page generation, Web Api, real-time / push notifications. It is simply unrealistic to expect that each of these services should be running, and managed separately. There is a need for a new level of abstraction between hosting and applications in order to bind all the modules and at the same time does not care about the details of the 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 infrastructure components. The developers had two goals:
- New components will be easy to develop and use.
- Applications can be easily ported from host to host, possibly even across platforms
And that’s what happened.
OWIN (The Open Web Interface for .NET) is a specification defining an interface and describing the interaction between all components.
The basis of OWIN is the IDictionary
An Owin-compliant server is responsible for populating this dictionary with data.
The following OWIN element. This is the delegate:
Func, Task>; As input, it takes the dictionary described above, and returns a Task object at the end of the process.
The Owin.dll library (available on NuGet) contains just one IAppBuilder interface :
public interface IAppBuilder
{
IDictionary 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 these components is 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 working with the dictionary: OwinRequest and OwinResponse, the WebSocket implementation for Owin is OwinWebSocket, and the auxiliary class for working with headers and other request parameters is OwinHelpers.
An 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. To begin with, we need to decide on how to launch Katana. Let's try to do this self-host. Let's create a simple console project WebApiOwinSelfHostDemo We need an appropriate implementation of WebApi. We put it through NuGet.
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost -Pre
This command installs all the necessary OWIN libraries.
Next, we add a new Startup class to our project. And we write the following code:
When creating this class, we follow one of the Katana conventions: when starting a web application, Katana looks for the Startup class and calls its Configuration () method to create and configure a message processing pipeline.
Next, add a simple WebApi controller:
Our application is ready, now we need to start the OWIN host and send a request using HttpClient:
After starting the application, we get the following output.
Everything is fine!
Option to run on the IIS server
All this is certainly good, 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 an already configured project to run in IIS express.
Add WebAPI:
Install-Package Microsoft.AspNet.WebApi.Owin -PreAdd OWIN implementation for IIS:
Install-Package Microsoft.Owin.Host.SystemWebYou 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 script for setting up the launch on the Owin host OwinHost.exe is included. But this is not important.
The rest is absolutely the same. Startup class and controller class from self-host project.
Remark: on the latest version of Katana Tooling Web Api it was not possible to start normally, it falls out in an error, the reason has not yet been determined. Maybe I just have crooked hands.
I described only the basic things to familiarize myself with Microsoft's new OpenSource technology. 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 clear, most of the points from this article I freely translated here.
Hosting nancy with OWIN
Katana Project
OWIN and Katana - this blog describes in detail how to work with Katana and how to start it, as well as how to create your own OWIN modules in detail. In general, I strongly recommend this blog, a lot of useful things, I constantly read.