XForms Thick Clients
October 19, 2007
All designers and developers face the problems of vague requirements, poorly defined data models, and last minute requirement changes. These sad facts of life drive some developers to embrace a document-driven architecture,but this approach usually breaks down when confronted with an environment that includes non-network attached devices that necessitate a thick-client application. This article describes the components and techniques for building a document-driven, thick-client application using XForms that operates on a non-network attached system. This approach provides for decreased deployment costs, cross-platform operation of a thick client, and increased component reuse within an enterprise. Although web-based applications are usually optimal for enterprise network deployment, there are classes of users that need access to the same types of applications while detached from a network. Using XForms, other XML technologies, and Java, a system can be constructed that provides detached users access to the same application systems as network attached workers and provides the flexibility of document-driven systems. This article covers the components used for a XForms-based thick client, including presentation, business logic, storage logic, and security.
Using inherently network-based technologies, such as XForms, in a thick client requires an unusual bundling of components. The resulting application consists of a native operating system executable that contains all the application tiers normally spread across multiple systems. Figure 1 illustrates the components and layering of such a thick client.
The outermost Native OS Executable is responsible for bootstrapping the application environment, providing a display context, setting the appropriate class path information and initiating the Java virtual machine (JVM).
The browser component embeds the OS default browser as the display component of the application. The presentation layer produces HTML/CSS that is rendered in the browser component.
The OS Executable bootstraps a JVM for the bulk of the application logic. The initial Java class instantiates an embedded web server component, which contains the traditional three application tiers. Packaging all layers of the application into one executable eliminates the coordination to ensure that the database is running prior to the application starting, since the database is embedded in the executable.
The Eclipse RCP project provides a robust runtime environment that includes an embedded browser component for displaying the output of the presentation layer. RCP wraps the Java programs into executables suitable for multiple target platforms. So one can use RCP to generate standalone programs for Windows, Mac OS X, Linux, and others based on the same Java components.
XForms supplies presentation controls suitable for clean interaction with the XML documents managed in a document driven application. XForms provides a modern, XML based approach to collecting user input in a web application. XForms goes further by providing the developer a means to fully control the page presentation by managing the content of the XML documents consumed by the form. For example, one can provide immediate feedback to the user regarding validation failures by using XForms events and actions to record field validation events.
Using XForms in a document-driven system allows developers to control data content and validation rules by specifying content and validation rules in the XForms model. XForms simplifies the expression of presentation logic in the presentation layer, but erects barriers that make coding business logic in this layer difficult.
Since the application operates with an embedded browser component determined by the OS, the best choice is for a browser-independent software translation component. Orbeon provides an XForms 1.0 implementation with some early enhancements from the XForms 1.1 specification. Orbeon also bundles an XML-centric business layer and an XML database into their standard distribution. Having all three layers bundled into one distribution saves time in bootstrapping the initial development environment. Orbeon also provides a very handy debugging widget that provides runtime visibility into the data model being edited by the form.
Since the presentation layer deals in XML, the business layer must either translate the XML into an object oriented (OO) representation or perform the business logic directly against XML. If the translation to OO can be avoided, the business layer can remain ignorant of changes to the schema unless those changes directly impact the processing logic. If the business layer is largely ignorant of schema changes, then maintainability and flexibility is increased by reducing the number of touch-points that exist for any given change to the system.
XForms is business layer agnostic, as long as the layer accepts XML documents, it can process XForms documents. The more XML-centric the business layer, the less glue code is required. One alternative approach to an XML-centric business layer is a W3C draft standard called XML Pipelines (XPL).
XPL allows a developer to define a series of steps to perform on an XML document. The steps can include XSLT transformations, document generation, filtering, looping, and calls to Java classes. In many cases complex business logic can be performed on a document without resorting to lower-level language code. The XForms model can perform submission actions directly to XPL pipelines eliminating the need for any glue code between the XForms and the business logic. XPL also provides hooks to call Java classes, EJBs, or web services directly, if more complex algorithms are required.
There are many choices for persisting data in a thick client application, including using embedded relational databases like Derby and HSQLDB, which all require XML-to-relational mapping. If mapping is performed then the XML schema and database schema must be kept in sync.
If the presentation layer and business layer are dealing with XML documents natively, storing the application data as XML rather than converting it into a relational representation removes an entire translation layer. XML databases, such as eXist, XIndice, and Tamino, provide means to store documents as XML and retrieve those documents based on XQuery or XPath queries. With an XML database the schema of the database is completely driven by the documents stored in the database. If elements are added to the presentation layer, nothing needs to change in the database to persist that new data element.
Security in a detached application typically focuses on access security and data security.
Access security, authentication and authorization, is handled either by the application container or surrounding operating system and is not particularly germane to this article, although it is important to most application designs. The most direct way to accomplish authentication is to use JAAS to protect the pages of the application. When combined with the local storage of the XML database, one can securely cache credentials for use when the user is offline.
Data security consists of protecting the data stored on disc to prevent unauthorized access. If the application is using XForms for presentation and an XML database for persistence, the encryption of the data must occur between the business layer and the storage layer. The business layer would emit and consume XML documents containing the encrypted data. The W3C XML Encryption Recommendation specifies a straightforward means of representing encrypted XML in a standard wrapper. A recommended approach is to keep some parent data elements in clear text for document indexing, and isolate all confidential information in a child tree that is encrypted for storage. The application of XML encryption can occur in a pipeline step following any business logic.
Benefits to This Approach
Benefits of this approach include:
Greatly reduced touch-points when maintaining the application. In a recent project I constructed an application that allowed TurboTax style workflow over hundreds of data elements within a document. Only three files in the system, the XSD, the model definition, and the page where the data is collected were impacted when fields were added or changed.
Increased levels of reuse between thick client applications and online applications
The same application can be hosted on a web server for network-based access or bundled into an offline executable for thick client type access.
Problems with This Approach
Some problems with this approach are:
The size of the resulting thick client application can be substantial. The aforementioned application with hundreds of elements weighed in with at 70 MB (which included a JRE and installer), but the size of the application does not grow substantially as additional features are added.
The XForms programming model is a bit atypical for many developers. Developers may need to do some new mental gymnastics to comprehend a state driven programming model rather than a more sequential or event driven model.
Using a Java environment on a Windows system can lead to some headaches when the program needs to access non-standard OS resources.
Using XForms in a standalone application has proven to provide a flexible and maintainable platform for developing both online and offline applications. If your users have difficulty expressing or settling on a set of requirements, then a flexible system like XForms with a document driven infrastructure may be your best bet for success.