Basically what DWR does is, it's a way of taking Java classes and making them easily usable from JavaScript. You take a Java class, you say to DWR "we would like to export this" and DWR will create you some stubs so you can call it from JavaScript - it'll do all the marshalling and that sort of stuff. The idea is pretty much any Java method, you can call that from JavaScript, and it will marshal pretty much anything, so all sorts of collections of maps, strings, integers, even things like DOM models will come across onto the browser for you to use there. That is really the basics. There is also a small DHTML library to allow you to manipulate the page with the results. DWR isn't really about widgets, but we do a bunch of stuff to help you get your data on the page, basically.
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.
Yes. What we described so far is the basics of DWR 1.0 - It's all about going from the browser calling the server and now we're doing it the other way around. The idea is that you will be able asynchronously on a server to push commands out to the browser. So it very simply enables you to say, "get me all of the browsers on this page" or "give me this particular browser", and then say "I would like all these browsers, or that browser, to do this thing - here is a command for them" -- that is the basic here, really. I guess the next step on from that is we have got a set of APIs in Java that mimic APIs in JavaScript -- the initial one at the moment is the script.aculo.us effects API as well as the DWR DHTML manipulation library.
It enables you to do things like, the obvious example everyone uses is the chat application. When somebody types something in on a message box you can say, "get me all the other browsers looking at this page and add this message to the list." and there's a Java API to let you do that page manipulation and it will automatically convert all the primitives from Java types into JavaScript types and pass that out to all the browsers looking at that page. So all of the browsers will dynamically change with a single Java command, which is quite nice. So not only do we do this with the DWR Util page manipulation library, but also with some script.aculo.us effects, and I guess one of the neat things going forwards is seeing all the other different libraries that we'll be able to do in the same way and it will be great; I guess the initial ones we'll be looking at is TIBCO GI and Dojo, Yahoo! User Interface Library, etc. , there is a whole bunch of things that it would be really interesting to remote control.
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.
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.
It's different than Google Maps, obviously it's a smaller area, but there is more data, there is more overlays, so you have got tube stations, there is more information about buildings than there is in Google Maps. It is restricted in terms of, it is not the whole of America, so it is not really a competitor to Google Maps, but that is quite a neat example of someone that uses DWR. We have just been doing some work; we think it should be possible to publish binary data from Java into JavaScript. We didn't quite finish proving that it's possible yet, but that will allow us to do some neat ways of dynamically generating graphics on the server and having those appear on the client, if we can get it working. I haven't been doing a lot of the work on that, but there are some smart guys that have been saying, when I was saying:" Oh, I am not sure", they were saying: "You know, we're sure." so that is going to be very cool. That will give some really nice abilities to dynamically generate stuff and have them pushed out.
9. Could you tell us a little bit about the new Spring integration that you guys are working on?
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.