Introduction
这个JSP作业是个Group作业，虽然整体是一个大工程，但是只需要代写两个页面的一小部分的业务逻辑，其余部分都是别的Group Member来完成。此外XML图，Report图什么的也不用管。
Assignment Overview
This assignment consists of 2 parts: development of a medium-sized web application incorporating web services and production of a report that contains analysis and reflection.
Part 1 – Web Application and Web Services
For Part 1 of the assignment, you are to develop a web application and web services using technologies and techniques taught in this subject as per the guidelines below.
Your task is to develop a web site and web services for allowing people to post advertisements for rooms or homes that others can rent for holidays.
The web interface should support the following minimum functionality:
- Main page: Shows a list of available properties for rent. For each listing, the minimum information to be shown is the location, the type of listing (either ‘whole house’, ‘whole unit’ or ‘bedroom’) and the number of guests that can be accommodated. Users can click on a listing on the main page to be taken to the listing detail page.
- Listing detail page: In addition to the location, listing type and number of guests, this page should also show the full address of the property, the username of the person who listed it (the property lister), and a short description of the property. If a viewer is interested in booking the property, there should be a button allowing them to send an enquiry to the person who listed it (via the enquiry page).
- Enquiry page: This page is an HTML form where a person interested in booking a property can enter their name, email address, requested booking dates and a short message, and submit the form. For this exercise, the contents of the form should simply be stored in an XML file. Do not attempt to implement email functionality (do NOT try and email a copy of the message to the person who listed it).
Note: behind the scenes, the property listing details and user enquiries should be stored in XML. Each team can design their own XML format, but it should at least store a unique id for each property listing, and there should be a way to uniquely identify the user who created the listing (e.g. username).
Your web application should also maintain information about the users placing listings (“property listers”), and should allow these people to:
- Login and logout.
- Create a new property listing.
- Close a listing. Each property listing has a status which is either “available” or “unavailable”. When a listing is created, its initial status should be “available”. Only the person who created a listing should have the ability to close it.
- View a list of their own listings (available and unavailable)
- When clicking on a listing, show the list of enquiries made about that property.
Note: users are the general public who don’t need to login. Property listers are people who must first log in. The list of available properties should be visible even to users who have not logged in, however a property lister (logged in user) should be able to view all of their own listings, both available and unavailable. You do not need to allow new property listers to register. It is sufficient to create a predefined set of property listers in XML. For this assignment, 3 or 4 people would suffice.
On the web service side, you will need to do the following:
- Create a REST web service allowing a client to fetch a list of properties in XML format, according to given URL parameters. Possible parameters are the lister (a username of a property lister), the status (available or unavailable), or numGuests – only show listings that can accommodate at least the specified number of guests. Any or all (or none) of these parameters may be specified simultaneously, and your web service must filter the returned list according to all parameters that were given. If no parameters are given, all available listings should be returned.
- Create a SOAP web service that allows clients to:
- create a listing
- view a list of properties, with parameters as above (but now using SOAP rather than REST)
- close a listing
User authentication information (for property listers) must be provided for creating and closing listings, as only property listers have permission to perform these operations. Retrieving a list of properties can be done without authentication. If the username and password provided are incorrect, the operation should not be performed. If successful, the method for creating a listing should return the id number of the listing just created. For the method to close a listing, if the specified listing to be closed does not belong to the authenticated person (i.e. it was a listing created by another person), then the operation should not be performed.
Note: for this assignment, it is adequate to pass the username and password in an unencrypted form as a SOAP message parameter.
Some additional requirements are as follows:
- All XML files should have a corresponding XML Schema, and you should write custom simple types to describe the format of your data precisely.
- A reasonable amount of HTML output should be generated using XSL Transforms. It is OK if not every page is generated using XSL, but the main data-driven information should be presented using XSL.
- Your web application and web services should perform validation of inputs to prevent system crashes. In the case of your web application, you should display an appropriate error message if the user has inputted incorrect data, allowing them to re-enter the data.
- Your user interface should be well thought out, providing a consistent look and feel on all pages, and providing useful navigation links. The user should be able to get to where he or she wants to go without ever having to click the browser’s back button.
- Your code should be well designed. Do not place all code into your JSPs. Create reusable Java packages, and reusable beans. These beans can then be reused by both your web application and your web services.
- Your code should be commented and neatly formatted.
In teams of three, each person in the team must take responsibility for roughly one third of the work. It is up to your team exactly how you decide to split your work, and it is ultimately every team member’s responsibility to ensure that your team is working effectively. One possible breakdown of the work is as follows:
- One student takes charge of the “data access logic”, including designing XML file formats, reading and writing XML files, writing XML Schemas, and providing Java classes for these operations this that can be used by other members of the team.
- One student takes charge of the “business logic”, including authenticating users, and writing code to perform searches and filtering the data. The business logic should also be provided as Java classes that can be used by other members of the team.
- One student takes charge of the “presentation logic”, including all of the XSL transforms to display the web pages, basic error checking on data the user has input, and ensuring web pages are secure (restricted operations are not accessible to users who are not logged in, and there are no passwords in the URL!)
- All three students should share the work of building the web services (REST and SOAP) equally.
As well as taking primary responsibility for one part of the assignment, students are also expected to work together and support each other as a team.
Note that the essential functionality of the assignment must be implemented using technologies and techniques taught in this subject (Java, JSP, XML, XML Schema, XSLT, SOAP, REST, etc). While you can use other technologies (e.g. JavaScript), they should only be used for non-essential functionality that enhances the overall user experience. However it is neither required nor expected for you to use technologies that were not taught in this subject.
Part 2 – Report
Your team will need to write a report describing the design and architecture of your web application and web services. In your report, you will also need to reflect on your experiences in developing your application, and discuss issues and challenges faced.
Describing the application design and architecture
Each team member should contribute to the report a description of the application architecture of the parts they developed. There should also be a section that describes the overall architecture of the web application. Diagrams are encouraged.
Reflection on experiences
Each team member should write their own reflection of their experiences in developing the application. The reflection may contain (but is not limited to) which topics were most valuable, which topics were most challenging, which topics were necessary to understand to make others fit into place.
Discuss issues and challenges
This part of the report should be a group effort, summarising what you feel are some of the key issues in the development of web applications and web services, and what tools, design patterns and other support is available to simplify these issues or challenges. This part will require some independent research.
Overall
The report should make it clear as to which team member wrote which section. This can either be done in a separate section of the report stating each person‟s contribution, or identified throughout the report (for example, by putting team member‟s names next to report headings).
In writing the report, take care to correctly reference all sources of information that you use, as described in the section on “Academic Standards” below. In particular, note that you should not cut-and-paste significant blocks of text from any other source (including web pages). Short quotes are acceptable, as long as they are clearly identified as quotes, and include an appropriate citation. Paraphrasing text with a citation included is also acceptable.
Failure to properly acknowledge your sources may be regarded as plagiarism.
You do not need to explicitly reference lecture or lab notes used in this subject.
The overall report body should be around 2500-3500 words in length, excluding the cover page, table of contents, abstract, bibliography, statement of contributions, etc, if these are used. The report body is an average of 1000 words per person.