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.
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.
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?
The benefits for developers and for enterprise level AJAX applications
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.
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.
- Events versus Requests and Response Events
Although events were introduced into web environments, they did not match their desktop counterparts, which forced developers to add 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 forced the developer, yet again, to deal with the need to use requests and responses in order to implement his application. Desktop developers, on the other hand, were always given a fully event driven environment, making their development tasks much simpler.
Programming a file explorer-like application was for them as simple as dragging a tree view and a list view and implementing a few event handling methods. This contrasts to web developers who have had to deal with exposing services and consuming them and, of course, doing everything using client-side scripting on the browser.
- Forms versus Pages
Web developers are familiar with the concept of a page, which originates from the early days when such pages were static resources that had links to other pages. The concept of a page is excellent when you are implementing a web site, but leads to a lot of work when you are creating applications. Take, for example, a dialog scenario, which is implemented over the web using two disconnected pages bound together through a client side script.
Imagine that creating a dialog was as simple as creating an object, calling its methods, and setting its properties. This is exactly how desktop developers see dialogs. This concept is called forms. A form represents a window which can have child forms, which are windows as well. It sounds outrageous that when you create a page it needs to have 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. This is in comparison to the desktop developer who simply creates an object.
When you are working in a single object oriented layer, you are also able to implement many useful design patterns, such as the observer design pattern. This means that when objects need to interact with each other they only need to post an event to the form and other objects will subscribe to that event saving you the hassle to explicitly bind events between controls. Just to highlight the difference, the same task in the web scenario would require multiple cross referencing scripts.
- Form Designer versus Text Editor
It is only natural that in a web environment, application design will take the form of a text editor. Originating from content authoring, web development environments require the flexibility of a text editor. The web development editor usually provides a mechanism for adding controls, while most of the layout is done via code.
Desktop environments, on the other hand, have always kept it simple. Their dedicated nature enabled them to provide very productive designers, allowing developers to really design their application with no need for hand coding whatsoever. Using concepts like anchoring and docking, they can lay out controls exactly how they want it.
Programming a complex dialog, using desktop designers, is as easy as using a Power Point application. This provides desktop developers with the ability to rapidly develop and, if need be, change their dialogs. Changing the layout, in web environments, usually requires a great deal of headaches to the web developers which are required to recode large tables to implement the new layout.
- Single Language vs. Multiple Languages
Web developers must master many different languages in order to implement a web application. There are multiple server side pages, interacting with multiple script files and CSS files, which are required to work together as a well oiled machine. To spice up the web development task, it must also be done in multiple layers, which add a greater level of complexity. It is common knowledge that the more application parts, the more work you must do to develop and maintain your application.
Desktop developers, on the other hand, use a single compiled language to manipulate a well defined object model, which dramatically reduces the complexity of their applications.
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:
- 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.
- The server exclusively handles interaction with data and other services.
- The client is responsible to render UI and send events to the server; in any case it can never control the server’s behavior.
- 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:
- 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:
- 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.
- 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.
- Render the UI at the control level – meaning that utilizing the XSLT, the client kernel can render:
- 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.
- 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)
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.
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.