Web application development is on the precipice of a revolution; through a confluence of independent practices and technologies, the way in which web applications are built and consumed is about to change radically.

What is happening is a fundamental shift away from the current state-heavy, page-based processing model to a loose collection of lightweight web-based services that an empowered client can consume to provide full functionality in a composite fashion. It started with AJAX, grew substantially with MVC, took shape with REST, and is now about to break wide open.

Web development up to this point has been tied very closely to processing HttpRequests on a page-by-page level. Remember classic ASP and ColdFusion with code intermixed with html on the page? [Honestly, was there ever a worse language to work with than VBScript? If…EndIf…Next? Please. Microsoft still owes the development community a sincere apology for making us suffer through the miserable excuse for a language that was VBScript – JT] Nightmare! ASP.NET brought the separation of code and markup, which was a huge advancement, but brought along with it a heavy page-processing model and cumbersome state management tied to the server, or worse, hashed and embedded in the page itself. [He’s using ViewState! Grab your torch and pitchforks! Raah!]

AJAX was the emancipation proclamation that freed web development from the confines of postback processing. Utilizing the substantially overlooked XMLHttpRequest object [Thank you Microsoft for developing the XmlHttpRequest in 2000 but not incorporating it into a browser until 2006], developers were suddenly free to call back into their server for processing without having to post an entire page’s content and wait for it to come back. In its entirety. Which took time. Like reading this. OK, you get the point. AJAX did more to enliven the web than any plugin had ever done previously, [sounding the death knell for Flash and similar technologies, R.I.P] and was the timely injection of functionality and responsiveness the web desperately needed. AJAX, however, despite its freedom from the page processing lifecycle, is still inherently tied to a page – its whole intent was to be able to refresh parts of a page without having to throw the whole page back to the server, so no matter how you implement it, Ajax is fundamentally tied to a page. Figure 1 is a good representation of the current state of web development, with different clients requiring dedicated applications to process information over the web

Figure 1 - The current state of web development


MVC changes how we even think about web processing by changing the url from pointing to a physical file sitting in a directory on a server somewhere to a call to a method in the code of our application. This is a huge change; the url doesn’t point to another page or image or even another site, it fires off functionality on demand.

Now, combine this url-based functionality with a robust client-side library such as jQuery, which is capable of consuming and populating services of various types, and you have the basis for a new processing model for web applications. Consider, free from the duty of page DOM processing, jQuery can intercept a click on the page and call any service we want instead. In this scenario, jQuery acts as a controller of our base page, synchronizing calls to a myriad of distributed lightweight service endpoints to deliver full functionality as a composite set. Incorporating the capabilities of HTML5, we’re free from supporting multiple plug-ins to support media, which we can also stream in from services as required.

So what’s really happening here is a combination of the extensibility of service oriented architecture (SOA) with AJAX-style web client processing for the purposes of delivering web applications as outlined in Figure 2.
 
Figure 2 - Composite Web Application Development



This model offers significant benefits over previous web development techniques including, but not limited to:

·         Extensibility: need a new feature? Build a new service and .js file to consume it. You’re done. And you can implement both to the live app without disruption of service.

·         Scalability: services can be provisioned collectively or separately to address performance concerns – which fits perfectly with modern virtualization practices.

·         Performance: by relieving the server from redundant page postback processing, and moving a large portion of processing onto the client, the server is free to dedicate more resources to handling dedicated lightweight service calls, significantly speeding overall responsiveness.

·         Maintainability: encapsulating functionality into independent services means if changes or added features are required by the application, only one service needs to be updated, not the entire application. And as it’s the service that will be altered in most cases, production environments will not have to be impacted by the service refresh.

·         Client Agnostic: Implementing this model frees processing from the page, meaning the same services which feed our web application can easily be consumed by a mobile or platform-specific client, extending the development effort in a parallel fashion.

Service based applications have been highly regarded for quite some time due to their clear separation of concerns and inherent benefits of such an implementation, but the challenge thus far in utilizing a Service Oriented Architecture with web applications has been the limitations of the page/postback processing model. Combining the capabilities of url-based method calls with AJAX-style lightweight service consumption, a composite web application model is emerging which will change the way web application development is considered and pursued. The revolution is coming.