DWR release 2.0 milestone 1 introduced a new term into the Ajax vocabulary - Reverse Ajax. So what is Reverse Ajax? In this article I use love, a French lesson and a donkey to illustrate the 3 main techniques for facilitating server updates to the browser as used by Reverse Ajax.

Firstly a brief recap. The Ajax that we have come to know and love is all about better user experience with the browser talking to the server and getting some updates without needing a full page refresh. This is great for updating parts of the screen in response to users in a very interactive and desktoppy sort of way.

The Problem. But what if you want to build a highly interactive application that adds updates to your page as soon as someone half way around the world updates theirs? What if you are in a CMS interface and you go to check out some content and find your colleague in marketing checked it out 2 minutes ago, but the page you are looking at hasn't been updated since then? What if you are writing an article on Reverse Ajax using Writely and your technical editor just updated the paragraph you were going to work on? These are essentially monitoring and multi-user applications.

The browser does the asking. The problem is that web servers can't easily contact web browsers. For one thing firewalls will get in the way, and even if they didn't, browsers only listen for answers to questions they've asked. So how is the web server to get the message through?

Essence of reverse Ajax. Answering this question is the essence of reverse Ajax. It is the means by which updates can be pushed from the server to the browser. Sure, techniques for doing this already exist and have cool names (see below), but Reverse Ajax ties them into a neat package and puts them more readily at the disposal of the developer.

3 techniques. So what are the 3 main techniques that Reverse Ajax brings together?

1. Polling: This is where the browser makes a request of the server at regular and frequent intervals, say every 3 seconds, to see if there has been an update to the page. To illustrate imagine a 5 year old (or a donkey - obscure Shrek reference) in the back of the car shouting 'are we there yet?' every few seconds and you get the picture.

2. Comet, long lived Http, or the slow load technique: Are all names for the same thing. As already mentioned, the server has to wait for the browser to make contact. But this technique allows the server to start answering the browser's request for information very slowly. Extremely slowly. Actually in the same way I used to answer my French teachers at school, it starts the reply but never actually finishes. This allows the server to keep a communications channel open (unlike me and my French teacher) to pass down additional information when the time comes. The closest we currently get to a server push. See Alex Russell's article for the coining of the phrase and outline of definition of Comet. See Bryce Nesbitt's for a brief description and simple demo of slow-load.

3. PiggyBack Technique: Here the server, having an update to send, waits for the next time the browser asks it a question and... pounce, sends the answer and the update. This technique is well understood in relationships and is usually preceded by 'and another thing.' You know, you ask what you thought was a straight forward question and get a lot more than you bargained for!

All of these are valid ways of the server updating the browser. Reverse Ajax describes a technique for using whichever of these is on offer and sending Javascript directly to the browser for it to execute.

Where now? ~ An Introduction to Ajax ~ The main Ajax Article on CMSWatch