Client Development Support in DDS: Overview, Tips and Tricks


This article focuses on support for client development in EMC Documentum Dynamic Delivery Services (DDS). It gives an overview of client development technologies explicitly supported by DDS: GWT, JSP, and XForms, including their possibilities and limitations. For each technology, it presents code and/or deployment examples. It also gives examples of how to develop clients using combinations of technologies.

Intended Audience

This article is written for developers starting on a client application for a DDS back-end. It requires the reader to have a basic understanding of Java, DDS, GWT, JSP, and the XForms standard. Also, the reader is assumed to be familiar with war deployment in an application server environment, and JavaScript programming.



EMC Documentum Dynamic Delivery Services (DDS) is a framework for building XML-based delivery applications with minimal development effort. Typically, DDS applications include a browser client, served by a scalable delivery platform based on EMC Documentum xDB, EMC's XML database product.

DDS offers a complete server-side API which is client-independent, and exposes functionality such as:

  • URI-based handling of (XML) content, e.g. stored in xDB or on the file system
  • Executing XQueries on XML content
  • Executing pipelines specified according to the XProc standard
  • Handling processes specified according to the S1000D Process Data Module standard

and much more.


Adapting this API for any particular client-server technology requires a small intermediate layer, primarily performing (de-)serialization. This basically implies that a developer of a DDS-based application can choose from any number of technologies to help build his client. However, DDS already includes explicit support for three such technologies: GWT, JSP, and XForms [*].


The following sections briefly introduce each of these technologies, and discuss how DDS supports them. We also provide tips and tricks on what needs to be done to mix multiple User Interface (UI) technologies in one web application. Finally, we give a short assessment of their possibilities, limitations and general applicability. Expert readers may want to skip the boxed sections (i.e. those titled "Execution Model", and Section 4 "Possibilities and Limitations").


The technology introductions below merely serve to highlight some of the things that are important when covering DDS support for them. For a full understanding, we refer to large volumes of documentation available on the Web. For the reader to be able to fully understand the material presented below, a basic understanding of Java, DDS, GWT, JSP, and the XForms standard is required. Also, the reader is assumed to be familiar with war deployment (e.g. here) in an application server setting, and the basics of JavaScript (e.g. here) programming.


DDS Supported Client Development Technologies


Google Web Toolkit is an open source framework for developing AJAX (Asynchronous JavaScript And XML, see for example here) applications using a Java API. The application developer uses the GWT API (JAVA), and a subset of Java to build:

  • his application's UI,
  • any client-side logic (such as widget interaction),
  • service (RPC) requests, and
  • service response processing (UI styling can be done in css).


The GWT compiler is then invoked to compile the entire UI part of the application to JavaScript, ready to be executed in a web browser.


There is also a server-side API for handling RPC calls from a GWT client, which the developer can use/extend to form entry and end points for any server-side logic. Most notably, server-side GWT takes care of many aspects of serialization, deserialization, and exception handling.



Execution Model

Loading a GWT application into the browser is no different from loading any JavaScript program, as shown in the following HTML snippet, which loads the garage demo (shipped with DDS) into the browser:


    <title>Garage Demo</title>
    <script language='javascript' src='garage/garage.nocache.js'></script>
    <iframe src="javascript:''" id="__gwt_historyFrame" style="width:0;height:0;border:0"></iframe>


After loading, execution control jumps to the onModuleLoad() method of (in the above case) the class, the entry point of the application. Here, the application developer will typically call code for initialization of the widgets that constitute his UI Layout, and for setting up event handling by linking listeners to widgets.


GWT includes a library of core widgets in its distribution, and some more in its "Incubator". At runtime, these widgets (e.g. lists and trees) typically need to be populated with data from some back-end system, to which end GWT includes Java components that enable RPC communication between the UI and a server.


Once started in a browser, a GWT application will keep the browser on the same "page". Any calls to the server will not result in navigation to another page, but just in an AJAX response, possibly resulting in dynamic updates to the same page. This implies that browser history (back and forward buttons) may not work as expected. GWT offers the developer hooks to cope with this.



DDS supports GWT-based application development, in terms of both widgets and services used to provide those widgets with data from a (DDS) back-end.


