Jon Udell writes about BEA’s Alchemy which “promises mobile users a blend of browser-based ease and rich functionality”:
In the rich vs. reach debate, rich usually means a user interface more responsive and more coherent than a browsers. 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 browsers 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. Ive long thought we could be getting a lot more mileage out of these capabilities than we do. BEAs 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 browsers other Achilles heel: offline capability. A local cache is the obvious answer, as other approaches to the Web-style rich client notably Kenameas have shown. But Alchemys 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.
BEAs Alchemy relies on a server component for the same reason that Macromedias Flex does. In BEAs 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. Bosworths 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.
More comments on Jon’s blog.
