CS636 Practice Final Exam Solution

Open books, handouts, solutions, etc.

Show all work on these pages, using backs of pages if needed.  Points are marked in parentheses.  Total points = 150.

 (40) 1.  Here are some coding rules that pa2’s solution followed, previously listed in the MidtermReviewOnLayers.  Recall that the pa2 solution was the final implementation of the client-server version of the music system. For each rule, consider if it is still true for the in-server implementations of pizza3 and music3, and mark it as follows:

 

Marks:

Y  It fully holds for the in-server implementations (no justification needed, and true for many of these.)

E   It holds if an edit is done to the language of the rule (and give the edit or new version.)

N   It no longer holds (give the reason.)

 

  1. System.in and System.out are only for talking to the user, only in the presentation layer.  This means no System.out.println's in the lower layers.

Mark:_N__  Edit/Reason:  The user is no longer seeing System.out.println’s—they go to the tomcat log.

 

  1. The business layer service APIs should be able to handle all the needed actions for the apps in the presentation layer, i.e., the apps should not call the DAO APIs directly.

Mark:_Y__  Edit/Reason:  

 

  1. The DAO should provide all the DB actions needed by the logic layer, in a way natural to the business layer requirements.  No SQL knowledge should be needed by the business logic programmer.  

Mark:_Y__  Edit/Reason:  

 

  1. No service object should construct another service object, and the service objects should be set up and shutdown by special code.

Mark:_Y__  Edit/Reason:  

 

  1. Errors in the DAO layer should throw SQLException, caught in the business logic layer and usually rethrown as ServiceException. We could set up a DAOException, but it's somewhat expensive to catch and rethrow, so we'll let SQLException do the job.

Mark:__Y but..._  Edit/Reason:   Actually, the JPA DAO layer throws exceptions that are of JPA classes or java classes, not SQLExceptions.

 

  1. Errors in the business logic layer should throw ServiceException, caught in the presentation layer.

Mark:_Y__  Edit/Reason:  

 

  1. Don't call up to a higher layer unless you can write a memo on why you need to.

Mark:_ Y __  Edit/Reason:   

 

  1. Consistent with the earlier rules, as much code as possible should be pushed down from the presentation layer to the logic layer.  The presentation layer has the minimal code needed to interface to the user.

Mark:_ Y __  Edit/Reason:  

 

 

(30) 2.  Suppose two students are ordering pizza at the same time, from different client systems, using an in-server implementation of the pizza system, that is, pizza3.  At the moment, both student sessions are executing in the transaction that does the database insert.

 

a. Explain what data is held separately for each student:

i. in the session bean/ session variables

 

pizza3: info on student: room #

 

ii. in the BL (business layer)

 

(executing in makeOrder) has local variables for PizzaOrder object, with PizzaSize, PizzaTopping objects. As local variables, they last only for this one BL call. Also an EntityManager object for this thread held in a ThreadLocal (good for duration of this transaction)

 

 

iii. in the DAO layer

(executing in insertOrder) local variables for PizzaOrder object, with PizzaSize, PizzaTopping objects (good for duration of this insertOrder call), also an EntityManager object for this thread held in a ThreadLocal (good for duration of this transaction)

 

b. Suppose at this moment an admin is setting a pizza ready, and has just started a transaction for this action, but it hasn’t yet changed anything in the database.  Thus there are two student sessions and one admin session in progress at this time. How many objects (0 is one answer) are there in the system for this app:

i. of class StudentBean? 2

ii. of class StudentService?  1

iii. of class AdminService?  1

iv. of class PizzaSystemConfig?  0   (not instantiated)

v. of class EntityManager? 3

vi. of class EntityManagerFactory? 1

vi. of class HTTPSession? 3

vii. of class DataSource? 1

 

 

(20) 3.  We developed the service layer API for the pizza system originally while using the client-server architecture (pizza1/2).  .  We have been able to use the same API for the in-server implementations (pizza3).  Which of the following ideas (all true) best explains why this happened?  Discuss, explaining what a business layer API expresses, and assuming a layered architecture in both cases.

--both in-server and client-server architectures support multiple concurrent users

--transactions should not have user interactions within them, so the work of a database-backed application is subdivided by user interaction needs.

--we were using JDBC to access the database in both cases.

 

This is of course open-ended.  I would pick the second idea as the most important reason the BL API is so portable.  The needed actions of the app are the actions that occur between user interactions, however those interactions are done.

The business layer API expresses the actions that the system can do without user interaction during the action.

 

4.  Consider the example in Murach, chap 7, illustrated p.205 (and in a handout), and provided in ch07cart. The user visits index.jsp for the first time, and clicks a button for 86 (the band), productCode 8601, causing the first execution of the servlet and display of cart.jsp. Then the user updates the order to quantity 3, causing a second execution of the servlet and second execution of cart.jsp.



page flow
 

 

 

 

 

 

a. Write down the sequence of requests from the browser, starting from the one that first retrieves index.jsp. Assume that index.jsp and cart.jsp are in tomcat’s webapps/ch07cart directory in the deployed webapp.  The forms in index.jsp have action=”cart” method = “post”, and a hidden input field called “productCode”. The forms in cart.jsp have action=”” (could be action=”cart”)  method = “post”, and two hidden input fields called “productCode” and “quantity”. Show the full POST commands, ending with HTTP/1.1. Since the params don’t show in the command, list them as well (they would be encoded in the POST body)   

GET /ch07cart/index.jsp HTTP/1.1

POST /ch07cart/cart HTTP/1.1

With query params in request body: productCode=8601

POST /ch07cart/cart HTTP/1.1

With query params in request body: productCode=8601, quantity=3

b. Here the servlet executes in two separate request cycles. Explain how the the second execution has knowledge of the previous user choice of product “8601” with quantity = 1 in the first execution.

 The cart object is a session variable, available in all the request cycles in the session (assuming cookies are enabled in the browser, as we have been doing.). The first servlet execution adds the product to the cart, and the second servlet execution can access that cart and see the previous contents.

(30)  5.Consider the application scenario from the practice midterm. Suppose you are automating operations for a store selling PCs.   All PCs of a certain model number are equivalent as far as buyers are concerned, but the store wants to sell them in FIFO (first-in, first-out) order so that no box gets too worn-looking.  Each PC has a model number (int), serial number (10-char string), vendor id (int), and delivery date (int day number, when the PC arrived at the store.)  At sale-time, the salesperson will enter a model number and get back the serial number of the system to sell (in case of ties for oldest, any one of the oldest.)

  1. Write a business layer (service) API that allows entry of new PCs by inventory clerks and retrieval of the next one to sell by salespeople.  Don’t forget the exceptions.

   void addPC(int modelNo, String serialNo, int vendor, int deliveryDay)
                          throws ServiceException;

   String getPcToSell(int modelNo) throws ServiceException;

 

     public void doPost(HttpServletRequest request, HttpServletResponse response)
                  throwsIOException, ServletException {
            String requestURI = request.getRequestURI();
            String url = null;
            if (requestURI.endsWith("lookupPC.html")) {
                String modelStr = request.getParameter(“model”);
                int modelNo = Integer.parseInt(modelStr);
                String result = inventoryService.getPcToSell(modelNo);
                Request.setAttribute(“serialNo”, result);
                url = “found_pc.jsp”; 
            }

            getServletContext().getRequestDispatcher(url)
                        .forward(request, response);
      }

  1. Write found_pc.jsp, using data you attached to the request object in DispatcherServlet.
found_pc.jsp:

<html>
<body>
      Serial number to use is ${serialNo}
</body>
</html>