DWR Java AJAX Applications: A step-by-step example-packed guide to learning professional application development with Direct Web Remoting

The main feature of DWR is its ease of use. DWR hides a lot of details from developers. This means that we can use AJAX functionality and we don't need to know about XmlHttpRequest for example, or how to send a Java object to a browser and so on. DWR has its own framework for performing the required marshaling/unmarshaling of Java objects to JavaScript and vice versa.

The setup for DWR consists of copying the dwr.jar file to the WEB-INF | lib directory in the application WAR file, and installing the application in the server before starting to use it. There are no special interfaces to implement in our own Java classes and it is even possible to develop a Java object completely transparently, so that the object doesn't know any DWR-specific classes. DWR provides well-documented APIs for us to use, and we can take advantage of it when developing, for example, Reverse AJAX applications.

And finally we can leverage the existing Java skills because DWR does not force us to replace...

The term Reverse AJAX is used when a server is used to query and/or control a client-browser behavior. This may cause some questions because it sounds like our browsers are now vulnerable to attack while we visit the web pages of the world.

Luckily that is not the case, because it is not possible for a server to open a connection to a browser. A browser must always be the initiator of the connection. So, the question about security is actually valid, but a problem would mean that the website in question is designed and implemented for causing harm.

DWR supports three different methods to do Reverse AJAX in applications: Piggyback, Polling (by the client), and Comet (server push).

DWR includes a few JavaScript libraries that are required for DWR to work and that are also helpful for developers: engine.js, util.js, and gi.js.

The first JavaScript library, engine.js, is the core of DWR's browser-side functionality, and is required for all the pages that use AJAX and DWR. The second library, util.js, contains useful utility functions but is not required for DWR. And the third library, gi.js, is used to integrate DWR with TIBCO General Interface (GI) for AJAX Applications.

<script type='text/javascript' src='/<web app name>/dwr/engine.js'>
</script>

Converters are DWR's means of marshaling data back and forth from the client to the server. There are many basic converters that are enabled by default, and it is also possible to create new converters.

Basic converters include converters for all primitive types, strings, and the following objects:

DWR also has converters for arrays (of all aforementioned objects), Java Beans and Objects, collections (Map and Collection), DOM objects, Enums, and others such as the Servlet objects and Hibernate beans.

The DWR API has a Converter interface that can be implemented for custom converters. This is not used very often because BeanConverter works for many custom objects if they are coded according to the JavaBean specification.

Creators are used by DWR to instantiate our remote objects on the server side. Chapter 3 has a section about Creators, and how to use them.

Filters are used to intercept calls to remote objects. Interception can occur before or after the call, and filters can be used for various purposes such as logging, security, parameter checking, or even adding extra latency to the DWR calls. The following samples shows simple filter code, and how it is configured in dwr.xml for a single class:

public class NotifyRestrictedAccessFilter {
public Object doFilter(Object obj, Method method, Object[] params, AjaxFilterChain chain) throws Exception {
//if params include monitored sentence
//then send mail to security officials
… code here …
return chain.doFilter(obj, method, params);
}
}
<allow>
<create creator="new"javascript="GetAreaDetails">
<param name="class" value="org.area.NumberedArea"/>
<filter class="org.filters.NotifyRestrictedAccessFilter"/&gt...

Often, DWR is not used just by itself. Perhaps, you have an on-going project where decision has been made to use a framework such as JSF or Spring for building the whole solution. In these cases, AJAX and DWR are just a part of the overall picture, and so DWR needs to integrate with other projects nicely. And that it does.

DWR integrates with the following:

Security is always important, and the DWR project has thought about security very thoroughly. The DWR framework has taken into account many security issues, and there is lots of discussion about security on the DWR website, enough to fill several books about the subject.

Among the people for whom security is important are developers like you and me. Software does only what we instruct it to do, so we must be conscious about security during development and do our best to limit the possibilities to exploit our work.

While using DWR, we manually specify in the dwr.xml configuration (unless we have created some automatic code-generation software that does it for us) which Java classes and methods we want to remote to JavaScript. This way we can be sure that no attacker can exploit any other objects than our explicitly remoted Java objects (and we can concentrate to make those objects as secure as possible).

The configuration in dwr.xml also includes a create entry for each remoted Java...

This chapter presented an overview of DWR features including JavaScript libraries (util.js, engine.js, and gi.js), security, and Reverse AJAX and on basic operational elements of how DWR works.

In addition to the topics discussed in this chapter, DWR has lots of other useful features that may or may not be relevant to developers. It depends on the application. Topics in this chapter are intended to be high-level overviews, but they will give you a good starting point to learn more from the DWR website (http://directwebremoting.org/dwr/documentation) and even from the DWR source code.

Very often, most developers do not need all the features of a technology when they start working on a project. After the project has been going on for some time, we may find out that the solution has matured to include most if not all features of the technology. But that is typically not the initial case and, besides, we have to start somewhere and it is practical to start taking small steps at a time...