Download Web Interface Assignment for Database Application and more Assignments Principles of Database Management in PDF only on Docsity!
CMSC 424{0301 Fall 2000 PHW03 (100 pts) Due Tue, 10 Oct 2000
Name:
Submission le name: (As in earlier assignments, ll in the ab ove information on a hardcopy of this do cument and submit it at the b eginning of class on the due date. You are required to upload your submission b efore you submit the hardcopy in class.)
Overview: This assignment asks you to build a Web interface to the toy database ap- plication you built in the last assignment. The goal is to gain exp erience in setting up a Web server and programming the interfaces of the Web server, your application co de, and the DBMS (and any other mo dules you may decide to use). The toy Web application in this assignment is similar in spirit to those on many p opular Web sites (e.g., amazon.com, ebay.com); however, several imp ortant issues, notably usability, maintenance, scale, and eciency, are ignored. Functionally, the Web application in this assignment is very similar to that in the previous one. The Web interface must allow users to invoke all the functions in that assignment (e.g., connect, createTable, details) and view their results. The semantics of the functions remain unchanged. The main di erence is that user interaction will use HTTP and HTML instead of the stdin-stdout interface of the previous assignment.
Software: By default, we will b e using a CGI interface to the Apache HTTP server soft- ware, which is installed on the detective cluster machines.^1 You may use a programming language of your choice. As always, you are free to use any libraries and co de you nd help- ful, but all co de you use must b e clearly and prominently acknowledged in your submission (b oth hardcopy and electronic). As always, no matter what resources you use, you must b e able to explain how everything works. (\I call function fo o with these parameters and library bar takes care of everything" is not a satisfactory answer.) Unless you are familiar with Apache and Web programming in general, please budget enough time to learn ab out them. Learning these interfaces is the ma jor part of the assignment (since the rest is essentially PHW02).
Web Interface: The entry p oint to your application is a page we shall call the application home page. It should include the following:
(^1) Apache is a very go o d HTTP server, but CGI is a very p o or interface. I would strongly suggest that
you not use CGI for your group pro jects; however we will use it for this assignment to keep things simple. If you strongly prefer using a di erent interface (e.g., mo d-Perl, Jserv, PHP), or a di erent HTTP server, for this assignment, you are free to do so. The only catch is that you will b e resp onsible for making sure all the software you use works with the submission pro cedure b elow, implying your Make le must result in the installation and con guration of any extra software you need. I may b e willing to make a few exceptions, but you must make arrangements with me very early.
Identifying information: A title (CMSC424-0301 Fall 2000 PHW03) and your name, Unix account and, Oracle account (no passwords). The title and your name should anchor links to the class Web page and your p ersonal Web page resp ectively. (The contents of your p ersonal Web page are irrelevant for grading as long as it is clearly your own page. If you don't have one, now is a go o d time to create it.)
Function links: For each function, there must b e a link that p oints to its function page (describ ed b elow). The link's anchor-text must b e the name of the function. The function links must b e in the order the functions are listed in PHW02.
All the HTML pages used by your application (e.g., the function pages describ ed b elow) must include a link to the application home page.
Function Pages: As mentioned ab ove, there is one function page corresp onding to each of the user functions of PHW02. Each function page should include the following:
Identifying information: All the identifying information on the application home page and the name of the function (e.g., searchEmail).
Input elds for function arguments: One text input b ox for each of the arguments the function takes. The b oxes should b e stacked vertically and should include descriptive lab els. For example, use a lab el such as Email address (substring match) for the argument of the searchEmail function.
An HTML form submission button lab eled Proceed.
When the user clicks the Pro ceed button, the appropriate function should b e invoked with the user-input arguments (e.g., searchEmail with the search string typ ed by the user in the input b ox). The result should b e presented as a result page.
Result Pages: These pages are used to display the result (output) of a function invo cation. Each result page should include the following:
Identifying information: All the identifying information on the function page followed by the arguments used in the function invo cation (e.g., searchEmail(umd.com).
Database Results: The output for each function should b e in a tabular format reminis- cent of the output format describ ed in PHW02. Instead of using tabs and newlines as column and record separators, you should use HTML tables with descriptive column headings. For example, the result page for the searchEmail function should contain an HTML table with two columns (and as many rows as there are result tuples). The rst column should list the email address and the second, the name; suitable head- ings are Email and Name, resp ectively. The output should b e sorted as describ ed in PHW02. Further, wherever a name is listed (e.g., in the second column in the output of searchEmail), that name should anchor a link leading to the details for that name. That is, clicking on the name should result in the invo cation of the details function with that name as argument.
The program startserver will b e invoked with a p ort numb er (e.g., 8424) as the single command-line argument. This action should result in everything required to set up and start your application's Web server. The output of startserver should b e a single line containing the URL of your application (e.g., http://holmes.umd.edu:8 424 /. Note that your program may b e tested on any of the detective cluster machines (not just Holmes). The program stopserver will b e invoked with no arguments. It must result in the termination of all the HTTP server pro cesses used by your application. Be careful not to assume that your application will b e the only one running on the test machine. If the p ort numb er supplied to startserver is unavailable, it should print out an appropriate error message and quit gracefully. (A b etter strategy would b e for startserver to nd and use an available p ort in the vicinity of the given one; however, you're not required to implement this feature.)
Cautionary note on running HTTP servers: Please b e very, very careful ab out how you run Apache (or another HTTP server) when you are debugging and testing your pro- gram. It is very easy to overload the machine with runaway pro cesses. Make sure you read, understand, edit, and use a httpd.conf le that do es not overload the system. Pay sp ecial attention to the MinSpareServers and MaxSpareServers directives. Make sure you under- stand how to shut down the httpd system by killing the prop er (parent) pro cess. Check your pro cesses frequently using ps -u yourusername, esp ecially b efore you log out (when you should kill all remaining http d pro cesses).
