Are Enterprise AJAX Applications Doomed…Or Are We?

Sometimes, it seems that the world is all about man vs. technology, and one has to lose. This seems to be the question raised about AJAX; from the general challenges of AJAX, including cost and expertise needed, to its security issues, will the technological good prevail or will we humans be seeking an alternative?  Navot Peled explains that it doesn’t have to be only one or the other; there are solutions that offer a win-win situation. 

I thought it would be useful to bring to your attention the following piece which I wrote for Methods & Tools.

Introduction:  The Challenges of AJAX

A recent DevX article by Rikki Kirzner noted that “Despite its many benefits and some significant real-world applications, including Google's Gmail email program, many developers consider AJAX implementation as somewhat tricky or difficult, depending on their experience with related technology.” While research shows that AJAX has fast penetrated into mainstream web programming, with around 60% of all newly built websites using some AJAX components, this contrasts with only 1% of all newly built enterprise web applications utilizing major AJAX components.

What does this mean to application developers? Essentially, AJAX presents a major problem for those with limited resources and tight budgets.  As application technology progresses, will those individuals or businesses that do not have the time, funds or resources to obtain the AJAX expertise required need to search for an alternative option?

Another fundamental issue that arises with AJAX is its security vulnerabilities.  In general, the security issues today aren’t resolved by using standard solutions to secure a server’s farm or from penetration through AJAX end points. Those security tasks can be quickly and efficiently achieved by using today’s firewall capabilities and other secured server’s farm solutions, as well as by securing the transferred data using HTTPS, WCF and other quality solutions.  When it comes to AJAX, more problematic issues arise because as responsive as it is, AJAX opens a huge attackable surface on the client side, transfers hidden data and exposes many scattered openings to the server, and decreases the control we have as well as what we know about those who have access to our sensitive data.

In Help Net Security’s "Top 10 AJAX Security Holes and Driving Factors", Shreeraj Shah writes, "One of the central ingredients of Web 2.0 applications is AJAX encompassed by JavaScripts. This phase of evolution has transformed the Web into a super-platform. Not surprisingly, this transformation has also given rise to a new breed of worms and viruses such as Yamanner, Samy and Spaceflash. Portals like Google, NetFlix, Yahoo and MySpace have witnessed new vulnerabilities in the last few months. These vulnerabilities can be leveraged by attackers to perform Phishing, Cross-site Scripting (XSS) and Cross-Site Request Forgery (XSRF) exploitation." Shah’s main claim is that this is caused by "multiple scattered end points and hidden calls”.  He notes that “One of the major differences between Web 2.0 applications and Web 1.0 is the information access mechanism. A Web 2.0 application has several endpoints for AJAX, as compared to its predecessor Web 1.0. Potential AJAX calls are scattered all over the browser page and can be invoked by respective events. Not only does this scattering of AJAX calls make it difficult for developers to handle, but also tends to induce sloppy coding practices, given the fact that these calls are hidden and not easily obvious."

The question persists: what does this mean to developers? 

A Non-Technological Review of AJAX

To utilize a non-technological scenario to better understand the challenges of AJAX, it’s like a good marriage gone bad.  At first everything seems nice and easy.  In-laws aside, life is grand after the wedding.  But then the honeymoon ends.  It doesn’t matter whether she discovers that the prince snores or leaves the toilet seat up; the princess has a different agenda for her spouse, only to learn quickly that Mr. Right not only isn’t so perfect, but he can’t be changed so easily.  And so it is with our AJAX princess that promises to get rid of the annoying page flicks devastating user productivity, but at what price does success come?

AJAX is actually only providing us with an alternative way to talk to the server, which initially seems positive.  But the honeymoon ends with the discovery that using this alternative conflicts with most of what you know about developing web applications. Sometimes, it seems that pre-AJAX, everything was simpler; every time the browser called the server, a full page was returned, leaving the heavy lifting on the server.  Post-AJAX, from a development aspect, everything changed.  Now when a browser calls the server it could be to request data, replace a part of the page, conduct a server action, and so forth. It’s actually even more challenging than understanding how the server should respond, as now the client is doing most of the heavy lifting and the server does not know what the current client state is. 

And then we face another problem. Suppose you figured out how to survive in the aforementioned AJAX jungle.  You still cannot escape the consequences AJAX brings to the security without adding more complexities; and even then, as the system administrator says, “If it’s open…it’s open.”

