The Cold Fusion Web Database Construction Kit
Cold Fusion's growing popularity is a result of being easy to use, simple to learn, and powerful enough to create industrial strength applications. To fully take advantage of Cold Fusion, it is imperative that you understand how it works, how Web servers work, and how the two work hand-in-hand.
The very nature of Web-based publishing requires a paradigm shift away from conventional and traditional application development practices. This chapter introduces Web-based publishing from the ground up and explains how Cold Fusion builds upon this increasing popular publishing technology.
This chapter is recommended reading for all Cold Fusion developers, even those who are intimately familiar with Web servers and HTTP. It starts with a brief overview of the Internet, the IP protocol, DNS, and Web servers, and then introduces Cold Fusion.
The World Wide Web is the most talked about publishing medium. Recent statistics indicate that close to 20 million people browse the Web (with over 250,000 different Web sites) on a regular basis. Hembrecht & Quist, a leading investment firm, forecasts that by the year 2000 the number of regular Web users will grow to 200 million.
In August 1981, 213 hosts (computers) were connected to the Internet. By August 1996, that number had grown to over 12 million! The number of Web sites on the Internet has grown at the same alarming rate. There were less than 25,000 Internet Web sites in June 1995 and exactly one year later there were 230,000.
What has made the World Wide Web so popular? That, of course, depends on who you ask. Most will agree that these are the two primary reasons:
A massive potential audience awaits your Web site and the services it offers. You could, and should, be offering much more than just static text and images. You need features like:
Cold Fusion enables you to do all this--and more.
Before starting Cold Fusion development, we need to take a step back. Because Cold Fusion takes advantage of existing Internet technologies, a prerequisite to Cold Fusion development is a good understanding of the Internet, the World Wide Web, Web servers and browsers, and how all these pieces fit together.
Much ambiguity and confusion surround the Internet, so let's start with a definition. Simply put, the Internet is the world's largest network.
The networks found in most offices today are Local Area Networks, (LANs), comprised of a group of computers in relatively close proximity to each other and linked by special hardware and cabling (see Figure 2.1). Some computers are clients (more commonly known as workstations), others are servers (also known as file-servers). All these computers can communicate with each other to share information.
Figure 2.1 A LAN is a group of computers in close proximity linked by special cabling.
Now imagine a bigger network, one that spans multiple geographical locations. This type of network is typically used by larger companies with offices at multiple locations. Each location has its own LAN that links the local computers together. All these LANs are, in turn, linked to each other via some communications medium. The linking can be anything from a 28.8 baud modem to high speed T1 connections and fiber-optic links. The complete group of interconnected LANs, as shown in Figure 2.2, is called a WAN, or wide area network.
Figure 2.2 A WAN is made up of multiple interconnected LANs.
WANs are used to link multiple locations within a single company. Suppose you need to create a massive network that could link every computer everywhere. How would you do this?
You'd start by running high speed backbones, connections capable of moving large amounts of data at once, between strategic locations--perhaps the largest cities or different countries. These backbones would be like high speed, multi-lane, interstate highways connecting disparate locations.
You'd build in fault tolerance to make these backbones fully redundant so that if any connection broke, at least one other way to reach a specific destination would be available.
Next, you'd create thousands of local links that would connect every city to the backbones over slower connections--like state highways or city streets. You'd allow corporate WANs, LANs, and even individual users with dial-up modems, to connect to these local access points. Some would stay connected at all times whereas others would connect as needed.
You'd create a common communications language so every computer connected to this network could communicate with every other computer.
And finally, you'd devise a scheme to uniquely identify every computer connected to the network. This would ensure that information sent to a given computer actually reaches the correct destination.
Congratulations, you've just created the Internet!
Even though this is an over simplification, it is exactly how the Internet works.
The high speed backbones do exist. Many are owned and operated by the large telecommunications companies.
The local access points, more commonly known as POP's, or points of presence, are run by phone companies, online services, and local Internet service providers (also known as ISP's).
The common language is IP, the Internet Protocol, except that "language" is a misnomer. A protocol is a set of rules governing behavior in certain situations. Foreign diplomats learn local protocol to ensure that they behave correctly in another country. The protocols ensure that there are no communication breakdowns or serious misunderstandings. Computers need protocols, too, to ensure that they can communicate with each other correctly and to be sure that data is exchanged correctly. IP is the protocol used to communicate across the Internet, so every computer connected to the Internet must be running a copy of IP.
The unique identifiers are IP addresses. Every computer, or host, connected to the Internet has a unique IP address. These addresses are made up of four sets of numbers separated by periods, for example 206.246.150.10. Some hosts have fixed (or static) IP addresses, others have dynamically assigned addresses. Regardless of how an IP address is obtained, no two hosts connected to the Internet may be using the same IP address at any given time. That would be like two homes having the same phone number or street address. Information would end up in the wrong place all the time.
A Brief History of the InternetThe Internet has evolved over the past 25 years to become an incredibly important communications medium. What follows is a brief history of the Internet.
1969--The U.S. Department of Defense starts researching a new networking project. The first node in the network is established at UCLA and, soon after, nodes are set up at Stanford Research Institute, UCSB, and the University of Utah.
1971--The number of connected nodes reaches 15 as additional government and education institutions are brought online. The ability to send e-mail over the Internet is introduced.
1972--Telnet is introduced to permit remote host access over the Internet.
1973--The U.S. Defense Advanced Research Projects Agency begins work on the "Internetting Project" to research ways to link different kinds of packet networks. FTP, the File Transfer Protocol, is introduced.
1977--E-mail specifications are formalized.
1983--Name server technology is developed at the University of Wisconsin.
1984--DNS, the Domain Name Service, is introduced.
1986--The U.S. National Science Foundation starts developing NFSNET, a major Internet backbone. NNTP, the Network News Transfer Protocol, is introduced to enhance the performance of Usenet news.
1987--Number of hosts connected to the Internet tops ten thousand.
1988--Internet "worm" cripples the Internet, affecting over 60,000 hosts. IRC, Internet Relay Chat, is introduced.
1989--Number of hosts connected to the Internet tops one hundred thousand.
1991--Gopher is introduced. World Wide Web is released by CERN, the European Laboratory for Particle Physics, located near Geneva, Switzerland.
1992--Number of hosts connected to the Internet tops one million.
1993--The InterNIC is created to handle directory and domain registration services.
1995--The World Wide Web becomes the service generating the most Internet traffic. InterNIC starts charging an annual fee for domain name registrations.
The Internet itself is simply a massive communications network and offers very little to most users, which is why it took 20 years for the Internet to become the present phenomenon.
The Internet has been dubbed "the Information Superhighway," and that analogy is quite accurate. Highways themselves are not nearly as exciting as the places you can get to by traveling them--and the same is true of the Internet. What makes the Internet so exciting are the applications that run over it and what you can accomplish with them.
The most popular application now is the World Wide Web. It is the Web that single-handedly transformed the Internet into a household word. In fact, many people mistakenly think that the World Wide Web is the Internet. This is definitely not the case, and Table 2.1 lists some of the more popular Internet-based applications.
| Application | Description |
| SMTP, the Simple Mail Transfer Protocol, is the most popular e-mail delivery mechanism | |
| FTP | File Transfer Protocol is used to transfer files between hosts |
| Gopher | A menu driven document retrieval system that was very popular before the creation of the World Wide Web |
| IRC | Internet Relay Chat allows real-time text-based conferencing over the Internet |
| NFS | Network File System is used to share files among different hosts |
| Newsgroups | Newsgroups are threaded discussion lists of which there are thousands |
| Telnet | Telnet is used to log in to a host from a remote location |
| WWW | The World Wide Web |
All of these different applications, and many others, use IP to communicate across the Internet. The information transmitted by these applications is broken into packets, or small blocks of data, which are sent to a destination IP address. The application on the receiving side then processes the received information.
IP addresses are the only way to uniquely specify a host. When you want to communicate with a host--for example a Web server--you need to specify the IP address of the Web server that you are trying to contact.
As you know from browsing the Web, you rarely specify IP addresses directly. You do, however, specify a host name, like www.mcp.com, (the Macmillan Computer Publishing Web site.) If hosts are identified by IP address, how does your browser know which Web server to contact if you specify a host name?
The answer is DNS, the Domain Name Service. DNS is a mechanism that maps host names to IP addresses. When you specify a destination address of www.mcp.com, your browser sends an address resolution request to a DNS server asking for the IP address of that host. The DNS server returns an actual IP address, in this case 206.246.150.10. Your browser can then use this address to communicate with the host directly.
If you've ever mistyped a host name, you've seen error messages telling you that the host could not be found, or no DNS entry was found for the specified host. These error messages mean that the DNS server was unable to resolve the specified host name.
DNS is never needed. Users can always specify the name of a destination host by its IP address to connect to the host. There are, however, some very good reasons not to:
DNS servers are special software programs. Often your ISP will host your DNS entries so that you don't need to install and maintain your own DNS server software.
You may host your own DNS server and gain more control over the domain mappings, but you inherit the responsibility of maintaining the server. If your DNS server is down, there won't be any way of resolving the host name to an IP address, and no one will be able to find your site.
The "Intranet" is currently one of the industry's favorite buzzwords. It was not too long ago that most people thought "Intranet" was a typo; but, in a very short period of time, the Intranet became recognized as a legitimate and powerful new business tool.
An Intranet is nothing more than a private Internet. In other words, it is a private network, usually a LAN or WAN, that enables the use of Internet based applications in a secure and private environment. As on the public Internet, Intranets can host Web servers, ftp servers, and any other IP based services.
Companies have been using private networks for years to share information. Traditionally, office networks have not been information-friendly. Old private networks did not have consistent interfaces, standard ways to publish information, or client applications that were capable of accessing diverse data stores. The popularity in the public Internet has spawned a whole new generation of inexpensive and easy-to-use client applications. These applications are now making their way back into the private networks. The reason that the Intranet is now gathering so much attention is that it is a new solution to an old problem.
The two things that distinguish an Intranet from the Internet is who may access it and where it may be accessed from. Don't be confused by hype surrounding applications that claim to be "Intranet ready." If an application can be used over the public Internet, it will work on private Intranets too.
As mentioned earlier, the most commonly used Internet-based application is now the World Wide Web. The recent growth of interest in the Internet is the result of growth in interest in the World Wide Web.
The World Wide Web is built upon a protocol called HTTP, the hypertext transport protocol. HTTP is designed to be a small, fast protocol that is well suited for distributed multimedia information systems and for hypertext jumps between sites.
The Web consists of pages of information on hosts running Web server software. The host is often referred to as the "Web server," which is technically inaccurate. The host is actually software and not the computer itself. There are versions of Web server software that can run on almost all computers. There is nothing intrinsically special about a computer that hosts a Web server, and there are no rules dictating what hardware is appropriate for running a Web server.
The original World Wide Web development was all performed under different flavors of UNIX. The majority of Web servers still run on UNIX boxes but this is changing. For almost every major operating system, there are now versions of Web servers. Web servers hosted on high performance operating systems, like Windows NT, are becoming more and more popular. This is because UNIX is still more expensive to run than Windows NT and is also more difficult to use for the average user. Windows NT has proven itself to be an efficient, reliable, and cost effective platform for hosting Web servers. As a result, NT's slice in the Web server operating system pie is growing.
What exactly is a Web server? A Web server is a program that serves up Web pages upon request. Web servers typically don't know or care what they are serving up. When a user at a specific IP address requests a specific file, it tries to retrieve that file and send it back to the user. The requested file might be the HTML source code for a Web page, a GIF image, VRML worlds, AVI files, and so on. It is the Web browser that determines what should be requested, not the Web server. All the server does is process that request, as shown in Figure 2.3.
Figure 2.3 Web servers process requests made by Web browsers.
It is important to note that Web servers typically do not care about the contents of these files. HTML code in a Web page, for example, is markup that the Web browser will process, not the Web server. The Web server returns the requested page as is, regardless of what the page is and what it contains. If there are HTML syntax errors in the file, those errors will be returned along with the rest of the page.
NOTE: Some Web servers support advanced features so the servers can actually process Web pages themselves. For example, Netscape Enterprise server has a feature called "server side includes" which enables you to instruct a Web server to include another URL in a specified location within a Web page.
You can expect to see more "intelligent" Web servers in the future. For now, however, these features are the exception rather than the norm.
Connections to Web servers are made on an "as needed" basis. If you request a Web page from a Web server, an IP connection is made over the Internet between your host and the host running the Web server. The requested Web page is sent over that connection, and as soon as the page is received, the connection is broken. If the received page contained references to additional information to be downloaded, for example GIF or JPG images, each would be retrieved using a new connection. A Web page with five pictures in it, therefore, takes at least six requests, or hits, to retrieve it all.
This is why hits is such a misleading measure of Web server activity. When you learn of Web servers that receive millions of hits in one day, it may not mean that there were millions of visitors. Hits does not equal visitors, nor does it equal pages viewed. In fact, hits are only a useful measure to determine changes in server activity. Hits are meaningless in determining how many visitors your Web site has had.
Web servers are often not the only IP-based applications running on a single host. In fact, aside from performance issues, there is no reason why a single host cannot run multiple services. For example, a Web server, FTP server, DNS server, and a SMTP POP3 mail server can run at the same time. To ensure that each server application only responds to requests and communications from appropriate clients, each server is assigned a port address. If IP addresses are like street addresses, ports can be thought of as apartment or suite numbers.
Most servers use a standard set of port mappings, and some of the more common ports are listed in Table 2.2. Most Web servers use port 80, but you can change that. Web servers may be installed on nonstandard ports if desired to "hide" Web servers as well as host multiple Web servers on a single computer by mapping each one to a different port. Remember that if you do use a nonstandard port mapping, users will need to know the new port number to be able to connect to your server.
| Port | Use |
| 20 | FTP, File Transfer Protocol |
| 21 | FTP, File Transfer Protocol |
| 23 | Telnet |
| 25 | SMTP, Simple Mail Transfer Protocol |
| 53 | DNS, Domain Name Service |
| 70 | Gopher |
| 80 | HTTP, Hypertext Transfer Protocol (the protocol used by the World Wide Web) |
| 107 | Remote Telnet service |
| 109 | POP2, Post Office Protocol version 2 |
| 110 | POP3, Post Office Protocol version 3 |
| 119 | NNTP, Network News Transfer Protocol |
| 143 | IMAP4, Interactive Mail Access Protocol version 4 (used to be used by IMAP2) |
| 194 | IRC, Internet Relay Chat |
| 220 | IMAP3, Interactive Mail Access Protocol version 3 |
| 389 | LDAP, Lightweight Directory Access Protocol |
| 443 | HTTPS, HTTP running over secure sockets |
| 540 | UUCP, UNIX to UNIX Copy |
Information on the World Wide Web is stored in pages. A page can contain any of the following:
Web pages are plain text files constructed using HTML, the hypertext markup language. HTML is implemented as a series of easy-to-learn tags, or instructions. Web page authors use these tags to mark up a page of text. Browsers then use these tags to render and display the information for viewing.
HTML is constantly being enhanced and new features and tags are being added constantly. To ensure backwards compatibility, browsers must ignore tags that they do not understand. For example, if you were to use the <MARQUEE> tag to create a scrolling text marquee, browsers that do not support this tag would still display the marquee text but would not scroll.
NOTE: For more information about HTML, see the electronic version of Special Edition Using HTML on the accompanying CD.
Web pages may also contain hypertext jumps which are links to other pages or Web sites. Users may click on links to jump to other pages on the same Web site or any page on any site.
The word "Web" in World Wide Web refers to this ability to jump to any Web page on any Web server, and back again.
Pages on a Web server are stored in different directories. When requesting a Web page, a user may provide a full path (directory and file name) to specify a particular document.
You can specify a default Web page, a page that is sent back to the user when only a directory is specified, with a Web server. These default pages are often called index. html or default.htm. Depending on how the server was set up, if no default Web page exists in a particular directory, it will either return an error message or a list of all the available files.
Every Web page on the World Wide Web has an address. This is what you type into your browser to instruct it to load a particular Web page.
These addresses are called URLs, or uniform resource locators. URLs are not just used to identify World Wide Web pages or objects. Files on a FTP server, for example, also have URLs that identify them.
World Wide Web URLs are made up of up to five parts. These are:
Let's look at a few sample URLs:
Links in Web pages are references to other URLs. When a user clicks on a link, the browser processes whatever URL it references.
Web browsers are client programs used to access Web sites and pages. The Web browser has the job of processing received Web pages, parsing the HTML code, and displaying the page to the user. The browser will attempt to display graphics, tables, forms, formatted text, or whatever the page contains.
The most popular Web browsers now in use are Netscape Navigator, shown in Figure 2.4, and Microsoft Internet Explorer, shown in Figure 2.5. Both browsers are displaying the same Allaire home page, but the pages do not look the same on both browsers.
Figure 2.4 Netscape Navigator is the Web's most popular browser.
Web page designers have to pay close attention to the differences between browsers because different Web browsers support different HTML tags. Unfortunately there is not one single browser that supports every tag currently in use. Furthermore, the same Web page often looks different on two different browsers because every browser renders and displays Web page objects differently.
For this reason, most Web page designers use multiple Web browsers and test their Web pages in every one to ensure that the final output appears as intended. Without this testing, some Web site visitors will not correctly see the pages you published.
Figure 2.5 Microsoft Internet Explorer is gaining popularity, particularly among users running Windows 95 or Windows NT.
Web servers can do more than just serve static pages. As mentioned before in the section entitled "URLs," Web servers can execute scripts as well. When a Web server receives a URL request that references a script, it executes it and returns the script output instead of returning the script.
For example, suppose you had a Web site that reported stock quotes. Creating Web pages that listed all the stocks by exchange along with their current values would be close to impossible. As fast as you'd update the page and save it, it would be out of date. What you could do, instead, is write a script that takes a stock symbol as a parameter and returns the current value. When a user requests a stock, the Web server executes the script referred to in the URL, passes the stock symbol as a parameter, connects the script to your designated system to obtain stock quotes, and generates HTML output containing the quote. This data flow is shown in Figure 2.6.
In order to make it easier to create scripts that work with multiple Web servers, a standard script interface was created. CGI, the common gateway interface, is a Web server scripting standard. It is important to understand that CGI is not a program or script, it is a mechanism that you may use to connect your script to your Web server.
When a CGI script executes, the following occurs:
Figure 2.6 You may extend the publishing capabilities of your Web server with scripts.
So, what exactly is a script? That depends on the Web server you are running.
In the past, most CGI programs were actually script files and were often written in scripting languages like PERL, but today scripts can also be executable programs. You can write scripts in C and Visual Basic. Some Web servers even enable you to execute batch files as scripts. As long as your program can execute without any user intervention, it could be a script.
TIP: The CGI specification has gone through several revisions. The best place to find up-to-date information on CGI is the W3 Consortium Web site, http://www.w3.org.
CGI scripts are a very powerful way to extend the capabilities of your Web server, and you've probably used them without even realizing it. If you have ever used an Internet search engine, or any intelligent forms, you've probably used CGI scripts. The beauty of CGI is that it is simple to implement, portable, and completely transparent to the end user.
As powerful as CGI is, it does have some shortcomings. These are:
To overcome these shortcomings, Web server developers have created interfaces with which to extend the capabilities of their Web servers. These are known as server APIs.
An API is an application programming interface. API's are used by programmers to write applications that can interact with other applications. A server API is a published interface that lets software developers write programs that become part of the Web server itself. Usually these are DLLs (Windows dynamic load libraries) that are loaded into memory and stay resident at all times. These DLLs hook directly into the guts of the Web server to enable you to extend or alter the server's capabilities as needed.
This power and capability does come with a price. Because server APIs are so closely tied to the Web servers themselves, each is very server specific. In fact, three different Cold Fusion server APIs are available for three different Web servers, as shown in Table 2.3. They are, of course, incompatible with each other.
| Server API | Supported Servers |
| ISAPI | Microsoft Internet Information Server |
| NSAPI | Netscape Commerce and Enterprise Server |
| WSAPI | O'Reilly Web Site and Web Site Pro |
Both CGI and server APIs have a place in the Web server arena. CGI is not as powerful or as fast as server APIs, but CGI scripts are simple to implement, and can be portable across different computing platforms. Server APIs are not portable, but they are faster and more powerful.
Now let's look at Cold Fusion to see how it works its magic.
If you're wondering why we went through all this discussion about the Internet, Web servers, CGI, and server APIs, here's where it will all fit together.
Back in the early Cold Fusion days, Cold Fusion was a CGI script. Every time a user would make a Cold Fusion request, (displaying data or inserting and updating records), the Web server would execute the entire Cold Fusion program. Cold Fusion would process the user's request, perform whatever actions were necessary, and return HTML output back to the user.
As Cold Fusion's feature set grew, so did the application's response time. Because CGI programs are loaded and unloaded as needed, there is no way to maintain variables, settings, database connections, and file handles between each executed session. Performance was a serious problem.
The Allaire development team went back to the drawing board and developed a scaleable and elegant new design. They broke Cold Fusion up into multiple parts, as follows:
The Cold Fusion NT service is the program that actually parses and processes any supplied instructions. Instructions are passed to Cold Fusion using templates.
A template looks much like any HTML file with one big difference. Unlike HTML files, Cold Fusion templates can contain special tags that instruct Cold Fusion to perform specific operations. Listing 2.1 contains a sample Cold Fusion template, one that we'll use later in this book. Don't worry if it doesn't make much sense yet, we'll cover Cold Fusion templates in greater detail in later chapters.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
<CFQUERY
DATASOURCE="A2Z"
>
INSERT INTO Employees(FirstName, LastName, PhoneExtension)
VALUES(`#FirstName#', `#LastName#', `#PhoneExtension#')
</CFQUERY>
<HTML>
<HEAD>
<TITLE>Employee Added</TITLE>
</HEAD>
<BODY>
<H1>Employee Added</H1>
<CFOUTPUT>
Employee <B>#FirstName# #LastName#</B> added.
</CFOUTPUT>
</BODY>
</HTML>
Earlier in this chapter, it was stated that Web servers typically passed back the contents of a Web page without paying any attention to the file contents.
That's exactly what Cold Fusion does not do. When Cold Fusion receives a request, it parses through the template looking for special Cold Fusion tags (they all begin with the letters CF) or Cold Fusion variables and functions (always surrounded by pound signs). Any HTML or plain text is left alone and is output to the Web server untouched. Any Cold Fusion instructions are processed, and if there are results, they are also output to the Web server.
The Web server can then send the entire output back to the requester's browser.
Cold Fusion's power comes from its capable and flexible language. CFML, the Cold Fusion Markup Language, is modeled after HTML which makes it very easy to learn.
CFML extends HTML by adding tags with the following capabilities:
That's not even the complete list.
The majority of this book discusses Cold Fusion templates and the use of CFML.
When accessing Cold Fusion templates with your Web browser, you need a way to specify which template you want to execute. You do this by specifying the template name in the URL.
Because Cold Fusion is both a CGI application, and a server module, two different types of URL syntax are available for you to use. As a general rule, you should always use the server module syntax whenever you can.
http://www.a2zbooks.com/cgi/cf.exe?template=/a2z/hello1.cfm
This example instructs the Web server on host www.a2zbooks.com to execute CF.EXE (the Cold Fusion CGI interface), and specifies that the template to process is /a2z/hello1.cfm.
Cold Fusion server module URL syntax. Now let's see how the same template
executes using the server modules URL syntax:
http://www.a2zbooks.com/hello1.cfm
This URL is both cleaner and simpler because it simply instructs the Web server to return the file hello1.cfm.
How does the Web server know to execute the template and return the results instead of returning the template itself? The answer is a technology called document type mapping. When Cold Fusion is installed, it configures your Web server so that it knows that any file that has an extension of CFM (or CFML) is a Cold Fusion file. Then, whenever a Cold Fusion file is requested, the Web server knows to pass the file to Cold Fusion for processing rather than returning it.
Of course, if you ever need to pass parameters to a Cold Fusion template, you still have that option. The example below passes a parameter called src to the template for processing:
http://www.a2zbooks.com/hello1.cfm?src=10
TIP: If you are using one of the Web servers for which Cold Fusion has a server API module available, you should always use it instead of the CGI interface.
One of Cold Fusion's most powerful features is its ability to connect to data created and maintained in other applications. You can use Cold Fusion to retrieve or update data in many applications, including:
The way Cold Fusion accesses these applications is via ODBC. ODBC, which is discussed in detail later in this book, is a standard interface that applications can use to interact with a diverse set of external data stores.
The majority of Parts II and III of this book discusses Cold Fusion's database interaction via ODBC.
In this chapter, you reviewed some of the basic concepts relating to the Internet, the IP protocol, Web servers and browsers, and how all these work together. Cold Fusion depends on all of these to work properly.
© Copyright, Macmillan Computer Publishing. All rights reserved.