How A Web Application Works

Let's look at the basic three-step process of the Web application:

1. The browser (the client) sends a request to the server (the Web Server) over the network (the Internet or Intranet) in the form of a link on a Web page, a Web address (URL) or an HTML form.

2. The Server runs an application that provides the requested service (data-entry, data-processing, data retrieval).

3. When the application closes, the Server returns some kind of response page back over the wire to the Browser. It may be an updated copy of the same page (a client code lookup would be one example), an error page ("sorry, duplicate name"), a response page ("thank you for your order") or just another blank data-entry form.

There you go, that's a Web application.

It's really a very simple process - familiar to anyone who's ever used a Web search engine, ordered books from Amazon.com or downloaded a dBASE Plus update. But the twin challenges posed by writing "stateless" applications and generating new pages instead of repaints each time the application goes back to the server must be addressed before you can create fully functional, highly interactive Web applications. As always, with new technology, it requires new approaches. Before we get into these, let's look a little more closely at the architecture of a Web application:

1. The Request

A "request" for a Web application uses a URL (Universal Resource Locator or "location") that includes special information not present in a static Web page address. In addition to the standard protocol and path, an application URL transmits the location of the application, its executable file name and (optionally) data to be sent to the application. Let's analyze the example below:

http://www.dBASE.com/cgi-bin/myprog.exe?firstname=Alan&lastname=Katz

http Hypertext Transport Protocol (web page protocol), which tells the server what kind of service to provide. In this case, it's http, which is used for standard "web pages".

www.dBASE.comthe server's address.

/cgi-bin/ the "virtual" folder in which the application resides

myprog.exe the application the server is supposed to run

?firstname=Alan&lastname=Katz parameters sent to the Web server as data for the application to use. The question mark is the parameter operator, the "&" is the separator between name/value pairs.

Tip:Name/value pairs are an important concept that we don't deal with much in dBASE Plus. You've probably seen them in ".ini" and other system files, but they're ubiquitous in Web applications. The name/value pair is the primary format for sending data. The "name" on the left (firstname=Katz) is the variable or control name, the text on the right is its value. So, if you have an entryfield on your Web page named "Address" and the user types in "101 Main Street", your application will receive "Address=101 Main Street". All information in name/value pairs is text. If your application needs data in numeric, date or boolean type, it's your job to convert it.

Requests to the Web server can come from URLs typed into the browser, links within a Web page or from an HTML form.

A link is an underlined area of text or an image on the page that's been assigned a URL (Internet address and path). When the text or image is clicked, the browser pokes the URL from the link into its "location" field and goes looking for it on the Web, Intranet or LAN.

An HTML formis a region of a Web page devoted to data-entry with its own dedicated "Submit" button. When the user clicks "Submit", all the data on the form is sent back automatically to a URL you specified when you created the HTML form. Regardless of which of the three methods is used to launch it, every Web application starts out with either a URL or a "starting" homepage that links to a URL.

2. The Server

"Web server" has two different meanings in the context of the Internet, one hardware, one software. First, it's the host machine, which is usually a Unix, :Linux or Windows NT box located on the host site. Second, it's the software that "serves up" the Web pages requested by the Browser. Normally, when we refer to a Web Server, we're talking about the software (when we refer to the server computer, we'll explicitly identify it as such).

There are many major Web server packages in the PC world: Apache is the most popular Web server software of all time. It runs more than 61% of the world's Web sites, it's incredibly easy to setup and maintain, and best of all, it's open-source and it's free. dBASE Inc. ships Apache for Win 32 on all of its dBASE Plus and dBASE Plus CDs.

