Tags: view all tags

Introduction to Web Server

Before running out and trying to attach your APPX application to a Web Server, you need to understand the basic concepts used to get information passed between the Web Browser, Web Server, and backend database application. There are a lot of books and free web documents available that go more in depth on this subject. You are encouraged to seek these out for more complete documentation. This section is only intended to provide a reasonable base upon which the following sections will build.

The Web Browser

The Web Browser is the client program that you run on your local machine to gain access to a Web Server. It is strictly a user-interface/document-presentation tool. It knows nothing about the application it is attached to and only knows how to take the information from the Server and present it to the user. It is also able to capture data entry made into a Form and get the information back to the server for processing. Dominant packages being used at the time of this writing are: Netscape, Internet Explorer, and Mosaic. All three of these tools are available for little or no charge on the internet.

The Web Server

The Web Server is the server program that runs on a network host machine and services requests made to it by Web Browsers. One server can service a large number of browsers. There are several free server programs available on the internet. Most web browsers are built to process two basic types of requests. File Server and Database Server requests. New features are always being added to provide additional support for new technology, but this document will focus on the two dominant features offered by most web servers. Here is a short description of each type of request:

File Server. The web server simply accepts a request for a document, validates the request, and sends the requested files back to the browser.
Database Server. The web browser acts as a front-end tool to collect data from the browser, feed it to some backend database tool or script, and send the resulting document to the browser. This technique is called a Common Gateway Interface (CGI).

APPX can be used in both of these transactions. In the first case, APPX can be used to generate static Web documents that can be stored on the web server. In the second case, APPX can actively accept the data from the web server, process it, and generate the resulting Web Document on-the-fly for the server to send back to the browser.

Web Document Formatting

Web documents are written using the HyperText Markup Language (HTML). This language is pretty simple and is implemented as special ASCII tags that you embed within your document to give the browser a general idea of how the information should be displayed. All of the browsers listed above, understand the standard HTML tags, although they may display the same document a little differently. Some browsers have implemented additional tags, but these should not be used in most cases. If you want your documents to be accessible by people using different browsers, you should stick with the standard tags. The HTML standard is still actively evolving, so new tags are constantly becoming available to support new browser features.

If you do not already know HTML, you should learn more about it before attempting to integrate APPX into your web server. This document is written assuming that you already understand HTML. There are a number of good books and online tutorials on the subject. Please find a good source and study it.

Browser / Server Communications

When planning an internet application, it is important to understand the limitations of the Browser / Server connection. This connection is the only link between the user of the application and the application server. The most restrictive limitation is that the connection is a one-shot interaction. The browser connects to the server, sends it a request or the contents of a form, waits for a reply HTML document, and then disconnects completely from the server. The application has ONE opportunity to get ONE batch data-block from the browser, act on it, and send ONE response back to the browser. To carry information from one connection to the next involves some creative thinking. Here are two possibilities:

Embed the information within an HTML reply document to be used as extra input by the server on the next connection. This lets you use the document as the vehicle to carry data forward from one connection to the next.
Store the extra information in a temporary file on the server and embed some kind of unique key in the reply document that will get sent back to the server on the second connection. This will let the application use the key to access the stored information from the last connection.

There are good and bad points to each of these methods. Embedding data within the document means that the user of the application could edit the document before the next connection and thereby change the data. This can be overcome by encrypting the data, or including a data element that is some magical checksum you can use to make sure the data is not tampered with. The problem with temporarily storing the data within the application means that it may stay around forever. If the person using the browser does not continue the sequence of transactions you expect, the temp data will never get used and cleaned up. In this case, you can expire the temp data after a period of time and remove it.

Example Transaction Flow

To help clarify what takes place during a transaction between the browser and the server, here is an example. The only difference between a static document request and a CGI request is what the server does with the data and where it gets the reply document. Here is a sample exchange:

The browsers connects the the web server.
The web server accepts the connection and then (in most cases) clones itself. This allows it to handle the new connection and also listen for more connections at the same time.
The browsers send the request. This is in the form of a Univeral Resource Locator (URL). An example of a static document may be "/index.html" or to send CGI data to the server, a URL may include the data elements as well. The data elements are made up of Variable Name and Data pairs. "/appx.cgi?APID=AAA&PROCNAME=TEST" will pass two variables to the server script "appx.cgi" for processing.
The server validates the request and in the case of a static document, it locates the requested document on disk and sends it back down the line to the browser. In the case of the CGI request, the server runs the CGI shell script and feeds it the data string as input. It then waits patiently for the CGI shell script to dump the reply document text to the terminal (stdout). It then sends this HTML back to the browser as the reply document.
The server disconnects from the browser and the conversation is complete. So, the cloned copy of the server that was processing this request dies silently.

As you can see, the real magic lies in the CGI shell script. This takes the request and data from the server, processes it, and then returns the reply document text. The trick is to have this script talk to code within an APPX application and get the APPX Application to generate the reply HTML document. That is the focus of the rest of this document.

-- JoeOrtagus - 2012-02-13