Cold Fusion is a reality today. No, not the supposed panacea for the world's energy problems as claimed by a couple physicists in Utah, but as a Web-based application server that can deliver your mainframe data to any Hyper Text Markup Language (HTML) compatible browser. In a nutshell, by combining a Windows 95 or NT system, an Hyper Text Transfer Protocol (HTTP) server, the Cold Fusion Application server, the appropriate Open Data Base Connectivity (ODBC) driver, and the ODBC-compliant data source, you can create Web pages for your company's intranet or the public Internet that interact dynamically with your mainframe-based data.

This article describes Cold Fusion-what it is, how it works, what some of its potential applications are, what is required to use it-and gives clear samples for reference. Although ALLBASE/SQL on an HP 3000 was chosen as the data source for the examples, any ODBC-compliant data source is acceptable. That means you can use any one of a number of back-end database servers and systems ranging from Microsoft Access on a Windows 95 PC, to Oracle on HP-UX, or IMAGE/SQL on MPE/iX. The flexibility offered by Cold Fusion's usage of ODBC cannot be understated.

Cold Fusion, a product developed by Allaire Corporation in Cambridge, Massachusetts, is one of several new products that interact with an HTTP (Web) server to extend normal HTML capabilities into areas such as dynamic page generation. Examples of these additional capabilities are the ability to set and manipulate variables, conditional logic, file I/O, database I/O, etc. In addition to providing these HTML extensions, Cold Fusion can also make use of other Web-enabling technologies. Java, JavaScript, Microsoft Common Object Module (COM) objects, etc., along with extensions to the Cold Fusion language itself via the use of special APIs known as "CFX" tags, all can be integrated. A product like this allows a Web site not only to display predefined information back to a user but also to engage the user in an interactive dialog so that resulting Web pages are created based upon what the user requests or even who he is.

To understand how Cold Fusion can provide these abilities, you need to understand a little bit about how the HTTP server along with the HTTP client (commonly called a Web browser) operate. The client performs two main functions: (1) requesting or supplying information from and to the server and (2) formatting the information received from the server for display back to the user.

Making the request and acting on the information returned is considered to be a transaction. In the HTTP protocol, each transaction is totally independent from those that came before it as well as those yet to come. Thus HTTP is considered to be a stateless protocol. The server recognizes the client only for the duration of that single request. Once the request has been satisfied, the server no longer keeps any information about the request or the action performed.

Contrast this to the normal transaction processing model used in most host-based and even most client-server-based applications-in that model, you know from function to function who your user is. For clarification, consider the sample HTML shown in Listing 1. This simple Web page consists of a page title, a main header, a few lines of text, and two graphic images. Table 1 shows a simplified version of the conversation between the browser and the server that is required for this page to be displayed back to the requesting user (Figure 1). As you can see, to display this single page it took three separate transactions (one for the actual Web page and one for each of the two image files). The three transactions are actually the minimum; there could be more, depending upon the security surrounding the files, their actual location, etc.

Cold Fusion interjects itself into this process after the HTTP server has received the request for the page (Figure 2). The HTTP server, recognizing that the page is a Cold Fusion template, passes control to the Cold Fusion executable program. Cold Fusion then reads the template file line-by-line looking for special tag elements called Cold Fusion tags. These tags define a form of action the Cold Fusion processor will perform. As Cold Fusion processes the template, all non-Cold Fusion elements are simply written to the output file unaltered. When the end of the template file is reached, the completed output file is passed back to the HTTP server, where it is then sent back to the HTTP client for display. You can consider Cold Fusion to be a preprocessor of the template file.

As previously mentioned, HTTP is a stateless protocol. While that works well for simple information request and delivery, it can certainly make programming "interesting" when you need to carry on some form of ongoing dialog between your application and the client. For those of you who have programmed only in a more traditional user environment, you may not readily see the problems that can be caused by this stateless protocol.

Let's take a specific example, involving one of the promises of the Internet-online shopping. A simple version of an online store allows you to browse through a list of available products and place the items you wish to purchase in a virtual shopping cart. When you finish browsing and wish to "check out," you are presented with a list of the items you picked up along the way and with the total amount you owe. At this point, you are given some shipping and payment options, which may include online credit card processing, offline credit card processing, or even billing to a previously established store account. After that process completes, your order is posted, and your delivery scheduled. Overall, this is fairly straightforward and easy to envision.

