CS636 Programming Assignment 1:  Client-Server Programming with JDBC

We will implement the core of the Music Store app of Murach as a client-server program, following the structure of the provided pizza1 project.

User app (simplified from Murach) and supplied in stub form.

See Murach pg. 645 for the home page of the web-app version of the user app.  It shows:

   Browsing through a catalog of CDs (the Catalog page)
   We're skipping the email items (join list, contact cust. support)

Thus the effective top level of the user app for us is the Catalog page.

The Catalog page, also shown on pg. 645, displays the catalog, i.e., the list of CDs. The user can choose a particular CD (for example product code 8601) and get more info on it, or display the current cart (Cart page, see below) or go back to the Home page.
     The resulting Product page for chosen product code 8601 is shown on pg. 675. From here, the user can:

1.      Browse the catalog (return to the top level Catalog page)
Show cart: displays cart contents (Cart page).
Add to cart: displays new cart contents (Cart page, see below)
Listen to sample (more just below)

Listen to Sample:  if user is not registered, they must register now (Register page, pg. 675). Then a Sound page (pg. 676) is displayed, where the user chooses which song to play, with additional options for actions 1-3 above. If a song is chosen, its mp3 is fake-played (print out its URL), the download is recorded in the DB, and the Sound page is redisplayed.

Cart page (pg. 677): displays cart contents. The user can:

  After the display of the Complete page,  the user is returned to the Catalog page. In the web app, the user will have a choice of returning to the Catalog page or the Home page.

Admin app (also simplified from Murach), supplied, but needs some fixes in service layer to work properly.
Note that admin users are defined in the userpass table, and should not to be confused with ordinary site users.
The admin app’s top-level page is the Login page, p. 681. Ignore the home and “Browse Catalog”, and other links here. The entered username and password must match userpass data. Then on to the Admin Menu page, pg. 683, 2 choices: Process Invoices and Display Reports
     Process Invoices: list unprocessed invoices (Invoices page, pg. 685, but add invoice dollar total column), and instead of “Click to view”, just suppose the link says “Process Invoice”. Additionally, the user can go back to the admin Menu page. When the “Process Invoice” action is done for a particular invoice, the invoice is processed, that is, the "is_processed" field is set to ‘y’ in the invoice row in the DB, and the remaining unprocessed invoices are listed again. This is fake order processing of course.
    Display Reports: Just support lists of invoices (as in Process Invoices, but all invoices, processed or not) and lists of downloads (download id, product code, filename, user, download date, in download time order).

Note that the Cart is held in memory only, not saved in the database. The apps change the database only by adding/updating users, downloads, lineitems, and invoices, and updating the isProcessed column of invoices. This is typical of a simple web app. The DBA can insert a new row for a new CD when necessary, for example, or a new row of userpass for a new admin.

Design Tasks (not necessarily in order, and to be revisited as you go)

How to proceed?  Here are some ideas.

1.  Install and run the supplied music1-setup project and copy it to music1, for your first delivery. Set up an eclipse project, and compare it to pizza1.
2.  Create the tables in Oracle first and write a program Register (in cs636.music.presentation) to insert a new user, directly, no User object, no "DAO" yet.  This brute force starter program follows the idea of using all the pieces of the needed technology as soon as possible.  Elegance can wait a bit.
3.   Make the simple program work for MySQL as well (the server on topcat or both that and your own).
When you finish these 3 steps, put this version in your cs636/pa1a directory at cs.umb.  This is problem 5 of hw3.
4.   Refactor Register to use the supplied User domain object and a DAO for it (one way: Murach UserDB, pg. 667, but don't use static methods!).
5.  Write the User-related service methods and make the ureg command work in SystemTest, then the gui command.
6.  Write the ProductDAO, first without Tracks and then with Tracks. The provided InvoiceDAO may help, since an Invoice has LineItems.

7.  Write the Product-related service methods and make the gp and gpi commands work in SystemTest.
8.  Now that Users and Products are supported, uncomment parts of the provided Invoice and Download DAOs and get them working.

9.   Incrementally, fill out the service API to go with your DAOs and get more of SystemTest to work.
10   Fill out UserApp.java and make AdminApp work.

Here is the test.dat for SystemTest, read in the same way pizza1's SystemTest reads its file.

i             reinitialize system to bring it back to starting state
gp            get a list of CDs (products)

gpi pf01      get info for product pf01
ureg  joe smith joe@cs.umb.edu     register user
ureg  sue cohen sue@cs.umb.edu     register user
gui sue@cs.umb.edu      get info on user
gti pf01               get track info for CD pf01
dl joe@cs.umb.edu jr01 1    record download by user joe of product jr01, track 1
cc            create cart (for current user)         
addli pf01    add lineitem for prod pf01 to cart 
sc            show cart            
co sue@cs.umb.edu
       checkout cart for user (creating invoice 1 for it)
setproc 1     set invoice 1 as processed
gi            get list of invoices
gd            get list of downloads

Note: this is not a complete test, but will have to do for now. We may change it, so check again before using it.

Cart Handling: We don't need unique id's for carts, because they are memory-only constructs. As shown in the stub version of UserApp, the presentation layer needs a cart variable to remember its Cart object across multiple user actions. The "new Cart()" is code in the service layer, executed at the request of the presentation to create a cart.  That's the cc command above. The presentation layer passes the cart back to the service layer in any subsequent cart action. So the service layer does not have to remember the "current cart" itself.

Although the pizza1 project has some unit tests, in files *DAOTest.java, you can ignore these for pa1a and pa1b, since we have not yet covered the JUnit testing package in class.

Implementation Notes.

Final delivery: this may be edited, so check back

Due Sunday Oct. 29, midnight, in your cs636/pa1b directory, full project with java files, database support, and build.xml, tested 6 ways (UNIX, Windows) x (Oracle, mysql, hsqldb). 

cs636/pa1b/build.xml with added targets for pa1a such as oraTest (these should still work, as specified in hw3 #5)
cs636/pa1b/src: top of source tree, Register.java from pa1a
cs636/pa1b/src/cs636/music/presentation/SystemTest.java, UserApp.java—filled in with working calls to your service layer
cs636/pa1b/src/cs636/music/service/*.java: provide a complete service API even if you don't have time to implement all of it. Leave unimplemented service methods as "stubs", i.e. just { return null; } or whatever is needed to avoid compiler warnings.

--other source files can be named anything reasonable, all java files in the expected packages will be collected.

grading run (what I will do to test your project):
reload all three databases
use your build.xml for the following:
ant clean
ant build

ant oraTest  (run Register.java in cs636.music.presentation)
ant oraSysTest
ant show-oradb (using database/build.xml)
ant mysqlSysTest
ant show-mysqldb (using database/build.xml)
ant hsqlSysTest
ant show-hsqldb (using database/build.xml)

Late Days
Each student has 3 late days to apply to the 2 project deliveries, to cover ordinary problems like business trips, other deadlines, etc. You can use them in any pattern, but not all 3 for one project--I will record the number of late days used on each project along with the score. To use late days, simply put a README in your project directory (pa1b this time) saying how many days you are using.