Technological Thoughts by Jerome Kehrli

I discovered DWR recently and I believe it to be an amazing breakthrough in the world of HTTP client-server comunications.

First what is DWR ?

DWR stands for Direct Web Remoting - Easy Ajax for Java.

DWR is a Java library that enables Java on the server and JavaScript in a browser to interact and call each other as simply as possible.

Quoting the official website :

"DWR is a RPC library which makes it easy to call Java functions from JavaScript and to call JavaScript functions from Java (a.k.a Reverse Ajax)."
Read this : http://directwebremoting.org/dwr/introduction/index.html.

What's the point ?

Yes you can actually call your server-side Java code from within client-side Javascript code just as if it was in fact some other Javascript code located just aside and definitely not remote code in a foreign technology located on a server far away. Using DWR, you get the illusion your java environment on the server side and the Javascript environment on the client side suddenly and magically got merged together in a single client side Javascript environment.

Even better, using long-poll HTTP requests (recently renamed COMET or Piggy-back HTTP requests or even reverse-AJAX thanks to happy marketing efforts), you can get as close as possible from real server pushes where the Java code running on the server issues RPC-like calls to the client side Javascript code.
Pretty nifty, huh ?

And all of this of course is done (almost completely) transparently. The Javascript code is not aware that the Javascript stub it calls actually forwards the call to some sort of Java server somewhere, no. You can program your client-side Javascript application just as if the server-side business logic actually stands right there on the client-side.

Obviously real-life scenarii suffer from some limitations. For instance, for this to work efficiently, a thorough SOA design is required on both sides to minimize round-trips between the client and the server.

Why is it cool ?

It's cool ... because it's quite obviously cool. Let's look at the alternatives:

For ages we have been using CGI scripts, then PHP, then even JSP or lately JSF or any other crappy technology alike to build dynamic web applications. I'm sorry fanboys but all of this sucked a lot : complete mixture of concerns and technologies in the same file (some must be thinking this is some sort of good pattern), steady learning curve (got to know HTML, Javascript, CSS, PHP or JAVA, taglibs, etc.), hard to debug, huge network bandwidth consumption (90% of it being presentation stuff, no data), and many other reasons.

Then some smart boys came up with AJAX ... Well XMLHttpRequest actually is a good thing (although it's just an easier way to do just the same thing others were doing with hidden iframes since ages).
Anyway, it made (a)synchronous (or at least hidden) server calls easier and enabled client-side Web developers to build Web GUIs acting a little bit more like real GUIs : a single page is loaded, ït builds a GUI and then interacts with the server using artificial, hidden and (a-)synchronous method calls. This definitely was an improvement for two reasons: first it enables a much richer user experience with much more dynamic interfaces where only sub-parts can change and evolve depending on the user interactions. Second, the developer work is made easier as the GUI is built within a single technology, although different languages: Javascript, DOM (HTML) and CSS.
Most of the time, the client-side interface is built using high-level Javascript libraries such as Bindows or DOJO. With such libraries the building of a Web GUI becomes almost as easy as a rich-client GUI.

But let's face it, there is something with all of this still far from ideal. The problem comes with the XML in XMLHttpRequest. Why the hell should one bother to marshal / unmarshal XML in two different technologies (client-side Javascript and server-side PHP, java, etc.) ? There are cases where Web-services make sense, for instance when a .NET GUI needs to communicate with a Java backend. Both technologies offer several tools to simplify Web-services integration and make them an appropriate choice.
But guys, let's be honest, this very example really is the only one where Web-services make sense. In every other technology combination, especially within Web application where one side is written in Javascript, there is always a way better alternative to XML. In our case it's called: JSON.

JSON stands for Javascript Standard Object Notation. Doesn't it ring a bell ?
Happily, a lot of web developers understand this perfectly nowadays and JSON/RPC is becoming a de-facto standard for cutting-edge modern web developments. The server side backend usually relies on simple REST services and that is a huge simplification as well over the overwhelming complexity of Web-services.

And this is where DWR kicks in. DWR over-simplifies the complete development process for web application build around REST services and using JSON/RPC as the data exchange format. As I stated before, DWR offers such a high level of abstraction around those REST services that the Web developer really completely ignores every REST, RPC, marshalling, etc. concerns. She calls the services as if they were plain-old Javascript objects written in Javascript and standing at the client side.
Really cool.

And this is where I believe is the paradigm shift. DWR makes it feel like the client-server separation vanishes. It really feels like everything now stands in one single unified place at the client side.

How does it work ?

DWR consists of two main parts:

• A Java Servlet running on the server that processes requests and sends responses back to the browser.
• JavaScript running in the browser that sends requests and can dynamically update the webpage.

DWR works by dynamically generating Javascript based on Java classes. The code does some AJAX magic to make it feel like the execution is happening on the browser, but in reality the server is executing the code and DWR is marshalling the data back and forwards.
DWR used JSON to transmit the data over the network to the server. On the server sides it provides the completely JSON to Plain Old Java Object serialization system.

Every Java object which is intended to be available for remote method calls on the client application should be declared in the dwr.xml configuration file. DWR then generates the Javascript stubs taking care of the marshalling of the arguments, the remote over HTTP and the unmarshalling of the results. It can be used on a wide range of browser as it supports several way to actually implement the HTTP call: usually using an XMLHttpRequest object, but it can also use hidden iframes in case XMLHttpRequest is not available.

DWR can serialize a complex graph of objects from Javascript to Java and back as well as every sort of collections, exceptions, etc.