10 things IT needs to know about Ajax

The introduction of any new Web technology will affect a network's infrastructure in ways that range from inconsequential to earth shattering. Ajax is one of the more disruptive new Web technologies traveling across networks today. To help you minimize future surprises on your network, we've outlined the 10 things you should take to heart about Ajax. (Also see our slideshow illustrating tips for deploying Ajax applications effectively.)

1) Ajax is an idea, not an acronym

While Ajax commonly is spelled out as Asynchronous JavaScript and XML, the full name is not entirely appropriate because it oversimplifies the history of the technology and the implementation options that lie at its heart. More exactly, Ajax encompasses the idea that Web applications can be built to opt out of the typical post-wait-repeat cycle used in server-side-focused Web applications. Ajax lets Web applications move to a more responsive, continuous, but incremental style of updating. Ajax provides users a richer, more interactive way of experiencing the underlying Web application. This goodness for the user might mean that more monitoring and security oversight might be required of network professionals, as well as, potentially, server and network alterations.

2) It's really all about JavaScript

Ajax applications are written in JavaScript and usually rely on the XMLHttpRequest object for communications, which is making its way through the World Wide Web Consortium process. Because, like many Web technologies, it now is only an ad hoc industry standard, notable differences can be found in various browsers' implementations of it. It's also possible to use other data transport mechanisms — with and without widespread industry support — with Ajax applications, including traditional frame and image-cookie methods, as well as the use of binary bridges to Flash or Java.

Regardless of the transport approach used by the developer, Ajax has raised JavaScript to a more important position within a Web application than it previously held. JavaScript now is responsible for important data-collection, communication and consumption duties, so it no longer can be treated as a second-class Web technology without serious repercussions.

Developers who think the JavaScript technology is toxic can try to avoid the language by having a tool or framework generate it from some other language like Java (Google Web Toolkit, for example), or hide the code behind components or tags (such as with .Net or Ruby). At the end of the day, however, JavaScript still will be in the application. It's better to understand the language and embrace it directly, because if you are going to use Ajax, you ultimately are using lots of JavaScript.

Ajax is intertwined with the network, so bad code is going to mean lots of troubleshooting by network administrators, as well as developers: The bottom line is to encourage good, network-aware coding! The same organizational "rules and tools" -- coding standards, testing regimes and source-code control — that are in place for other languages must be applied to JavaScript to ensure that Ajax applications are supportable and robust.

3) XML is not required

Despite the "x" in the acronym, Ajax does not require XML. The XMLHttpRequest object can transport any arbitrary text format. For many Ajax developers, JavaScript Object Notation or even raw JavaScript code fragments make more sense as a data format, given that JavaScript is the consuming environment. For direct input into documents, other developers may favor raw text or HTML fragments. Still others will use such data formats as the less-known YAML markup language or such old standbys as comma-separated values.

Of course, it is possible and certainly reasonable to use XML, but it is far from required. Using binary formats for uploading files is not supported yet by the XMLHttpRequest object, but considering that Flash uses a binary format called Action Message Format, it is likely that similar features will be found in Ajax applications soon enough. You should know which format is being passed around the network, because it isn't always XML. Also, make sure you can analyze the format for performance and security.

4) Plan for an increase in HTTP requests

The most obvious issue for the network administrator supporting Ajax applications is that the architectural programming pattern has changed the network utilization of Web applications from a batch-like, somewhat infrequent response of a few hundred kilobytes, to a more continuous exchange of smaller HTTP responses. This means that network-bound Web and application servers may find themselves even busier than before. What Ajax will do to your server and network utilization certainly will depend on how the application is built — make sure your developers understand the network impact of their applications.