Thin clients and rich data

In the rich vs. reach debate, rich usually means a user interface more responsive and more coherent than a browser’s. Prime contenders in the rich-client struggle are Java, .Net, and Flash. All three can be used natively or as renderers for a new breed of tools — from Altio, Digital Harbor, Droplets, Laszlo, among others — which create GUI applications for these platforms. Meanwhile, developers in the trenches know that rumors of the browser’s death are greatly exaggerated. The browser continues to deliver a killer combination of reach plus ease of learning and use, with simplicity of development, no-touch deployment, and continuous update.

In its modern incarnation, the browser can connect to Web services, query and transform local XML data, and dynamically inject results into a live page. I’ve long thought we could be getting a lot more mileage out of these capabilities than we do. BEA’s chief architect Adam Bosworth thinks so, too, and a project code-named Alchemy (unveiled last week at BEA eWorld 2004) aims to prove it.

Prototyped for Internet Explorer but intended to be open sourced and implemented — Bosworth hopes — in Mozilla, Safari, and Opera, Alchemy starts by addressing the browser’s other Achilles heel: offline capability. A local cache is the obvious answer, as other approaches to the Web-style rich client — notably Kenamea’s — have shown. But Alchemy’s cache is more than a persistent dictionary of name/value pairs.

At the core of each Alchemy application is a data model defined by an XML schema. Programmers interact with that data model using XHTML templates and JavaScript. The style will seem familiar to Web developers, but has some postmodern aspects. For example, the JavaScript engine supports ECMAScript for XML (E4X), an ECMA-endorsed BEA extension that’s implemented in WebLogic Workshop. The E4X technology makes it easy to “walk around” inside the data model and insert new XML fragments. Another postmodernism, the XHTML templates, which include server-side invocations of Web services à la MXML (Macromedia Flex Markup Language), typically do server-side XQuery transformations of the resulting data. The XQuery technology, supplied by BEA’s Liquid Data in the demo I saw, isolates the local data model from the remotely invoked services that feed it.

BEA’s Alchemy relies on a server component for the same reason that Macromedia’s Flex does. In BEA’s case, the server architecture includes a mirror of the client-side cache. However, synchronization between the two caches relies on an HTTP-based protocol that will be open and — Bosworth hopes — standardized and broadly adopted.

The caching scheme is the heart and soul of Alchemy. Current approaches to taking browsers offline typically queue messages that later update in a server-based data model. An Alchemy application, though, always works with a genuine local data model that it stores as sets of XML fragments and navigates in a relational style. Bosworth’s hunch is that a Web-style thin client, driven by a rich data model intelligently synchronized with the services cloud, could do most of what we really need — both offline and online. Nothing prevents Java, .Net, and Flash clients from adopting the same strategy, by the way. But if Bosworth is right, the universal client that we know and love could get a new lease on life.