Previous Page TOC Next Page

1 — Computing and the Internet Today

by Warren Ernst

The Internet is on the verge of a minor revolution, of sorts, even though you as an Internet user might not be aware of it. It will transform not how the Internet is designed or constructed, but how you use it.

There's a good chance you've already been exposed to this potential future in the form of Java applets and JavaScript in the Web pages you encounter with your browser. These Web pages temporarily give your Web browser something it's never had before: smarts—at least in a limited, temporary way. And by "smarts," I mean that your browser can do more than just display static, unmoving, unchanging Web pages; they can display information in a new, "intelligent" way.

Microsoft hopes to drive this Internet revolution, a revolution that will not only give Web browsers smarts, but also give "conventional business applications"—such as word processors, spreadsheets, and database programs—Web-browser[nd]like connectivity. Microsoft plans to accomplish this with wide use of a technology collectively called ActiveX, a convention of coding and API (Application Programming Interface, or the method that programs use to communicate with each other) and an evolution of existing Microsoft technologies that should simplify modifying existing programs and generate results that truly are revolutionary.

To understand the potential benefits of joining current "Internet" and "conventional business" applications, you need to understand the Internet (and the programs used to interact with it) and the business programs currently in use and the similarities and differences between them.

Connectivity Versus Computing

On the surface, a spreadsheet program and a Web browser are operated similarly. In Windows 95, for example, both Excel and Netscape are started from their icons in the Start menu; both use pull-down menus, dialog buttons, and the mouse for interaction, and each is minimized, resized, and closed in the same way. They might even have similar purposes to many users: Excel can be used to merely view spreadsheet files, and Netscape can be used to view Web page files.

Even though they might look and feel similar, however, these applications are clearly different; each can do something remarkable that the other can't. Excel can compute new data from known information (at least in the hands of someone who knows how), for example, and Netscape can retrieve remote information from the Internet.

Still, you don't think the distinction is big enough to get worked up about? You're not convinced that there really is that much of a difference between connectivity and computing, and that there's no revolution in combining the distinct elements of the two with ActiveX? You wouldn't be alone, but perhaps reviewing the differences as they exist between connectivity programs and computing programs will put the power of mixing the two into perspective.

Connectivity: Retrieving Internet-Based Information

The modern Web browser, such as Netscape or the Internet Explorer, represents the pinnacle, to date, of connectivity software. It manages to manipulate half a dozen Internet protocols and twice as many file formats, all through a connection that can range in speeds from 1 kilobyte per second all the way to 10 megabits per second, and seems to do all this with deceptive ease. Even a novice computer or Internet user can use one of these programs to retrieve Internet-based data with almost no previous instruction—it's almost entirely a point-and-click affair.

Yet this simple interface belies an exceptionally complex latticework of programming that is the ultimate communications program—that's what a Web browser is really all about. All a Web browser does is communicate to various Internet servers, first requesting servers to communicate back to establish a basic link, then asking the server to transmit information that, in and of itself, requires little computing power to display to the Web browser's user. Of course, this is a brief summary of the process of displaying a Web page, but by breaking it down, you'll see that a Web browser is little more than a communications-based, graphically oriented, Internet walkie-talkie.

