Moving Complex Data Structures Across the Web with WDDX

You can move complex data structures across the Web using Web Distributed Data Exchange (WDDX). This capability is based on Extensible Markup Language (XML) 1.0 and you can use it to exchange data between CFML applications and other applications.

Additionally, you can use WDDX for server-to-browser and browser-to-server JavaScript data exchanges. You can transfer server data to the browser and convert it to JavaScript objects. You can serialize JavaScript data generated on the browser, which translates the native data structures into an abstract representation in XML, and transferr the data to the application server. Conversely, you can deserialize WDDX XML into a native data structure. You serialize and deserialize WDDX data using the cfwddx tag.

While WDDX is a valuable tool for ColdFusion developers, its usefulness is not limited to CFML. WDDX serialization of common programming data structures (such as arrays, record sets, and structures) enables data communication, using HTTP, across a range of languages and platforms. Also, you can use WDDX to store complex data in a database, file, or even Client variable.

WDDX was created in 1998, and many applications now expose WDDX capabilities. The best source of information about WDDX is http://www.openwddx.org/. This site offers a free download of the WDDX SDK and a number of resources, including a WDDX FAQ and a developer forum.

An overview of distributed data for the Web

WDDX is an XML vocabulary for describing complex data structures such as arrays, associative arrays, and record sets in a generic fashion so you can move them between different application server platforms and between application servers and browsers using only HTTP. Target platforms for WDDX include ColdFusion, Active Server Pages (ASP), JavaScript, Perl, Java, Python, COM, Macromedia Flash, and PHP.

Unlike other approaches to creating XML-based generic distributed object systems for the Web, WDDX is not designed as an analog of traditional object programming languages. These approaches use XML as a generic descriptor for initiating remote procedure calls between different object frameworks. This is a valuable response to the problem of using traditional object-based applications on the Internet, but it is more useful as a bridge between different programming paradigms than it is as a Web-native methodology for distributing structured data between application.

There are several problems with merging the distributed object model of computing with the Internet. Primarily, this model was designed with a completely different vision of general internetworking. Instead of the "dumb and disconnected" model of HTTP, distributed computing was built on the assumption of rich network services that allow resources on remote machines to act like local components. These services allow an application on one system to find, invoke, and maintain state with objects on a remote system. Communication between objects on remote systems uses an efficient, special-purpose wire protocol.

In the disconnected world, however, these services are a barrier to development. At the most fundamental level, the wire protocols of Distributed COM and CORBA are blocked by most Web firewall software. The largest barrier, though, is that client-server-oriented distributed computing frameworks impose a development methodology that is radically different from that of the Web. This methodology excludes the vast majority of developers building Web applications whose main tools are tag-based markup languages and scripting. While WDDX works with systems that support component object development paradigms, there is a large set of applications that can benefit from the general characteristics of a distributed data system without the client-server overhead.

WDDX and Web Services

Independently of WDDX, the Web community has been working on how to solve the general problem of open and flexible distributed computing using a model that is closer to the traditional messaging and client-server systems.

The result is a set of specifications for Web Services, such as Simple Object Access Protocol (SOAP), XML Protocol (XMLP), Web Service Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). The importance of Web Services will increase as the technology matures.

WDDX does not compete with Web services. It is a complementary technology focused on solving simple problems of application integration on the Web in a pragmatic, productive manner at very low cost.

WDDX is a proven technology that has been shipping for several years. There are numerous applications that leverage WDDX as a foundation for distributed interoperability with other applications.

Currently, WDDX offers some unique advantages not present in Web Services:

It can be used by lightweight clients, such as browsers or the Macromedia Flash player.
It can be used to store complex data structures in files and databases.

Applications that take advantage of WDDX can continue to do so even when Web Services become widely available. If need be, these applications could easily be converted to use the upcoming Web Services standards. Only the service and data interchange formats-not the application model-must change.

WDDX components