In the stateless world of HTTP, you need to link your progress from Web page to Web page so the system "remembers" the items you placed in your virtual shopping cart, your shipping and billing information, etc. Since the HTTP server processes each request independently, each must contain sufficient information to identify you uniquely from every other potential "shopper" wandering through the store. Probably the most common method involves assigning a unique customer identification number to you and then returning that ID number to the server with every request. In that way, the server application can store your information in a database on the host, updating it as items are placed into and removed from the shopping cart. Of the several standard approaches devised to address this issue, two types that may be used with Cold Fusion are cookies and URL parameters.

Cookies were first proposed and implemented by Netscape in their HTTP servers and browsers and have since become part of the HTTP standards. You can think of a cookie as a special type of variable. Each cookie is set or established from the HTTP server but is stored on the HTTP client's system. A cookie has the following components:

1.	NAME:	The name by which this cookie is known.
2.	VALUE:	The value assigned to the cookie by the server.
3.	EXPIRES:	An optional value which determines the period of time for which the cookie is considered to be valid. If this value isn't specified, the cookie will not saved when the client's browser is closed.
4.	SECURE:	If specified, the cookie will only be returned to the HTTP server if a secure connection has been established. The default is to allow the transmission of the cookie during normal (unsecured) connections.
5.	PATH:	If specified, the cookie will only be transmitted to the HTTP server when the URL of the document being requested is included within this list. The default is to transmit the cookie to any URL path that matches the DOMAIN attribute.
6.	DOMAIN:	Specifies the domain or sub-domains for which the cookie is valid. Only hosts within the specified domain can set a cookie for that domain. The default value is the host name of the HTTP server establishing the cookie.

Once set, the HTTP client automatically sends all non-expired cookies which match the value of the URL being request from the HTTP server. For example, if a cookie was previously defined by the HTTP server residing on www.editcorp.com without a PATH attribute, then the HTTP client would automatically send that cookie with each request made to that server. That same cookie would not be sent when requests are made of any other HTTP server. Since cookies are sent by the HTTP client, and not pulled by the HTTP server, the information stored via servers in one domain is not directly accessible by HTTP servers residing in another domain. Cookies can therefore be used to simulate a consistent state by having the HTTP server establish a cookie with a given name, but with a unique ID value at the beginning of a series of transactions. The HTTP server then checks for the existence and value of this cookie at each request and therefore knows the history of this client. Cold Fusion has the ability both to set and evaluate cookies.

URL Parameters are used in many different situations. One method of simulating a consistent client state is to pass identifying information as a simple URL parameter (an example of which is shown in the sample application listings). In this case, no information is ever stored on the HTTP client system, and so long as the client progresses through a known series of pages, the simulated consistent state can be preserved. The major problem associated with this type of tracking is that if the client ever deviates from the known series, the state information (and therefore the customer information) is lost. Cold Fusion can evaluate any URL parameters available.

The task of creating a Web page can range from relatively simple to frighteningly complex. As HTML specifications mature, more and more tags are being defined. A tag is simply a reserved word or words that specify a particular action to be performed by either the HTTP server or client. As seen previously in Listing 1, most tags have a beginning and ending form. Tags are specified by enclosing them within less than (<) and greater than (>) marks. The closing tag is identified by prefixing the name of the tag with a slash (/). For example, is the closing tag used to signify the completion of that "text." If a tag unknown to the HTTP client is included within a Web page, the HTTP specification states that the browser is to ignore the tag, along with everything encountered, until the closing tag is reached. This allows new tags to be defined without causing unwanted results for HTTP clients that have not implemented those features.

Cold Fusion also defines a series of tags that make up what is called the Cold Fusion Markup Language (CFML). These tags are also enclosed within less than and greater than marks, and most have a corresponding closing-tag represented by the tag name prefixed with a slash mark (some simple tags do not require the use of an closing tag). You can easily distinguish the CFML from HTML by the actual name of the tag. All CFML tags have names that start with the letters 'CF'. Thus, when you see something like

<CFSET A_Cold_Fusion_Variable_Name = "A literal string">

you know this represents a Cold Fusion Tag, not a standard HTML tag. As with HTML, CFML is still maturing. With each new release from Allaire, new CFML tags are brought forth that provide increased functionality. There are currently over 30 tags (Table 2) and 150 functions available, ranging from database inquires and manipulation to tags that interface with standard SMTP and POP3 mail servers. If a feature you require is not part of the standard CFML language, you also can use Microsoft-compliant COM objects (also known as ActiveX objects) or create your own Custom tags in a language like C++.