Here are all the steps a Web browser takes to display a simple Web page once you give it a URL. Don't worry—this will be in plain English. Trust me, it's interesting:

  1. The browser looks at the URL and breaks it down into its component parts. It determines that if you gave it a URL of http://www.cris.com/~wernst/index.html, you want to use the HyperText Transfer Protocol (http) to try to get a Web page named index.html from an Internet host (or server) named www.cris.com in a subdirectory called ~wernst. You see, there's very little computing involved in breaking down the URL—the browser merely performs the equivalent of diagramming a sentence, as you used to do in grammer school.

  2. The browser looks at your network configuration settings to find the Internet address of the nearest predefined Domain Name Server (DNS), a computer that has a big database or table of all the Internet servers out there. It communicates to the DNS the name of the server you want (in this case, www.cris.com), and the DNS tells the browser what the numeric Internet address (called an IP address) is (which in this case is 199.3.12.172) through the TCP protocol. At this point, only two lookup tables have been accessed, and there's been some communication between the DNS and the browser—not much real computing.

  3. Next, the browser takes the addressing information from the DNS and communicates to www.cris.com through its IP address of 199.3.12.172 with HTTP because it was specified in the URL. This initial communique basically breaks down into "Hello www.cris.com. I am a Web browser named (Netscape, Internet Explorer, or something similar) and would like some Web pages (or other information) from your directories. Is this OK? Are you alive?" Usually, the server replies with the equivalent of "Sure. What do you want?" At this point, you've now had two more lines of communication from start and finish and very little computation.

  4. The browser, now knowing the server is serving, requests the file: "I would like the file index.html from your subdirectory '~wernst,' please." The server looks through its directories for the file, finds it, checks to make sure it's a valid file type with its own set of lookup tables, sends the message "I found it. Here it comes," and sends the file. If it can't find the requested file, it sends the message "Huh? I don't have the file you've asked for," (or other error message, depending on the type of problem) and the communication stops. At this point, you just have more communication and table lookups—not much computation.

  5. Assuming the file exists, the browser receives the Web page in the form of an HTML file and starts to decode it. HTML files are human-readable text files, essentially, requiring almost no real computation to decode and display. When the browser finds an embedded image, for example, it sends another communiqué to the server: "Just a minute. I also need the file 'image1.gif' for this page. Can you send it now?" The server, upon receiving this new message, checks its directories and file type tables to make sure the requested file can be sent, says "OK," and sends the inline image file. This process repeats for every inline image in the HTML file and ends the communiqué once the browser says it has all the inline images. As the files are sent (with lots more communication), the browser builds the page onscreen with the codes in the HTML file as a guide and the inline images as they're received, using a fraction of your CPU's computing power to generate onscreen fonts, colors, and images.

Figure 1.1 graphically represents all these steps.


Figure 1.1. Steps involved in getting a regular Web page.

There are some important points to draw from this scenario. First, transmitting a Web page requires a lot of communication, and with more than just the Web server specified in the URL—the specified Web server's address had to be requested from the Domain Name Server, with a communication protocol distinctly different from the HyperText Transfer Protocol used to talk with the Web server.

Second, the process of retrieving a Web page is broken down into several smaller messages between the browser and the Web server, each with a different purpose; it isn't just one big burst transmission between the browser and server that gets the HTML file sent, even though it might look like it while you're Web surfing.

Third, there's very little computing power used to get all this information moved around and displayed. The DNS uses a lookup table to find the IP address of the requested Web server, the Web server uses a lookup table to check file types and directory locations, and the browser itself uses a lookup table to determine what fonts and colors to use for displaying the Web page. The browser has no leeway or decision-making capability when it comes to figuring out what parts of the page to display—it simply goes through the HTML file line-by-line and follows the instructions within the file, without deviation. The browser has no need for, and hence doesn't have, much computing power or "smarts" (as I like to call it).


NOTE

I've been using the term "lookup table" for quite some time without explaining how little computing power is required to use it or even describing it conceptually. Suffice it to say, then, that a lookup table can be thought of as consulting a two-column table, finding an entry in the first column and seeing what it corresponds to in the second column, then doing something with the second column's entry. This might remind you of using a Captain Video decoder ring when you were a kid to transform a bunch of numbers into letters to write a message in code. Lookup tables work exactly the same way, but on a larger scale; to a computer, this is a simple task to execute.

Finally, and perhaps most important, no new information is created in this process. All the communication is being used to transmit existing information from one location (the Web server) to another location (the Web browser) just to be viewed. That's not to say that the information isn't new to the user of the Web browser, but the information in the Web pages existed before it was retrieved by the browser, and it will remain untouched once the browser is through with it. As with anything, there are exceptions to this, but these points hold true for the vast majority of static, unchanging Web pages.


What About Forms and CGI Scripts?

The previous section's discussion described the process of viewing a "regular" Web page within a Web browser, one that didn't include forms to fill out or dynamically changing information. Would a Web page form increase the computation going on within a Web page, you ask? For the Web server, yes, it would; for the Web browser, absolutely not.

When the information entered into a Web page form is sent to the server by clicking the Submit Form button on most Web pages, all the browser does is send a message like "I have some information that someone typed into the form fields in that Web page you just send me. If you can take them, here they are." After receiving an "OK" message from the server, it sends out the form information exactly as it was typed and waits for a response.

The server then takes this information, breaks it down, and probably runs an actual program that computes something, looks something up in another table, or executes a script (or performs any one of many other methods of computing new information). Whatever it actually does, the server computes the results and generates an HTML file on the fly with the newly computed information. Next, it responds with: "I have an HTML file for you to display. If you can take it, here it comes." The browser displays the new HTML file, whose contents are probably the results of the server's computation.

