Project Information

CS/CIS 530 has a substantial, multi-part programming project, which will be done in groups of two or three students.

The ultimate goal is the design and implementation of a website. You get to define what your website will do, with certain constraints. Your project should:

• support atomic transactions of some kind.
• support authenticated sessions and encrypted data.
• support a mix of transactions that includes some very frequent small transactions as well as less frequent large transactions.
• do something arguably useful.

These requirements slightly constrain your choice: Amazon, eBay, an airline reservation or supply chain management system would be okay, but a search engine would not (no transactions).

Your project should also

• be scalable–you should be able to argue on paper and to show experimentally that your design could scale to large numbers of users simply by adding hardware. This argues that large transactions should perform well, and that large numbers of small transactions should perform well, achieving a high degree of parallelism.
• be highly available–your design should allow for appropriate replication/redundancy, failover and queueing techniques to eliminate as many single points of failure as possible.

Here is a list of URLs for recommended project resources, that is, documentation and software downloads you might consider using in your project. This list will grow rapidly in the next couple of days.

(Due 17 Feb on CMS) Initial Conception of what service your website will provide to the public. Right now this seems completely open-ended. To show the level of detail we want, here is an example for the WebVan site we discussed in lecture. Please create a PDF file (or just a .txt file if PDF is a problem for you) and submit this in electronically using CMS.

Note:Submit the description once per group.

Use CMS to form your group before submitting the project concept document. Instructions for forming a group are part of the CMS documentation (PDF).

(April 1) Mockup and Detailed Design for the Initial Conception site we have agreed upon. The “mockup” could just be a written description, but better a simple site (e.g. built using JSP, or even just static HTML pages) that lacks functionality such as session management, transactions and failover but demonstrates the user interface “look and feel” of your design.

Design a very simple UI and stick to it for the remainder of the project. The point of this whole exercise is to learn and use the technology, not build an artistic site.

You should include “usage cases” describing each of your site's major functions.

The “detailed design” should describe your multi-tier design: where components reside and how they interact, what external WebServices interfaces exist, tentative database schemas where appropriate, (or a description of your data as persistent Entity Beans!), provisions for fault-tolerance and scalability.

Nearly all the projects have asynchronous components (e.g. shipping, sending email to a customer when a back-ordered item is shipped). These will be triggered either by some of your usage scenarios or possibly by invocation from a business partner. You should describe these asynchronous processes in enough detail to convince us they work.

You will get feedback on this.

(April 23) Status Report for my information (here is no grade for this). Just a couple of paragraphs saying what your current status is. What software (Web server, app server, database, IDE/toolkit) are you using, what is the status of its installation, how far have you gotten in implementation of the project.

Don't spend much time on this.

(Date on signup sheet) Project Demo.

The signup sheet remains on the door of 4115 Upson.

The “default” configuration seems to be to run the application server(s) on a laptop, using either our provided Oracle™ back end or a database that also runs un the laptop. In that case the demo will take place at my office (Upson 4115).

If you need to do your demo somewhere else (e.g. if your server doesn’t run on a laptop) please make arrangements by email with me or Adrian well before your demo is scheduled.

CMS Submission: There are two components we ask you to submit to CMS by midnight the night before your demo:

• A short architecture summary document that describes the site as it exists at the time of the demo. This is our “pre-reading;” we will use it as the basis for our penetrating questions as we grill you mercilessly about properties of your design.
• A .zip file of your sources. It is okay for you to make last-minute changes after you submit the sources but before the actual demo.

Don’t stress out over any of this–it’s supposed to be fun.