Agencies at every level of government have a wealth of information in legacy databases that needs to be accessed or shared. Whether the agency wants to share this information internally or externally, the problem is essentially the same: making the information available in a secure, accessible way that minimizes development time and keeps application maintenance costs to a minimum.
As the world races toward universal acceptance of the World Wide Web, many are looking to the Web as the way to solve this problem. Admittedly, the Web offers some powerful advantages: Access is nearly ubiquitous; it is platform independent; existing infrastructures can be used, often with few or no changes; and the same technology can be used for internal as well as external applications.
Despite these advantages, the protocol that makes the Web work (Hypertext Transfer Protocol or HTTP) leaves much to be desired when building robust client/server applications. HTTP is a rather simple protocol:
* The client, typically called a browser, requests a file from a program called a Web server. Usually, the Web server is running on another computer so the request is done over a corporate network or via the Internet. The requested document usually includes embedded Hypertext Markup Language (HTML) "tags," which describe how the document should be displayed. Some tags may also include references (links) to other documents or images.
* The Web server looks for the document and, assuming it finds it, sends it to the requesting client.
* The client reads and formats the document in accordance with the embedded HTML tags.
If the client later wants another document, the above cycle is repeated. The fundamental problem with using HTTP as the basis for robust, interactive applications is that it has no memory. HTTP doesn't provide a means for knowing whether the same user has made one request or a thousand requests. This approach works perfectly for the original intended purpose: to provide a simple way to organize research data and make it accessible. However, it does not work for most database-related work that requires a "session" -- an ongoing connection between the database program and a particular user.
For example, suppose a user is looking at an alphabetized list of people in a mailing list and wants to scroll down to see the "next" group of names. In order to provide the "next" group, the application program needs to know which query produced the list of names and which names are currently displayed. HTTP isn't capable of this kind of interaction -- as soon as a document is delivered in response to a request, HTTP forgets everything related to the request and the requester. In more technical terms, this lack of session continuity is called a "stateless connection," meaning the server does not keep track of the "state" of the client.
Due to the statelessness of HTTP, Web-server software can operate very quickly and, with very few exceptions, doesn't need to know anything about the content of the documents it provides: It simply finds the requested document, checks file permissions and, if allowed, returns it to the requester.
Expanding the capability of Web-based applications are programmers and vendors who have devised ways to create what might be called "pseudosessions." These solutions all amount to different ways of keeping track of values between HTTP requests. For example, these techniques can let a user enter his name in a Web-based form, store the name so that the next time he requests a document (whether six seconds or six weeks later), the Web-server software appears to remember the user's name.
The limited functionality of Web-server software can also be expanded by installing "partner programs," which work with the Web-server software and provide functionality not present in the software itself. Here's how it works:
* The client makes a request.
* The Web-server software sees the request and recognizes it as "belonging" to one of its partner programs. It sends the request to the appropriate partner program.
* The partner program carries out the requested action. This could involve running a program, asking a database for some information, formatting a report, uploading or downloading a file, etc.
* The partner program returns an HTML file to the Web-server software; this may be as simple as a message stating it completed the task, or it could be a fully formatted summary of information returned from a database.
* The Web-server software sends the document to the requesting client. As far as the Web-server software is concerned, it received a request and returned a file. It doesn't know or care how the file was created or what occurred behind the scenes.
* The client reads and formats as usual.
A growing number of solutions and languages exist for creating these partner programs. However, many require sophisticated programming skills often beyond the experience of people who have cut their development teeth writing HTML (see "Cold Fusion Advanced Capabilities" on page 68).
This is where Cold Fusion enters.
Cold Fusion, developed by Allaire of Cambridge, Mass., consists of several pieces:
* The Cold Fusion Server (CFS) is a program that works cooperatively with Web-server software. When a user requests a page with a ".cfm" extension (as opposed to the usual ".html" or ".htm" extensions for ordinary HTML pages), the Web server passes the request to CFS, which reads and interprets the Cold Fusion commands in the document. These commands may instruct CFS to query a database, upload a file, set the value of a variable, etc. After the commands have finished, CFS sends a standard HTML page to the Web-server software, which returns the page to the client browser via the network.
* The Cold Fusion Markup Language (CFML) contains the Cold Fusion commands that are understood by CFS. Like HTML, CFML consists of simple tags added to text documents. However, unlike HTML, most CFML tags do not tell the client browser how to display a document. Instead, CFML tags give CFS instructions that are carried out before the page is returned to the client browser. CFML pages are stored in files called Cold Fusion "templates" and are identified by the ".cfm" extension.
* Cold Fusion Studio, sold separately, is a development environment specifically designed to facilitate creation of Cold Fusion templates.
COLD FUSION MARKUP LANGUAGE
Since CFML is a markup language, it is quite easily learned by people with little to no programming experience. "There are very basic prerequisites for learning Cold Fusion," said Steve Drucker, president of Figleaf Software and co-author of The Cold Fusion Web Database Construction Kit. "You need to know HTML and have some knowledge of SQL. With that, the beginning course takes you through developing a full-blown order-entry application. Actually, anyone who sits with [Cold Fusion] for a couple of hours is amazed what they can do with it."
This ease stems from the fact that any complexity associated with connecting to and requesting information from a database is transparently handled by CFS. All the developer needs to know is the CFML tag that defines a query and the tag that displays the query results.
Instead of training an HTML writer on an entirely new scripting language, he or she can be taught new tags that are used in the same way as the familiar HTML.
COLD FUSION SERVER
The CFS is Windows NT- or Sun Solaris-based server software that runs in association with a Web server. When CFS is installed, the associated
Web-server software is automatically configured to pass all requests for files ending with ".cfm" on to CFS, which reads the CFML tags in the requested file, carries out the specified actions and returns an HTML document to the Web-server software.
On testing, CFS software was easy to install. Configuration was largely automatic and a Web-based utility is available through which administrators can change Cold Fusion parameters, define sources of data, turn debugging off and on, and perform other common tasks. This administration screen can even be accessed remotely -- a convenience for the system administrator who receives a support call at home from an application group working in the evening or over the weekend.
According to Drucker, CFS performance is good and scales well. This tends to be supported by the existence of some well-known, high-access Web sites that depend on Cold Fusion (see , for example).
CFS allows developers to easily create pseudosessions without having to delve into the details of how it is done.
COLD FUSION STUDIO
Although Cold Fusion Studio is sold separately from CFS, it is intended as an integrated development tool. It also ships with a single-user version of CFS, making it easy for developers to build Cold Fusion applications without the initial investment needed to purchase CFS.
Studio nicely combines the editing capabilities of Allaire's HTML editor, Homesite, with facilities geared specifically to the Cold Fusion developer, including tool bars that give push button access to Cold Fusion tags. Although this type of functionality is common to most HTML editors, Studio fortunately avoids the trap other editors fall into: trying to make things too "easy." Many HTML editors try to shield developers from the underlying HTML by providing a graphical user interface (GUI). The problem with this approach is simple: With the exception of the most basic HTML pages, the GUI usually gets in the way. Most developers prefer to work with plain-text HTML files, so they have direct access to HTML tags and can more precisely place text and images. Studio is set up to let developers work this way.
A particularly nice feature of Studio is its integrated GUI query builder; this helps the developer write and test database queries before cutting and pasting them into the actual application code. John Stanard, a Web application developer based in Northern Virginia, particularly likes this feature. He tested numerous HTML editing tools before settling on Studio.
"As a Web developer, I've found Cold Fusion Studio to be one of the best tools I have used," commented Stanard. "It's integrated database connectivity, project management and version control features have reduced development time enormously."
David Aden is a senior consultant for webworld studios -- a Northern Virginia-based Web application development consulting company.
June Table of Contents