The main point to keep in mind is that most HTML tags today define an action to be performed by the HTTP client, whereas most CFML tags define an action to be performed on the HTTP server.

The flexibility offered by HTML along with Cold Fusion allow you to design a multitude of different types of applications. The main criteria is that you wish to have your users interface with the application via a Web browser. For an organization with many different types of computer systems in use on employees desktops, this can greatly increase the availability of an application since it will no longer be written "display dependent". As long as the Web browser software in use on your employee desktops meets or exceeds whatever HTML specification you are coding for, you do not need to worry about display dependent issues (like are they using an HP compatible terminal so they can run VPLUS screens!). This means, for example, that Human Relations information can be accessed equally well by a person using a Microsoft Windows PC, an Apple Macintosh, a UNIX-flavored workstation, or even by someone with only a character-based display running a host-based browser like Lynx.

Some of the application types that have been developed using the principles described above are:

• Access to Human Relations information
• Secure access to personal employee files
• Online catalogs and shopping services
• Help Desk systems
• Software registration and tracking
• Calendar and groupware scheduling
• along with many others

Cold Fusion operates within the traditional three-tier client-server model (refer to Figure 2). The user utilizes an HTTP client on his local system which communicates with an HTTP server on a host. Cold Fusion also resides on that host and can in turn draw upon the resources that reside on database servers accessible via standard ODBC connections. Once again, the client can be just about anything that can run a Web browser.

Also required is some form of TCP/IP access between the HTTP client and server systems. Generally, this is a local area network (LAN), but it can also be one of several varieties of serial or dialup access similar to that used by most people to access the Internet from home.

Cold Fusion now operates only under Microsoft's 95 or NT operating systems (although a UNIX version is due out shortly). Since Cold Fusion must reside on the same host as the HTTP server software, this currently limits you to a Windows 95 or NT-based server. Cold Fusion can interact with the HTTP server software either as a standard Common Gateway Interface (CGI) program or, if available from the server, one of several custom APIs. The custom APIs currently supported by Cold Fusion are NSAPI by Netscape, ISAPI by Microsoft's Information Server, and WSAPI by O'Reilly's WebSite server. Custom APIs provide for a higher degree of integration with the Web server than does the standard CGI approach, so you will find that Cold Fusion applications perform much faster when operating via this method. In contrast, the inclusion of the standard CGI interface allows Cold Fusion to operate with just about any Web server that currently runs under the Windows 95 or NT operating systems.

To access and manipulate data from a database, Cold Fusion uses ODBC as its protocol. The standard (or workgroup) version of Cold Fusion is limited to those databases considered to be for use by a single user (for example, Microsoft Access, FoxPro, and dBase). The professional version allows the use of any ODBC-compliant data source, opening the way for you to utilize database servers such as those using Microsoft's SQL Server, Oracle, or even ALLBASE/SQL.

