Visual WebGui Empty Client Approach

Abstract
Up to now, in order to design new web applications, enhance and modernize existing ones or port desktop applications to web, one would use tools that extend traditional multi-layer, multi-language architecture. This traditional architecture is complex, time consuming to develop, hard to debug and maintain, and the end result is vulnerable and hard to secure. Whether one chooses the "Thin client" approach which requires specific installation on the client, or the "Thick client" which requires strong terminals and entails severe security hazards by exposing logic and data on the client, they both present their challenges. AJAX has added more design complexities that require highly skilled (and expensive) technologists to implement, and even more security concerns. The bottom line led to a doubtful ROI for enterprise use cases.

Now, for the first time since the introduction of Web there is a real simple and economic alternative to develop new web applications or port exiting applications to the Web. Employing innovative new Empty Client approach, Visual WebGui extends desktop technologies to the Web rather than Web technologies, and introduces new Web like desktop behavior over the Web. It lets developers create desktop-like Web applications in no time using their existing skill sets with no re-learning, no retooling, without the traditional web complexities. It also eliminates traditional security concerns, by facilitating literally Empty clients - no open services, no data, no logic, or any other exposed security hazards on the client.

The outcome is literally a new Web that facilitates desktop's user experience which is very powerful, fast and responsive while still highly economic with standard browser, installation free accessibility. Typical high ROI usage scenarios for Empty client would be creating new line of business web applications that use large data bases (such as CRM, ERP, BMP and more), enhancing existing ASP.NET applications, porting legacy desktop applications without re-writes for web expenses, creating applications that share same codebase for either web, desktop or hybrid, SAAS enablement and customers facing rich UI using Microsoft Silverlight as rich presentation layer.

For typical use cases watch this video presentation

Technological breakthrough that incorporates the best of all worlds: desktop, "Thin client", "Thick client" and AJAX
"Thin" or "Thick client" have their downsides and upsides: In a nut shell, "Thin client" downsides are; network dependency, network latency, limited scalability as all processing is on the server and the need for specific terminal underlying installation. Its upsides are no need for powerful terminals that cost less, higher security as not much is exposed on client, its ability to support large data centric applications that are being processed on a powerful server and central management that saves a lot of resources otherwise would be required for local terminal installations updates, and maintenance. "Thick client" on the other side, needs strong terminals, local installations and maintenance which are distributed and therefore expensive, present sever security hazards as logic and data are exposed on client and open end point that could present even larger security hazards.

The breakthrough is a new AJAX server-web client updating protocol, with an Empty client approach. It provides a new Web like Desktop platform. The new platform introduces a compelling application dedicated alternative platform to platforms such as ASP.NET which it extends. It also provides a framework to develop Web like desktop application atop its platform.

The Empty Client approach combines for the first time on web, the best of both desktop and web environments. An optimized protocol makes server side power, typically achieved with "Thin client" available for data centric web applications, with "Thick Client" scalability and performance.

With the Empty Client approach the entire application flow, UI logic and validations are developed and processed on the server while the browser serves as a “display” for the output and a “receptor” for user input. Server simply reflects the “screens” to the client, captures user input from the client and reflects the incremental changes back to the client all over a highly optimized communications channel. Not every user interaction produces a post back due to an algorithm that analysis the code and creates post backs only on critical events. Post backs never exceed 1 KB, as they are actually only differential Meta data.

In the Empty Client case there is no need to consider the “screen” as a purely graphical representation of the application – a bitmap, but rather it can be considered as a series of related components which change according to the application logic. In effect this is similar to how X-Windows communicates changes to X-Terminals by transferring component changes between the client “host” and the server’s state. The optimization achieved by this approach is so high that band width usage is minimal and the concept is valid for mobile applications as well.

Empty Client design time benefits
Desktop simplicity visual, intuitive drag & drop development patterns are enabled for web development. This simplifies and shortens development cycles by as much as 90%. These major design time benefits of the Empty Client means no-relearning or re-tooling for developers are needed.

Current web application construction requires requests, responses, html and scripts, as the tools and common practices of the trade. These serve well when creating sites. But, the complexities of web applications bring a good deal of sweat even from web experts while Visual WebGui offers a simplified alternative.

With traditional web development tools, developers are using a hand drill to do a tractor's job. The irony of it is that on the other side of the "ocean", the desktop side, there is a VB6 or WinForms or WPF that have been doing exactly the same, but in a frication of the time.

The difference can be demonstrated with WebForms. They are originated from the evolution of the web. From static pages to dynamic client-side and server-side pages. Pages are still the cornerstone of every web environment and they are served well as a general purpose environment but when it comes to web application they are time consuming.

Desktop environment such as WinForms on the other hand, originated from VB, MFC and other desktop environments and were developed solely to serve application development. As such, they are much more applicable for developing applications, and provide larger building blocks for that.

This comparison explains the great time and complexity differences between the two environments. Traditional web development has to deal with many details, and low level interactions, which are not necessary for desktop development. In the past, web environments were totally based on requests and responses. It means a form submitted to the server as a request which in turn generates a server response. Such concepts have evolved with time, and translation was added to events layer, that resulted in environments like ASP.NET and J2EE, which present a much more intuitive way to program a web application.

But although events were introduced into web environments, they did not match their desktop counterpart's structure pattern, which again forces developers to add their individual scripting client side glue code. When AJAX was introduced such concepts were reshuffled once again as most of the logic was transferred to the client. This forces developers, yet again, to deal with the need to use requests and responses in order to implement applications.

