Reference no: EM131005073
Assignment Objectives:
• To build a simple distributed application with multiple clients that uses persistent data from a database (as is typical of many actual distributed applications).
• To implement a simple "redirect server" driven by server load suitable for use as a frontend to a server farm.
• To learn about a couple of web-related concepts that we won't be covering in class
• To learn some more about the Document Object Model (DOM) and JavaScript.
• To gain some first hand experience developing a very simple web application using PHP and MySQL/MariaDB.
Assignment Questions:
1. Restructure and extend your JDBC application from Assignment 2, Question 2 to process the commands S, R, C, P and T (and also some new commands described below) not from the command line but now, instead, over a Java stream socket from clients running on other machines.
Thus, your prior application will now be a sort of a "university database server" (that hosts the COURSE, STUDENT, PROF, etc. tables that you have already created). You are then to write two clients that will use your database server. The first client program will be for students and will allow them to declare themselves as students (S command) assuming that they already have a student number, to register in courses they wish to take (R command), to drop courses they previously registered in (using a new D command) and to get a course listing given their student number (using a new L command). The second, separate, client program will be for the university to use and will allow courses and professors to be created (C and P commands, respectively) and professors to be assigned to teach courses (T command). Your server should get the necessary database password from the command line at startup. You will need to hand in your database table creation script again, please. Also, the table naming convention from A2 will still need to be followed.
2. You are to develop a very simple redirect system (similar in spirit to the RHS of slide 42 in the Client-Server notes given in class). Clients will know the address of the redirect host and use it simply to acquire the IP address of one of two servers "behind" the redirect host. After that, communication will take place directly with the selected host. Your redirect host should run an RMI server that supports client's making a remote method invocation to a getHost() method that returns the IP address of one of the two servers. Your redirect server must sense the load on each server and should return the IP address of the most lightly loaded server that is up (or 0.0.0.0 as an error indication if neither server is up). You should assume the server code is running on *nix machines. You can then use the *nix uptime command with the RunTime and Process classes in Java to determine the load on a machine. You can use the isReachable method from the InetAddress class to determine whether or not a server is currently up and running. To test your server redirection system, you should run two instances of the simple lookup service from assignment 1, question 2 (obviously running on two different *nix machines) and you will have to modify the corresponding client program to begin by making an RMI to getHost() to select the server to connect to. Obviously, the two lookup servers will have their own independent hash tables of <key, value> pairs. There is no need to have these servers communicate with one another to ensure the consistency of their contents for this question. You are free to use and modify the posted sample solution code for A1Q2 if you like. To simulate a machine being down, you will need to temporarily disconnect the network cable of one or both "server" machines.
Do not forget to reconnect the network cables!
3. In class, we discussed the Hyper Text Transfer Protocol (HTTP), which is a text-based protocol. Obviously, sending information between browsers (web clients) and a web server in a web-based application using HTTP is problematic in certain situations due to the ease with which HTTP traffic can be captured with a packet sniffer and then examined (e.g. think about what information is passed during a web-based banking session). Do a little Internet research to learn about HTTPS. What is HTTPS? How, generally, does it work? What technologies does it build on? Give a simple example of another common web-based application where HTTPS would certainly be needed.
4. If necessary, do some Internet research to learn more about the document object model (DOM) and JavaScript then write a simple JavaScript program that will recursively walk the DOM for an associated HTML file and print the types of the elements encountered (embedded data need not be printed), indented to reflect the hierarchical nature of the HTML document. Thus, <HEAD> and <BODY> would be at the same level but indented further than <HTML>, as in the following:
<HTML>
<HEAD>
- stuff within "<HEAD> </HEAD>" indented appropriately
</HEAD>
<BODY>
- stuff within "<BODY> </BODY>" indented appropriately
</BODY>
</HTML>
To test your code, you can create an HTML file and embed the JavaScript in the file. You should then just be able to open the file in a browser (by double-clicking it) to see the output. This is necessary since the JavaScript interpreter is embedded in the browser and not generally available from the command line. You can use any valid HTML file for testing. You will need to test this on www3.cs.umanitoba.ca. Hand in your JavaScript code embedded in a simple HTML file. The markers may, of course, change the HTML but will not modify your JavaScript code during testing.
5. Do some more Internet research so you can explain what the term "same origin policy" means when discussing client-side scripting? Sometimes application of the "same origin policy" can be too restrictive. One way to address this issue is known as "cross-origin resource sharing". Briefly define "same origin policy" and then explain how "cross-origin resource sharing" avoids the problem of being overly restrictive.
6. You are to develop a basic web application re-implementing Question 1 above (without JDBC) and re-using the MySQL/MariaDB database you have already created. Instead of having two separate clients though you will provide a single web-based interface supporting all the available commands (S, R, C, P, T, D and L). You will naturally work on www3.cs.umanitoba.ca and you will use PHP to develop the application and get access to your database tables. Your web application will have an initial ("landing") page that presents the user with a choice of commands to execute and when a command is chosen it should take the user to a new page where the needed information can be entered into a command-specific HTML form. When that form is submitted, a corresponding PHP script will have to be run that uses the information to generate the necessary database queries. Information returned from the database and any error messages will have to be presented to the user as generated HTML pages. Note that browser-based presentation defaults are fine (we'll use CSS later).
Your PHP scripts (with .php suffix) and tatic web pages (with .html suffix) must be in the directory public_html under your home directory. Your application's landing page (HTML) must be world readable (i.e. chmod 644 app.html) and all your PHP files must be controlled only by you (i.e. chmod 700 *.php). Your PHP pages must be accessed on www3 (not on any other CS machine). That is, you must always remember to point your browser to www3.cs.umanitoba.ca not www.cs.umanitoba.ca. No client-side code is needed for this question (we'll do some client-side JavaScript later). Note that you must leave your web application on your homepage (and hence www3.cs.umanitoba.ca) for the markers to use and inspect during testing. All source files (.html and .php) must also be handed in in a separate zip file along with a README file that briefly describes your implementation. Some information about using PHP on www3 and links to general PHP resources will be provided in UMLearn.
You are to hand in your assignment via dropbox in UMLearn. For written questions you should hand in formatted text, Word, or PDF files. Please no scanned, handwritten assignment questions. The markers have only a few hours to finish the marking and trying to decipher poor handwriting slows the process significantly. For coding questions, you should handin a zip file for each coding question. The zip file should contain all the source code materials as well as a single text file called "README" that describes how to build and run your code. To be safe, it is best to include your name and student number in each file handed in. Be aware that the markers will be testing your code in the lab environments available in the department (e.g. Linux lab and on www3.cs.umanitoba.ca for database and web work) so you would be well advised to check that your code and build/run instructions are all correct for the test environment(s).