With the release of VS2013, Microsoft has introduced many new features in ASP, such as using the new authentication module identity, using async to improve the throughput and efficiency of the Web server. One of them had to mention Owin and katana. Owin is the full name of open Web Interface for. NET, Owin is the. NET open source community's. NET Web development architecture for reference to Ruby, with a very simple specification definition while significantly reducing inter-module coupling. Owin is not a concrete implementation, but a specification that guides how to build a web ecosystem that conforms to OWIN standards. Microsoft introduced and promoted Owin, and implemented the Katana in accordance with the Owin specification.
So to speak, Owin will make ASP. NET glow in the second spring. Below, let us step by step near Owin and Katana, a glimpse of hosting.
One, review the development history of ASP.
Unknowingly, the ASP has been with us for more than 10 years, gradually into middle-aged. In the face of the ever-changing web development, ASP. NET has become somewhat inadequate. Why this happens, let's review the development History of ASP:
ASP phase
The web was originally developed using ASP, which is a scripting language embedded in the page. The advantage of ASP is simple, quick to get started, but with the development of the increasingly complex and web programs are constantly large, ASP this logic code and page HTML mixed in the development of the way has not been able to adapt.
ASP. NET Web form phase
Because of ASP's short board, upgrade ASP, build a new Web development platform is already the inevitable thing. Guess that Microsoft might want to make it easy for developers on WinForm to move to web development, creating a development process and WinForm and a similar development approach, which is ASP.
The ASP. NET Web form was undoubtedly advanced at the time, but over time, some of its problems were revealed:
Most of the core classes in ASP. System.Web.dll are included in the. NET Framework, and System.Web.dll is included in the, which means that if you want to publish a new version of ASP. NET must be accompanied by a new Framework, which results in a reduced frequency of ASP. In addition, System.Web.dll is coupled with IIS, which makes it impossible for the ASP to migrate to other servers.
A positive change
The new ASP. NET MVC has changed its past shortcomings, and it is published as a standalone. So the version change of MVC is not subject to the. Net Framework. The project team that develops MVC can quickly develop and release new versions of MVC autonomously.
Further, when developing and publishing the Web API, it doesn't even use any of the types contained in the System.Web.dll, which means:
- The Web API is completely non-externally dependent, and it is quickly released and updated through NuGet.
- Not dependent on System.Web.dll, which means that the Web API can run in other host processes, such as console programs, Windows Service, and so on, which is not dependent on IIS services.
The future: a more flexible framework
By deconstructing one of the framework components in ASP, Microsoft is able to iterate faster and release new versions through NuGet, adding new enhancements.
The more flexible framework of the future is that we can assemble these components as needed, and then run them on the supported host.
Second, the idea of solving the problem
Before introducing Owin, let's abstract the process of Web request-to-response:
The entire process of a Web request is a simple input and output, which is the header information, cookies, data, etc. that the request contains, and the output is the last HTML. It's like putting flour in, and finally coming out with a good steamed bun. But from flour to steamed bread but to go through a lot of processes, this work together, the whole process is formed. Very similar to decorator mode, each decorator object follows the same interface, so that we can stitch together different decorators.
is the WSGI specification in Python (python Web Server Gateway Interface), which is basically similar to the Owin mentioned below. The request passes through a layer of onion skins, which is then output. This layer of onion peel is our component that complies with the Owin specification.
Three, Owin introduction
Owin is a specification based on the above ideas and goals, and does not contain any concrete implementations. The goal is to isolate an abstraction layer between the Web server and the application to decouple them.
The 2 goals of the Owin design are simple, and rely less on other framework types.
This allows you to:
- New components can be developed and applied very simply
- The program can be easily migrated on host and OS
Owin Core Definition
Owin simplifies all relevant information such as request, response, session, cookie, etc. in the Web application into the following dictionary. Essentially, this dictionary contains all the contextual information for a Web request.
A Web server that conforms to Owin needs to wrap the request information into the following dictionary type, which is passed to the next layer. The next layer of the component or application, all you have to do is read and modify the data in this dictionary. Finally, the Web server obtains this layer of processed dictionaries and then outputs the Web page to the client
idictionary<object>
Here are the specific definitions
Key Name |
Value Description |
"Owin. Requestbody " |
A Stream with the request body, if any. Stream.null may used as a placeholder if there is no request body. See Request Body. |
"Owin. Requestheaders " |
An idictionary<string, string[]><string, string[]= "" > of request headers. See Headers. |
"Owin. Requestmethod " |
A string containing the HTTP request method of the request (e.g., "GET", "POST"). |
"Owin. Requestpath " |
A string containing the request path. The path must is relative to the "root" of the application delegate; See Paths. |
"Owin. Requestpathbase " |
A string containing the portion of the request path corresponding to the "root" of the application delegate; See Paths. |
"Owin. Requestprotocol " |
A string containing the protocol name and version (e.g. "http/1.0" or "http/1.1"). |
"Owin. Requestquerystring " |
A string containing the query string component of the HTTP request URI, without the leading "?" (e.g., "Foo=bar&baz=quux"). The value is an empty string. |
"Owin. Requestscheme " |
A string containing the URI scheme used for the request (e.g, "http", "https"); See URI Scheme. |
Another core is the application delegate, which is the interface that all components running under the Owin protocol must follow
func<idictionary<object>, task>;
The reason for this definition is:
- Because of the less reliance, writing a component is very easy and simple
- Asynchronous design makes the program more efficient, especially in the face of some I/O intensive operations
- The application delegate is the smallest executable unit, and OWIN components can be easily interconnected to form an HTTP processing pipeline
Iv. Owin Prospects and Forecasts
With the use of the Owin specification, ASP. NET evolves faster and can respond quickly to new things.
Owin development, there will be more and more Owin-based application framework (middleware), will also be more owinhost appear, one is Microsoft preemptive katana, it can run in Windows, independent of IIS to support the framework of the OWIN protocol to provide host support While another is the first to support the Owin protocol for the Jexus Web Server running on Linux and FreeBSD (requires more than 5.6 versions of Jexus).
Although NET is very old, but now also more and more tide, the boys have something, it also has, and later on the sensitivity of fashion will be more sharp. And it has a stable, mature temperament, but it is difficult for other young men to have. This is. NET the best of times, isn't it?
Reference: http://www.csharpkit.com/2017-09-24_62916.html
Background and brief introduction of Owin generation