We've expanded our XML news coverage and improved our search! Search for all things XML across O'Reilly!

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.

---

Interested in TAXI, or got asimilar idea? Talk back to Tim Bray and XML.com.

---

(* You must be a member of XML.com to use this feature.)
Comment on this Article

---

Titles Only

Titles Only

Newest First

• TAXI Application
  2006-02-10 06:52:56 laptopjockey [Reply]
  
  Hi Tim - Great article! As a more-or-less non-technical advocate of everything XML, I really appreciated your description of the progression from Mainframe out to TAXI. The first computer I used was a Honeywell Multics at the University of Calgary - Hollerith Cards and the whole deal!

  
  Since then I have moved more into the business analytics side of things with an emphasis on document/content/knowledge management from the technical writing side of software.

  
  I was talking to Kerri Knull the other day about an architecture that will deliver information in a similar way and the first thing she said was 'Visual Net.' We spoke at length about our proposed application, and she thought you would approve.

  
  I will keep in touch as to our progress but wanted to thank you for pushing the envelope (again)!

  
  John O'

  
  
  
  

• TAXI to the Future
  2001-05-06 07:47:51 SURESH Venkatraman [Reply]
  
  1. XML Messages are sent from Server to Client

  
  2. These messages occupies more space and hence more time to transmit on the network.

  
  3. Request you to inform what all methods are there to reduce the transmission time.

  
  4. Is compression the only option other can we do something more.

  
  Thanks in advance

  
  SURESH T.V.
  
  

• A similar approach
  2001-04-04 08:31:40 David Levett [Reply]
  
  I read Tim's article with a great deal of interest. He has clearly articulated what I believe will be a fundamental shift in the architecture of networked applications.

  
  At the risk of sounding like an advertisement, but in the spirit of 'Interested in TAXI, or got a similar idea?...' I introduce an alternative but similar approach.

  
  At Altio we have been addressing the problem of delivering the richness and interactivity of client/server user interfaces through a browser, and our approach is comparable to that described as the 'Gen X:Web' architecture.

  
  All the application data is transferred to and from the App/Web Server and the browser based client as XML (including the interface definitions) and the UI rendering is performed on the client. All the business logic remains on the server and updates to the data can be broadcast to one or more clients in real-time.

  
  We support multiple OS & browser platforms, and allow for client-side data validation to save round-trips to the server.

  
  
  
  

• This is what users want?
  2001-03-21 07:58:32 Murray Gill [Reply]
  
  I found the following comment interesting:
  "But the users voted with their feet for the browser and we got to about where we are now."

  
  The majority of end-users I deal with find the web:

  
  1) Slow
  2) Difficult to understand
  3) Error-prone
  4) Non-standardized

  
  The author claims that the thick-client apps with the "funny-shaped buttons and bizarre screen layouts" are what users rebel against. Try and find two web applications that look even remotely similar in terms of navigation or functionality.

  
  For example take a look at www.microsoft.com, www.yahoo.com, www.sun.com for three diffreent web interfaces (all horrible) which would overwhelm any novice user far more than any WinApp that I've ever seen.

  
  If anything users are flocking away from the browser back to thick client interfaces such as Napster, MSN Messenger, Netmeeting, etc.

  
  The idea that the big advantage of XML is in how we move data to the browser misses the point. The big promise of XML is that it allows us to move BEYOND the browser and let my Delphi App on Win2K talk to your Java App running on Linux which is talking to some WebObjects app running on an IMac.

  
  Developers really need to move beyond this "my platform is better that your platform" mentality (e.g. my browser is better than your VB app) and start working on developing apps designed to interact with other platforms.
  
  

• where will this tool be applied
  2001-03-18 19:40:54 Andrew Scheiffers [Reply]
  
  Hi tim.

  
  I am doing my honours year at university in Australia and I am interested in XML as my thesis topic. I am looking at XML as a systems integration tool to gain data from multiple applications. From your article I get the impression that your tool is designed to acheive this. Is this true? I am interested in any more basic references for someone that needs to learn about XML and what it can do. If you know any sites like this or other people I might be able to email then please contact me.

  
  Andrew Scheiffers
  scheiffers@bigfoot.com
  
  

