ßA Normal Database Connection.
First lets look at a typical database application layout :
Figure 1: A Normal Database Connection.
Clients connect to a database server, typically using a proprietary library. The client is normally a special purpose application that has to be downloaded and installed at the end-users site. Connections are usually of a long lived nature : The client connects, makes several queries, then disconnects. The server therefore has some notion of what state the client is in ( A "current" query, how many rows have been retrieved, which row are the next to be send to the client etc. )
ßA Normal Web Connection
Next, we need to understand a "standard" World-Wide Web connection.
World Wide Web consists of an http "daemon" which accepts socket connections
on a single port, reads a URL query from the client thus connected,
outputs the data associated with the URL specified by the user, and
closes the socket.
The "standard" World-Wide Web configuration is something like:
Figure 2: A Normal Web Connection
Here the connection is using a standard (and publicly available) protocol.
The clients are freely available, and normally already installed at the
end-users site.
Besides static information in files, most web clients and servers now
support fill-out-forms. The contents of these can, once filled out by
the users, be send to a CGI script (Common Gateway Interface) which can
process this data and send the result back to the user. This is the
mechanism used by WDB to allow the users to query the databases.
One obvious difference between a database connection and a WWW connection
is the length of time the connection lasts - In the case of a database
connection, it can be up to several hours; in the case of WWW the
connection is often less than a second in duration, or more precisely, the
time it takes to process one query.
ßA WDB Connection.
WDB is implemented as a CGI script which can generate forms and send them
to the user, retrieve the contents of the form, process it and return the
result to the user.
Because of the different nature of a WWW connection the WDB system has
to be designed differently from a normal database application. There
are no long-lived connections, the server has no notion of what has been
going on earlier in a "session". The WDB process is
exited immediately after the results are send back to the user. This
means that all information needed to perform a given action has to be
send from the client each time. Of course the client will have this
information from the last results it received from the server.
The way this information is send back and forth between the WWW
client and server is via the URL's. URL stands for "Uniform Resource
Locator". It is a standard for specifying a piece of information on
the Internet. The URL is composed of a protocol name (ftp, http,
gopher) the name of the server, and a path on that server pointing to
the piece of information need. This can be a file or, on a http
server, a CGI script such as WDB. Here the trick is that if there is
extra information in the URL after the path, then this is passed to the
script as what is called PATHINFO.
(ex. http://arch-http.hq.eso.org/cgi-bin/wdb/PATHINFO)
