The ASP.NET Framework has been around for over ten years, and the platform has enabled the development of countless Web sites and services. As Web application development strategies have evolved, the framework has been able to evolve in step with technologies like ASP.NET MVC and ASP.NET Web API.
Web Evolution
- Classic ASP – At the time, ASP was one of the primary technologies for creating dynamic, data-driven Web sites and applications by interweaving markup and server-side script. The ASP runtime supplied server-side script with a set of objects that abstracted core aspects of the underlying HTTP protocol and Web server and provided access to additional services such session and application state management, cache, etc. While powerful, classic ASP applications became a challenge to manage as they grew in size and complexity. This was largely due to the lack of structure found in in scripting environments coupled with the duplication of code resulting from the interleaving of code and markup
- ASP.Net – The first version of ASP.NET – also known as “Web Forms” provided a similar design time experience along with a server-side event model for user interface components and a set of infrastructure features (such as ViewState) to create a seamless developer experience between client and server side programming. Web Forms effectively hid the Web’s stateless nature under a stateful event model that was familiar to WinForms developers.
- ASP.Net MVC – ASP.NET team took several evolutionary steps to enable ASP.NET as a family of pluggable Web components rather than a single framework.One of the early changes was the rise in popularity of the well-known model-view-controller (MVC) design pattern thanks to Web development frameworks like Ruby on Rails. This style of building Web applications gave the developer greater control over her application’s markup while still preserving the separation of markup and business logic, which was one of the initial selling points for ASP.NET.
- ASP.Net Web API – Another major shift in Web application development was the shift from dynamic, server-generated Web pages to static initial markup with dynamic sections of the page generated from client-side script communicating with backend Web APIs through AJAX requests. This architectural shift helped propel the rise of Web APIs, and the development of the ASP.NET Web API framework. As in the case of ASP.NET MVC, the release of ASP.NET Web API provided another opportunity to evolve ASP.NET further as a more modular framework.
By decoupling framework components from one another and then releasing them on NuGet, frameworks could now iterate more independently and more quickly.A modern Web application generally supports static file serving, dynamic page generation, Web API, and more recently real-time/push notifications. Expecting that each of these services should be run and managed independently was simply not realistic.
What was needed was a single hosting abstraction that would enable a developer to compose an application from a variety of different components and frameworks, and then run that application on a supporting host.
The Open Web Interface for .NET (OWIN)
Inspired by the benefits achieved by Rack in the Ruby community, several members of the .NET community set out to create an abstraction between Web servers and framework components. Two design goals for the OWIN abstraction were that it was simple and that it took the fewest possible dependencies on other framework types. These two goals help ensure:
New components could be more easily developed and consumed.
Applications could be more easily ported between hosts and potentially entire platforms/operating systems.
The resulting abstraction consists of two core elements. The first is the environment dictionary. This data structure is responsible for storing all of the state necessary for processing an HTTP request and response, as well as any relevant server state. The environment dictionary is defined as follows:
IDictionary<string, object>
An OWIN-compatible Web server is responsible for populating the environment dictionary with data such as the body streams and header collections for an HTTP request and response. It is then the responsibility of the application or framework components to populate or update the dictionary with additional values and write to the response body stream.
In asp.net WebApi v2, the OWIN pipeline becomes the default. It is eventually going to be the standard pipeline under any asp.net project.
Without OWIN, the asp.net bits are coupled to the way IIS communicates with the application. OWIN abstracts web servers and framework components. That means that your application code will now be aware of the OWIN interface, but not of the webserver that is serving the request.
In return, applications can be more easily ported between hosts and potentially entire platforms/operating systems. For example, the ability to host an application in a console or any process allows Mono to host it without efforts…
The second aspect is that it works as a pipeline.
You can plug any middlewares (and as many as you want) between the webserver and your application.
This allows for more modular solutions. You can develop redistributable middlewares that can impact the request/response coming to/from your application, but keep these modules separated from the application code.
To persuade yourself of the benefits of this modular approach, take a look at the nuget packages available for OWIN : http://www.nuget.org/packages?q=owin
A lot of these packages were previously core asp.net functionality, and have been extracted as middleware.
For example, adding support to login using various OAuth providers becomes an infrastructure concern (a middleware) and does not need to be part of your application code anymore :
Project Katana
Whereas both the OWIN specification and Owin.dll are community owned and community run open source efforts, the Katana project represents the set of OWIN components that, while still open source, are built and released by Microsoft. These components include both infrastructure components, such as hosts and servers, as well as functional components, such as authentication components and bindings to frameworks such as SignalR and ASP.NET Web API. The project has the following three high level goals:
Portable – Components should be able to be easily substituted for new components as they become available. This includes all types of components, from the framework to the server and host. The implication of this goal is that third party frameworks can seamlessly run on Microsoft servers while Microsoft frameworks can potentially run on third party servers and hosts.
Modular/flexible – Unlike many frameworks which include a myriad of features that are turned on by default, Katana project components should be small and focused, giving control over to the application developer in determining which components to use in her application.
Lightweight/performant/scalable – By breaking the traditional notion of a framework into a set of small, focused components which are added explicitly by the application developer, a resulting Katana application can consume fewer computing resources, and as a result, handle more load, than with other types of servers and frameworks. As the requirements of the application demand more features from the underlying infrastructure, those can be added to the OWIN pipeline, but that should be an explicit decision on the part of the application developer. Additionally, the substitutability of lower level components means that as they become available, new high performance servers can seamlessly be introduced to improve the performance of OWIN applications without breaking those applications.
And Now..
ASP.Net 5 – vNext
The next generation of ASP.net
ASP.NET 5 is a significant redesign of ASP.NET.
ASP.NET 5 includes the following features:
- New flexible and cross-platform runtime
- ASP.NET MVC and Web API have been unified into a single programming model
- New modular HTTP request pipeline
- Cloud-ready environment configuration
- Modular design, depedency injection and lot more.
- Unified programming model that combines MVC, Web API,SignalR and Web Pages
- Ability to see changes without re-building the project
- Side-by-side versioning of the .NET Framework
- Ability to self-host or host on IIS
- New tools in Visual Studio 2015
- Open source in GitHub
- Can run on Mono, on Mac and Linux
Learn more : http://www.asp.net/vnext
Pixytech 