A number of vendors now offer 32-bit ODBC drivers, which will allow access from the HTTP server to your HP 3000. Each driver has different strengths and abilities such as serial access in lieu of a LAN or access to nondatabase files, such as KSAM or flat files, etc. In testing the examples in this article, I used HP's new ODBCLink/SE driver (licensed from M.B. Foster Associates). Drivers by other vendors may provide greater performance and flexibility, but I chose ODBCLink/SE it for my testing because I think it will become the driver used by most companies since HP will ship it automatically to customers with a maintenance contract covering either IMAGE/SQL or ALLBASE/SQL. I've also used the PARTSDBE ALLBASE/SQL database in my tests since HP provides everything required to create and populate this database as a sample on both MPE/iX and HP-UX for systems with ALLBASE/SQL installed. (For more information about setting up PARTSDBE, please refer to HP's Up and Running with ALLBASE/SQL manual.) HP provides samples for IMAGE/SQL customers as well (refer to the Getting Started with HP IMAGE/SQL manual), and you can easily alter some of the sample HTML/CFML shown later to work with the MUSICDBE IMAGE/SQL sample database.

Now that I've introduced Cold Fusion, it's time to illustrate its use. I will use the PARTSDBE ALLBASE/SQL database to create a series of Cold Fusion Web pages that will allow a user to input selection criteria into a HTML form and retrieve matching entries from the PURCHDB.VENDORS table.

The steps for establishing the data source will vary somewhat, depending upon the ODBC driver chosen. ("Data Source" is used to refer to the database, file, etc., accessed via the ODBC driver on behalf of the client software-in this case, Cold Fusion.)

Step 1.	Open the ODBC Administrator from the Control Panel icon. Select the System DSN tab and click the [Add...] button.
Step 2.	Select the appropriate ODBC driver to use.
Step 3.	Name your data source along with real database name and location.
Step 4.	Define how the ODBC driver should logically "log on" to your system.
Step 5.	Select desired setup options.
Step 6.	Select text translators desired.

You need to define the data source as a System Data Source so that Cold Fusion can access it regardless of which username is logged into the Windows 95 or NT server system. After you have defined the data source, the type of system the database server is does not matter so long as only standard ODBC and SQL features are used.

Most databases have special features and options available, and if they are supported by the particular ODBC driver, they will also be available to your Cold Fusion applications. If portability is a concern in your design, resist the urge to use these "enhancements." Take, for example, a handy (but nonstandard) datatype called AutoNumber available in Microsoft Access. As each tuple is added to the table, a column in that table defined as AutoNumber is automatically incremented to reflect a value one greater than the previously inserted tuple. This is great when used to define a unique value for a column, but when you upsize that database into ALLBASE/SQL, you'll have to revisit your application logic since ALLBASE/SQL does not support AutoNumber datatypes.

Now that the data source has been set up, you may wish to alter how the Cold Fusion Server interacts with it. Cold Fusion itself is administered via a Cold Fusion application. Therefore, you'll need to start your HTTP client of choice (for these functions to work correctly, your Web browser must support Java and JavaScript, as well as allow cookies). Netscape's Navigator 3.x (and higher) or Microsoft's Internet Explorer 3.x (and higher) work fine. Select the local URL of the Cold Fusion Administrator pages defined at the time Cold Fusion was installed. You will need to supply the administrator password in order to continue. Once access is granted, you will be presented with the administrator screens. Click on the 'Data Sources' button, and you will be presented with a screen similar to that shown in Figure 3. Here you can define how long a particular Cold Fusion transaction accessing this data source will remain valid, the number of simultaneous connections that can be managed to the database server, etc. For general usage, the default values should be more than adequate, although it is always nice to have a few more options available to "fine-tune" performance. Update these values, if necessary, and "Verify" the data source back on the main screen. The Verify data source option actually confirms that Cold Fusion can access the data source. If it succeeds, then you are ready for your applications to start accessing your data source. If Verify fails, go back and doublecheck your ODBC entries (logon information, server name, etc). If everything appears OK, then turn on all tracing options and retry Verify. Examine the trace files for error messages. When the problem is found and corrected, the Verify option should return a positive confirmation message.

First, define the goals for the application:

• The client must be able to search on the vendor's ID number or any portion of the vendor's name.
• All information on file for any qualifying vendors must be displayed.
• Following the search, the user can return and perform a new search as many times as desired.

• The first page will be HTML-only consisting of a FORM to accept the selection criteria. The contents of the form will be submitted to the second page.
• The second page will be a Cold Fusion template consisting of both HTML and CFML tags. This page will perform validation of the FORM fields entered on the first page, and if the values are found to be acceptable, an SQL SELECT statement will be dynamically generated to retrieve the qualifying tuples. Each tuple returned will be displayed in a multiline format with a horizontal rule separating each tuple.
• After all tuples have been displayed, a hyperlink back to the original page will be available for the user to perform a new search.

The commented source code for both pages are shown in Listings 2 and 3, with samples of the screens in Figures 4 and 5. Overall, the sample application is very simple. Normally, an application would have more extensive search capabilities, along with the ability to insert, update, and delete vendors. Although these abilities are not part of this sample, they can be added easily at a later date.

Cold Fusion coupled with IMAGE/SQL or ALLBASE/SQL brings the HP 3000's powerful and reliable OLTP (OnLine Transaction Processing) abilities to an intranet or the Internet. It is no longer a major undertaking to bring data residing on the mainframe to your users on the LAN. This working sample application, along with several other online demonstrations, are available on the Internet at:
http://www.editcorp.com/site-demos/

Michael Gueterman is the owner of Easy Does it Technologies (EDIT), a consulting and services firm specializing in HP 3000 and Internet interoperability issues. EDIT is also an Allaire Alliance partner. Michael may be reached at M_Gueterman@editcorp.com or voice at (888) 858-EDIT.