In this project, you will gain experience working with concurrency, network programming, and cloud computating. There are three pieces of the lab. First, you will write a client-server program simulating an online bookstore. Second, you will deploy your program to cloud machines located in Amazon EC2 and evaluate your program's performance when compared with local machines. Third, you will write a short paper on Amazon EC2 to gain a better understanding of how the 'cloud' actually works.
You are launching Nile.com, a new business to facilitate high-frequency book trading (HFBT). Your service will allow customers to rapidly buy and sell books in realtime from the comfort of their homes. Your task is to write the server program that will manage your inventory and be responsible for handling customer requests.
Your server must expose the following remote interface to clients:
int sell(String bookName, int copies);
This method is called when a user wishes to sell the specified number of copies of the specified book to Nile.com. The books are added to inventory, and the previous stock of the book is returned to the client (i.e., the stock before the new copies were added). If the specified book name is not already in the directory, it is added. If the request is not valid (e.g., copies is negative), the server should throw an exception to the client.
int buy(String bookName, int copies);
This method is called when a user wishes to buy the specified number of copies of the specified book. If the requested books are available, they are deducted from inventory. If the book has insufficient stock, then the server should 'buy' the available inventory and then wait for up to 10 seconds for other copies to arrive (you're expecting a lot of traffic at Nile.com), claiming inventory as it arrives.
If multiple users are waiting on the same book, the user that sent its buy request first should receive all added inventory until it has timed out or reached its desired number of copies.
Once either the specified number of copies has been claimed or 10 seconds have passed, the server should return the final number of copies bought to the client. As with selling, this method should throw an exception if the request is invalid.
Your server may expose other methods as well, but must include the above two following the specified behavior.
In addition to your server itself, you must design client test cases that evaluate the behavior of the server. Your test cases should demonstrate that your server is working correctly by creating multiple client threads, having the threads issue requests to the server (possibly in a particular order), and verifying that the expected responses are received.
For example, a very simple test case would be to issue a buy request for a new book (any number of copies), and verify that the server returns zero (after waiting 10 seconds).
Your program will have two main components - the server (which processes requests from clients) and the client (representing users issuing requests). Your server must be able to handle any number of concurrent clients issuing requests. You will write your system in Java, using Remote Method Invocation (Java RMI) for communication between clients and the server. You should use Java's concurrency functionality to handle multiple users (e.g., synchronization and monitors).
Starter code consisting of a minimal RMI client/server program is provided below.
$ wget http://lass.cs.umass.edu/~shenoy/courses/377/labs/3/lab3-starter.tar.gz
$ tar xzvf lab3-starter.tar.gz
To compile and run the client and server on the local machine, you can do the following (running the client and server in separate windows):
$ javac lab3/*.java
$ java lab3/Server
$ java lab3/Client
Your primary two files should be Server.java (your main bookstore server code) and Client.java (which includes your testing code). You may wish to add an interactive client that allows you to type and issue manual requests to the server, but this is not required.
RMI automatically creates threads on the server side when requests are received, so you do not need to explicitly create or manage threads on the server. However, for testing, it will be useful to explicitly create multiple threads client-side to simulate multiple concurrent users.
A list of references that may be useful:
Many other tutorials and references on these topics may be found online.
If you have not used Java RMI before, you should review the above RMI tutorial before starting to code. The tutorial covers setting up a very basic "Hello Word" RMI application involving a client and server. Note that the tutorial gives instructions on starting the RMI registry from the command line (under "Start the Java RMI registry") - in general, this is not necessary, because your sever can start its own registry from within Java code using the LocateRegistry class. As always, JavaDoc is your best friend when using an unfamiliar library such as RMI, so be sure to use it if you are not sure about something.
You should first test your system on your local machine (or EDLAB). You can create both the server and clients on the same machine initially, then move to testing on multiple machines.
To test your system, you should create a test program that creates multiple client threads (simulating many concurrent users accessing the server). These threads should issue requests in parallel to allow you to test that your program is handling concurrency correctly. Remember that concurrency errors due to bugs can appear unexpectedly, even if your program seemed to be working correctly previously. Running with many threads will help ensure that your program is correct.
Amazon EC2 (short for Elastic Cloud Compute) is Amazon's public cloud service that rents out machines to arbitrary users for their applications. These machines are housed in large datacenters spread throughout the world, with each datacenter containing thousands of individual machines. We are going to give you access to accounts on EC2, which will allow you to run your server on EC2 machines. You will then test your server to compare its performance on EC2 vs. a local server (e.g., an EDLAB machine).
We have created a single EC2 instance that will be shared by all groups. To gain access to the instance, email the TA and CC all group members. Do this ASAP, even if you are not yet ready to run your program on EC2. You will then be provided with the following:
Once you have the above, you can log into the EC2 instance using the above keypair:
ssh -i id_group7 group7@1.2.3.4
The EC2 machine is configured as a standard Linux machine, and should have all the software you require already installed (e.g., Java), although you may email the TA if you want something else installed. You should be able to copy your program to EC2 and run it with minimal modifications. However, a few things you should keep in mind:
Once you are running on EC2, you should take some benchmarks of how your system is running. In particular, you should measure:
To take these measurements, you will likely need to add code to your program -- the System.currentTimeMillis() method will be helpful in benchmarking.
You should document whatever experiments you ran (exploring the above properties and anything else interesting you observe in your system) in a separate EXPERIMENTS file, along with providing and discussing the results of those experiments. Graphs are helpful but not strictly necessary, so long as your textual discussion is clear.
This part of the lab should be completed individually.
The final component of project 3 is to write a short term paper on EC2 to gain a better understanding of how the 'cloud' actually works.
First, you should read the EC2 primer. While you do not need to analyze every number and feature covered, you should get a good understanding for how Amazon operates its cloud computing services.
You should then write a short term paper (2 pages or so) overviewing what EC2 is and why it is useful. In particular, your report should cover the following issues:
Your report should be uploaded to Moodle separately from the rest of your submission (everyone must submit a report, while only groups need to submit the rest of the lab).
You should upload two archives to Moodle - one containing parts 1 and 2 (one submission per group), and one containing your report from part 3 (one submission per person). The submission deadline is Friday, December 7 at 9 pm. In particular, your submissions should include (as detailed above):
Note: We will strictly enforce policies on cheating. Remember that we routinely run similarity checking programs on your solutions to detect cheating. Please make sure you turn in your own work.
You should be very careful about using code snippets you find on the Internet. In general your code should be your own. It is OK to read tutorials on the web and use these concepts in your assignment. Blind use of code from the web is strictly disallowed. Feel free to check with us if you have questions on this policy. And be sure to document any Internet sources/ tutorials you have used to complete the assignment in your README file.