So at the end of the day, we find ourselves asking, how did we end up with the snoring prince?  And it comes down to the simple answer: we weren’t supposed to fall in love.  Indeed, the prince was never supposed to stay overnight.  It was never supposed to be a marriage. Maybe a little flirting…even holding hands.  But that’s where it should have ended.

And so too with AJAX.  The initial goal of the web was to create a host for information sites, the desktop was for applications, and AJAX was supposed to be used to enhance web sites. Then we fell in love with the concept of AJAX, and we over-used it to create applications on the web which offered huge business short-term returns but led to long-term concerns of security hazards, overshooting deadlines and unsatisfied customers.

It wasn’t a fairy tale after all; it turns out that AJAX is a very high maintenance princess, which demands expert handling and care.

Now That We Love AJAX, Are There Solutions?

We shouldn’t dismiss AJAX so quickly, but we must understand that there is a lot of R&D that goes into finding solutions. With hundreds of thousands of private developers or small software houses and enterprises around the world, we cannot ignore two key issues with regards to technological, and particularly cloud, development: the expertise and the costs that are involved with building enterprise level AJAX applications.  We need to realize and resolve the widening gap between small-to-medium organizations with minimal budgets and the large organizations which have expanded resources and can afford expensive and experienced personnel.

But it’s not only about money.  Many are willing to invest initially for the long-term benefits, and they may be willing to calculate the financial outlay as a necessary step.  What becomes a larger problem is the dependency on highly skilled personnel that are hard to find. In the past, web application development was very complex, and required the mastering of various languages and practices for a single application.  Rather than simplify it, AJAX made it much more complex. With the introduction of AJAX, the multi-layer, multi-language practices have more than doubled.

The challenges of AJAX are not new, and there are many tools, libraries components and software companies examining options for easing and simplifying AJAX development. Most of the current alternatives are partial solutions, which provide some relief but do not offer a comprehensive solution that eliminates the multi-level, multi-languages and multi-practices that are needed to develop enterprise applications.  But now a practical and ideal solution has been created.

The Key Solution:  "Empty Client" (AKA Clever Client) Methodology

Before presenting the simplification that this new methodology brings to AJAX, we should first introduce an emerging open source methodology called "Empty Client" which offers a different approach to developing AJAX front-ends. In order to shed some light on this methodology, we will compare it to the classic Thin and Thick (also referred to as Fat or Smart) client approach. "Empty Client" offers a new balance between the Thin and Thick client approaches.

The Thin client model communicates with a central processing server, meaning there is little hardware and software installed on the user's machine. This allows all end users' systems to be centrally managed with software deployed on a central server location, as opposed to installed on each individual system. This is usually used in places where it would create a major headache for IT to both deploy and maintain so many user stations. In contrast, a Thick client will provide users with more features, graphics and choices, thereby expanding the opportunities to make the applications more customized. Unlike Thin clients, Thick clients do not rely on a central processing server because the processing is done locally on the user system, and the server is accessed primarily for storage purposes. For that reason, Thick clients often are not well-suited for public environments. To maintain a Thick client, IT needs to maintain all systems for software deployment and upgrades, rather than just maintaining the applications on the server.  Additionally, Thick clients often require operating specific applications, again posing more work and limitations for deployment. The trade-off is a more robust and local computing environment.

For the first time, the "Empty Client" approach combines for the web and cloud, the best of both worlds - the desktop and web environments or Thick and Thin client approaches. An optimized protocol generates server side power, typically achieved with Thin client, available for data centric web applications, typically achieved with Thick Client. It also achieves scalability and performance that, in the past, were enabled only with the Thick client approach. It is called the "Empty Client" because it doesn’t expose data or logic, nor does it open web services as AJAX does on the client. It is also referred to as Clever Client because the client renders, processes and integrates the user interface; it creates as native client side web application that usually run as Thick or Fat client. The "Empty Client" differs from the Thin client also because it runs with no plug ins or bitmaps, instead using plain browsers. This way, the "Empty Client" is really offering the best of both worlds by allowing central computing with the strong processing power that clients typically have today. 

How does the "Empty Client" approach work?

