Of course, there are other, less exotic ways to move data. A typical office PC running Windows can easily be a peer file server. A central replication service could simply pull entire database files from a group of machines, sort out their differences, and put them back. The file-oriented approach sacrifices granularity, though. When you grab whole files, you can’t ask for just yesterday’s records. More generally, it sacrifices all the benefits that flow from a true distributed computing model. A distributed HTTP service is, I’m arguing, as fundamental to a web-centric model of computing as is a browser. Think about what Windows brought to the table back when DOS reigned: large memory, a GUI, device independence. Once developers could assume these services were available—wherever their code ran—there was no looking back. The dhttp model brings a new core service to the table—a lightweight, scripted, HTTP-aware service that connects local and remote applications and services to resources on the local machine.
That dhttp can serve files is, as we’ve seen, the least interesting of its capabilities. Products such as Microsoft’s Personal Web Server haven’t caught on widely as desktop-based applications, because they don’t really solve a new problem on the LAN. What made first-generation web servers interesting was the way they made the whole Internet a giant LAN. With peer file sharing, I can already grant you access to files on my disk, so in that respect a local web server is largely redundant.
Of course, the Internet web server soon evolved into something more akin to an object request broker than a file server. Like ORBs, web servers connect clients to methods, which in turn connect to data. This ORB-like quality, along with the simplicity and universality of the HTTP protocol and the web programming model, is what makes the dhttp technique useful. Consider the invoice function of the Jobs module. In a standalone context, it’s just one of any number of ways to automate Microsoft Word. You could equally well use a Visual Basic for Applications (VBA) macro to clone a Word document from a template, merge ODBC data into it, save it, and print it. In a LAN context, you could export that VBA macro to a group by using DCOM to start a remote instance of Word and then calling the macro in that remote instance. In an Internet/intranet context, you could export it by way of an ASP web page, which could also start a remote instance of Word and call the macro. The third approach is clearly the most general. Done that way, the invoice function will work on the intranet, or the LAN, or on a standalone machine, since an ASP server can run in all three places.
At stake here is the ability to carve applications into sets of services that can be deployed anywhere and that will work the same way everywhere. One of the best expressions of this idea is the Forte Application Environment, a high-end toolset for three-tiered software development. A Forte developer writes GUI, business-logic, and data-access services in Transactional Object-Oriented Language (TOOL), the Forte scripting language, without regard to where those services run. When it’s time to deploy the application, the developer partitions it, allocating services to machines purely for reasons of convenience and efficiency. To continue with our invoice example, let’s suppose that complex business rules attach to the function that generates an invoice. In Forte’s system you can locate those rules in a middle-tier service, where they’re easier to maintain and update, or you can locate them directly on clients, where they’ll run a lot faster because there’s no network latency.
The Forte toolkit not only makes services location independent, it abstracts multiple GUIs with a portability layer that’s also controlled by the script language. You can write a graphical application once and deploy it to a diverse population of Windows, Unix, and Macintosh workstations. Clearly dhttp relies not on a portable native GUI, but on the browser with its universal HTML/JavaScript display model. That works for applications that can comfortably display using only first-generation browser technology, and a premise of this book is that many useful but unwritten applications fall into that category. The HTML/JavaScript client has yet to be exploited to its full capability. To the extent that new applications do exploit it, they target the world’s largest installed base of application platforms.
Isn’t the installed base rapidly evolving? Absolutely. There are at least three models competing to dominate the next stable plateau:
- Java
So far, Java’s bid to supplant native GUIs with a portable (and mobile) alternative has mostly failed. You can chalk that up to immaturity of the language and tools, restrictions imposed by the sandbox security model, computational overhead of the Java virtual machine, or some combination of these and other factors. Whatever the reason, Java to date is far more successful as a provider of network services than as a replacement for the native GUI. That might change in the next few years, or it might not.
- ActiveX
The power of ActiveX components is seductive. Microsoft’s Developer Network site (http://msdn.microsoft.com/) deploys two versions of a tree control that affords navigational access to a vast collection of documents. One version is Java based, the other ActiveX based. If I need to use that site and I happen to be running Communicator, I’ll switch to MSIE just so I can use the ActiveX version of the tree control. It’s far more effective. It’s also Windows-centric. The ActiveX approach isn’t yet a practical, portable way to extend the capabilities of all browsers on all platforms. That might change in the next few years, or it might not.
- DHTML+DOM+XML+XSL+script
This bubbling cauldron of alphabet soup promises to establish a happy medium. There is, after all, a large middle ground to occupy. The HTML/JavaScript technology, at one end of the spectrum, has done more with a handful of basic GUI widgets than most anyone would have guessed was possible. Complete native GUI capability, at the other end of the spectrum, will always be needed for certain applications, such as visual interfaces to geographic data. But in between these endpoints lie huge numbers of applications that create, edit, navigate, search, and transmit semistructured and structured data. What’s needed here is a richer successor to HTML/JavaScript, and that’s just what is now evolving. To the extent that this effort succeeds, the kinds of user interface techniques we’ve seen in this chapter are likely to remain relevant.
Consider the Jobs module’s data viewer. I chose to write it using only standard HTML/JavaScript constructs, because today that’s the only way to ensure cross-browser portability. One alternate solution that’s just appeared—for MSIE 5 only—is to use a combination of XML and XSL. Using MSIE 5 you can, for example, embed an XML “data island” in a web page and associate that chunk of XML with an XSL style sheet that maps the data into what the browser ultimately renders as an HTML table. I can’t wait for this approach (or something like it) to become a cross-browser standard and penetrate 95% of the installed base of browsers. It’s the appropriate successor to HTML/JavaScript.
When that successor arrives, the need for script-driven template processing, à la the HTML/JavaScript user interfaces shown in this chapter, won’t go away. If anything, it will intensify. How, for example, will XML get into the web page? Dynamic generation of the page will continue to afford crucial leverage by enabling scripts to select and tailor the data sets handed to the browser for display. Likewise, how does the XSL style sheet get into the web page? Dynamic generation of the page will again continue to afford crucial leverage, by instantiating different versions of XSL style sheets to support dynamically changing requirements. A page generator will matter as much to these next-generation pages as to today’s pages. And a local page generator will continue to be a useful complement to a server-based one. It’s an enabling service. The more places that it can run, the more it can enable.