AJAX application Architecture, part 1th

Whether you are a system administrator, a designer, or a developer, your work will be greatly influenced by AJAX. Administrators must ensure that security protection is high enough to handle various possible new types of attacks. The Intranet administrator must ensure that JavaScript is not disabled on any browser. Web designers need to face some new challenges, because the functionality that AJAX can implement is not previously achievable or impractical. Developers, however, need to familiarize themselves with new APIs and new, comprehensive programming methods. Still, what does AJAX mean to architects?

AJAX applications are challenging because they introduce new concepts and new basics. AJAX patterns are across the client and server environments, so the architect role is essential. A clear architectural vision is important for determining the logic that occurs on the client and handling content that is reserved on the server, and determining which data objects on the client and server can be exchanged.

AJAX comes in handy.

A static page that the WEB was originally used for sharing information. In a few short years, it developed into a more dynamic medium. Today, the Web is made up of highly interactive pages, but it still relies heavily on patterns that are based on full page transformations. The more users interact with the page, the more frequently the pages must be created and returned to the user's browser. There are a lot of negative results from using interactive pages in this way, such as slowing page refreshes and flashing. This is an imperfect solution that often leads to a bad user experience. AJAX makes for a very desired change in this pattern, which allows for more concise WEB applications and lays the groundwork for generating new applications. AJAX is the end user core. With AJAX features, WEB applications become more interactive, responsive, faster, and friendlier. Interaction and response (feedback when the operation is slow) are handled more appropriately, making it easier for users to do more with the page. In short, users get a better experience.

With AJAX, more code is executed on the browser, which requires more scripts to be assigned to the client page. However, this leaves some big problems to be solved. What kind of script? Who will write this script? What architectural principles and patterns do this script follow?

In this column, I'll introduce AJAX from an architectural perspective, helping you, developers, and architects make informed choices. At the same time, I will provide designers and administrators with enough contextual information to make their work easier. This is a fairly large subject, so I'll divide it into two parts. Please do not miss next month's column, I will continue this discussion.

AJAX Architecture

If you want to consider AJAX, take a look at Figure 1, which illustrates the architectural implications of this step. Traditional WEB applications need to perform all operations on the server, and the application only occasionally emits scripting code to run tasks on the client, such as processing data validation.

Figure 1 Traditional Web mode vs. AJAX mode (click the image for a larger view)

AJAX applications use the client framework that is responsible for making calls to the Web server. The AJAX server-side framework is responsible for requesting a data feed and returning it to the client. This is typically a JavaScript Object notation (JSON) data stream, but other formats, such as XML, RSS, and CSV, are also available.

The client receives the data feed and uses JavaScript to update the UI. The server responds to the request by returning the original data encoded in the specified format. Bandwidth consumption is minimized, application speed increases (because less time is required to complete the request), and UI updates can take effect without visible postbacks. However, while solving many problems, the increase of operation on client also brings new problems, such as new coding practice, new security hidden trouble, accessibility problem, etc.