Desktop development on the other hand always had fully event driven environment, making development tasks much simpler. Programming a file explorer like application, for example in desktop environment is as simple as dragging a tree view and a list view and implementing a couple of event handling methods. Compare it to web development that requires exposure of services and consuming them, all as scripting on the browser, and the difference becomes obvious.

Furthermore, with traditional web development, one has to be familiar with the concept of pages which originates from the early days, when such pages where static resources that had links to other pages. The concept of pages is tolerable when implementing a web site, but creates lots of extra time consuming work when creating applications.

Another example is creating a dialog. In desktop environments creating a dialog is as simple as creating an object, calling its methods, and setting its properties. It sounds unbelievable; that creating a page that has a script, which in turn opens a new browser window with a second page, which receives arguments and displays user interface, which then, uses a script that is used to callback the parent page… all that, while in a desktop environment one simply creates an object. With Visual WebGui Empty Client approach, one develops web exactly as if he develops desktop. This is the design time big news!

Real world feedback attest to the productivity achieved with VWG: "Simplicity at last...All I can say is, wow!" ASP MVP Goodyear.
"It's ridiculous how productive you can be with a tool like this..." MVP Strahl.
"A revolution in Web development" SAP

Empty Client Run time responsiveness, scalability and security benefits
Desktop Responsiveness - MVP Victor Zychla, an independent test expert ran a series of tests comparing VWG Empty Client performance with other available platforms. We bring the results as reported by him in his blog HERE.

Tests abstract:
"…The first version of the application was built as a server-side application: all SelectedIndexChanged events were auto-post backed and processed on the application server. This caused a lot of trouble since the heavy form had to be sent to and from the server. The year later we've completely redesigned the application…

In the meantime, few promising AJAX frameworks appeared and we thought that it would be possible to go back to the initial version of the application but instead of expensive postbacks we could take the AJAX approach and replace postbacks with callbacks. This could solve all problems: reduce the traffic and still keep the application logic on the server-side."

The Test:
Microsoft Application Center Test has been chosen as the contest judgment tool. Tests were performed on the Windows XP machine serving as the application server. Exactly 200 sessions have been simulated for 5 concurrent users. Each session has been recorded as the complete user session - forms have been filled with data and dropdown selections have been made. Each session ended with the application showing the print-ready document.

The Results:
Gathering all results together, we had 2 non-Ajax contestants: pure Web.Forms application, JavaScript version of it and 6 Ajax frameworks: Microsoft's ASP.NET AJAX, Ajaxium, VisualWebGUI, ComfortASP.NET, Anthem.NET and Telerik's RAD Ajax.

Regarding requests-per-second we have following results:

Framework requests-per-second reference
 VWG 422 198,1220657
 JavaScript 400 187,7934272
 Telerik 292 137,0892019
 ASP.NET AJAX 222 104,2253521
 Web Forms 213 100
 Anthem 133 62,44131455
 Ajaxium 111 52,11267606
 Comfort 35 16,43192488

Regarding number-of-bytes-sent we have following results:

Framework sent data reference
 JavaScript 1938800 24,23560589
 VWG 2066800 25,83564589
 Ajaxium 5029800 62,87407185
 ASP.NET AJAX 5600600 70,00925023
 Comfort 5880400 73,50683767
 Anthem 6161400 77,01942549
 Telerik 7293200 91,16727918
 Web Forms 7999800 100

Regarding number-of-bytes-received we have following results:

Framework received data reference
 VWG 23348807 29,11700146
 JavaScript 37121000 46,29153905
 Ajaxium 47756301 59,55423272
 Web Forms 80189600 100
 Comfort 83742600 104,4307491
 Anthem 121547800 151,575516
 ASP.NET 129531800 161,5319194
Telerik 172294800 8592835

When looking at the responsiveness tests results it is obvious that VWG is the overall winner.

Scalability – Visual WebGui Empty Client allows server-side scalability and redundancy. Visual WebGui scales over a web-farm and boost the concurrent user's capacity of a Visual WebGui application per server even above that of a standard ASP.NET application.

Visual WebGui provides the scaling capabilities required in order to store the session state within an external state server that can be either an SQL Server or any state server which is enabled by Microsoft ASP.NET session state. As a result of the static state which is kept on the server, VWG server performs a minimal amount of construction and disposal of objects and therefore minimizes the CPU consumption. From the memory consumption perspective, even though VWG keeps the entire local state on the server, for each user the memory consumption is only a bit higher than that of a standard ASP.NET application. This is possible due to the fact that the state is local (partial) and the objects are optimized in weight.

Desktop Security - Visual WebGui Empty Client concept introduces a new level of secured web applications, which eliminates AJAX/Silverlight security concerns. Visual WebGui features secured-by-design platform for developing and deploying Line of Business DHTML & Silverlight applications.

Conventional AJAX/Silverlight requires the browser to connect directly to a web service or even a raw data provider. Client side AJAX / Silverlight, therefore, exposes credentials, tokens and other sensitive data which presents a key concern for enterprises applications. Since there is no data, no logic and no open services on the client, Visual WebGui Empty Client approach presents a highly secured alternative to conventional client-side AJAX/Silverlight.

Visual WebGui client never consumes data or services directly since all of the application logic, UI logic and data access is handled on the server. The client simply connects to the “view” on the server, via a standard protected HTTP/HTTPS pipeline, and the "view" is projected on the browser by Meta Data and therefore never compromises security.

Trackback the original Visual WebGui Empty Client White Paper

No Comments