Everyone has one or two words or phrases that people associate with them. For example, I always think of my friend Rob eating squid when I hear the words "What do you mean it's not chicken?" Just thinking about those words is enough to transport me through the years to that moment. And the look on his face still makes me smile.

Of course there can be some painful associations too. Like the words "I could code it in about an hour," which will forever remind me of a former manager who was fond of boasting about his prowess as a developer. The fact that he could barely turn a machine on never entered into it. In his mind he was the greatest developer who ever lived and the fact that some tasks took others more than an hour only served to reinforce his belief.

Somewhere between these two poles are the feelings I get when I hear the words "It doesn't blink." That was what the guy kept saying over and over again as I demonstrated an AJAX application. What this person, who remained true to his mainframe roots, was attempting to say was that the page wasn't going through the normal unload/reload cycle.

Because I'm not fond of being kept in the dark myself I made an effort to explain how the application worked. It went something like this: "Instead of using the browser's standard unload/reload cycle to communicate with the Web server client-side JavaScript uses the XMLHTTP request object to communicate directly with the server. This means that less information is passed back and forth so that this kind of application is inherently faster than a traditional Web application. It doesn't 'blink,' as you so put it, because the client-side JavaScript is only updating the parts of the page that changed instead of the whole page."

This was several years ago, years before Jesse James Garrett's AJAX article, and looking back now I suppose I expected too much of most of the people in the room. For some reason I expected immediate acceptance of the application I had written by everyone there. My expectations were dashed when the "it doesn't blink" guy latched on a single phrase like a pit bull, the phrase was, client-side JavaScript.

Because of this phrase, the mainframe developer, still reeling from the job market downturn after Y2K, uttered a phrase of his own in the form of a question, "So, it's a mockup?"

"No, it's communicating with the Web server using client-side JavaScript and the XMLHTTP request object. It's a working application," I replied.

"But it doesn't blink!" he said.

This banter continued for about two hours and would probably still be going on had one user not made a suggestion. He wanted the application to look up a specific item of information. So we did. When the information was displayed in the Web browser, he uttered a remark of his own, "It's not a mockup."

The user elaborated by saying that he had entered the information we displayed five minutes before the meeting began. He earned a glare from the mainframe developer and my undying gratitude.

Until recently scenes like this were pretty much par for the course when demonstrating AJAX applications. But now, since Garrett's AJAX article, everyone wants to jump on the AJAX bandwagon. The rapid adoption of AJAX leaves only one question: other than using the XMLHTTP request object how does one go about writing an AJAX application?

Unfortunately, there's no simple answer, but there's a way to make the question simpler by concentrating on one aspect of it. Look at the problem as putting a Web front-end on a Web Service. So, since we're hip-deep in Web Services - or at least books and articles about how to create Web Services - let's look at creating a pretty front-end for a Web Service.

Because most Web Services use SOAP, the Simple Object Access Protocol, we'll start by looking at the SOAP request:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getItems xmlns="http://tempuri.org/">
       <guild_item_id>string</guild_item_id>
       <guild_id>string</guild_id>
     </getItems>
    </soap:Body>
   </soap:Envelope>

As incomprehensible as the above SOAP request appears to those unfamiliar with the protocol it's actually quite simple. Most of what you see above is a wrapping that identifies it as a SOAP request, essentially any element with the namespace "soap." The stuff that works with the Web Service, getItems, is with the soap:Body tags and it invokes a Web Service named date passing the value "string" in the guild_item_id and guild_id parameters.

All right, now that we know what to send, the next question is how to create an XMLHTTP request object on the client-side to send it to the Web server? This is one of those times when a line in my old resume comes into play. No, not the one about being an escaped mental patient, the one about cross-browser development, which is roughly the same thing. Yes, there's Microsoft's way and then there's everyone else's way.

Why do I feel like I just said a bad word in the pages of LinuxWorld? I feel dirty.

One of the differences between my favorite browser, Firefox, and Internet Explorer is something called ActiveX. Only Microsoft uses it, so it can't be found in Firefox, Flock, or SeaMonkey. And that means that a little more coding is required to consistently create an XMLHTTP request object. What we end up with is code like this:

try {
     objXMLHTTP = new ActiveXObject('Microsoft.XMLHTTP');
}
catch(e) {
     objXMLHTTP = new XMLHttpRequest();
}

Not, bad, but to quote Michael Kane, "What good is a mace if you don't use it?" But before we use it let's take a look at all of the bells and whistles that go along with it (see Table 1).