With the "Empty Client" approach, the application is developed and run on the server, and its user interface is only partially projected on the client. An algorithm is charged with the task of transferring user interactions and application responses back to the client. While other frameworks utilize AJAX to enhance scattered parts of the applications (like individual controls), the Empty Client approach seeks AJAX to accomplish one specific need: acting as its main pipeline to the server.  This explains why it is so secure, why there is not need to code AJAX, and why there is a very speedy performance regardless of the size or the amount of data that the application consumes. All one has on the client is a small JavaScript kernel that is responsible for drawing on the browser and receive the user interaction. With this approach, security hazards are completely removed as there is "nothing" on the client to hack into or manipulate to get access into the server. That is one of the reasons it is called the "Empty Client".

The benefits for developers and for enterprise level AJAX applications

This model offers intrinsic benefits for enterprise applications since it provides additional measures of security and control which is not available on AJAX browser-based solutions. This approach employs de-coupled GUI components which decouple GUI logic from GUI presentation (rendering) and enable remoting of the display/input capture between the client (browser) and the server. This provides an even greater benefit by enabling application logic (usually entailing both business and presentation logic) to be handled within one, object-oriented environment developed in a high level, OOP language such as C#, VB.Net or Java rather than a mix between JavaScript and a server based language.

Using a homogenous platform provides developers with immeasurable productivity benefits and enables developers to make better use of existing assets, knowledge and experience rather than requiring the steep learning curve of AJAX. The approach provides server side controls that behave like existing desktop application controls, both in design time and in run-time. These controls manifest themselves as AJAX controls on the browser in run-time and look like their desktop counterparts. The architecture of the system is in no way limited to representing these base controls in their current "desktop" look and feel since it makes use of de-coupled components.

In addition, this approach is extremely flexible; it enables extending the framework by adding additional controls, changing themes/flavors (skins), creating composite controls based on base controls and creating gateway components. Since ultimately this is an extension to the ASP servers context (in the case of .Net, an extension to IIS/ASP.net), it can interoperate with client side and server side legacy code. This means that it can host and interoperate with existing HTML/Javascript client only controls or with embedded DOM objects such as Applets and ActiveX controls. Similarly existing web applications can interoperate with the structure of this approach's components/forms/windows since they are, in essence, URLs like any other sharing the same application and session context.

Whether you are a web developer, desktop developer or both, the new "Empty Client" approach offers a unique productive experience that maximizes development efforts with its simplicity and capability.  It enables individual developers and small developer shops to build applications in a very short time frame, without having to code JavaScript, HTML or CSS. A VB or VB.NET developer can also use this approach for development, relying on his former experience with coding VB or VB.NET, and without needing any AJAX or Web experience.

Examples of the new "Empty Client" approach practices versus traditional AJAX development

Web developers are used to working with requests, responses, html and scripts as tools of the trade. These tools are significant when creating sites, and can even be utilized to create a full blown application. But developing web applications is definitely not a job for rookies, and even experts don't get the job done without a good deal of sweat. A review of your efforts will probably conclude that you have been using a pick axe to do a tractor's job. The irony is that on the other side of the world, there is a VB6 or WinForms developer doing exactly what you are trying to do, but what takes you weeks to achieve, they achieve in days.

Why can s/he succeed in only a few days? The answer is below, but for now imagine that you had VB or VB.NET working for you on the web; what effect that might have on your productivity? With the "Empty Client" approach you can develop applications exactly the same way you develop with VB or VB.NET. You will still be creating the same standard, browser agnostic, zero footprint web application, only using a much more powerful and intuitive methodology. The concepts that you are so familiar with in Web forms originated from the evolution of the web. From static to dynamic client-side and server-side, pages are still the cornerstone of every web environment. They serve well as a general purpose environment, ranging from developing personal home pages to developing full websites. VB and VB.NET, 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 developing such applications.

This explains the great difference in implementing the same solution in each environment. An AJAX developer has to deal with many details and low level interactions which are taken for granted by desktop developers as part of their environment. The following samples will highlight the differences.

Using the explorer application scenario again, a WinForms implementation will include a single layered, compiled file. Developing the same application using WebForms will entail multiple files in multiple languages, with multiple layers. The complexity differences increase dramatically as the complexity of the application grows, presenting a glass ceiling for web developers that is reached very quickly.

