DBMS

Cold Fusion 1.5 and Autobahn

By P.L. Olympia, Ph.D.
DBMS, July 1996

Cold Fusion 1.5

Allaire's Web application development platform lets you create applications that integrate relational databases with the Web via Intranets and the Internet.

Autobahn

Speedware's server enables you to create and deploy dynamic Speedware, Cobol, or C programs on the Web.

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.

First, A Little Background

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.

Cold Fusion 1.5

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.

How Cold Fusion Works

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:

<FORM ACTION="cgi-shl/dbml.dll?template=myprog.dbm METHOD=POST>

In this example, dbml.dll is the ISAPI-compliant version of Cold Fusion, and myprog.dbm is the Cold Fusion template containing the commands to talk to a SQL database or output query results. The Cold Fusion engine processes the directives embedded in the template file, sends the appropriate commands to the SQL database, and then generates the output HTML page that the Web server hands back to the user.

Clearly, the real work is in developing the template file. A Cold Fusion template file is simply a text file consisting of the usual HTML commands and a new set of HTML-like commands called database markup language (DBML). They were designed primarily to converse with a database. Four essential DBML tags are: (1) Dbquery, to submit a SQL query, (2) Dbinsert, to insert database records, (3) Dbupdate, to update database records, and (4) Dboutput, to display the query results.

To create appealing HTML output pages, you'll need to be conversant with HTML tags and a few DBML tags such as Dbtable and Dbcol. You may nest Dboutput tags to create report-style data grouping. Your Dboutput command block may include dynamic references to database field values; for example, #LastName# displays the value of a record's Lastname field. The block may include formatting functions as well. An example of this is #DollarFormat(AmtOwed)#, which displays the value of the field or variable AmtOwed in currency format, and enclosed in parenthesis if the value is negative.

To give you an idea of what can be done with Cold Fusion, Figure 1 (page 33) shows the merchandise order form screen from a real Internet storefront application that maintains its data on an Oracle database running on a Windows NT server. The application was developed in less than a week and uses HTML 3.0 frames (supported by browsers such as Netscape 2.x and later).

Additional Features

Conventional HTML forms lack two common requirements of a database application form: the ability to define certain fields as required fields and the facility to enforce predefined validation rules on user input. Cold Fusion solves both problems through the use of "hidden" fields. The following statement is an example.

<INPUT type="hidden" NAME="SSN_required" VALUE="You must enter a social security number">

In this example, SSN is defined as a required field. Users see the message defined in value if they do not provide a social security number.

The product supports conditional processing through Dbif and Dbelse tags. The Dbif tag, when combined with the Dbsql tag, lets you assemble SQL commands dynamically based on user input on a data-entry form.

Cold Fusion lets you create and send email messages. This is a nice feature not only because your mail message can contain database query results but also because your list of addressees itself could be dynamically generated from a SQL query. The Dbmail tag is what you use to create mail messages. Luckily this tag is virtually identical to the Dboutput tag, so without realizing it, you already know how to pepper your associates with junk email.

Speedware Autobahn

Speedware advertises Autobahn as the first 4GL for the Internet. On another sheet, the product is described as "a new Speedware server that makes it easy to create real business applications for the World Wide Web." I'm confused. For some reason I can't envision something that is both 4GL and a server at the same time. Check out the Tom Ski Shop Autobahn application demo, and get relevant information from Speedware's Web site at http://www.speedware.com. The demo uses Oracle, Sybase, and Informix data. The demo contains a few errors that I have already pointed out to the vendor and hopefully will have been corrected by the time you visit. The main screen of the application is shown in Figure 2.

Actually, Autobahn is a CGI gateway program or script (residing on your server as the executable file "Autobahn.exe") that can converse with many popular DBMSs (including Oracle, Sybase, and Informix) through what the vendor calls the Speedware Open Application Server. Autobahn is supposed to work under Unix and MPE (Multiprogramming Executive, a Unix-like OS) as well as under Windows NT. I tested the product under Windows NT. At press time, the product was still in beta. Normally I don't write about beta software, but Autobahn has attracted so much interest of late that I feel duty-bound to at least let you know something about it. Consider this mini-review a first-look article, and remember that any product deficiencies I mention could well be corrected at ship time.

For this review I used the same Windows NT server that I used to develop Cold Fusion applications. This time, however, instead of using IIS as my Web server program, I used a free trial version of O'Reilly Associates' WebSite product. Speedware provided me with a CD-ROM disk (labeled "Orange version, February, 1996"), containing, apparently, a beta version of the entire Speedware software product line. All system documentation is online in Adobe Acrobat portable document format. This is unfortunate because, to be perfectly honest, Autobahn is not an easy product to comprehend and the online documentation does not explain some critical terms such as "Autobahn Agent." I believe the documentation should at least discuss one of the demo applications provided on disk. I don't think Speedware has done an adequate job explaining which part of the system is Autobahn and its exact relationships with the other products whose modules it uses.