The widgets include:

  • Trees and lists tailored to displaying XML-based content (including results from XQueries)
  • A panel for client-side processing and displaying of XForms (see below)
  • A frame for displaying the results of an XProc pipeline

and many more.


Among the GWT services offered are:

  • (XML) Persistence service, to manipulate (create, copy, move, insert, etc.) persistent (XML) content in the back-end
  • XQuery service, to run an xquery on xDB and return the result
  • XProc service, to provide input to, and run an XProc pipeline in the EMC Documentum XProc Engine, and return the result

and (again) many more.


Combining these, a developer could, for example, use the XQuery service to collect XML content from xDB, and display it in a tree or list. If the data has to go through some transformation first, possibly dependent on some options/settings, the developer may decide to use the XProc service rather than the XQuery service to collect the necessary XML.


Both DDS widgets and services are available as APIs, which can be used as is, but also provide plenty of hooks for extension.


A more traditional approach towards developing UIs is Java Server Pages (JSP). A JavaServer Page is a script which can be compiled into a servlet. The script specifies the contents of its resulting servlet's response. The response's format may be HTML, or XML (or other formats).



Execution Model

Consider the following JSP (actually this is one of the sample JSPs distributed with DDS to illustrate the DDS Tag Library, see below).


    <%@ taglib uri="" prefix="dds" %>
       <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
       <title>Taglib Demo</title>


When this JSP is addressed, the response will be an HTML page with title "Taglib Demo" (<title>Taglib Demo</title>), and some content, resulting from the tags with the "dds" prefix.


The response is constructed in the servlet container (e.g. Tomcat) who finds the JSP, and compiles it into Servlet code. Any tags not associated with "special" functionality are just translated to print statements of the literal text to the JspWriter, which "holds" the response (e.g. out.println("<title>Taglib Demo</title>")).


The prefixed tags ("dds:") are associated with Java code (through configuration files). The classes in this code together form what is called a Tag Library. The DDS Tag Library is the Java library provided by DDS for JSPs to interact with a DDS back-end. Many other Tag Libraries exist, each with their own area of functionality.


In the example, when the JSP compiler runs into a dds:transform tag, it will translate this into Servlet code calling the associated Java class (called TransformTag). This class is programmed to:

  • look up the stylesheet specified in the "styleURI" attribute,
  • apply the stylesheet to the document that was identified by the ContextNodeTag (which is associated with the "dds:contextnode" tag one line before), and
  • paste the result of the transformation (which should be HTML) into the response.


Once the JSP is compiled into servlet code, it is executed within the servlet container.


The resulting HTML from the sample JSP is this:

      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
      <title>Taglib Demo</title>
      Motor oil keeps your car's engine running smoothly.
      Oil should be changed every 6000 kilometers.

The content of the body element is the result of transforming oil.xml using taglib-demo.xsl.



DDS support for JSP-based development consists of the DDS Tag Library, a collection of Tag classes enabling the JSP application developer to:

  • start and end DDS sessions
  • run xqueries, iterate over query results, and display them
  • run xproc pipelines, and display the results
  • run XML transformations, and display the results
  • display xforms (see below)

and more.


Together they can be used to populate views with content from DDS data sets, using DDS application resources (XProc, XForms, XSLT, etc. instances)

The DDS TagLibrary's API provides the necessary support for developing custom DDS-specific tags. Most notably the TagHelper class (see the DDS API documentation) provides methods for:

  • retrieving the current user
  • retrieving the current context node
  • retrieving content from the database based on a URI

and more.


In web applications, users are often confronted with forms. The complexity of such forms may vary, and include such aspects as:

  • initialization
  • form control disabling
  • input validation
  • calculating derived values
  • new data retrieval (i.e. from a server, e.g. to fill a listbox control)

and many more


XForms is an XML-based standard for the specification of such forms. The XForms standard sees forms as composed of basically two parts (the XForms spec is extensive, we just present a very simplified look at it here):

  • The "model" part of an XForm consists of XML describing form data, constraints upon this data, and form submissions.
  • The "view" part describes the controls in the form, any grouping, and what data they are bound to.


Many form-related aspects are covered by the specification, including all those mentioned above.


Consider the following very simple form:

<?xml version="1.0"  encoding="UTF-8"?>
<html xmlns=""  xmlns:xf="">
      <title>Payment method</title>
            <ecommerce xmlns="">
         <xf:submission id="submit" method="post" action="/ProcessPaymentMethodServlet"/>
      <xf:select1 ref="method" xmlns="">
         <xf:label>Select Payment Method:</xf:label>
         <xf:hint>Please select method of payment: cash or credit</xf:hint>
      <xf:submit submission="submit">


The "model" part of this form (within the xf:model tag) specifies what will be submitted on form submission.


The "view" part (within the body tag) specifies the controls (a list of 2 options: "cash" and "cc", and a submit button), and the binding of controls to model elements (the value of the "ref" attribute of the "select1" element in the body refers to the "method" element in the model.



Execution Model

An implementation of the XForms spec, an XForms Engine/Processor, must be able to load a form, and process and interpret the XML in it, doing any initialization, validation of entered values, recalculation, etc., taking care that the proper XML is sent to "the server" on submission, and, of course, displaying the form.


The semantics of the above simple form is that, after the form is displayed, if the user selects a value "cash" or "cc", then this value becomes the text value of the "method" element in the model. On submission, if the selected value is "cash", then the submitted data will be:

<ecommerce xmlns="">

In a client-server setting, XForms processing can be on the client-side, on the server side, or a bit on both. With regard to performance, while moving more processing to the client-side avoids network latency, the processing itself of very complex forms might be faster on the server machine. Clearly, for an XForms implementation, there is a tradeoff here.


XForms and DDS

DDS includes a completely client-side XForms engine, implemented with GWT (implying that it runs as a javascript implementation in a browser). An important feature is its capability to interpret the layout specification of forms generated using EMC Documentum Forms Builder, EMC's graphical forms building tool.


The above simple form, displayed using this XForms engine, looks like this in the browser:


The GWT API (Java) as well as the JavaScript API of the compiled Engine are exposed, making it very easy to embed in GWT or more traditional web-applications (e.g. JSP based), as we will see later on.


Interoperability, Mixed model

Between JSP, GWT, and XForms, from a technical perspective, there is no real need to choose one technology for UI development, and stick with it throughout the application's lifecycle. For example, a development path that starts out with JSP, in which complex views and dialogs are gradually replaced by GWT, and complex HTML forms by XForms, is definitely feasible.


Below, we cover mixed model applications. We'll discuss four combinations:

  • A GWT application with Forms
  • A JSP application with Forms
  • A JSP application with GWT components
  • A GWT application with JSP components

A GWT application with Forms

When you want to include an XForm in your GWT-based DDS application, you can use the class. Based on the DDS URI(s) provided to its constructor, it looks up the XForm in DDS, and loads, processes, and displays the form:

DDSXFormsPanel formPanel fp = new DDSXFormsPanel("dds://DOMAIN=resource/xforms/MyForm");

By registering a (update: FormHandler is deprecated in GWT 1.6, use SumbitHandler and  SubmitCompleteHandler instead; workings are approximately the same) to the FormPanel, you can react to form events such as form submission, e.g.:

public class MyFormHandler implements FormHandler {
   DDSXFormsPanel formPanel;
   public MyFormHandler(DDSXFormsPanel formPanel) {
      this.formsPanel = formPanel;
      //register with FormPanel
      formPanel.setFormHandler("submit", this);
   public void onSubmit(FormSubmitEvent event) {
      //Do any work here before anything is actually submitted to the server.
   public void onSubmitComplete(FormSubmitCompleteEvent event) {
      //Do any work here after submit has completed

Now let's talk a bit more about form submission. In the simple XForm discussed earlier, we saw the following submission element:

<xf:submission id="submit" method="post" action="/ProcessPaymentMethodServlet" />

This suggests that on submission, the Servlet named "ProcessPaymentMethodServlet" is called with the instance data in the POST content of the request (provided that there is a mapping in web.xml from "ProcessPaymentMethodServlet" to a valid servlet class). Within the XForms specification, submission elements are the designated way to get instance data submitted.


If you register a FormHandler to your DDSXFormsPanel, and (as is the case in MyformHandler) this FormHandler has a reference to the DDSXFormsPanel, then a lot of information on the form (XFormsDocument) can be retrieved. For example, this code snippet gets the current XML content of the data that would be submitted:

String instanceXML = this.formPanel.getXFormsDocument()

This implies that there is another way to submit the form instance data to the server: the onSubmit method of the registered FormHandler can retrieve the instance data through the above code snippet, and invoke an RPC service with the data as an argument.

A JSP application with Forms

XForms can be used with JSP as well, by using the DDS taglibrary in the form of the dds:xform tag. The following JSP code loads the same form as the one used in the GWT example:

   <%@ taglib uri="" prefix="dds" %>
     <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
     <title>Taglib Demo</title>
     <script language='javascript' src='formula/formula.nocache.js'></script>
         <dds:xform uri="dds://DOMAIN=resource/xforms/MyForm/"/>

Basically this JSP loads the XForms Engine using the script tag. The dds:xform tag retrieves the appropriate form by its URI, and generates additional JavaScript into the resulting page, that looks like this:

<div id='form_37692'>
   <script type='text/javascript'>
      function xformsInit() {
         var xform = "[the XML of the form as a string]";
         var form = new emc.xforms.XFormsDocument(xform);
         var formId = "form_37692";

Executing this JavaScript will load the XML of the form into the client-side engine.


Obviously, for this to work, the compiled (to JavaScript) XForms application has to be available, including images, on the server. The script tag suggests that the JavaScript file com.emc.documentum.xml.xforms.gwt.Main.nocache.js should be present directly under the public folder of the web application as deployed on the server. When using the XForms Engine this way, make sure that your .war file is such that the path of com.emc.documentum.xml.xforms.gwt.Main.nocache.js in it, corresponds to the path specified in the src attribute of the script element.

A JSP application with GWT components

JSP applications can easily incorporate GWT applications as view components. Actually, this was already demonstrated in the previous section, where a JSP includes the Forms Engine (also a GWT application). As can be observed in that example, the resulting page includes a JavaScript method xformsInit(), in which a method xformsAdd() is called.


Who calls xformsInit() and where is the implementation of xformsAdd()?


The answer to both is: the forms engine application/component. GWT includes Java-like constructs to enable a compiled (into JavaScript) GWT application to integrate with other (native) JavaScript in the same page. In this way, a GWT component can expose a JavaScript API, and do JavaScript calls to code outside its own code. The GWT code below, called from the onModuleLoad() method of com.emc.documentum.xml.xforms.gwt.Main shows how this can be achieved:

private native void initJS() /*-{
  $wnd.xformsAdd = function (xmlContents,id) {
  if ($wnd.xformsInit) {

This code tells the GWT compiler to expose the compiled add(String, String) method of as JavaScript under the function name xformsAdd. Also, on loading of the application, it looks for a JavaScript function declaration of xformsInit in the current window. If one is found, the function is called.


Using these simple constructs, it becomes very straightforward to incorporate GWT components in your JSP, and initialize them with values coming from JSP forms or request parameters.

A GWT application with JSP components

A final mixed-model possibility is: including JSP components in a GWT application. The GWT API includes a number of methods accepting a URL as an argument. Through these URLs we can address a JSP, a Struts action, or a servlet (or anything else for that matter). Dependent on the method used, the GWT client will react differently to the response. Below, we consider two typical cases, Window.Location.assign and Frame.setUrl. A special case is the XForms submission element, which we'll discuss last.


The Window.Location class in GWT includes a static method assign(java.lang.String newURL), which will assign the current window to (the result of) a new URL. A side effect of this is, obviously, that any GWT application state will be lost after the new page loads: the GWT application has effectively terminated. Any client-side state that was not encoded in the URL is lost for the remaining duration of the application.


The Frame class in GWT includes a setUrl(java.lang.String url) method. Its result is that the resource addressed by the given URL will be displayed within the frame. This is used internally by DDS's com.emc.documentum.xml.xproc.gwt.client.ui.XProcFrame widget, which calls setUrl with a url starting with "XProcServlet", and including the location of a pipeline. This refers to a servlet which makes sure the intended pipeline is run with the proper input, and sends back the serialized result.

Special case: Submission

The URL of a submission element in an XForm can also specify a servlet, Struts action, or JSP. This results in a request to the server. Whatever happens with the response of the submission can be coded in the onSubmitComplete method of the registered FormHandler (see XForms and DDS).



Possibilities and Limitations

The choice for one UI technology over another is impacted by many factors, among which are often awareness and plain tradition/experience. As we have shown, between JSP, GWT, and XForms, on an applications level, there is really no need to choose, since the three technologies can be used together in one application. Still, it is worthwhile going over some of their objectively assessable strengths and limitations, to see which technology helps you where.


The strength of JSP lies not in the syntax and specification itself (although the XML syntax is very convenient to work with), but more in its use within development frameworks such as Struts. Struts lets a developer separately specify model components (Java classes), view components (JSP), and (in a declarative manner) the control between them (XML). It also includes frameworks for form validation, bean instantiation from forms, screen layout, and localization.


Another strength of JSP is that the output of a Java Server Page can be XML, which can be run through any number of (XSLT) transformations before being sent back to the client. This means that a JSP only needs to specify layout in very abstract terms (menu, block, label, textbox, etc.), and that stylesheets (XSTL and css) can take care of output specific for the client (e.g. pop-up menus vs. of pull-down, HTML vs. XHTML etc.).


With JSP-based development, one view is generally one browser page (although it is perfectly possible to have a JSP respond to an AJAX request, not resulting in a new browser page), implying that browser history navigation "works". All these new browser pages, however, make it hard, if not impossible, to maintain any state on the client side. State is therefore usually maintained in multiple levels of server-side "contexts".


If, as a developer, you want to spice up your views a bit, you quickly run into the need of incorporating some JavaScript in combination with asynchronous server calls. Apart from the fact that JavaScript has a reputation of being hard to maintain, this adds yet another syntax to the application, next to JSP (views), Java (model classes), and XML (controller configuration, validation, tiles).


IDE support for Struts-based development has been around for some time now. This can significantly speed up development.


With GWT, it's all about Java, client and server side, so really only one syntax is required. A substantial number of available widgets provides for just about anything a developer needs to build complex views and dialogs. Usually, the application stays within the same browser page, and issues AJAX-based server calls from there. This implies that any application state that is, by nature, client side (e.g. which controls are visible, on which column a list is currently sorted, etc.) can be actually kept on the client side.


All this switching of views within the same browser page does imply that the developer needs to use the appropriate GWT hooks to implement his own browser history navigation (back and forward). Explicit support for something like MVC (available in Struts) is lacking, as is a declarative manner for specifying form validation.


IDE support for GWT-based development is available. More specifically, there are graphical tools enabling a developer to compose a UI by dragging and dropping controls onto a canvas.


In both JSP and GWT, we can build forms in terms of a number of input controls (text boxes, checkboxes, radiobuttons, etc.), and a submit (and cancel) button. For Struts-based applications, on the server-side there is forms support in terms of validation and extracting form values. There are, however, more aspects to forms, most notably (as stated before):

  • initialization
  • form control disabling
  • calculating derived values
  • new data retrieval (i.e. from a server, e.g. to fill a listbox control)

None of these are properly covered in JSP or GWT. Apart from that, there is no support there for separate specification of data model and user interface, and the binding between them. So if there is some complex relation between a (set of) form control(s),and a piece of data being sent over to the server on submit, you're pretty much on your own.


All this is properly handled in the XForms specification, and implemented in the EMC Documentum XForms Engine.


IDE support for XForm development is available. EMC ships the EMC Documentum Forms Builder, a graphical tool enabling a developer to compose forms by dragging and dropping controls onto a canvas, and specifying logic, binding and validation through dialogs.

Other technologies and specifications

While DDS includes explicit support for GWT, JSP, and XForms, the DDS server-side API is sufficiently generic to provide back-end functionality for any client technology. DDS's generic services and operations framework and its XProc API are easy to use, and cover most of the DDS server-side functionality. Also, WSDL will be made available shortly.



In this article we covered client development in DDS. An overview of the technologies explicitly supported by DDS (i.e. GWT, JSP - Tag Libraries, and XForms) was given, including their possibilities and limitations. Tips and tricks on how to use them, including usage in mixed-model applications, were provided to give you a comfortable start developing your DDS client, and convince you that one technology does not at all exclude the others.


[*] Actually, a fourth one is supported: the S1000D Process Data Module (PDM). However, while PDM support on the server side is sufficiently developed to be included in the DDS APIs, on the client (browser) side, development is still very much an ongoing thing. This is why the client/UI part of it is only shipped with DDS as demo application code.[