| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

HTML

Web pages are created using HyperText Mark Up Language (HTML). HTML isn’t a programming language; it is a text formatting or “markup” language. The developer creates the text he wants to put in the page and then marks it up using HTML, either using his normal word processor, an HTML editor, or an HTML generator tool.

HTML does not behave like Postscript (which is a page description language). An HTML document consists of the text with tags that tell a browser how the text should appear on the screen, or how to do specific things like draw a horizontal line.

To make a Web page, the developer writes the words and then adds tags to say how they should appear. HTML uses various categories of markers to mark up the text, for example:

  • Comment
  • Document structure-for example, head, body, link
  • Document headings-title, headings
  • Links-anchors and hypertext links
  • Layout elements-line breaks, preformatted text, horizontal rules
  • Graphics
  • Forms-blocks, widgets, text area, pick lists, selectable items
  • Paragraphs
  • Lists-directory, ordered lists, glossary lists, menu lists, etc.
  • Text controls-bold, citation, font, italic, emphasis

By using HTML, the developer can also add pointers in the Web page to graphics files that get loaded as the page is read by the Web browser. These graphics files, sound files, or other “blobs” can be stored in local directories which can be accessed by the Web server. If the developer wants to add a new picture or a new piece of text, he or she loads or scans it into the local directory and modifies the Web page pointer to point to it.

Developers can add pointers in their documents that enable the user to jump about within a Web page or across pages. These points are called anchors in Netspeak and tell the Web browser where to go to get information when you click on it. Simple anchors can be used to jump to other points in the same document—in other words, to get the browser to jump about in the one Web page.

Another type of anchor is a hypertext reference. In this case, the user is taken to a different address on the Internet. The addresses of these files are invisible to the user but must be written into the HTML document. These addresses are described using URLs—Uniform Resource Locators—as normal. The main difference between these URLs and the URL the user uses to get access to a site is only that the user never sees these addresses; they are embedded in the marked up text.

CGI

Web browsers and Web servers were designed to be geared more towards dissemination of “multimedia” objects rather than tools that could access DBMSs or perform application-type processing such as giving the time or date. Although the normal architecture is very effective for dissemination of infrequently changing information, it is less effective (in its basic form) for dissemination of database information, application information, or information derived from databases, which may be refreshed every minute (or second even).

The solution devised to solve this problem was the creation of the CGI standard (Common Gateway Interface). CGI is one means by which a Web browser (via its Server) can communicate with a separate program or application that can be used to provide customized information, up-to-date information from databases, or any application function.

Web servers normally access static files in directories. If CGI is used, the Web server can be made to access the CGI programs, which can then provide less static information. Similarly, the CGI can also be used to build interactive exchanges between clients and servers.

The importance of this concept cannot be overstated. The Web in its basic form provides none of the capabilities of a normal application—there are no accesses to databases, no calculations, no dialogues, or conversations between users and computer. By using CGI, the developer can go partway to providing this capability—albeit with some limitations.

Developers must write their own CGI applications that perform the processing they want to achieve. There is no difference between writing a CGI program and writing a normal server-based program except that developers seem to favor the use of C and Perl (an interpreted scripting language) above other languages for developing these programs. Apple users tend to use Applescript.

If the developer wants to access one or more databases, he or she must code the database logic to access the data, but must also code the logic to format the resulting output so that it is in HTML format. Some of the tools which can handle CGI programs work with ODBC drivers, for example, Allaire’s Cold Fusion and Nomad’s WebDBC.

CGI programs are also found using their URL. This means that a user could (without necessarily knowing it) directly ask for a CGI program using the URL of that program, or a Web page may contain the URL embedded in a page—in which case the user will not know the address of the program and will be unaware of the action behind the scenes. At runtime, it is the Web server which invokes the CGI program, based on the URL that points to the CGI program.

The CGI program performs whatever actions it has been built to perform using input from the browser request. The CGI program then returns the data back to the server in the form expected (e.g., an HTML page), and the server then passes the results back to the browser. If the exchange is part of an ongoing interactive Web session, these results could include additional form tags to accept further user input, along with a URL for this or another CGI program, and the cycle begins again. In this way, it is possible to have a sort of disjointed conversation over the Web, but without the session and context-based approach familiar in most applications.

Previous | Table of Contents | Next