With Direct Web Remoting (DWR) unnecessary complexity is a bug

With Direct Web Remoting (DWR) unnecessary complexity is a bug Direct Web Remoting (DWR) creator Joe Walker talks to IndicThreads about Ajax toolkits for Java, the capabilities of DWR and the new features lined up. He feels that the key differentiator for DWR as an Ajax framework is that it is mostly about remoting and not widgets. He adds that one of the important benefits of using DWR is that unlike many other frameworks, DWR will fit with any project without the need to start from scratch.

Sangeeta Oak >> Hi Joe, Welcome to IndicThreads. Could you introduce yourself to our readers ?

Joe Walker >> I’m a developer from the UK. I’ve been a developer for years. It seems like every job I’ve had for ages has tried to stop me developing and start me writing ethereal architecture documents, but I keep finding a way to squeeze my way back into development. I much prefer Eclipse or IntelliJ as an IDE to Microsoft Word.

SO >> What is Direct Web Remoting (DWR) and how did it come about?

JW >> A few years ago there was a car manufacturer in the UK called MG-Rover. I did some consultancy work with them for a while and discovered some gaping security holes in some of their internet sites. At the same time I’d been playing with a few ideas along the lines of DWR, when I saw that DWR could help their security problems. I took some time off work to create a prototype, which they used to fix their problems, and helped me with further development.

“DWR allows you to take some Java code and make it available to JavaScript in the browser…”

DWR allows you to take some Java code and make it available to JavaScript in the browser. The code still runs on the server, but to the JavaScript developer it seems like it runs on the client. From version 2 it also allows you to call JavaScript code asynchronously from the server – what we call Reverse Ajax. (You can find out more about DWR here: http://getahead.org/dwr)

“DWR version 2 also allows you to call JavaScript code asynchronously from the server – what we call Reverse Ajax…”

Since then DWR has been supported by TIBCO, and I’m really happy to have their support. DWR is a good partner to the General Interface project which is a rich open source Ajax widget toolkit.

SO >> For a Java web developer, what is the learning curve involved with DWR? Could you list the steps involved in developing a simple DWR web application?

JW >> We consider unnecessary complexity to be a bug so we’re always looking for ways to make things easier. The current steps are – copy the dwr.jar file into your webapp, add some short boiler plate to web.xml, create a file (dwr.xml) or some annotations to tell DWR what to export, and then start coding to your new JavaScript API.

“We consider unnecessary complexity to be a bug…”

SO >> What kind of exception / error handling support does DWR provide?

JW >> Since Ajax is asynchronous, data returned by the server is sent via a callback. Exceptions are handled the same way. You can configure an error handler that is global to a page, or elect to specify an exception handler for a specific call.

“Configure an error handler that is global to a page, or elect to specify an exception handler for a specific call…”

SO >> With so many Ajax frameworks around, it’s tough to decide which one to go for. How does DWR compare with other popular toolkits like Dojo, Scriptaculous and GWT?

JW >> DWR doesn’t really compete with any of those frameworks because it’s mostly about remoting rather than widgets. Dojo and Scriptaculous are entirely client side frameworks. GWT is mostly about the client side and one that is perhaps better suited to the intranet than the internet. If you are in need of lots of widgets, you can use TIBCO GI, or Dojo or GWT, and populate them with data from your server with DWR.

“DWR is mostly about remoting rather than widgets…”

“DWR has the benefit that it will fit with any project without the need to start from scratch…”

DWR has the benefit that it will fit with any project without the need to start from scratch. So it’s ideal for having a play to see what it can do. DWR already works well with TIBCO GI, and has some Scriptaculous integration. I hope to be adding integrations with Dojo and possibly even GWT too.

SO >> How easy or difficult is it to integrate DWR with Struts, Spring and JSF?

JW >> Very easy. We’ve got integrations with all of those projects. We can remove Spring Beans, or JSF Managed Beans. Struts2’s ajax theme uses DWR for ajax validation so there is some good integration there too.

SO >> What’s the risk of an application getting locked into DWR with no hope of being able to migrate to some other framework ?

JW >> Little, I hope. If you are only calling DWR on the server from the client, you can do so without importing any DWR code at all, so it has zero impact on your code. There are other remoting libraries like JSON-RPC-Java, which, although (in my totally unbiased opinion!) are not as functional, could be an alternative.

“If you are only calling DWR on the server from the client, you can do so without importing any DWR code at all…”

SO >> What are the significant differences in the new DWR 2.0? What’s coming next?

JW >> DWR is mostly about Reverse Ajax, but there are a large set of new features like Guice integration and a clever new script scope. For full details see http://getahead.org/dwr/changelog/dwr20. We’re working on support for JMS, The Open Ajax Hub, JSON and Bayeux. I’m hoping to have 2.1 ready in the autumn.

“DWR 2.0 has new features like Guice integration…”

SO >> Any DWR success stories you are proud of and would like to share with our readers?

JW >> DWR has been used in some cool projects. Walmart, American Airlines are big examples. DWR is used by Confluence and JIRA so it’s been deployed many thousands of times too.

SO >> Thanks for talking to IndicThreads. Wish you the very best.

JW >> Thank-you for taking the time to interview me.

Related

• All Ajax development can happen serverside using the Backbase
• Seven Ajax Frameworks / Toolkits to watch out for
• Ajax technologies aren’t particularly new or sexy