Database Reference
In-Depth Information
scripts increases. Every time a request is made by a Web client to a database server
and every time a result is conveyed by the database server to the client, the Web
server must convert an HTML document into data or vice versa.
A CGI-based approach lacks efficiency and does not provide transaction support.
Essentially, this approach is not able to shake off the limitation of statelessness of
HTTP. Even repeated requests from the same user require logon and logout every
time.
CGI and Web-Database Integration
To what extent does CGI enable the inte-
gration of the database into the Web environment? How exactly does CGI support
database applications on the Web?
Take the example of a user filling in a form on a web page at the client side. The
browser transfers the information to the Web server, which in turn passes on the
information to the CGI script while launching it. Suppose the scenario is like this:
The Web server sends the blank web page containing the form to the browser to
display the blank form to the user. The transaction is completed, and the server ends
the connection. The form is expected to be filled in and sent back to the Web server
so that the server can pass on the information to the CGI script for further action.
However, if the user does not complete the mandatory fields on the form, the CGI
script is unable to display a warning box and refuse to accept the incomplete input
on the form. Applications of this nature require extending interaction with the users.
The difficulties caused by the statelessness of HTTP persist even when adopting
CGI.
For simple direct queries against the database, CGI seems to be useful. CGI pro-
vides a useful interface to the database server. For example, if you want to know
the current status of the parcel you sent through a shipping company, you can log
on to the company's website, type in your tracking number and send it to the Web
server. The tracking number is supplied to the CGI script, and the script is launched.
The CGI program retrieves the current status of the parcel from a database and
sends the information to the browser through the Web server. If the transaction is
meant to end here without any further interaction, then CGI is helpful. CGI pro-
vides a generic way to interface with the database server and send back the infor-
mation to the browser. The Web browser, just by itself, could not accomplish this.
To get around fundamental problems arising out of the stateless nature of HTTP,
some methods other than CGI must be explored.
As you have already noted, performance could be a major concern while working
with CGI. Each request requires an additional process to be created. This places an
enormous overhead on the server when the number of on-line requests peaks during
the day.
Application Programming Interface (API)
To overcome the performance problems encountered while adopting CGI, one
approach is to extend the functionality of Web servers. Servers can be changed and
enhanced to provide application programming interfaces. Such enhancements or
extensions are known as non-CGI gateways. An application programming interface
(API) offers an interfacing technique between the Web server and a database appli-
cation at the back end based on shared objects and dynamic linking. This technique
Search WWH ::
Custom Search