Therefore, as with a conventional Web page, the browser merely communicated with the server and displayed Web pages; it didn't actually do much of its own computing. The server does all the computing (and perhaps generates new information in the process) itself, independently of the browser's capabilities.

Computing: Generating New Information Locally

Although the title of this section sounds rather lofty, the fact is you generate new information with your computer practically every day without thinking about it that way. You might use Microsoft Excel to calculate data and draw graphs, Microsoft Word to type new data sheets, term papers, or entire books, or Microsoft Access to enter, keep track of, and search through volumes of data—in short, you create data.

Even if you use these programs only to view data created by others, you have the potential to create information either from scratch or from other data on your hard drive, which is something no Web browser has the potential to do (browsers with HTML editors built in, such as Netscape Gold, notwithstanding). Furthermore, these programs work with files available through your immediate file system—in most cases, your set of hard and floppy disk drives—though a local area network (LAN) such as Novell might be included as well. They aren't set up to work beyond the boundaries of your immediate surroundings.

In fact, for a software- or service-oriented business, the information output of desktop applications might well be the only "product" resulting from work and effort, as opposed to widgets from an assembly line or software from a compiler. To these people, the fact that these programs generate new information where there was none before is obvious.

"Connectivity" and "Computing" Are Separate Animals

Whether by accident or design, most people are aware of the fundamental differences between connectivity software and computing software, so they use them differently. No big surprise, this observation; however, it illustrates how inefficiently you're working when you use separate classes of programs for a larger task requiring both connectivity and computation.

Suppose you want to write a proposal with Microsoft Word, send it to an FTP site so someone can collaborate with you, retrieve it again to finish the file, then send it by e-mail to a third party. Naturally, you'd start the task by opening Word, using it to create your document, then saving it to your hard disk when it's finished.

Next, you'd launch your separate FTP program (dialing your modem to make an Internet connection, if necessary), log into the FTP site, pick the Word DOC file from its directory on the hard drive, ensure that the FTP binary mode was enabled, and upload the file. Once your collaborator was finished, you'd start your FTP program, log into the site, change directories, set the binary mode, retrieve the file, and save it to a local directory. Then you'd quit the FTP program, launch Word, open the file, make any further changes, and save the document.

Finally, you'd start your separate e-mail program, create a message and address it, go through the e-mail program's attachment process, then send off the file to its final destination. When the process is finished, you will have used three completely different programs, each consuming time and memory and creating the potential to introduce errors. Why is software used this way?

Why Computing and Connectivity Haven't Mixed

Computing and connectivity software don't really mix right now because "that's the way it's always been," but this remark creates a sort of ""the chicken or the egg"" issue. Until the past year or two, business applications with true computational power (such as Excel or Word) had no need for connectivity because there wasn't really any place to connect to or much of a need to do so. Computing and creating information were, therefore, rather local affairs; if a file needed collaboration, chances are you worked in the same office as the other person, so you could exchange a floppy, or, more recently, use the LAN.

With the explosion of the Internet, people realized that even though they were separated by vast distances, two (or more) people could work together to some degree, as long as each had Internet access; people could use connectivity programs to communicate with each other. Because of the way these two sets of programs are written, however, you are forced to use specific connectivity programs to connect and computing programs to get work done.

Why Computation and Connectivity Will Be Mixed Soon

Times and computer users have been changing, however. It seems that a critical mass of users needing to both create and connect has been reached, and hybrid programs with computing and connectivity powers are being envisioned. In fact, a tool currently exists—Sun's Java programming language and JavaScript—to begin giving connectivity programs like Web browsers a little bit of smarts. Unfortunately, even with Java applets, your browser can have only so much intelligence and computational power. That's why Java programs are applets instead of applications; there's only so much a Java applet can do.

To make it reasonably easy to give connectivity programs real computational ability, and computational programs real connectivity, Microsoft has introduced and refined technology it calls ActiveX. With ActiveX tools and methods (explained in Part II, "Components of ActiveX"), creating programs with both computational and connectivity capabilities, from existing programs or from scratch, is not only possible but has a remarkably short development timetable.

Chapter 2, "Microsoft's Vision of the Future with ActiveX," will explore these programs's possibilities and potential.

Previous Page TOC Next Page