The Servlet mapping in WEB-INF/web.xml can look like this:

The WEB-INF/dwr.xml can look like this, and I will follow up on this later.

On the client side, in the JSP or HTML page, calls to server side Java go though the AJAX JavaScript bridge. The JavaScript code for the bridge is in engine.js, util.js, and custom files generated dynamically corresponding to the exposed Java classes. Therefore, you need to include at least these files in your pages.

Ex.

<script src='http://tcftc.com/[WEBAPP-NAME]/dwr/engine.js'></script><script src=’http://tcftc.com/[WEBAPP-NAME]/dwr/util.js’></script>

JavaScript to Java via AJAX

For the purposes of this article, I am using the Eclipse IDE and Tomcat application server, but any modern IDE and Java application server can work with the DWR. I set up a simple web application and several POJO classes, with one "exposed" for Direct Web Remoting through dwr.xml. When all correct JavaScipts are included on the page, the exposed class and its methods are "allowed" to be invoked from client-side JavaScript.

<allow>   create creator="new" javascript="ItemManager">   param name="class" value="model.ItemManager" />   <include method="findById" />

In the client-side JavaScript, methods from ItemManager will be invoked asynchronously by using AJAX.

For example:

ItemManager.findById(handleItem, 1);

Note that the second parameter is the ID, and the first is a callback function that will be invoked when the response comes back with the data from the server.

The test client provided by the DWR Servlet also let you invoke methods, but it is a visual interface that hides the true method signature, and can only verify if the correct result returns. Nevertheless, it is a very useful tool (see next section).

Here is the flow diagram:

The parameters, such as ID, are JavaScript values that are sent to the server where only Java is executing. After the Java method returns data, the Java values are translated by DWR into JavaScript and are passed into Callback functions on the client side. There are some limitations as to what type of data can be converted from JavaScript to Java (and vice versa) as method parameters. The current version of DWR also has issues with overloaded Java methods. Because JavaScript does not support overloaded methods, a JavaScript file generated from a class that has overloaded methods will contain two methods, the second of which will replace the first.

Testing DWR

The DWR Servlet is very robust. It can output dynamic JavaScript code, it can correctly route Ajax calls, and it can even be used to debug the DWR logic. The debugging and testing functionality is conceptually similar to some implementations of Web Services test clients provided by different application sever vendors, such as BEA or IBM.

Recall that the DWR Servlet was mapped under the dwr pattern in the web.xml file.

<url-pattern>/dwr/*</url-pattern>

Client JSPs (or HTML files) can request dynamic JavaScript from the server by referencing this name in the path.

Also, recall that in the dwr.xml file there is a definition to expose ItemManager class.

allow>
   <create creator="new" javascript="ItemManager">
   param name="class" value="model.ItemManager" />

To use this object and its methods on the client page, DWR exposes a corresponding JavaScript file generated dynamically, when the client requests a specially defined URL from the server (via the dwr pattern path). The Servlet will generate and output this file on the fly.

The general format for the dynamic address is:

/[WEBAPP-NAME]/[MAPPING-NAME]/interface/[CLASS-NAME].js'

In the <script> tag, this address is set as the src attribute’s value. For example:

<script type='text/javascript'
src='http://tcftc.com/[WEBAPP-NAME]/dwr/interface/ItemManager.js’></script>

Including this in your page is perfectly valid and if you call this address directly, you will see the actual JavaScript code, even though this file does not exist on the server.

If you want to debug/test the DWR calls, the DWR Servlet needs to be in debug mode in the web.xml file. To enable debug, set the parameter for debug to true. Note that this is probably not desirable in production because it shows all available methods of the object to the client.

<init-param>
   <param-name>debug</param-name>
   <param-value>true</param-value>
</init-param>

To see the test client point your browser to

/[WEBAPP-NAME]/[MAPPING-NAME]/

This will show all exposed objects, and if you click on the object name, you will see available methods-both exposed and not exposed by the DWR.

Only exposed methods are callable directly on the test page.

Notice that the methods defined in the dwr.xml are active and some methods even take parameters.

Considering that this is all auto-generated for you by the DWR Servlet, using this technology becomes trivial. The test client even pre-generates the JavaScript includes needed to use the exposed objects.

Conclusion

In this article, you looked at Direct Web Remoting (DWR)-a unique way to use AJAX and call Java on the server from the client side. This technology is conceptually similar to the Web Services implementations, but designed only to work with Java and JavaScript. Currently, DWR is popular and continues to gain popularity. The technology is stable, albeit with some limitations, has good documentation, and is straightforward to set up and use. If you are looking for a way to expose existing Java code to clients, and do not want to deal with complexities and incompatibilities of Web Services toolkits, you should definitely take a closer look at DWR.

Download Source

Download the source code for the article here. The author would like to acknowledge and thank James Harmon for his contribution of the source code.

Reference

DWR: http://getahead.org/

About the Author

Vlad Kofman is working on enterprise-scale projects for the major Wall Street firms. He has also worked on the defense contracts for the U.S. government. His main interests are object-oriented programming methodologies, UI, and design patterns.