WDDX is based on XML, which is a World Wide Web Consortium (W3C) Recommendation. The core of WDDX is an XML vocabulary, a set of components for each of the target platforms to serialize and deserialize data into the appropriate data structure, and a document type definition (DTD) that describes the structure of standard data types. Functionally, this creates a way to move data, its associated data types, and descriptors that allow the data to be manipulated on a target system between arbitrary application servers.

When you use WDDX in ColdFusion pages, you typically use the ColdFusion cfwddx tag and the JavaScript utility classes that are installed as /CFIDE/scripts/wddx.js on your local host.

Working with application-level data

The real strength of WDDX is clear if you think of the client and server as a unified platform for applications. There is a subtle, but profound, distinction between this view and the traditional view of an application in which services are partitioned between the client and server.

In client-server, a client might query a database and get a record set that can be browsed, updated and returned to the server without requiring a persistent connection. In this scenario, data is highly structured and that structure is integrated into the client side of the application ahead of time.

While this style of data binding relies on the presence of data sources that expose well-structured data of known types, WDDX is designed to transport application-level data structures to facilitate seamless computing between the client and the server side of a Web application. Application-level data structures generally differ from data exposed by traditional data sources, such as databases. These structures are generally more complex and ad hoc, with dynamic structure. WDDX lets you work with this data without the overhead of setting up a data source for every type of data needed. Therefore, it integrates nicely with and complements other approaches that rely on existing data sources.

Data exchange across application servers

The other common use of WDDX is expected to be the transfer of complex, structured data seamlessly between different application server platforms. For example, an application based on ColdFusion at one business could send a purchase order to a supplier running a CGI-based system. The supplier can then extract information from the order and pass it to a shipping company running an application based on ASP. Unlike traditional client-server approaches (including distributed object systems), minimal-to-no prior knowledge of the source or target systems is required by any of the other system components.

Time zone processing

Because producers and consumers of WDDX packets can be in geographically dispersed locations, using time zone information during the serialization and deserialization phases becomes critical for correct date-time processing.

All ColdFusion WDDX serializers (CFML and JavaScript) have a useTimezoneInfo attribute or property that specifies whether to use time zone information in the serialization process. The default value is True.

In the CFML implementation, useTimezoneInfo is an attribute of the cfwddx action=cfml2wddx tag. In the JavaScript implementation, useTimezoneInfo (note the case sensitivity of JavaScript) is a property of the WddxSerializer object.

Date-time values in WDDX are represented using a subset of the ISO8601 format. Time zone information is represented as an hour/minute offset from UTC; for example, "1998-9-8T12:6:26-4:0".

During WDDX deserialization to CFML, time zone information is automatically taken into account and all date-time values are converted to local time. In this way, UTC is taken out of the picture entirely and you do not need to worry about the details of time zone conversions.

However, during deserialization to JavaScript expressions, time zone information is not taken into account. Complications arise because of the difficulty of determining the time zone of the browser.

How WDDX works

The WDDX vocabulary describes a data object with a high level of abstraction. For instance, a simple structure with two string variables might have the following form after it is serialized into a WDDX XML representation:

<var name='x'>

  <struct>

    <var name='a'>

      <string>Property a</string>

    </var>

  

    <var name='b'>

      <string>Property b</string>

    </var>

  

  </struct>

</var>

When the WDDX Deserializer object deserializes this XML, it creates a structure that is also created by either of the following scripts:

JavaScript

CFScript

x = new Object(); x.a = "Property a"; x.b = "Property b";

x = structNew(); x.a = "Property a"; x.b = "Property b";

JavaScript	CFScript
x = new Object(); x.a = "Property a"; x.b = "Property b";	x = structNew(); x.a = "Property a"; x.b = "Property b";

The WddxSerializer and WddxDeserializer objects are defined in the file CFIDE/scripts/wddx.js. For detailed information on these JavaScript objects, see the CFML Reference.

Developing ColdFusion Applications
Interacting with Remote Servers