Once upon a time, back when mainframes ruled the land, people cried: "We want to be closer to our data!" And so it was that everyone came to have a PC. But soon people started demanding data and application sharing. And so it was that LANs came to rule the land. But not for long. The LANs started choking from all that data traffic, and people cried: "We want client/server!" Soon client/server ruled business departments, but people wanted more. They wanted enterprisewide client/server, and because they were spread around the world they wanted worldwide client/server with thin clients. Eventually, someone came up with the brilliant idea of giving them client/server-server-server-server-server/client -- in short, the Internet.
And that is how we came to have Web-based client/server. In this review I discuss two software products that help you deploy corporate client/server applications on the Internet or Intranet: Allaire's Cold Fusion and Speedware's Autobahn.
When you think about it, the Internet's World Wide Web is the ideal medium for deploying client/server applications. Apart from global availability, the Internet makes very little demand on clients -- they can be running on any operating system and they can be Twiggy-thin with just enough RAM to run browser software.
The increasing popularity of Web-based client/server applications has given a new dimension to delivering information to clients anywhere around the globe. Where before users had to be content in being passive recipients of data delivered through static HTML pages, they can now be fully interactive, able to specify database query conditions and receive results through the same HTML documents. What made this possible initially was the advent of HTML 2.0 and the Common Gateway Interface (CGI) mechanism. The HTML 2.0 specification includes support for data-entry forms, which can contain the usual GUI widgets such as text boxes, check boxes, list boxes, and radio buttons.
CGI is a widely used standard for allowing the Web server and server-based programs or scripts to communicate with one another. The Web server receives the data supplied by the user on an HTML page form, hands the data to the CGI script that processes it (typically by talking to a server-based DBMS), and gives the result back to the server, which turns around and returns the output to the user. An important advantage of a CGI-based application is its portability; it can be ported across Web server platforms.
However, one major problem with a CGI-based system is its statelessness -- every client request requires establishing a new connection that is terminated at the end of the request with no memory of previous requests or transactions from the same client. (I like to call it the Amnesiac Computing Model -- great for the server that gets introduced to a "new" client every nanosecond.) You don't have to be a Nobel laureate to figure out that this process is slow, memory-intensive, and requires quite a bit of overhead in executing or re-executing a program (especially a DBMS program) and initializing it for each client request.
So what's the alternative? A Web server API. Web server APIs (for example, Microsoft's ISAPI or Internet Server Application Programming Interface) are more efficient than CGI because they require comparatively less memory and they must be initialized only once. Additionally, they can maintain state and so are able to retain critical information about the client across multiple client requests. Server APIs are also great news for developers because they facilitate customization or extension of server functions.
What's the disadvantage? Clearly, Web server APIs are bound to specific servers. For example, ISAPI currently binds the application only to a set of Web servers that includes Microsoft's Internet Information Server (IIS) and Process Software's Purveyor WebServer. On Windows platforms, you develop Web server applications using DLLs (dynamic link libraries). The first time a user requests a service from a DLL, the library is loaded into the server's memory and stays there until it is removed. Thus, a database connection can be held open across client requests because the program remains in memory.
Allaire's Cold Fusion is one of the first and most popular tools for developing Web-based database applications. Version 1.0 of the product was a CGI-only tool. Version 1.5, available since the first quarter of 1996, adds support for ISAPI. You can download a copy of the software for a 30-day free trial from Allaire's home page at http://www.allaire.com. For this review, I used the ISAPI-compliant Cold Fusion 1.5, supplied by Allaire, on a Windows NT server running Microsoft's IIS (downloaded from Microsoft's Web site, http://www.microsoft.com).
Cold Fusion communicates with your database through ODBC. As it turns out, the hardest part of working with Cold Fusion is not developing applications with it. Actually, the product is easy to use and good at what it does. The hardest part is in getting started with the project. It is a story worth telling if only because it may save you from going prematurely gray, so bear with me a bit.
Our corporate DBMS standard is Oracle. Cold Fusion does not come with a 32-bit ODBC driver for Oracle. Surprisingly, neither does Oracle. Faced with an extremely tight deadline for this article, I decided to try Intersolv's heavily promoted DataDirect product. After many futile hours of working with Intersolv's technical support folks trying to get the driver to work, however, I gave up. What does work is Visigenic's ODBC driver. If you want to save money, you can use the same Visigenic ODBC driver that comes bundled with your copy of Visual Basic 4 professional.
Cold Fusion is one development tool that is elegantly simple yet delivers what it promises. If you have some familiarity with HTML and SQL, you could develop serious Web-based database applications with Cold Fusion in a day or so. Like other CGI scripts, Cold Fusion is invoked from the action attribute of your HTML form. For example: