Our AJAX-enabled page is ready. The complete working example is available at: www.ajaxmaker.com:8080/blog/zipsearch.htm.

Remote Scripting - An Alternative Approach
Some older AJAX implementations are based on so-called remote scripting. The idea is that the user's actions result in querying the server via IFRAME, and the server responds with the JavaScript, which is immediately executed as soon as it reaches the client. This is a big difference compared to XMLHttpRequest approach, where the server responds with the data and the client interprets the data. The advantage is that this solution supports older browsers.

The HTML portion of the IFRAME-based example (see Listing 2) is similar to the one we've used in the XMLHTTPRequest scenario, but this time we'll introduce an extra IFRAME element - controller:

Zip:<input id="zipcode" type="text" maxlength="5" onKeyUp="zipChanged()"
style="width:60" size="20"/>
City: <input id="city" disabled maxlength="32" style="width:160" size="20"/>
State:<input id="state" disabled maxlength="2" style="width:30" size="20"/>
<iframe id="controller" style="visibility:hidden;width:0;height:0"></iframe>

We keep calling zipChanged() per every key stroke, but this time the function ask(), called from zipChanged() (see Listing 3), sets the IFRAME's src property, instead of invoking an XMLHTTPRequest:

function ask(url, fieldToFill, lookupField)
{
   var controller = document.getElementById("controller");
   controller.src = url+"&field="+fieldToFill.id+"&zip="+lookupField.id;
}

The server-side logic is presented by a sketchy resolveZip.jsp (see Listing 4). It's different from its XMLHTTPRequest counterpart in that it returns JavaScript statements, which set the global values of the variables field lookup and city and the call function response() from the global window's execution context as soon as it gets to the browser.

The function response() is a modified version of the handleResponse() which is absolved from dealing with uncompleted requests (see Listing 2.)

The Fine Print
For simplicity's sake, we've "overlooked" some important issues in our sample code:

1.  The fact that the instances of the XMLHTTPRequest object and callback invocations haven't been destroyed after being used, which causes memory leaks after every call. Properly written code should destroy or reuse such instances in the object pool. Object management techniques common to the server software have to be used for the client

2.  In quite a few places the errors weren't handled properly. For example, the call to request.open() in the method ask() can throw an exception that has to be caught and processed even though JavaScript exceptions don't have to be checked. The handleResponse() function is another example. It has to check headers and responseText for possible server-side and communication errors. In case of an error, it has to try to recover and/or report an error. Properly developed AJAX applications eliminate loosing data on "submissions" due to disconnects and other low-level communication problems via a robust, self-recovering framework.

3.  Current server-side frameworks provide quite a few functions that have to be reconciled with a refresh-free approach. For example, let's consider a custom server-side authentication with a timeout. In that case we'd have to intercept security system response to the XMLHTTPRequest calls, bring up the login screen, and then re-issue the request after the user was authenticated.

All these problems are typical of any application code working with low-level APIs and all of them can be resolved. The good news is that the technologies needed to resolve these issues are quite familiar to most Java developers like Web Services, custom tags, and XML/XSLT. The only difference is that nowadays these technologies come to the rescue on the client in the form of:

• Web Services using SOAP/REST/RPC for a simple communication standard
• Client-side custom tags for packaging rich client-side controls with integrated AJAX functionality
• XML- and XSLT-based data manipulation

Summary
The AJAX approach offers a rich Internet experience on a par with that of desktop applications. AJAX features have to be applied selectively: you definitely don't want your credit card charged by the background process while you're still shopping. Is AJAX momentum sustainable? We certainly hope so. We've been developing AJAX applications for the last five years and can attest that it's sound and very effective. However, it requires that a developer be exposed to a much wider set of technologies than the ones used in the traditional "click-refresh" Web applications.