Internet Information Server runs only on Windows NT. It, too, is free, but only if you buy Windows NT Server (it's one of the infamous Microsoft "bundles"). You can get a free copy of Microsoft's Personal Web Server bundled with FrontPage or the NT Option pack.

Netscape (now AOL) offers both the Enterprise and FastTrack servers. 

O'Reilly's has WebSite. Appropriately enough named, it's available free from the O'Reilly's Web site.

.

All these Web servers "serve" HTML pages (http), many support other protocols, such as FTP. Apache, O'Reilly's and Microsoft's PWS run on Windows 95/98, the others only run on NT.

Tip:Win 95/98 is a poor server platform. It's just not built to provide fast multi-user access the way a server is built to provide fast multi-user access. You won't believe the difference in the performance of the same site running on Win 95/98 and NT 4.0. NT blows Win 95/98 away! On the other hand, Win 95/98 is an excellent platform for developing and testing Web applications without jeopardizing your real live Web server. There's nothing worse than a work-in-process that brings down a live Web site several times a day!

Whichever Web server you use, it receives the request from the browser, executes whatever it's instructed to execute and returns a response page. It's a rule of the Internet that the browser never "ends". Every page submitted to the server returns a new page to the browser, and on and on until you close the browser. Which leads to an interesting question: how does the Web server know if the request is for a page or for an application? Several ways, depending on the Web server.

O'Reilly's, for example, recognizes a call to a pre-mapped CGI folder (more on CGI later). IIS, on the other hand, knows the request is for an application by its ".exe" extension. At least that's the default - you can set up IIS to recognize any executable format just by telling IIS that the particular extension is to be executed, not read.

3. The Response Page

This is where you get creative. To return the required response page to the Browser, you have to stream out an HTML page to the Web server using dBL code. Fortunately, we've made that easy for you by providing a tool (HTMLtoPRG.wfm) that allows you to get fancy with visual HTML editors such as Microsoft Front Page or Symantec's Visual Page. HTMLtoPRG.wfm will read in the HTML code you created in these easy-to-use visual designers and generate dBL source code ready to cut-and-paste into the streamBody( ) method of the WebClass. Voila, instant customization.

But before you start streaming out HTML to the Web server, you've got to decide what you're going to stream out. The possibilities are endless, and these response pages provide the glue that bind your applications together.

Some options:

Acknowledgement Page. Returns a "thank you" or an order confirmation or some such terminal page. Just to close the loop, it should at least have a "home" link so you don't inadverdently invite your user to move on to someone else's Web site.

Another data-entry page. You may chain your applications so that the response page of one application calls a data-entry page for the next application. You can even default or display the data processed in the first page (in fact you should) in the HTML page you send back to launch the next application. This is the typical architecture of an online store. Check out the dBASE online store (and buy something, please!) to see how data-entry and processing pages are chained together.

  A static page or even a graphic static page. Federal Express's Web site returns a graphic airbill (generated on-the-fly by the server-side applet) that you're supposed to print and attach to your package or envelope. Cool.

  Another copy of the original calling page. This is the plan for the dBASE Plus bug submission application. Once you've entered one bug or wish, you get back a fresh new copy of the page to submit another (assuming that there are bugs to report, of course).

A Web application consists of all the parts we've mentioned so far, from the browser request to the server to the server-side application to the response page. Events that happen and software that runs on the server are said to be server-side. Events that occur on the browser are said to be client-side. The progam you'll write in dBASE Plus is not literally a Web application, it's a server-side application.

The requirements for a server-side application are pretty minimal:

  They should be non-visual. Since you can't send the Windows interface back to the browser, there's absolutely no reason to use up the disk-space, load time and runtime overhead required to paint Windows screens that will never be seen. Most Servers, in fact, supress the visual interface elements when they run a server-side program. Forget putting a msgbox( ) in your application as a trap - it'll never see the light of day.

  The server-side application has to have access to whatever distributed data it requires. Which means that your application must be able to talk to your database if it's located on another server somewhere on the network. You data does not have to be located on the Web Server PC. You can even run a multi-tier client/server application across your network as long as your application sports a valid login and access to the pieces it needs to run. Fortunately, dBASE Plus sports the BDE Alias that allows your data to be accessed from any computer on your network without hard-wiring a single path. Use a BDE alias on all your dBASE Plus Web apps!

  The server-side application has to be able to receive input from the Web server. It has to be capable of streaming its output back to the server ( See How CGI Works for more detail.)