Due Wed 10/1, 12:01am
For Project 1, you will implement version 1 of a Twitter-like microblogging service. Your service will use a two-tier architecture. The replicated front end will consist of one or more hosts, each running a multithreaded HTTP server. You must implement the HTTP server yourself. The back end will consist of a data server that communicates with the front end, stores tweets, and provides tweets to the front end when requested.
Your service will provide very minimal functionality. There will be no user accounts; users can post status messages that may contain hashtags, and search the entire database based on hashtag.
During class on Monday, September 8 the class will decide on the API and data formats used for communication with the front ends as well as between the front ends and back end. I will post the API specs after class and you will be responsible for conforming to the API specifications defined.
Requirements
- You must use a two-layer architecture.
- The front end will consist of an HTTP server.
- The back end will be a data server. The only requirement for the back end is that it must correctly handle concurrent requests to access and/or update data. It must support concurrent reads of the data but must prevent a read or write from happening during another write.
- The front end must accept an HTTP request to post a new tweet. The tweet may contain hashtags. The tweet will not be tied to any user account.
- The front end must accept an HTTP request to search for tweets by hashtag. The response will contain a list of tweets matching the query.
- The front end will maintain a cache of search results it has already returned to a user:
- The back end will maintain a version number that keeps track of the number of updates to the data store.
- When the front end executes a query on the back end, it provides the version number of its cached result of the query (if it has a cached result) along with the hashtag.
- If the back end has not been updated since the version specified by the version number, it will respond with a message indicating that the cached data is fresh.
- Otherwise, the back end with reply with the data and the front end will cache a copy of the data to service later requests.
API Specification
You are required to implement all components of the API specification we defined in class.
Code Design Requirements
Most Lab 2 submissions contained several suboptimal design choices. I will deduct points for all of the following in your Project 1 submission:
- Manual encoding/decoding of URLs -- use URLEncoder and/or URLDecoder instead of String replace.
- Class naming -- choose descriptive names for classes, for example RequestProcessor rather than Service.
- Non-reusable parsing of URL and URL parameters -- do not simply check if the request startsWith("xxx")
- Manual construction of the JSON response -- instead create a JSONObject and use methods to add properties (e.g., restaurantjson.put("name", restaurant); rather than appending "name=xxx" to some string. The latter approach introduces lots of encoding problems.
Submission Requirements
On or before October 1 you are required to schedule a demonstration of your project. A schedule of demo times during the afternoon of 10/1 will be available later. During your demonstration, you will be asked to do the following:
- Run at least two instances of your web server on two different machines.
- Run your data server on a third machine.
- Demonstrate the following test cases - be prepared with an appropriate test client:
- Several correctly formatted POST requests.
- Several correctly formatted GET requests, including requests that retrieve cached data and requests that require data be fetched from the data server.
- An incorrectly formatted GET and POST.
- A GET/POST with incorrect URI
- A PUT request and a DELETE request.
- Provide an overview of your code design.
- Show specific elements of your code and be prepared to answer questions about any portion of your code.