Web Database Innovations

Now that Internet years are about the same length as lead times for monthly print publications, writing a column on Web application development tools is a little risky. Between my May deadline and our August publication date, an entirely new architecture may be introduced and accepted. Well, that's what makes this industry so interesting and fuels the continual demand for articles. In this column, I will discuss several of this month's strategies for developing and deploying database applications on a Web site. To illustrate these strategies, I will discuss three products that are available now.

We are as interested in technology and architecture here as we are in specific products, although we will get into some product details to illustrate both their capabilities and the difficulties inherent in successfully introducing new development paradigms. The range of technology strategies for implementing database-oriented applications on a Web site is rather extensive. Those I will review this month use application servers accessed from the Web site via CGI, ISAPI, or NSAPI. The technologies that underlie the application servers themselves include dynamic HTML generation through proprietary processing engines, DCOM objects, and JavaScript. I will not discuss Java-based technologies or products this month, nor will I consider what Microsoft Corp. is pushing -- currently the company wants us to use Visual Interdev to create Active Server Pages. I'm not ignoring them because I discount those technologies. Au contraire -- they are so important that they merit a more focused discussion; I expect to come back to them in future columns.

The technologies you can choose for implementing database applications on your Web site follow the evolution of Web technologies from static HTML pages to the deployment of scripts and applets on both client and server platforms. The developers of the original HTTP provided a mechanism -- the Common Gateway Interface, or CGI -- for the Web server to access other resources or processors in its local domain. Most vendors of Web server extension tools continue to support CGI, even as they add support for more advanced APIs such as Microsoft's ISAPI and Netscape Communication Corp.'s NSAPI. As businesses increasingly deployed Web servers, the most common need for extended functionality was to make the results of a database inquiry available to browsers. Web developers wrote custom programs that performed such queries, formatted the results in HTML, and called them through CGI.

The first generation of Web data access tools wrapped the process of invoking queries through CGI and returning results as HTML in familiar-looking query builder interfaces and allowed developers to specify templates for how the results should be presented. They provided additional assistance with support for some debugging and error-management functions. Products built according to this architecture, such as Allaire Corp.'s Cold Fusion and Everyware Development Corp.'s Tango, continue to support query-intensive applications very effectively. Having been initially developed with relatively early Web tools, current versions of these products tend to be mature, stable, and well documented. These attributes are often more important to information system developers than the latest technology.

Over the past 18 months, demand for interactive Web database applications has been the driving force behind the proliferation and maturation of multitier application server architectures. These are taking an impressively wide range of shapes. Several of the products that I find interesting leverage development tools and deployment technologies initially developed for slightly different purposes. Borland International Inc.'s IntraBuilder includes an application server that runs in conjunction with a Web server and an IDE for building applications that emits code written in JavaScript, with custom extensions. Although Netscape initially developed JavaScript to provide browser based scripting of HTML objects, here Borland is using it as a complete application development language executing on a server. Antares Alliance Group's EdgeworX product encapsulates HTML in DCOM objects and leverages Visual Basic for Applications (VBA) as a scripting environment. Although Microsoft is attempting to reposition DCOM as a distributed component architecture for Internet applications, that was not its original intent. Nor was VBA designed to serve as a scripting environment for Web applications. We shall see what advantages and challenges these technologies bring to the party.

Dancing Through CGI

The other actions offer mechanisms for flow control and extending the application. Branch actions permit specification of a condition and a resulting action that the application should jump to. Stop actions terminate execution of a branch. "No operation" actions allow presentation of static pages defined as HTML code without any data or application processing, and they supply a vehicle for assigning global Tango variables. The dialog for defining no operation actions contains a menu for inserting "Tango language" statements but lacks a corresponding menu for HTML tags; such a menu would make it much more usable. External actions call external dynamic link libraries and retrieve the result of their execution.

Tango associates a definition dialog with each of the query type actions. When one of these dialogs is open, another dialog is available that lists tables available in the current database and allows columns to be dragged into the dialog. The Select query dialog presents three tab pages. The first allows specification of the level of aggregation, as well as the set of columns to display in the result. The next displays a grid on which the designer enters selection criteria. These criteria can reference variables collected on the search page. The third page presents a form for indicating query parameters, such as the maximum number of rows to return. This interface started its life as the query tool for Everyware's own RDBMS product, and its strict SQL orientation is evident. Openness to multiple back ends via ODBC connectivity is a recent addition to the Tango arsenal.