• Full OOP vs. Semi OOP
  Web developers use object oriented concepts in a small portion of the implementation, which dramatically decreases when combined with AJAX. The importance of these concepts for complex applications is crucial and the emergence of frameworks such as GWT and Script# show that the big guys are aware of these issues as well. These frameworks generate your scripts for you while allowing you to develop your application in a fully object oriented programming environment. But don’t sit back too soon; this implementation presents a loose connection between your code and the runtime code making it very hard to debug your application.
  
  On the other hand, desktop developers are provided not only with a full OOP environment, but also with lots of mature concepts that have been developed during many years of developing desktop applications. Design patterns originating from desktop development have, through the years, found their way to web implementations, but the architecture of web environments permits only partial implementations, leaving a great deal of useful design patterns exclusively to desktop developers.
  
• Data Binding vs. Data Oriented
  Web developers are used to working in a stateless environment forced by the need to be scalable. But even when not implementing the next Amazon-like application, the same general purpose tools are still presented. It is common practice to implement stateful web applications as it dramatically simplifies implementation and reduces security issues. However, working with pages still implies some kind of stateless implementation that presents developers with non-trivial tasks.
  
  Desktop developers, on the other hand, are provided with a stateful environment which utilizes the state to simplify development tasks. They are presented with a full object model allowing them to interact with the UI elements in a much more intuitive way. They are provided with a richer data binding mechanism which simplifies their development tasks.
  
• Full vs. Limited User Controls
  Web developers are not used to being able to share user controls between applications. For those who insist on sharing them, it is necessary to switch to web controls which are implemented at a lower level without design time capabilities.
  
  Desktop developers are provided with a user control mechanism that can be used across projects. This is a very important feature for a component vendor or architect who wants to divide the solution into different logical parts that are developed by different teams. Design time usage of these controls generates an actual visual presentation of what the control looks like rather than a square place holder.
  
• Dedicated vs. General Purpose
  The bottom line is that web environments were not intended to be used as a way to develop applications. The web evolved layer after layer, trying to close the gap between web environments and the desktop. After many years of evolution, the underlying concepts of web environments are still limiting the ability to provide a solid basis for web application development. While web concepts are left lacking for developing applications, desktop environments have always been there, providing a much more productive way to develop complex applications.
  
  The "Empty Client" concept offers the same tools and capabilities that were designed for developing desktop applications reengineered to work over HTTP. Under the hood, it provides the same legacy HTTP request/response interface that standard browsers can utilize but it is exposed to the developer as plain old reliable desktop concepts. Developers can enjoy the richness and effectiveness of a desktop development environment without losing any of the capabilities that were enjoyed when you developed using web environments. Although it is presented as a desktop like framework, the "Empty Client" is an extension of ASP.NET and allows the combination and use of the best of both worlds.

Could this kind of simplification solve the AJAX challenges?

Garnter’s Erick Knipp, wrote in his blog about complexities of web and cloud development, "…Could this new level of simplicity in complexity be the disruptive innovation that saves the world – or at least gives us a bit more time?"
"Ria development gets a ton easier," says Analyst Peter Brockmann. "Faster development of a rich media experience for web applications that are secure in operation has been a particularly elusive goal for many enterprise application developers since the debate about thin client and thick clients a decade ago." Brockmann, of the notable Brockmann & Company reports that now, for the first time, the "Empty Client" solution offers a solution.

Could it be that with such a productive method, individual developers and small-to- medium developers can create complex AJAX applications (which used to take significant expertise and a long time) more quickly and without any prior experience and expertise?

And can the "Empty Client" approach remove the security concerns of AJAX?

Security is where the "Empty Client" really shines, and it is undoubtedly one of the most significant attributes of this model. By utilizing the "Empty Client" solution, all the serious security issues are eliminated because nothing except for UI commands and one static kernel is downloaded to the client. This means:

1. No sensitive/hidden data is sent to the client. Neither the infrastructure nor the developers can perform security violations by sending sensitive data to client machines.
2. The server exclusively handles interaction with data and other services.
3. The client is responsible to render UI and send events to the server; in any case it can never control the server’s behavior.
4. Each client request is validated by the single layer server code which constitutes a single point access control center.

The following flow, which describes an "Empty Client" application, explains it in greater depth:

Flow Step 1
The first time the client approaches the server it downloads a small amount of kernel code which is constructed of:

• JavaScript– responsible for the client behaviors and communication with the server.
• XSLT – responsible for the UI layout including the HTML rendering of the entire set of controls.
• CSS  – responsible for UI styling

The kernel is sent in a compressed mode and weights about 200kb. Furthermore, it is cached on the client and on the server statically and will never change from this point forward.

