Assessed Coursework Builds Upon The Theory And Programming Exercises
This assessed coursework builds upon the theory and programming exercises in days 5-7 of SCC401.You will design and implement a computational task submission system using one of two possibleapproaches as described below. This coursework represents 50% of your grade for SCC401.
Option A – REST and an RMI server
This option is worth a maximum of 60%. Tasks will be submitted by the user (using a web browser)to a REST service. The REST service will use RMI to post the task to a “worker” server. You should usea load-balancer architecture to enable a cluster of such servers to be used. This worker server willasynchronously execute the task. The results of the task will later be collected by the REST servicewhen requested by the client. The definition of “a task” is given below. Throughout your design youshould pay careful attention to the efficiency of your solution, particularly in minimising the numberof distributed interactions that are required.
Option B – REST and Chord
This option is worth the full 100%. You will implement a computational task submission systemcombining RMI, REST and a DHT. This will test your ability to use each of these technologies and tointegrate them. Tasks will be submitted by the user to a REST service; allocated to a “worker” nodein a DHT which will execute the task; with results later collected from the DHT by the REST service.The definition of “a task” is given below.
A basic solution must demonstrate the ability for the user to upload a task, for that task to beassigned to a DHT node and (asynchronously) executed there, and for the user to later download theresults of that task from the REST service. Note that your DHT implementation must use RMI forinter-node communication. Also note that you can easily place RMI “client-side” code into your RESTclass but you should not attempt to also use it as an RMI “server” (see tips section below).Throughout your design you should pay careful attention to the efficiency of your solution.
You can gain up to 80% with a solution matching above description. To achieve the remaining 20%,you must generalise your implementation to accept multiple different types of task (at least 3). Youwill need to design a way of describing what kind of task is being submitted so that the taskprocessing nodes know which kind of processing to use on the associated input file. Additionally,your REST server should provide an intuitive way of showing which tasks have been completed (sotheir results are ready to be downloaded) and what kind of task each completed task is.
Definition of a Task
For the purposes of this exercise a computation task is assumed to be a text document which shouldbe analysed to determine: (i) the total number of words; (ii) the most frequently occurring word; and(iii) the average word length. The results should be returned as an XML file with this information.
The student must submit their code and a report (maximum 1200 words) detailing their submission.Code should be submitted as a compressed zip archive and the report should be submitted as a PDF.Students are advised to test that the exact code submitted compiles and runs from a commandprompt on a standard Windows setup. Your report and code must be submitted to the onlineMoodle system by 6th February 2015 at 4pm.
This coursework will be graded on functionality, software design, code clarity including appropriatecomments, and evidence of thoughtful features beyond the basics described here. The report will begraded on readability and insight into the rationale behind your design. Your report is worth up to15% of the overall mark, with your code making up the remaining part of your mark (i.e. the code isworth up to a maximum of 45% for option A, or 85% for option B).
Your report should not contain your name (neither should your code contain your name).
Your report must have the following sections (section word counts are guidelines only!):
Overview: 100-200 words. Describe the problem and outline your solution. Briefly describe how tocompile and run your code (e.g. the command-line commands to compile/run each element or theweb addresses to use in the case of browser-based REST interactions).
Design: 900 words. Describe your design in more detail and highlight any extensions attempted orother unusual features that you would like to draw our attention to. Where appropriate providerationale for your design choices (e.g. why you picked one particular solution from multiple options).You may also provide references to reading / other material you used beyond the course material.Notes on how you tested your solution (e.g. the range of test cases covered) may also be provided.
Personal assessment: 100 words. Provide your thoughts on the coursework in general (i.e. what didyou like / dislike about it, was it appropriate difficulty etc.) and describe what you have personallylearned from doing this coursework.
Your report may include one diagram which will not be counted towards the word limit. Note thatthis is optional and no marks will be deducted for not having a diagram!
Also note 1200 words is an upper limit. If you can adequately describe all pertinent aspects of yourcoursework solution in fewer words, that’s fine, as long as you have all sections listed above.
Your REST class will at some point need to interact with an RMI “server” (e.g. a Chord node) and so itwill have RMI “client” code in one or more of its functions. Note that the RMI interface class used bythe REST class to interact with the RMI server must be present in the folder “myapp\WEB-INF\classes” (assuming that you’re using “myapp” as your REST package folder – see lab day 2).
Note that your Chord nodes should not process submitted tasks within the “put” function, or anyother function called by the REST server (if you did this the client would have to wait for theprocessing to finish). Instead the Chord nodes should process submitted tasks asynchronously.Likewise, if using option (A) of the spec, your worker server must process tasks asynchronously.
Depending on the distributed architecture that you decide to use you may find a need for your RESTservice to have an RMI “server” element. If so, note that instead of trying to directly make your RESTclass an RMI server, you should develop a separate server class that runs at the REST server (but isstarted manually) and which the REST class is an RMI client to and can cheaply poll when needed.Draw architecture diagrams on paper to help yourself understand the flow of interactions.
Students are again reminded of the University’s policy on plagiarism. All coursework submissions arechecked for similarity by an automated plagiarism detection system and are further checked by thestaff that grade your work. Penalties for plagiarism are severe and, in cases where students havecopied from each other, affect both of the students involved. Students are expected to discuss their work and ideas with each other but make sure that their solution is entirely their own.