Introduction to ASP.net Katana project

When ASP.net first released in 2002, The Times were different. At that time, the Internet was still in its infancy, with about 569 million users, with an average of 46 minutes per day for each user, and about 3 million sites. Just 10 years later, the same metrics revealed that about 2.27 billion internet users, each with an average of 4 hours of Internet access per day, had about 555 million sites (see BIT.LY/MY7GZO).

Obviously, this growth stimulates the change in demand for application developers, as well as the underlying framework, tools, and runtimes for building and running WEB applications. Modern WEB applications must be able to evolve quickly, leveraging many different components and frameworks. They must be small in size to run effectively in the cloud's large run-time environment.

Ensuring that ASP.net can meet these current needs and future needs is the primary goal of the Katana project. Katana Introduction

The Katana project actually dates back to an open source project named Open Web Interface for. NET (Owin) outside of Microsoft. Owin is a specification that defines the interaction between Web servers and application components (see owin.org). Since the purpose of this specification is to develop a broad and dynamic WEB server and application component ecosystem based on the Microsoft. NET Framework, it can reduce the interaction between the server and the application to a small subset of types and a single function signature, a function that signs The name is called an application delegate (that is, Appfunc):

Using Appfunc = func<idictionary<string, object>, task>;

Each component in an Owin-based application provides the server with an application delegate. These components are then linked into a pipe, and the Owin server pushes the request to that pipe. In order to use resources more efficiently, all components in the pipeline should be asynchronous, as reflected in the application delegate that returns the Task object.

All States, including application state, request state, and server state, are saved in the idictionary<string, object> object specified on the application delegate. This data structure is called an environment dictionary, and is passed from one component to another as the request passes through the pipeline. Although Ningho/value data can be inserted into the environment dictionary, the OWIN specification defines keys for some HTTP core elements, as shown in Figure 1.

Figure 1 Required Environment dictionary keys for HTTP requests

Defines a set of basic Environment dictionary key/value pairs that allow many different frameworks and component authors to interoperate in one Owin pipeline without enforcing protocols to a particular. NET object model, such as httpcontextbase or asp.net W in asp.net MVC EB API in the Httprequestmessage/httpresponsemessage protocol.

Application delegation and Environment dictionary these two elements form the Owin specification. The Katana project is a collection of Owin-based components and frameworks that Microsoft has created and launched.

The Katana component can be viewed through the architecture stack, as shown in Figure 2 .

Figure 2 Katana Project architecture