Introduction
If you look at the current web stacks in open-source, it is fast evolving with wide-range of capabilities getting added day by day. On the other hand, Microsoft too is constantly working to update its web application stack and released many new framework components. Though Microsoft’s Asp.Net is very mature framework, it had lacked some basic qualities like portability, modularity and scalability which the web stacks in Open Source communities were offering. This had led to the development of OWIN, a specification how an Asp.Net application and hosting servers has to be built to work without any dependency on each other and with minimal runtime packages. By implementing OWIN specification, Asp.Net can become more modular, have better scalability, it can be easily ported to different environments, and thus making it competitive with its open source counterparts. Besides this, it is also aimed to nurture the .net open source community participation for its framework and tooling support.
OWIN
OWIN stands for Open Web Interface for .Net. It is a community-owned specification (or standard) and not a framework of its own. OWIN defines an interface specification to de-couple webserver and application using a simple delegate structure. We will discuss more about this delegate later in this article. Now, let’s take a closer look at classic Asp.Net framework’s design issues in detail and how OWIN tries to mitigate it.
ASP.Net - Webserver Dependencies
Asp.Net framework is strongly dependent on IIS and its capabilities, so it can be hosted only within IIS. This has made the portability of Asp.Net application an impossible task. In particular, Asp.Net applications are basically build upon the assembly called System.Web which in turn heavily depends on IIS for providing many of the web infrastructure features like request/response filtering, logging, etc.
System.Web assembly also includes many default components that are plugged into the Http pipeline regardless of its usage in the application. This means there are some unwanted features that are executed in the pipeline for every request which degrades the performance. This has made the current open source counter-parts like NodeJs, Ruby, etc. perform way better than Asp.Net framework.
To remove these dependencies, to make it more modular and to build a loosely coupled system, the OWIN specification is built. In simple terms, OWIN removes Asp.Net application dependency on System.Web assembly at first place. That being said, OWIN is not designed to replace entire Asp.Net framework or IIS as such, thus when using OWIN model we are still going to develop an Asp.Net web application in the same way we were doing all these days but with some changes in infrastructure services of Asp.Net framework.
The other major drawback of System.Web assembly is it is bundled as part of .Netframework installer package. This has made the delivery of updates and bug-fixes to Asp.Net components a difficult and time consuming task for the Microsoft’s Asp.Net team. So, by removing the dependency with System.Web assembly, Microsoft is now delivering its owin web stack updates faster through its Nuget package manager.
Implementing OWIN
As I said before, OWIN is not an implementation by itself. It just defines a simple delegate structure commonly called as Application Delegate or AppFunc designed for the interaction between webserver and application with less dependency. AppFunc delegate signature below.
Func<IDictionary<string, object>, Task>
This delegate takes a Dictionary object (IDictionary<string, object>) as a single argument called Environment Dictionary and it returns a Task object. This Dictionary object is mutable, meaning it can be modified further down the process. All applications should implement this delegate to become OWIN compliant.
In an OWIN deployment, the OWIN host will populate the environment dictionary with all necessary information about the request and invoke it. This means it is the entry point to the application, in other words, it is where the applications startup/bootstrap happens. Hence, this is called the Startup class. The application can then modify or populate the response in the dictionary during its execution. There are some mandatory key/values in the environment dictionary which the host will populate before invoking application. Refer the spec under the heading Environment.
Below are the components of Owin-based application that makes this happen. From OWIN spec,
Server — The HTTP server that directly communicates with the client and then uses OWIN semantics to process requests. Servers may require an adapter layer that converts to OWIN semantics.
Web Framework — A self-contained component on top of OWIN exposing its own object model or API that applications may use to facilitate request processing. Web Frameworks may require an adapter layer that converts from OWIN semantics.
Web Application — A specific application, possibly built on top of a Web Framework, which is run using OWIN compatible Servers.
Middleware — Pass through components that form a pipeline between a server and application to inspect, route, or modify request and response messages for a specific purpose.
Host — The process an application and server execute inside of, primarily responsible for application startup. Some Servers are also Hosts.
Building an OWIN compliant application
To be OWIN compliant, our Asp.Net application should implement the application delegate AppFunc. With current set of framework components, we also need the actual OWIN implementation for host, asp.net application and infrastructure service components. So, building Owin compliant application is not just implementing AppFunc delegate alone it also requires other components. Here comes the need of the Project Katana, which is Microsoft’s own implementation of this specification.
The Asp.Net's infrastructure services like Authentication, Authorization, routing services and other request/response filtering has to be done by OWIN middleware pass-through components to prevent its dependency with IIS. These middleware components resembles the Http modules in the traditional Asp.Net pipeline. They are called in the same order they are added in the Startup class similar to HttpModule events subscription in classic Asp.Net application object(Global.asax). To recall, Owin’s AppFunc delegate implementation in our application is commonly called as Startup class. We will understand it better when we build our first application.
Project Katana has evolved so much after its initial release and it is now fully incorporated into the newest version of Asp.Net called Asp.Net Core. Next section will provide us a brief history of OWIN implementation from Project Katana to Asp.Net Core releases.
Project Katana to Asp.Net Core
-
Project Katana is Microsoft’s first own implementation of OWIN specification and it is delivered as Nuget packages. Developers can include these packages from Nuget and start working.
-
Microsoft planned for Asp.Net vNext, the next version after Asp.Net 4.6 with full support of OWIN and thus Project Katana was slowly retiring. Note – Any project implementation with Katana libraries will continue to work as expected.
-
.Net Core 1.0 is another implementation of .NetFramework. .Net Core is a portable, open-source, modular framework and it is re-built from scratch with new implementation of CLR. The Asp.Net vNext, the next version of Asp.Net was renamed as Asp.Net 5.0 and is capable of running on .Net Core framework and latest .Net framework 4.6.2
-
Asp.Net 5.0 was renamed to Asp.Net Core since this framework was re-written from scratch and Microsoft felt the name was more appropriate. Asp.Net Core is delivered as Nuget packages and it will run on both .Net Core 1.0 and .NetFramework 4.5.1+ frameworks. So, the latest version of Asp.Net is now officially called as Asp.Net Core.
Though OWIN and Project Katana was released years ago, there were lots of updates happened to its implementation all these days. Hope this article helped you understand the current status and start the learning process of building Owin-based application.
Let’s implement a sample Owin-capable application in the next part. Stay tuned!