• we need to change corporate mindset to realize it
  2001-03-18 08:12:50 bill parducci [Reply]
  
  "If they all supported the W3C DOM, style sheets, 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."

  
  You are not the only ones! :o) TAXI definitely represents the holy grail of community computing, but until such time as a common interface is achieved that can take advantage of standard XML processing most of the advantages are negligible. Working in a very large and diverse WAN environment over the last three years has provided me with three client options: (1) choose the lowest common denominator; (2) force a common browser upon the client; (3) develop dual (or multiple) code paths.

  
  Regardless of the approach taken a certain baseline has to be established to ensure any degree of functionality. Even with option 1, this has been done by selecting a specific browser version as the minimum client platform (i.e. must have Netscape 4.x or ie 4.x to view this page). To me this is barely a step up from declaring a specific browser be used by all (the most evil of choices). I find it almost amusing that even with this dictatorial situation the natural tendency to "leverage the platform" by developers causes clients to run with very specific minor version/service pack/patches to achieve proper operation. The problem this causes is that much of the benefit gained form the Web platform in terms of support and management are lost by moving the support up to the browser.

  
  Perhaps continued improvements in browsers will raise the bar high enough to make the TAXI approach viable. Industry doesn't seem to be waiting though as third parties such as macromedia are trying to provide for a rich and consistent environment for browser via tools like Flash. While appealing in this aspect, this too represents obvious issues in support because it introduces a whole new level of support and compatibility requirements (ignoring what it does to MVC development guidelines).

  
  It will be interesting to see how it finally plays out. In the meantime, I am working hard in my little world trying to raise the awareness that "browser standards" need to be replaced with protocol standards (such as XHTML). I believe that the sooner we can get away from "requires ie vX, Netscape vY" in the corporate mindset the sooner we can realize the TAXI model.
  
  
  

• TAXI == REST
  2001-03-17 11:48:58 Mark Baker [Reply]
  
  Tim, it looks like you rediscovered REST ("Representational State Transfer"), the architecture of the Web itself. Good job! 8-)

  
  See;

  
  http://www.ics.uci.edu/~fielding/talks/
  ("Research Talk").

  
  MB
  
  

• Good for TAXI ing data what about behaviour...
  2001-03-16 15:43:33 Steve Brackenbury [Reply]
  
  I'm very interested in the TAXI approach.

  
  Is there a way for TAXI or TAXI extensions to accomodate the need to provide (when required) behaviour/business rules objects on the client?

  
  Example, what if I want to provide (for the sake of performance) some validation logic on the client side rather than making network calls back to application server?

  
  How do you address these types of issues, or is TAXI really not suitable for applications with this type of requirement???
  
  

  • OpenGIS Consortium has published specs for this
    2001-03-18 00:52:30 Simon Cox [Reply]
    
    The OpenGIS Consortium (www.opengis.org) has been
    developing open specs in this area, with the collaboration and commitment of the major players
    in the geospatial industry. See in particular
    Web Map Server
    Web Feature Server/Service
    Geography Markup Language
    linked from the webpage
    http://www.opengis.org/techno/specs.htm
    
    
  • Client Side Processing Tips
    2001-03-16 23:07:06 Anand Bashyam Narasimhan [Reply]
    
    AS much as I would greatly appreiciate the idea behid TAXI and how you have showcased it through your example of Maps, it would help it if some amount of detail can go into it wherein you can discuss various ways of client side processing of the XML data say with respect to a Database ResultSet in mind
    
    
    • Client Side Processing Tips
      2001-03-23 04:39:01 Big Rat [Reply]
      
      I couldn't agree with you more, Tim. I have an application server which calls our legacy code via a scripting language I made myself (RatScript) and produces XML data streams from GET/POST requests. In the HTML pages I use MS-XML objects to load and process the XML via (mostly) XSL (sometimes straight DOM API calls) in Javascript to produce the HTML (in some cases VML).

      
      People say, what about Netscape and so on. I say "Let's do it first, see what the customers buy second, and worry about the past when we retire"

      
      Rat's Wish: XML DOM & XSL Transform as part of Javascript standard (then I don't need to rely on MS)

      
      BigRat@t-online.de
      
      

      • Brower vs Good old Multi-Tier Client Server
        2001-03-26 18:13:32 PK Y [Reply]
        
        Hi guys,

        
        The idea of browser client is great on paper and does work for most, non-time critical, non data entry centric applications.

        
        The lack of many desktop integration features in a browser app. is just not fleasble in building feature rich clients, plus a lot harder to build compare to traditional clients, due to the various limitations of HTML and browsers.

        
        But the big problem that back-fire many many projects are, reporting and printing. No project is complete w/o reports, yet, HTML is just not rich enough to deliver high quality reports easily; the high customizability of browsers easily make your report looks supurb on one desktop but horrable on the other. And printing is just a no-no; come on boys, there is no 'page break' concept in HTML!

        
        And then here comes the much bigger problem - multi-casting; one major advantage for moving towards multi-tier client/server is that server can push data down to the clients, at real time. Right you can write java applet to do that but then you are writing a java application, downloaded and run in the client's browser.

        
        So what's the future? Thinking about it, all these web-browser / web-server things are nothing more than vendor provided middle-tier product. In the old days, we use RPC/Cobra/MQ to invoke server code; now, we use SOAP, SSL, HTML.

        
        What do we gain? Large part of the networking and server management code are done by the web-server; we only need to concentrate on building the core application. Because web-servers are so widely used, due to the internet gold rush, unlike the 'pre-Gen-X' middle-tier buggy products, they are tried and working.
        
        

        • Brower vs Good old Multi-Tier Client Server
          2001-04-03 07:10:57 Joe Golden [Reply]
          
          Anumber of the reason you mention for why existing Web technolgy makes for bad multi-tier client server, is why Curl was created (www.curl.com).