Wednesday, May 24th, 2006

Reverse Ajax with DWR

Category: Comet, Java, Remoting

<p>More and more, Ajax apps are using various techniques to keep content fresh in the browser. Essentially, we’re talking about reversing the usual communication flow- the server notices something’s happened, and wants to tell the browser about it. Server “calls” browser, not browser calls server.

The popular Java Ajax framework, DWR, recently released milestone 2 towards a 2.0 release, and introduced the term “Reverse Ajax” in the process, to capture this high-level pattern. This article (via Joe Walker) abstracts the communication details behind a clean API, so you can easily switch between three different implementations of Reverse Ajax:

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) 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 long term 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.

Related Content:

  • Using DWR with TIBCO General Interface
    This simple request/response cycle example demonstrates some of the basic utilities Direct Web Remoting (DWR) provides for making interactions between...

Posted by Michael Mahemoff at 4:38 pm
16 Comments

++++-
4.1 rating from 121 votes

16 Comments »

Comments feed TrackBack URI

Why not just use a socket connection? I’ve been using sockets for my “reverse AJAX” for awhile now. Flash, Java, maybe other plug-ins can do it. I use Flash because it’s available on most computer systems. It’s funny how things are going back to the MainFrame. I never figured out whey they changed in the first place.

Comment by Phill Kenoyer — May 24, 2006

[...] Reverse Ajax with DWR: “More and more, Ajax apps are using various techniques to keep content fresh in the browser. Essentially, we’re talking about reversing the usual communication flow- the server notices something’s happened, and wants to tell the browser about it. Server ‘calls’ browser, not browser calls server. [...]

Pingback by Reverse Ajax with DWR — May 24, 2006

are we there yet?

Comment by Hubris Sonic — May 24, 2006

Totally agree with Phill, sockets which flash (esp. Flash 8) is easy, efficient and very fast. I’m not sure how this would scale, but luckely my apps will not attract many people :-) I use it in combination with Backbase and can send bxml from the server to the browser. At any time I can influence any browser that is open, move elements, execute javascript, popup layers, change text, etc.

Comment by Arnoud — May 24, 2006

Arnoud/Phill – how are you getting around firewall issues when using Flash sockets ? Are you connecting back to server on port 443 – which would normally be open ?

Comment by Nutz — May 25, 2006

Sockets would be good as a further types of implementation for DWR. (One in Flash, another Java).

Comment by Michael Mahemoff — May 25, 2006

The sky is falling …
I heard socket and Flash in the same sentence. I know a lot of Flash “programmers”, and I don’t want them connecting to my computer. They have a tendancy to be less than through. I’m going to modify my Flash settings now … maybe stick up an extra firewall or two.

Comment by Dan — May 25, 2006

[...] Highlight: Reverse AJAX with DWR [...]

Pingback by Grant Gochnauer - Blog : Technology : Foundation » Thursday News — May 25, 2006

Nutz – We have a closed customer base. We just tell them to open the port to our server. Currently we are using Aflax as our Flash socket client. The only problems we’ve ran into is getting our customers to install Flash 8.

Comment by Phill Kenoyer — May 25, 2006

Sockets (other than over port 80) may not be allowed from within corparate intranets to the internet. HTTP is then the only resort. This was one of the reasons I developed Pushlets (www.pushlets.com). Pushlets can operate in 3 modes: pull, stream (comet) and poll. Note the difference between pull and poll: with pull the server holds the request until events are available or a timeout, but the request is returned and reissued (after a random configurable time). It is like fishing: wait for an event and catch. Dependent on the application a client may use either mode (or the server may force a particular mode). Through a client library (among them JavaScript with AJAX) this is transparent to the client (they just receive events). Also event routing is tackled: broadcast, multicast (topic subscription) or unicast.

Comment by Just van den Broecke — May 25, 2006

Curious to know whether Aflax/Pushlets work well with Microsoft IIS web server and ASP – anyone using this sort of setup ?

Comment by Nutz — May 26, 2006

Just my 2 cents on refreshing every x seconds:
if there is a listener stack, and Ajax web-parts could register itself to that listener, then the listener would resfresh the Ajax web-part.

Perhaps with external modifications on shared sources, the listener itslef would have to pull the server for changes, but that’s only 1 pull instead of each Ajax web-part pulling.

Comment by Marcel Huijkman — May 29, 2006

refershing after every x seconds might not be a good idea if application is heavy loaded and being used by several users at same time.

I wonder is it possible to make an update when a system is Idle? could it be implemented at client end?

Comment by Adnan Siddiqi — March 27, 2007

complete example will do lot good

Comment by Ananth Packil Durai — April 19, 2007

DWR is cool but I expected more efficient way of using the bandwidth. I am thinking to use this technology or technique in mobile application where the bandwidth and the connection is relatively expensive. I am not even sure about the ability to keep continuous connection with the server. Anyway, I will give it a try ;)

Comment by bashar — May 19, 2007

We are using ajax using DWR and calling an RMI server through our web server. But we feel the java script code and control we use are open to the workld. Does Reverse – ajax facilitate to encapsulate the Java script code in java itself or am i wrong in understanding. Is there any working model web site or litreture we can find to test the Reverse ajax concept using DWR.

Comment by Manikandan — October 30, 2007

Leave a comment

You must be logged in to post a comment.