Term
| 1a. 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. |
|
Definition
| N__ The user is no longer seeing System.out.println’s—they go to the tomcat log. |
|
|
Term
| 1b. 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. |
|
Definition
|
|
Term
| 1c. 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. |
|
Definition
|
|
Term
| 1d. No service object should construct another service object, and the service objects should be set up and shutdown by special code. |
|
Definition
|
|
Term
| 1e. 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. |
|
Definition
| Y but..._ Actually, the JPA DAO layer throws exceptions that are of JPA classes or java classes, not SQLExceptions. |
|
|
Term
| 1f. Errors in the business logic layer should throw ServiceException, caught in the presentation layer. |
|
Definition
|
|
Term
| 1g. Don't call up to a higher layer unless you can write a memo on why you need to. |
|
Definition
|
|
Term
| 1h. 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. |
|
Definition
|
|
Term
| I. - 1.(a-h) Here are some coding rules that pa2’s solution followed, previously listed in the hw4 assignment. Recall that the pa2 solution was the final implementation of the client-server version of the pizza system. For each rule, consider if it is still true for the in-server implementations of music3 and music4 |
|
Definition
|
|
Term
| II - 2. (a,b) 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 or pizza4. At the moment, both student sessions are executing in the transaction that does the database insert. |
|
Definition
|
|
Term
2a. Explain what data is held separately for each student:
i. in the session bean/ session variables
ii. in the BL (business layer)
iii. in the DAO layer |
|
Definition
i. pizza3: info on order: room #, pizza size, toppings (but only the room # is relevant for longer than this request/response cycle)
pizza4: room #
ii. (executing in makeOrder) has local variables for PizzaOrder object, with PizzaSize, Topping objects. As local variables, they last only for this one BL call.
iii.(executing in insertOrder) local variables for PizzaOrder object, with PizzaSize, Topping objects (good for duration of this insertOrder call), also an EntityManager object for this thread held in a ThreadLocal |
|
|
Term
2b. 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 in use for this app:
i. of class StudentBean or StudentBean1?
ii. of class StudentService?
iii. of class AdminService?
iv. of class PizzaSystemConfig?
v. of class EntityManager?
vi. of class EntityManagerFactory?
vi. of class HTTPSession?
vii. of class DataSource? |
|
Definition
i. of class StudentBean or StudentBean1? 2
ii. of class StudentService? 1
iii. of class AdminService? 1
iv. of class PizzaSystemConfig? 0
v. of class EntityManager? 3
vi. of class EntityManagerFactory? 1
vi. of class HTTPSession? 3
vii. of class DataSource? 1 |
|
|
Term
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/4). 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. |
|
Definition
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. |
|
|
Term
| 4. 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.) |
|
Definition
|
|
Term
| 4a. Write a business layer 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. |
|
Definition
void addPC(int modelNo, String serialNo, int vendor, int deliveryDay)throws ServiceException;
String getPcToSell(int modelNo) throws ServiceException; |
|
|
Term
| 4b. Write code for SellerBean.java, for session beans for this app, to be used from pure-JSP pages for the salesperson page flow. Use the back of the previous page. |
|
Definition
public class SellerBean {
private PCService service;
private int modelNo;
public SellerBean() {
service = PCServiceConfig.getSellerService();
}
// getter and setter for modelNo
public getSerialNo() {
try {
return service.getPcToSell(modelNo);
} catch (ServiceException e) {
return “failed”;
}
} |
|
|
Term
| 4c. Write pure JSP pages (like pizza3) for the saleperson to specify a model number, say 1234, for the next PC to sell, and then receive back the right serial number to sell, or a simple failure message |
|
Definition
[jsp:useBean id="seller" class="something.SellerBean" scope="session"/]
[html]
[head] [title].[/title][/head]
[body]
[form method="post" action="modelno.jsp"]
PC model number:
[input type="text" name="modelNo"]
[input type="submit" name="submit"]
[/form]
[/body]
[/html]
[jsp:useBean id="seller" class="something.SellerBean" scope="session"/]
[jsp:setProperty name="seller" property="modelNo"/]
[html]
[head] [title] .[/title][/head]
[body] Serial number to use is ${seller.serialNo}[/body]
[/html] |
|
|
Term
5. Consider the example in Murach, chap 8, illustrated p.247 and suppose it is implemented using pure JSP, no servlet. The user visits index.jsp, and then makes a first visit to cart.jsp, then updates the order, causing a second visit to cart.jsp. Here index.jsp has a link to cart.jsp, and cart.jsp has an “update” button, that if used, causes cart.jsp to execute again.
*GET to cart.jsp, with param productCode=8601
[index.jsp with links]-->[cart.jsp with update button]
*POST back to cart.jsp,
params productCode=8601&quantity=3 |
|
Definition
|
|
Term
| 5a. 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/musicStore/catalog in the deployed webapp. Show the full GET or POST command, ending with HTTP/1.1. If the params don’t show in the command, list them as well. |
|
Definition
GET /musicStore/catalog/index.jsp HTTP/1.1
GET /musicStore/catalog/cart.jsp?productCode=8601 HTTP/1.1
POST /musicStore/catalog/cart.jsp HTTP/1.1
With params in body of message: productCode=8601, quantity=3 |
|
|
Term
| 5b. How does the HTML specify that cart.jsp should be executed again when the user clicks the Update button? |
|
Definition
By the HTML form attribute ACTION=”cart.jsp”
(or ACTION=”/musicStore/catalog/cart.jsp”)
(The JSP to generate these would be ACTION=”cart.jsp” or ACTION=”/catalog/cart.jsp”, or better, with use of ) |
|
|
Term
| 5c. What do we need to do in JSTL to ensure that session tracking continues to work when the user clicks the Update button, even if the user has disabled cookies? |
|
Definition
| Use for generating the urls, or otherwise arrange to use response.encodeURL. |
|
|
