Advanced Internet Programming - Assignments 31242/32549/ AJPCPEAdvanced Internet Programming INFO: What's New FAQ Software Machines Oracle Assignments MODULES: 00 Admin 01 Intro 02 Architecture 03 Servlets 04 JSP 05 JDBC 06 RMI 06 JNDI 07 EJB 08 XML 08 Web Services 09 Security 10 Transactions 11 Legacy 12 Review 99 Design LINKS: START page Faculty of IT UTS Advanced Internet Programming - Assignment 2 - Spring 2013 Due date Draft Architecture and Design progress report due: Wednesday 9th October, 05:30pm Working application and final report due: Wednesday 30th October, 05:30pm Late assignments will be deducted 2 marks (out of 40) per day late. More than fourteen days late the assignment item will receive zero. Special consideration for late submission must be arranged before the due date with the lecturer. Weighting This assignment is worth 40% of your final grade in the subject and will be marked out of 40. This is a groupwork project, consisting of 2 or 3 students who will be marked equally, unless prior arrangements have been made with the lecturer. Objectives This assignment is designed to assess objectives #1 Implement a medium sized web application incorporating multiple data sources, transaction integrity, data and application security; #2 Describe at a conceptual level, a full e-commerce application; #3 Describe the components that make up a multi-tier web based application, including application servers; #4 Describe the features of a web based application system that provides robustness, high availability and security; #5 Explain how transactions are used in web applications; #6 Introduce security features to web applications; #7 Compare and contrast competing web application architectures and list their advantages and disadvantages; Description Your task is to write a multiple front-end, n-tier application that: Allows the user to view a list of products Allows the user to enter product orders Allows the user to view an orders Allows an administrator to list orders Allows an administrator to update orders Allows a supplier to list and update orders via web services For this assignment, you will: Design the application, including web site map, database design, architecture and web pages and forms. Create database tables and queries. Use JSP and Servlets to implement the application and presentation logic. See the JSP lecture slides for possible/preferred architectures. It is highly recommended that you implement this assignment with the Type 2 (Model-View-Controller) architecture. You are free to use MVC frameworks such as Spring MVC, JSF, Struts & so on. You must use EJB for business components and data access. Must not use JDBC APIs to access the database (this will be severely penalised) Write a web services server with 2 functions - List orders, and Update order Write a web services client that uses the above web services. Add security to the web services You must use Java EE technologies learnt in the lectures, labs and in the text book. Any additional tools or techniques should be approved in advance by the lecturer. Hints: You should be able to re-use your existing presentation logic from assignment 1. If you used a Model 2 (MVC) architecture, you can move the business logic in your servlet into a session EJB and convert references to the JavaBeans into references to JPA entities. If you used a Model 1 architecture in assignment 1 then you will also have to move business logic in your JSPs into session EJBs and JPA entities will now replace JavaBeans used for database access. The recommended technique for the authentication includes the use of Java EE security roles (see JSP labs), however, other approaches are also acceptable. Ask questions on UTS Online if you have any queries about this assignment. You must regularly read the Announcements and the Assignment 2 discussion board for any clarifications, hints and comments about this assignment Business Specification FC Sportsware Pty. Ltd. has decided to launch an Online shop front to sell its range of soccer sportsware and equipment which they expect to both expand their business and cut costs associated with traditional "bricks and mortar" shop fronts. The Online shop front will sell a range of products including jerseys, shorts, socks, balls, goals and nets. Your job is to design and develop a shop front for customers to browse these products, select these products and to buy these products. You will also create a password protected page which lets an administrator list, view and update orders. Part A. Public web site The Part B specification is identical to that of Assignment 1. However, you must adapt your code to use the Java EE technologies JPA and EJB. A.1 Entry page Your website should have an introduction web page mapped to the path / under your context root. This should provide links to the product browsing/product order pages, as well as some overview of what your company does. It should also have a link for the administrator and any documentation for your assignment. A.2 Product selection Your website should allow the customer to browse the list of products. This list should be organised by the following categories: Jerseys, Shorts, Socks, Gloves, Jackets, Equipment. Consider in your design how this would work if you had 1000s of products! This implies that you should implement some form of pagination, and should allow users to browse products by category. Where possible, try to be flexible so we can add categories and more products later. Try not to hardcode anything. The list of products should include: A product category A product code A product description A product price (in A$) A.3 Product ordering The customer should be able to select one or more products to order. This implies that you will need to have some form of session management, where each customer will have their own "Shopping cart". You are welcome to use any mechanism you wish to manage this, but using HTTP sessions is probably the best way to do this. The customer should be able to enter or select an unlimited quantity for each product order. Your code should cope with adding repeat orders of the same product by adding the quantities together. A.4 Checking out Once the customer has finished selecting and ordering their products, you will need to provide an option to check out. This should provide the following information to the customer Product category Product code Product description Product quantity Line total for each product (quantity * product price) Grand total of the order (sum of all line totals) The customer should then be able to Add more products to the order (ie: continue shopping) Delete products from the order Change quantities of products on the order Cancel the entire order Proceed to purchase the order A.5 Purchasing the order If the customer chooses to purchase the order, they will get a page where they are asked to enter the following information: Name: (Title, Surname, given name) E-mail: (email address) Address: (House/unit number, street, State, Suburb, Postcode, Country) Payment details: (credit card number) After submitting this information, the customer is presented a confirmation page asking them to confirm this information, giving them the option to cancel or proceed. If the customer proceeds, a unique order number must be generated in the format: fituseridnnnn (where fituserid is your Faculty userid and nnnn is a number generated by you. eg: rheise0001). You must then record this order number in the database along with all of the details about the customer's order. After storing the order information, show a final page to the customer quoting their order number with message to confirm that the order has been successfully placed. You are not required to do any processing of this purchasing information. Just record it in a database!! You MUST to create a 7 character column on the order table called status. The various status codes are: ORDERED PAID SENT The initial status code should be 'ORDERED'. Once the customer proceeds, the shopping cart should be reset and they should be returned to the entry page. A.6 Viewing the order A customer should be able to view an existing order. They can do this by entering the order number and surname recorded in the order. This should be via a link on the entry page. Please note that this isn't good practice for real shopping web sites! You should display the following information only for the chosen order: Product Category Product code Product description Product quantity Line total for each product (quantity * cost price of product) Grand total of the order (sum of all line totals) Order status code Part B. Administrator Web site The Part B specification is identical to that of Assignment 1. However, you must adapt your code to use the Java EE technologies JPA and EJB. This part of the assignment will test authentication. You will need to develop a password protected part of the web site that will allow suitably authorised staff to update orders with changes to the order status. B.1 Authentication You will need to create a company orders administrator account which will allow the staff to update orders. This should be a link off the entry web page and this should be password protected. You can use BASIC authentication or FORMS based authentication. You will need to create the following users with the following passwords Username: orders Password: orderspw After authenticating, the user will have two options: View a list of outstanding orders Update an order B.2 View a list of outstanding orders Selecting this option will display a combined list of orders that have a status of either 'ORDERED' or 'PAID'. The list should include the following information Order Number Surname Country Postcode Grand Total of order Status code The user should be able to select an order to update. B.3 Update an order The user should be able to enter an order number directly, or this can be selected from the 'List of outstanding orders' above. When an order is selected, the following information should be displayed for the order: Order Number Name: (Title, Surname, given name) E-mail: (email address) Address: (House/unit number, street, State, Suburb, Postcode, Country) Payment details: (credit card number) Order Status. This should be updatable. You can use text boxes, selection lists, radio buttons or any other mechanism. The following information in the order should also be displayed. Product Category Product code Product description Product quantity Line total for each product (quantity * cost price of product) Grand total of the order (sum of all line totals) For this assignment, you will only need to store and retrieve the orders. You are not required to implement the actual ordering process or do any inventory checking. Part C. Supplier access We are allowing some suppliers to query orders and to update orders on the system. These suppliers will be accessing the system using Web Services. C.1 Web Service Server You will need to create a Web Service which will be invoked by a supplier. This will need to provide the following functions: C.1.1 List PAID orders You will need to create a Web Service operation that will return a list of all orders with the status of 'PAID'. This operation does not require any input parameters. The list should include the following information Order Number Surname Total count of items in the order (ie: the sum of all quantities in the order) Order Status Grand Total of order Note: Order status will always equal 'PAID'. C.1.2 Update an order You will need to create a Web Service operation that will allow an order status to be updated. The following input parameters should be passed Order Number Order Status Notes: Order Status should only be allowed to be set to 'SENT'. Anything else should generate an exception. C.1.3 Authentication Protect your Web Service by including authentication. You will need to create an account which will allow a supplier to update orders. When the supplier performs a web service call, they will need to pass this authentication to your web service. You will need to create the following user with the following password: Username: supplier Password: supplierpw You can choose any means of securing the Web Service, however, hardcoding userids and passwords is not acceptable. Use of Java EE BASIC authentication is acceptable, but more marks will be given for WS-Security. C.2 Web Service Client You will need to write a simple client that demonstrates invoking the above Web Service operations.. This does not have to be a GUI client (a JSP page or a command line client are both acceptable), and should allow the user perform the following functions: C.2.1 Query PAID orders This function should allow the user to invoke the above "C.1.1 List PAID orders" web service operation and should display the result to the user. C.2.2 Update an order status to 'SENT' This function should allow the user to invoke the above "C.1.2 Update an Order" web service, prompting for the "order number" and 'SENT' status parameters. C.1.3 Client Authentication Protect your Web Service by including authentication. Your client will either prompt for a userid and password, or you will have some mechanism (eg: Java .properties file, security certificate) which will allow the client to authenticate with the above Web Service. Part D. Documentation You must provide some project documentation electronically. This can be HTML, PDF, WORD or RTF formats ONLY. Do not submit ODF, DOCX or WP file formats (since I can't read them). Do not provide a user guide to your website - this is not project documentation!! As a minimum, you should have the following: A list of team members and their roles (i.e. identify who wrote which components/parts) An overview of your application (which should include your design and architectural decisions and assumptions) Database definitions (SQL will suffice) Installation/setup instructions. If you are not using WebLogic, please add comments on how you would install this on WebLogic Any additional information about your application Additional documentation will be considered favourably. This includes: The web site map (this can be diagrammatic or textual). The database design (an E-R diagram and/or short textual description) The system design - eg: Use cases, context diagram, architecture and component descriptions. Whenever diagrams are included, they must also be accompanied by explanatory text. UML would be nice but is not compulsory. JavaDoc is nice but not required. A brief discussion of relevant issues such as security, transaction processing etc. Additional information You can make any reasonable assumptions about this assignment, as long as they are documented. For example, you may change the screen flow to suit your idea of site navigation, or you may choose to limit quantities to reasonable numbers. Do not concentrate on the visual appearance of the user interface. This is only worth a couple of marks. Writing the web site in Flash, using fancy graphics, animations etc will not give you extra marks. Keep the navigation and workflow simple and straight forward. Groupwork and Submission Note that this assignment should be developed by a group of 2 or 3 students. Any variation requires prior approval from the lecturer. Any group experiencing problems that cannot be resolved within the group should contact the lecturer as soon as possible to have the problem resolved by the lecturer. No complaints will be heard after the due date. In week 10, by 5:30pm 9th of October, your group is to submit a progress report containing draft of your final documentation (see Part D above), focusing specifically on your architecture and design. This progress report should be approximately 250 words, and should be submitted to the dropbox at UTSOnline/Assignments. In week 13, by 5:30pm 30th of October, your group is to submit your application and final documentation to the dropbox at UTSOnline/Assignments. Your group will also need to demonstrate your assignment to your tutor during your scheduled tutorial session. You are to submit one file only - an EAR file that contains all parts of your submission. The EAR file you submit should be ready-to-deploy into a Java EE server. This means that all source code must be compiled into Java classes, and the directory structure of the EAR file must be correct. Do not include any files which are not directly related to running your EAR file (for example, backup files, old java files etc) You must submit your Java source code in a subdirectory in the EAR file. You must submit your documentation as part of the EAR file. You should have a link to your documentation from the welcome page. You must submit your web service implementation as part of the EAR file. You must submit your web service client as part of the EAR file. It is acceptable to have the web service client as a standalone JAR or .class file. Please indicate in your documentation how to execute/setup your web service client. You must submit your EAR file electronically via UTS online. You must demonstrate the working of this assignment to your tutor during tutorial hours. If you do not demonstrate the assignment, you cannot receive more than 20 marks. Be prepared to describe and explain your design during this demonstration. You must bring a printout of your design documentation with you. Your assignment mark will be finalised and returned 2 weeks after the due date, and a marking sheet will be returned to you with a breakdown of your marks. Expected work load You are expected to spend around 32 hours of work per group member on this assignment. Marking This assignment counts as 40% towards your final grade. An assignment that does not execute (i.e. will not deploy into a Java EE server, or crashes during execution) will receive no more than half the marks available for this assignment. You can demonstrate this assignment on laptops or Microsoft Windows if you wish. The key elements of the assignment are to show that you can build an e-commerce website using Java EE technologies. You do not have to use Weblogic to demonstrate, any Java EE server is acceptable (eg: JBoss, Geronimo, IBM Websphere etc) The marking criteria for this assignment are as follows. The following table illustrates what is required of an assignment to achieve a particular mark: Mark range Description 34+ (High Distinction) To achieve a mark in this range, assignments must satisfy all the requirements for a Distinction grade, but in addition must demonstrate an excellent understanding of the architecture and technologies used in creating n-tier enterprise applications with Java. In addition, assignments in this range must demonstrate originality in their design and/or coding. Good documentation is expected. Note that a large number of hours spent working on the assignment does not necessarily imply that it demonstrates originality. 30+ (Distinction) To achieve a mark in this range, assignments must satisfy all the requirements for a Credit grade, but in addition must demonstrate a very good understanding of the architecture and technologies used in creating n-tier enterprise applications with Java. The design must be sound and the coding must be of a high quality. All requirements described in the assignment problem must be satisfied. 26+ (Credit) To achieve a mark in this range, assignments must satisfy all the requirements for a Pass grade, but the design and coding of the assignment must be more than the "minimum" standard in order to pass. That means the design must show evidence of understanding the Java EE architecture, the application must implement at least 80% of the required functionality and the coding must be good quality. 20+ (Pass) To achieve a mark in this range, assignments must solve the problem described using Java EE technologies, but may do so in a simplistic way. Some of the harder requirements may perhaps be omitted, but the application must implement at least 60% of the required functionality, including authentication. < 20 (Fail) An assignment that does not satisfy the basic requirements of this assignment will not achieve a passing grade. Also, an assignment that does not compile, deploy, or does not execute will also not pass. Some of the features that will be considered when marking the assignment are listed below. Features not on this list may also be assessed if they are relevant to the quality of your assignment. completeness of the assignment. How much of the specification is implemented? overall architecture and design of application level of understanding shown in the demonstration of the solution separation of business logic from presentation logic as much as possible appropriate user interface (a simple interface is adequate, so long as it is easy to use and navigate) appropriate workflow from a user perspective correct syntax of the deployment descriptors, and correct directory structure in EAR file use of relative URLs for SRC, HREF, etc. HTML attributes correct use of RequestDispatcher forwarding and including if appropriate avoidance of hard-coding values where possible (e.g. use , or Java .properties on the web services client) flexibility of application to add more users, categories, products, alternative user interfaces and additional functionality. database table structure chosen use of welcome-file to specify entry URL for application completeness of documentation use of security to protect your web service The following features are optional, but may reflect favourably on the overall quality of your assignment: implementation of security using container-managed authentication (users should not be able to bypass security) visually appealing and well-designed user interface consideration for how well the application design would scale to deal with with thousands of products Collaboration/plagiarism Note that this is a groupwork assignment. Collaboration (as defined by the statement below) is permitted between members of a group, but not between groups. Students are reminded of the principles laid down in the Statement of Good Practice and Ethics in Informal Assessment in the Faculty Handbook. Assignments in this Subject should be your own original work. Any collaboration with another participant should be limited to those matters described in the "Acceptable Behaviour" section. Designs and code from the supplied references, lab material, the Internet or any other source should be acknowledged in the form of comments within the code and/or documentation. In particular, specific code, or forms design, are not to be shared, or developed jointly. Students are not to give other students copies of their assessable work in any form (hard copy or an electronic file). To do so is 'academic misconduct' and is a breach of University Rule 5.3(1)(b). That is, assisting other students to cheat or to act dishonestly in a submitted assignment. Accidental submission of another students work as your own is considered to be a breach of Rule 5.3(1)(a) in that you are acting dishonestly since you should not have a copy of another students work anyway! Any infringement by a student will be considered a breach of discipline and will be dealt with in accordance with the Rules and By-Laws of the University. The Faculty penalty for proven misconduct of this nature is zero marks for the Subject. For more information go to start.it.uts.edu.au/w/doc/student/integrity.html © 2013 University of Technology, Sydney. All Rights Reserved. Redistribution without permission prohibited.
