Bio Joe Walker is a developer and consultant working on advanced web development techniques like Ajax. He recently developed DWR which has become the most popular AJAX toolkit for Java by making browser/server interaction intuitive for web developers. He currently works through his consultancy, Getahead Ltd, which is supplying a growing number of customers with AJAX and advanced web solutions.
It would be very easy to rail against all the browsers because they are all broken in so many different ways. To be fair, broken is not really a fair description because none of them were really designed to do this in the first place, so they all have very different quirks. The real challenge of AJAX development is working your way around all the browser incompatibilities; the job for me is to make sure that users don't face that problem - that's my problem. So that is the biggest challenge really.
Basically there's 3 routes for getting data from the server to the browser. Obviously the core problem is it's the browser talking to the server all the time and not the other way around; there's all sorts of reasons why you can't just call out to the browser. So there are basically 3 routes: Comet, polling and piggyback. The easiest one is polling. polling is when you get the browser to periodically say: "Have you got anything for me?" which does OK for lightly loaded applications - you can get yourself into a storm if you are not careful. It is nice and simple and it will work with pretty much any browser. The next optimization is to do Comet where you are holding open a connection. So the browser says: "Have you got anything for me?" and the server just waits and doesn't answer and when the server does have something it pushes it down, but it keeps the connection open.
So that gives you really good responsiveness, the server can push a message to the browser and it will be there within milliseconds. The downside is, in a heavily loaded application you are going to have the problem of lots of threads open on the server. So we've got integrations with things like Jetty to drop the connections and reuse the threads so we can keep something open on the server, without actually tying up a thread the whole time. I will be looking to make that thing work on more, Tomcat, WebLogic etc as time goes on, because they have all got ways of doing a similar kind of thing. So that's two methods. The third method is what we call piggyback which is simply, we wait for the browser to come and ask some other question and we kind of slide the answer in on the result somewhere. And DWR tries to manage whichever is the best message for you. You can configure it in various different ways but you shouldn't really need to know which method is going on under the hood. You can change from one to another without changing anything else.
It is fantastic for DWR from a future point of view. I think reverse AJAX is the hardest thing I have ever had to get working; it's multithreaded because you have got several browsers coming in at the top at the same time and you can have two connections from the same browser, even from the same window, and you have got different threads coming out from the bottom at the same time and then you got to cope with all of the weirdnesses of the various different app servers down there and all the weirdnesses of the browsers up there, so it is a nightmare to get right and we have been in release candidates for quite a while, it has been basically working for quite a long time but there is always some other weirdness you have got to iron out. We would never have got where we are now, which is very close to a release, without TIBCO support, because they are supporting me developing it, but we are also working on integration with GI; we have got a basic integration going at the moment, where we are using the OpenAjax hub as a way of having events on the server published through the OpenAjax hub to TIBCO GI. So it is a great way of doing interactions between the browser and the server; you can have two basically disconnected applications, they don't have a great tie on each other, they are just publishing events, so it is great for things like testing and that sort of thing. We have got a little application that demonstrates DWR publishing stuff out to GI and yet the two applications don't know about each other, they just sat either side of the OpenAjax hub.
The answer is no. We are going to carry on supporting them, definitely. Particularly TIBCO want me to carry on supporting Dojo, it's a goal, They are going to help me do it. To a large extent these guys are not competing with GI, and GI is about providing intranet applications that are very rich and it is not generally for deployment on the Internet, you can do that, but mostly it is a kind of intranet based system and Dojo is in a different area. A great example, TIBCO have published examples of how to make GI work with Dojo so there is not that antagonism there that you might think there is at all and we are all part of the OpenAjax Alliance. I think really the number of problems to solve, they are great enough that we are not fighting over them, the game is too big, there is plenty of space for us all.
I don't know about other IDEs; the NetBeans is just great. They have just updated it again today, they have got some Struts they have added into it as well. I'm all for that sort of thing and I think it is great that Sun has put the effort into doing that.
8. What is the most innovative application you have seen make use of DWR? I hear a lot of developers circles say "We are using DWR to let us do all kinds of interesting things." What is the most interesting thing you have seen with it?
I think the biggest application I can think of, which is not interesting in a flashy kind of way, Wal-Mart have a very big web store. They are a massive company and what is good about the Wal-Mart thing is it's not a rewrite, they've just added some bits of functionality -- they have got a "more info" button and that uses a bit of DWR to get you more information about whatever the item is you are thinking of buying. So that is a great example of small scale integration -- big stuff, all sorts of infrastructure behind there and you just have a few tweaks to get DWR running in that so that is pretty cool. As far as more flashy goes, New York City have created a mapping application, a bit like Google Maps, but that uses DWR as a way of interacting with the server and changing how the data is displayed.
Yes. There is quite a few new bits of integration with DWR too, as far as the back end goes -- Spring is the biggest, I guess. You could always export Spring beans by DWR, but there's now a Spring namespace, so that you can ditch all your DWR config files if you want and keep your Spring config file and within your Spring config file say: "Oh, by the way, this is for export using DWR", which is quite neat. We have beefed up quite a few integrations and DWR now by default comes with RIFE, if you want to do AJAX within RIFE, you are going to be using DWR. We have done quite a few tweaks with, we talked to Struts, we talked to JSF, we have got some new stuff with WebWork and in fact WebWork 2/Struts 2, comes with DWR as well, as a way of doing AJAX, so there is a bunch of interesting stuff going on with interactions on the back end as on the front end.