Tango presents an alternative user interface; this can be confusing. The alternative interface consists of two expert style dialogs that ultimately generate query documents with the standard Web query application structure. This model presents the browser first with a form for entering search criteria, then a results list with hyperlinks to a form that presents further details for the selected row. This form can be editable. Of the two expert style dialogs, one generates search and update applications and the other generates insert new record applications. Using the expert is the only way to get the Tango application builder to create an HTML page for entering search criteria. Using the tools to update existing queries is a somewhat convoluted process. Some of the idiosyncrasies of the user interface are also difficult to overcome. For instance, in Tango, the right mouse button does nothing; I'm guessing that this is a result of its Mac lineage. Concomitant with the avoidance of right-mouse menus, there is an excessive reliance on having to initiate commands from application menus and on double-clicking to open objects. On the other hand, Tango's drag-and-drop support is pretty flexible.

With the query document's decision tree metaphor, you can build some fairly complex little Web applications. Doing so puts a lot of work on the Tango application server. You deploy a query document as a single file. Your Web server calls TangoCGI.exe/ with the initial action as a parameter. The Tango application server presents the opening search form that the Tango editor generated (or one that you wrote in HTML using the "No Operation" action). Once the person behind the browser enters initial criteria and submits the criteria form, the application presents the query to the target database. I inferred that Tango executes these queries as ODBC-compliant SQL. I was unable to determine from its behavior whether it generated the SQL from the dialog entries when I saved the query document or at run time. It presented the result set to me and appeared to do some caching of the result set so that it can return details of any one of the rows very quickly.

Pushing JavaScript to the Max

With IntraBuilder, Borland has extended JavaScript and cast it in a role as a language for running application servers. IntraBuilder adds full object orientation to JavaScript with formal classes and an inheritance hierarchy. Predefined classes represent data components, forms, reports, and queries. IntraBuilder permits inclusion of standard JavaScript for execution on the client browser. IntraBuilder's extended JavaScript runs only on the IntraBuilder application server. Developers use the IntraBuilder Designer to create complete applications; they can enhance those applications by modifying or extending the generated code. With the IntraBuilder runtime architecture, multiple instances of the IntraBuilder server share a processor with the Web server. When a client requests an application, the Web server passes that request through to the IntraBuilder server, which runs the specified application. The IntraBuilder server converts application objects into HTML, which it returns to the Web server for presentation back to the client.

In developing the IntraBuilder Designer, Borland was able to leverage its expertise in producing integrated development environments (IDEs) for business applications. IntraBuilder Designer looks and feels very much like dBASE for Windows (see Figure 2, page 94); like other development products, Borland has implemented the design surfaces as two-way tools, so that components can be edited in the designer or as code. The IDE employs the file cabinet metaphor, with separate folder tabs representing collections of entry forms, reports, scripts, tables, queries, images, Web page description files, and developer-defined custom components. The form and report design surfaces present a reasonably accurate representation of how the target component will look in a browser. The form designer in particular is fairly flexible. Its tool palette includes ActiveX controls and Java applets as standard components, in addition to the usual edit box, list box, and button types of controls.

The form designer tool palette borrows metaphors for data access controls from Delphi and provides prebuilt controls for navigation and database updates. Developers can build custom components and add them to their control palettes. JavaScript's object-oriented nature facilitates creating custom controls based on existing controls, and it allows subclassing of data access components. Taken in their entirety, the IntraBuilder design tools are well designed but need work on execution. Even with the alignment tools, I had a difficult time laying out forms and reports exactly how I wanted them. It seemed that every slight change I made intentionally would cause some other small unintended change in layout.

Although extended JavaScript is a powerful object-oriented language, as IntraBuilder is a powerful development tool, there is a price for power. Developing simple forms is a fairly simple exercise in the designer, but connecting one form to another, or defining a transaction update based on user entry, takes writing code. JavaScript is not a difficult language to learn, but it is extensive, and the designer tools emit a substantial amount of it. JavaScript's object-oriented syntax bears a remarkable resemblance to that of Borland's dBASE for Windows product, reflecting a common lineage. The problem I have with extended JavaScript is that its flexibility quickly leads to very deep object hierarchies, and it does not lend itself to a convenient shorthand notation. To simply assign a value to a column in a table, I had to refer to the column by object reference, which resolves to this.form.query.rowset.fields["field name"].value. Together with the sheer volume of code you have to manage, this makes IntraBuilder appropriate only as a tool for committed database application developers.

