XML.com

TAXI to the Future
by Tim Bray | Pages: 1, 2

But the Web Isn't Perfect

In some important ways, this architecture is remarkably like the Gen 1 mainframe setup. All the code and logic (except for HTML and bitmap rendering) is living on the server in a locked-up back room. To interact with an application typically requires that the user fill out some form fields, send it off to the server, and wait for the server to send another screenful back.

This shares some of the advantages (and problems) of those older architectures but also highlights an important new problem: performance. People have simply become accustomed to the near-instant performance of their word processor and spreadsheet, running at their fingertips on a processor quite a bit faster than those Gen 1 mainframes. The Web, which requires a round-trip to the server and back across the network for any interaction with the system, is slow in comparison.

Let me make a strong statement: not only is the architecture slow, it probably just can't be made fast. Fatter pipes won't do it. Gigabit routers won't do it. Just like the freeways feeding a city, the traffic on a network expands to fill the available capacity, and in the big picture, there is no way you'll ever make a remote application hiding behind a web server feel as fast as if the work were happening on your desktop. I've been working actively with the Web since 1994, and to this day I've never seen a web application that I could describe as fast.

This is serious; whenever you have people sitting around in front of a machine waiting for it to react, you're practicing bad management, because computers are cheap and people are expensive.

An Example: Visual Net

At this time, if you have a browser handy, you might want to visit my company's showcase site; here is a 2-D map that we can use as a starting point for our examples. It's a map of the top-level Arts category. View the source; what you see will depend on whether you're using Internet Explorer or Netscape, but it will be 2-D vector graphics encoded in XML: VML on IE, SVG on Netscape.

Then, if you're using an XML-capable browser, go to this version. Finally, if you don't mind a bit of waiting and plug-in downloading, dive deep into the map and click anywhere on it to get a 3-D view.

Here's how it works.

This is a lot like the traditional Web architecture; the server is a black box (with in this case a lot of map-database code in it). As with the Web, the defining principle is the data formats, only we're exchanging mostly XML instead of HTML -- the 2-D and 3-D graphics rendering is done by the client. Unlike the traditional Web, there's application code (specifically, the map renderers) running right on the client.

This is an example of the TAXI architecture at work.

TAXI: Transform, Aggregate, send XML, Interact

My claim is that TAXI delivers many of the benefits, and hardly any of the problems, of the previous generations of application architecture discussed above. Let's walk through it.

Transform

A lot of business logic boils down to one kind of data transformation or another: applying transactions, generating reports, updating master files. The right place to do most of this work is on the server, where you can assume a rich, high-powered computing environment, with infrastructure including:

The ability to deal with large data objects
Support for safe concurrent access
Indexing facilities for finding and fetching data
Transaction semantics for safe updates
A multi-layer environment with rich middleware tools

Concretely, you expect to be able to run your application code, issue SQL commands, run XSLT transformations, and use templates to generate output as with PHP or ASP -- and that's just getting started on the acronyms.

Aggregate

The next architectural principle is the aggregation of enough data from around the server to support some interaction with the user. An example would be a list of airplane flights that could be sorted and filtered or (as with Map.net) a description of a scene that can be rendered.

This is where a lot of judgement at application design time has to come into play; you want to send enough information to support some real interaction but not so much as to overwhelm the browser or the desktop machine that it's running on.

Send XML

Once you've gathered an appropriate amount of data together on the server side, you encode it in XML and send it off to the client over HTTP. There's no need to get fancy; we generate XML using printf statements in C code.

If you're fortunate, there'll be a well-established XML vocabulary available that someone else invented for use in your application. But probably not, and you'll have to invent your own. We did. Now here's a key point: once you've invented your vocabulary, document it! Because once you've got an XML-based application interface that runs over HTTP, and you've documented the XML vocabulary, you've invented an API. Yes, you could dress it up with additional layers like XML-RPC or SOAP, and that might be a good idea, but there's really not that much need; an HTTP-XML interface is one of the easiest things in the world to do application integration with.

Related Books

Table of Contents
Sample chapter

How do you document an XML vocabulary? A DTD is a good start; working your way through one will help clarify your thinking. And if you're one of the special people who understand the W3C XML Schema system, you might want to use that too.

More important, you need to create lots of examples of your sample XML output and make them available.

Most important, you need to create some well-written human-readable documentation explaining what the tags and attributes mean and what goes inside them. Once you've done this, you've provided an interface that any reasonably-competent programmer in the world can deal with.

One key thing not to forget: invent a namespace for your XML vocabulary and declare it at the top of each chunk you send; this will allow other people to extend your interface without breaking your software.

Interact

Once the XML has arrived in the client, probably a Web browser, you'll need to parse it. Your browser probably has this built-in; it may be more convenient to compile in Expat or Xerces or one of the other excellent processors out there.

Based on our experience in building Visual Net, these are the things you're going to need to build a compelling TAXI-architecture client:

You'll want to have the parsed XML loaded into memory, ideally with a W3C DOM API to get at it.
You'll want to be able to get access to the browser's HTML and graphics rendering machinery, so your application appears to be a natural part of the interface.
You'll need access to user input events.
You'll probably need to call out from your application code back to the server to pick up more data on demand.

All of these things can be done now in today's browsers at an immense cost from building different versions for each revision of each browser. If they all supported the W3C DOM, stylesheets, and HTML processing in the same way, life would be immensely simpler; something that I and my colleagues at the Web Standards Project have been saying for years.

Why TAXI is a Good Idea

First, it comes at the user through the browser, something that they've proved they want. Second, the application can run faster and scale bigger than traditional web applications in which the server does all the work. Third, the system is defined from the interfaces out, so nobody can lock it up, and you can switch your black-box clients and servers around with little difficulty or breakage.

TAXI will win for the same reason that the multi-tier architecture swept away its predecessors; people, once they've had a taste of big systems with the responsiveness of a personal computer, just won't go back.

I can speak only for myself. I've been building Web applications since 1994, and having gone the TAXI route once, I'm certainly not going back.