Installation

I had quite a time just installing Autobahn on the NT server and testing the demo applications that come with the product. To their credit, the Speedware technical support folks stayed on the phone with me for hours into the middle of the night.

To install Autobahn properly on an NT server, you need to install four modules in the correct sequence. These modules are, in order, (1) Speedware, (2) Resource Manager, (3) Autobahn, and (4) Designer Server. Each module creates its own program group, with the Autobahn group containing nothing but an .ini file, a Readme, and an uninstall icon. The Speedware program group contains the icon for Speedware/4GL, and four others. Don't be tempted to click on any of the three Make icons (Make Profile, Make Config, or Make Catalog). If you do, there is no way to end the session or get out of it. Much later, I learned (from tech support around midnight) that to get out without rebooting you must type EXIT (in uppercase) followed by a semicolon, in response to the program's prompt.

After you install Autobahn you will have an NT service called Autobahn Server. Naturally, you'll need to activate this. If you uninstall the product and re-install it (an exercise I had to do more times than I care to admit), you come to a dead end because the Autobahn Server service from the old install remains on the list but leads nowhere and the result of your current install is nowhere to be found. You must delete the old service from the NT registry, and therein lies a problem that you'll need a Harvard Ph.D. to solve. This is not Speedware's fault, however; the uninstall program cannot delete the old Registry entry because of NT security.

How Autobahn Works

Autobahn, like other CGI scripts, only requires a client to be running browser software. You can invoke Autobahn from an HTML page that contains nothing but a URL line that might read something like: http://wwwtest/cgi-bin/Autobahn.exe/Browse

Here, Autobahn.exe is your so-called "Speedware Autobahn Agent" (looks like a CGI script, no?). Browse is a directive that instructs the Autobahn server to list all available applications. Each item on the list is a hot link. Click on it, and the target application is launched.

Autobahn tries to maintain state by assigning to your session a unique Dynamic Session ID (DSI), which binds you to the application. Through the DSI, the server tracks your session and any pertinent variables you need or use, even when one program chains to another.

If you already know which Autobahn program to invoke, you can dispose of the Browse command in the URL line shown previously, using instead the Execute command followed by the name of the application you want to run and any parameters that application requires.

Developing Autobahn Applications

An Autobahn application consists of two major components: Autobahn HTML templates and Autobahn application programs. An Autobahn template is nothing more than a normal HTML document that has been enhanced to include dynamic substitution variables and tags that are understood by the Speedware/4GL processor. For example, the SPWBLOCK tag defines a named block containing variables that the Speedware engine can interpret and process. You can launch the Autobahn application program from the template through the use of the HTML tag called META.

So what is an Autobahn application program and how do you write it? The program looks like a Basic program to me, even though Speedware insists on attaching the 4GL label to it. The application program consists of two modules (Speedware calls these "sections") derived from the Speedware/4GL product: Logic and Report. The Logic section contains the application's processing logic and procedural routines. Here you can use the customary processing verbs such as if-else and while-do. The run command lets you execute an external program, and the command verb lets you execute operating system commands.

For users to see the output of a Logic section, the section must pass its results to a Report section. The Report section, which normally prints the results on a physical device such as a printer, can redirect its output to a Web page through a Report section declarative statement such as:

DCLPRINTER html ASSIGN(DEVICE=SLAVE) DEFAULT 

How does a 4GL print results? Following are three examples:

PRINTHTML "cashier.htm" "NO-RECORDS"
PRINT 'This is a line from 4GL'
PRINT ';

This looks suspiciously more like BASIC to me, rather than a 4GL.

My Recommendation

Speedware Autobahn will get better by the time it ships, I am sure. If you need to deploy Web applications quickly and you have the appropriate ODBC drivers for your back-end databases, there is little question that you would want to get Cold Fusion. With it, there is hardly any programming involved; you could go a long way with just a little knowledge of HTML and SQL. Furthermore, the Cold Fusion manual is superb. It is a thin volume but contains almost everything you need to get going. The product also comes with a rich set of ready-to-run examples from which you can learn. At Allaire's Web site you can download a few outstanding Cold Fusion add-ons, appropriately called Fuel Packs, including a Java Graphlet.


Pete Olympia has a doctorate in chemical physics and is the author of several books on dBASE and FoxPro. He is the author of MemoPlus, a memo file handling/repair utility, FPNet, a FoxPro API library of NetWare functions, and RDsecure, a dynamic NetWare rights server that ensures the security of application data. You can email him at polympia@erols.com or 73765.121@compuserve.com.
Table of Contents - July 1996 | Home Page
Copyright © 1996 Miller Freeman, Inc. ALL RIGHTS RESERVED
Redistribution without permission is prohibited.
Please send questions or comments to mfrank@mfi.com
Updated Saturday, July 20, 1996