HTML Components on Edge

EdgeworX offers yet another IDE, and it's one that's not especially intuitive. It displays the components in your application in an explorer-style outline control. (See Figure 3.) For each application that you build, you create one or more documents. At run time the Edge server will render each document as a separate Web page. A document can incorporate forms and certain objects, including links, images, list maps, and HTML tags. A form can incorporate these objects, as well as common field-level controls. EdgeworX really treats these all as objects; each has an associated property dialog that permits the developer to set the values for each of the object's properties. Each object's properties correspond to the HTML parameters that can be assigned for an object of its class; for example, a button's properties include type, name, image source, alignment, border, width, height, and spacing.

You configure datasources in EdgeworX's Data Access Manager window. EdgeworX can connect with Access- or ODBC-compliant databases. You can create multiple datasources in an EdgeworX repository, and each datasource represents a connection to a single database. Within each datasource you can define multiple recordsets that represent tables or views.

Rather than use a form painter, you define an EdgeworX application by adding objects to the application hierarchy. For instance, you add a form to a document and set its datasource property to the name of a recordset that you created in the EdgeworX data access manager. Then you add your choice of text entry fields, combo or list box controls, command buttons, and so forth to the form. As you add these controls, tab dialogs appear prompting for property values. When you dismiss the dialog, the object gets added to the application tree. The property dialogs for each object are laid out like control panel dialogs rather than like the property list dialogs that you work with in VB. It's not clear until you have worked with the tool several times and read some documentation that they are, in fact, just property dialogs.

Once you have created the objects that should reside on a form, you need to format the form. To lay out a form, you have to write HTML code. The first time you edit a form's HTML script, all you see is a blank editor that contains object tags for the EdgeworX objects you created. Writing an HTML script is annoying, because it's all longhand editing, and you have to be careful to leave EdgeworX's object tags intact and code around them. It would be advantageous to at least be able to use an HTML editor in conjunction with EdgeworX. More fundamentally, this approach suffers from multiple IDE problems that are inherent in developing with one tool that leverages another. Whenever I look at such products, I end up wishing that the vendor had looked for a way to completely embed their technology in the more widely used tool (in this case, VB), rather than creating another tool that has to run separately.

It also took a little while for me to discover that the objects created in EdgeworX are really part of the COM hierarchy for your application. That only becomes clear when you create your first event script for an object. In response to the Edit Event Script command, EdgeworX launches the VBA IDE and positions you in the VBA script editor for the default event assigned to the selected object. Once in the VBA IDE, the true nature of EdgeworX becomes more clear; all of the documents and forms that you create in the EdgeworX IDE now appear in the VBA project explorer. EdgeworX defines generate, pregenerate, and postgenerate events for documents and forms; you write the code that executes when these events occur in the VBA editor.

Why Did I Write This Column?

While these tools overlap in the types of applications for which they are effective, it's possible to draw some distinctions. EdgeworX clearly has the edge where integration of Microsoft Office objects with Web applets is desirable. With VBA, automation in EdgeworX is identical to automation in the Office 97 suite. By virtue of its language capabilities and flexible database-management tools, I would suggest IntraBuilder for Web database applications with extensive relational update and transformation requirements. Its built-in reporting tool makes it quite capable of implementing industrial-strength database reporting applications as well. Of the three, Tango represents the fastest way to implement a query-oriented Web site.

Investigating IntraBuilder served to alert me to the capabilities of JavaScript and was one factor that triggered my downloading a beta copy of Netscape's Visual JavaScript product. The IntraBuilder model of a server-side JavaScript enhanced with a collection of database objects is a very good one. EdgeworX demonstrates how to leverage DCOM in a Web application server. Although its application builder displays the immaturity of many 1.0 products, the server-side architecture promises to be as scalable and robust as a Windows NT-based platform can be. Tango is a very interesting product that presents an interesting perspective on what visual programming could become. As development tools seem to be moving further away from nonprocedural definition of application functions and requiring that we write more code, Tango is a nice reminder that developing applications does not need to be a code-oriented task.

Figure 1.

Figure 2.

Figure 3.

What did you think of this article? Send a letter to the editor.