uch of the innovation in programming in recent years has involved loose coupling. The invention of database driver methodologies such as JDBC and ODBC led to applications being loosely coupled with their back end databases, allowing best-of-breed databases to be chosen—and swapped out when necessary—without any ill-effect on the user interface. In the bad old days when the user interface was part of the data engine, an update to the database would require an extensive rewrite of the GUI.

Similarly, the decoupling of data and presentation in HTML—by using XML for the data and XSLT for the presentation of data—has led to much innovation and flexibility, not least of which is the ability to deliver a document as data in XML and deliver custom styling for that document with different XSLTs.

The next big trend in decoupling appears to be separating the user interface implementation from the user interface definition. There are countless initiatives, both open source and commercial, that will have at their core this very principle. The next big revolution in the desktop Windows operating system from Microsoft, codenamed Longhorn, is perhaps the most notable of these. With this type of decoupling, when a user interface is defined in a document such as XML, users would not have to download and install their GUIs; they can simply browse them as easily as they browse Web pages. A runtime engine would be present on the desktop, and servers would be able to deliver the GUI to the browser with an XML document.

This will be huge for the corporate environment where at present, rich desktops are difficult and expensive to produce and maintain. Corporations are necessarily paranoid about allowing users to download and install binary files, and in general block users from doing this. The only options are to build a rich interface in HTML, or to build Windows applications and install them using a CD.

With this type of decoupling, when a user interface is defined in a document such as XML, users would not have to download and install their GUIs; they can simply browse them as easily as they browse Web pages.

Building rich applications in HTML or DHTML is feasible, but suffers from a number of drawbacks. First, an application written in these languages is interpreted by the browser, which isn't optimized for running applications. Browsers are of course designed to render content; having scripted, parsed applications run within their context is an afterthought, and as such is very slow. Second, once the application is designed and coded, should you want to present a similar application to another customer—branded and designed according to their styles and tastes or to coordinate with their existing systems—a rewrite of the application is usually necessary. The world is becoming used to XML driving HTML, with XSLT stylesheets to brand the data differently for different users.

So why should more complex user interfaces be any different? They shouldn't, and that's the philosophy behind these new initiatives, including Longhorn, which will have its user interfaces defined using a language called XAML (XML Application Markup Language). In short, if a user interface is defined using XML as opposed to programmed using something such as C# or Java, then a runtime engine can parse it and render it on screen. Hooks within the XML could link to server-side applications that process information.

A Better Way
Java applets were originally designed to fill this role, but they are now used infrequently, as difficulties with versions of the runtime engine, technical issues with running Java in Windows, and performance issues with AWT and Swing led many to become disenchanted with the technology. Interestingly, the architecture of Java applets is very similar to XML-GUI, consisting of a run-time rendering engine (analogous to the JRE) that downloads and runs data over HTTP.

You only need to do one download for the runtime, and then every subsequent download is firewall-friendly.

ActiveX on the other hand was designed for a number of purposes, one of which is downloadable user interfaces. Further, ActiveX Documents, which were part of Visual Studio 6.0, was a pioneering concept but security considerations regarding downloadable applications having full reign on the operating system and the hard drive have generally been a showstopper for this technology.

With XML-GUI, there is a single runtime engine running on the client desktop. (With Longhorn, this will be part of the operating system; with others, it is a downloadable, installable binary.) You only need to do one download for the runtime, and then every subsequent download is firewall-friendly.

This need for a downloadable binary in the current implementations of XML-GUI such as Bambookit or XWT may appear to be a showstopper for the same reasons as was Java applets or ActiveX controls. Indeed the architecture is very similar, but there is a subtle difference.

In the case of Bambookit, you have a Java applet that provides the Java runtime engine. This has to be installed once, and can be installed with a known JDK/JRE upon which it works. All GUIs are then rendered by this engine. Previously, when every GUI was an independent applet, you faced two problems. The first was that different applets could be targeted at different JDK/JREs, and the second was that you had no guarantee that the optimal version JDK/JRE for your GUI was installed at your client site, or that every instance of the JDK/JRE was the same at each client machine. XML-GUI effectively runs on a virtual machine on top of another virtual machine, and that level of abstraction should give you enough flexibility to control your dependencies more effectively. A similar argument exists for the ActiveX-based rendering engines such as the one with XWT.

As mentioned above, the XAML runtime for Microsoft Longhorn will be a part of the operating system itself, so all you will have to do to deliver a UI will be to deliver the XML document, and not have to worry about the runtime.