Security aspects: No code generation at runtime, the kernel is well known and static.

Flow Step 2
The client renders the basic HTML to the screen and from that point on it acts like a smart AJAX client which consumes a UI service from the server only.

Security aspects: Only UI essential data is sent to the client, no applicative or sensitive data.

Flow Step 3
Highly optimized events are sent to the server whenever a client performs a set of action that should result in executing server code. Events metadata are constructed of UI object Id and the action performed.

Security aspects: Events are reflecting UI behavior and never applicative logic which is uniquely handled by the server.

Flow Step 4
The server executes the event handler and sends back highly optimized UI instructions to the client. The instructions are reflecting the deltas of changes between the last balanced state and the new state.

Security aspects: Server instructions are reflecting UI changes and presented data changes, however, will never contain hidden applicative logic or data which is uniquely kept and handled by the server.

Flow Step 5
The client accepts the UI changes instructions and re-renders the parts which have changed according to the last server execution of logics.

Security aspects: The client is responsible to render UI and that is the only aspect which is affected by application logics.

From this we can conclude:

1. Client security-holes which are commonly created by either applicative or sensitive data, which is kept on the client or even simply sent to the client, are impossible by design. 
2. Client scripting cannot control the server behavior as "by design", simply because the responsibilities of the client are limited to:
• Render the UI at the control level – meaning that utilizing the XSLT, the client kernel can render:
• The entire screen – this happens only when the UI is entirely replaced.
• Specific control (thoroughly) – this happens when the control cannot be partially drawn to adjust to its new given state.
• Control Part – this is the most common scenario, in this case only the part of the control which has changed is drawn.

This responsibility is pure client side and cannot affect any server behavior. The only server’s requests which can be caused by such client action are when the rendering of whatever is rendered items require resources (i.e. images, or dynamic data). Those requests are uniquely controlled by the server code.

• Send client events to the server (yet the server has the freedom to decide which are valid events and parameters according to the current user’s  credentials)
• Those are predefined events which are exclusively handled by predefined handlers and can never affect other parts of the code or change the server behaviors.
• Any non-formatted data which will be added to those requests will be filtered by the server and might invalidate the entire request.
• Replaying requests does not affect the server behavior due to a unique timestamp mechanism.

The server centric, event-driven design results in an enterprise-level security and very high level of fine-grained control over precisely what the user is seeing - all using one programming language - standard .NET (C#, VB, etc.)
 
The main safety benefit of the "Empty Client" model is that it will be impossible to hack a web application. This means that assuming https and/or any other incredible secured communication solutions (i.e. WCF) are used to secure the HTTP communication and that the OS and DB are safe on the server side, the "Empty Client" application is thoroughly safe. 

Conclusion:

When reviewing AJAX as a concept, we must remember that it was introduced to achieve a UI that was much more responsive, using asynchronous incremental refreshes (AJAX = Asynchronous JavaScript XML), which would allow for asynchronous  refreshing of small sections or components   rather than synchronous full page refreshes which take much longer .  

The Empty Client ,does the same thing, but uses AJAX in a different way.  The Empty Client  refreshes  asynchronous uses XML protocol, and JavaScript based engine to communicate with the server.  Instead of communicating at the component level in a scattered way it communicates the incremental updates, asynchronously through one central pipeline which it creates by design. What this means is that instead of opening scattered and numerous routes to the server, it channels all communication through its centrally controlled pipeline and that is the fundememtal difference between traditionaAjax approach to the Empty Client approach. Without getting too technical, its kernel contains JavaScript and it draws on the browser using a JavaScript engine. XML is what is going back and force between the client and the server. It does refresh incrementally, just like AJAX does, but in a much more granular way. Moreover, it can refresh incrementally at the level of a single letter rather than a page or per component.

Essentially, Empty Client relies on AJAX but does all the plumbing under the hood.  It looks like a dog, walks like a dog, and wags like a dog, so it’s a dog.  It may not be traditional AJAX, but reaches the same effect with a different path.  

Despite its problems, AJAX is not the evil empire of technology.  It is not necessarily doomed, and it will not necessarily doom us or lead us to search for alternatives.  Like most things in life, we have learned that we “can’t live with it, can’t live without it.”  AJAX is vital and valuable to developers so, like every aspect of technology, we have to better understand how it was meant to be used, and utilize the solutions that are already available for resolving the challenges it presents.