java web代写： 31284 Web Services Development Assignment

31284 Web Services Development Assignment – Autumn Semester 2018

DUE DATE:

Weighting: Group work:

Week 11, 11:00PM Thursday 31 May 2018

40% of your final grade

This is a group assignment, normally to be done in teams of three (3). Other team sizes will only be permitted where the number of students in a class is not divisible by three, and only with the permission of the subject coordinator. Team sizes other than three may have the requirements described in this document adjusted to reflect the number of team members. It is not permitted to leave a group to work alone or join another group after the groups are finalized in week 6 (Assignment release week). A penalty of 50% towards the assignment mark will apply to the leaving student.

This assignment must be the original work of your team. Plagiarism, including copying or sharing code between teams or taken from other sources, may result in an allegation of academic misconduct being made against you. Please read the section on Academic Standards.

Assignments submitted after the deadline will be deducted 8 marks out of 40 per calendar day (including weekends, holidays, working days). If the assignment is submitted more than five calendar days late, the assignment will receive zero.

Special consideration, for late submission, must be arranged with the Subject Coordinator before the assignment deadline. When requesting special consideration, documented evidence of illness or misadventure must be provided.

This assignment addresses the following subject objectives:

1. Describe and evaluate typical application architectures and

   requirements for web-based applications

2. Discuss some of the issues of designing web-based applications in

   an e-business context

3. Describe the roles and uses of web-based applications in

   organizational contexts

4. Apply concepts of information representation and parsing, in the

   context of XML and other relevant standards for information

   interchange

5. Describe and evaluate different technology options available for

   the development of web-based applications

6. Develop a small, distributed web-based application based on

   existing software libraries.

Late submissions/ Special consideration:

Objectives

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, architecture, reflection, challenges and research based on references in neatly formatted bibliography.

Part 1 – Web Application and Web Service

For Part 1 of the assignment, you are to develop a web application and web service using technologies and techniques taught in this subject as per the guidelines below.

Your task is to develop a site and web service for allowing students to post advertisements for selling second hand text books.

The web interface should allow users to:

• Main page: Shows a list of titles of available textbooks for sale. For each book title,

  the minimum information to be shown is the book title, book author, category (e.g. Computer Science, Biology, Physics etc.) and the number of textbooks with the title. Textbooks with the same title will be only listed as one item in the main page. Users can click on a book title on the main page to be taken to the book detail page.

• Book detail page: Shows a list of textbooks with the selected title. For each book, in addition to the information listed in the main page, this page should also show short text (abstract) of the book and the username of the student who listed this book, publication data (e.g. ISBN, edition, year of publication, publisher name), and the condition of each book (i.e. As new, Good, Fair and Poor).
• Reserve book page: A user can reserve a particular book by inputting his/her name and email address. For this exercise, the user’s name and email should be simply stored in an XML file.

  Note: behind the scenes, the list of textbooks and user reservations should be stored in XML. Each team can design their own XML format, but it should at least store a unique id for each textbook, and there should be a way to uniquely identify the user who created the listing (e.g. username).

  Your application should also maintain information about the users placing listings (“textbook listers”), and should allow these people to:

• Login and logout.
• List a new textbook.
• Delete an existing textbook.
• View a list of their own listings
• When clicking on a listed textbook, show the reservation information.

  Note: users are the general public who don’t need to login. Textbook listers are users who must first log in. All listed textbooks should be visible to all users. Reserved books should be shown as “reserved”. You do not need to allow new textbook listers to register. It is sufficient to create a predefined set of textbook listers in XML. For this assignment, 3 or 4 listers 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 textbooks in XML

format, according to given URL parameters. Possible parameters are the lister (a

username of a textbook lister), the status (reserved or not reserved), or the condition of the books. 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 listings should be returned.

• Create a SOAP web service allowing a client to: o List a textbook,

o fetch a list of all textbooks, and

o delete a listed textbook.
User authentication information (for textbook listers) must be provided for listing and deleting a textbook, as only listers have permission to perform these operations. Retrieving a list of textbooks can be done without authentication. If the username and password provided are incorrect, the operation should not be performed. If successful, the method for listing a textbook should return the ID number of the textbook just listed. For the method to delete a textbook, if the specified textbook to be deleted 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.

• Create a SOAP web service CLIENT as a standalone Java application (i.e. with a main method) that invokes each of the SOAP web service operations.

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. You should use regular expression for all fields. All XML should be valid.
• 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.
• The data validation should be server-side not client side (Do not use Java Script or CSS for data input validation). Use in-line validation server side.
• 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.
• All XML should be properly validated against their corresponding schemas. All XML

  can be properly transformed into HTML output in Netbeans. No errors should occur

  during validation and transformation due to connection of XML, XSL, and Schema.

• XML Schemas must use regular expression patterns for all fields.
• 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.). You can use other technologies (e.g. JavaScript, CSS), but they should only be used for non-essential functionality that enhances the overall user experience (Do not use Java Script or CSS for data input validation). However, it is neither required nor expected for you to use technologies that were not taught in this subject.

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 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 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.

  Note: Students will be individually asked to explain their own code (the code they say they contributed towards in the assignment) on Demo day. Failure to explain your own code will negatively affect the mark of the whole group. 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.

  Bonus (4 marks):
  When completing any two bonus tasks, you will have the opportunity to earn extra 4 marks (the maximum marks for the subject is 100 and maximum 4 marks will be given for completing bonus tasks).

• Bonus task 1: Allow new listers to register. (2 marks)
• Bonus task 2: On the main page, allow users to filter the listings shown based on the

  status of the listed textbooks (for example, only show un-reserved books). (2 marks)

• Bonus task 3: Allow a user to cancel his/her reservation on a textbook.
• Bonus task 4: The SOAP Web Service Client allows a user to reserve a textbook. (2

  marks)

  Note: for a group of 4 students, Bonus tasks 1 and 4 are mandatory.

  Part 2 – Report

  Your team will need to write a report (2,500-3,500 words) describing the design and architecture of your web application and web services. The report should be a word document named Group<ID>.doc. The report is composed of six sections:

• Cover Page that contains the Group ID, also all students (Names, IDs)
• Design and architecture
• Individual reflections
• Issues and challenges

• Research into solving the issues and challenges • Bibliography

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. The architecture is a group task. There should be a unified architecture in the report. Diagrams (such as class diagram) should be used to illustrate the assignment architecture and demonstrate the web application components interactions in all layers.

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. The individual reflections should also include the student experience working in a group.

Discuss issues and challenges

This part of the report should be a group effort, summarizing 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. In this step the group should detailed create a detailed list of challenges and issues encountered by the group during the application development

Research

The group should research external references (Web references, books, journals, conference papers) and attempt to find solutions for the challenges and issues encountered during the application development.

Bibliography

The group should create a properly formatted list of references used in the research section. References may include Websites, Books, Journals and conference papers.

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.

Assignment Submission and Demonstration

The two parts of the assignment are to be submitted separately.

The web application and web service are to be submitted as a single WAR file (or ZIP project), and submitted to PLATE (see PLATE assignment submission for file submission) before the deadline. The WAR file (or ZIP project) must include source code for your system. The web application and web service file should be named: Group<ID>.WAR.

In case your group is submitting a ZIP project to PLATE. Make sure you remove any extra JAR files to reduce file size before you export your assignment project to ZIP using Netbeans.

The web application must also be demonstrated in person to your tutor in your lab class during Week 11 starting Monday 28 May 2018 or Week 12 starting Monday 04 June 2018. All members of the team must be present for the demonstration. Any team member not present during the demonstration (without being granted prior permission) may have up to 50% of the marks for task deducted. During the demonstration, the tutor will ask a variety of questions about the design and development of the application. If you are unable to answer questions about code that you have written, it may impact your marks.

The report is to be submitted to UTSOnline via Turnitin. Turnitin will be used to check the report for material taken from other sources. Failure to properly acknowledge your sources may be regarded as plagiarism. The report should be a word document named: Group<ID>.doc.

Both files (Group<ID>.WAR and Group<ID>.doc) should be submitted by the due date, otherwise late submission penalties will apply. If either file is submitted late then, the late penalty mentioned above will apply to the group.

Self and Peer Assessment

Group projects are a part of this subject because effective groups pool complementary skills and knowledge to achieve better results. This is a highly desired attribute in all professions.

To give you feedback on your ability to work in a group and to modify your group mark for your individual effort, we will ask you to rate your own contributions relative to the contributions of your peers. SPARK is a web-supported program for collecting these ratings. SPARK calculates various factors which are used to adjust your group mark and help you understand your ability and/or effort to work in a group. There is a link to access SPARK from within this subject on UTSOnline.

Initially this assessment task will be given a group mark. However your individual mark for the task will be adjusted according to the ratings from SPARK.

From (Week 11, 31 May 2018 at 11:00 PM) until (Week 12, 7 June 2018 at 11:00 PM), you will be asked to rate yourself and your team members against the following 4 criteria:

• Performing tasks properly and on time as agreed by the group
• Overall contribution to meeting the application’s functional requirements
• Overall contribution to meeting the application’s quality requirements
• Contribution of content for inclusion in the written report

  The SPARK ratings collected after the task will be used to adjust your individual mark. Completing SPARK ratings is a requirement of this assessment task and marks will be deducted for non-completion.

  Marking Criteria

  The broad marking criteria for this assignment are as follows:

  The requirements specified in this document are the minimum requirements for your solution. In other words, a solution that just meets the requirements documented here will receive 50% of the available marks.

  To achieve higher marks, your deliverables need to demonstrate more than the minimum requirements. Note that this does not necessarily mean a larger quantity of features– preference will be given to solutions that demonstrate a higher quality over those that provide more features but do so poorly.

  The marking criteria described here relate to the “group mark” for your project. As mentioned above, your individual mark will be calculated by taking your group mark as a starting point and using information from SPARK to adjust it up or down.

  Note: Providing ratings in SPARK is a requirement of this assessment task. If you do not provide final ratings in SPARK within the required time frame, 5% will be deducted from your own scaled individual mark (but no deduction for your team members).

  Meeting the functional requirements is primarily about being able to demonstrate that your web application and web services are able to perform the tasks required. Marks will also be awarded here for choosing appropriate technologies or approaches for implementation. This will be primarily assessed during the demonstration, and through your tutor asking questions of each team member about their part of the implementation.

  Coding style and quality is judged based on the following criteria:

• code modularity and reusability (code duplication kept to absolute minimum)
• appropriate structuring of code into classes, methods, etc, or into templates for XSLT

• code readability (formatting)
• code documentation (comments)
• layout and design (of web pages) simple but professional
• error or warning messages should be human-friendly or machine-friendly as required

  For the report, marks will be awarded according to the following criteria:

• the accuracy of the architecture description;
• the quality and depth of reflection; and
• appropriate identification of issues and challenges;
• research to identify what is available to simplify issues and challenges;
• Bibliography (quality of reference sources, correct referencing technique).

  Academic Standards

  Students are reminded of the University’s rules regarding academic misconduct which can be found at; <http://www.gsu.uts.edu.au/rules/student/section-16.html>

  Assignments in this Subject should be your own original work. The inclusion in assessable work of any material such as code, graphics or essay text obtained from other persons or sources without citation of the source is plagiarism and is a breach of University Rule 16.2.

  Asking or paying anyone else to write any part of your assignments is considered cheating. This especially includes using outsourcing websites, and accesses to the subject data are monitored. If you are unsure if your activities (or other student’s activities) will be considered cheating, ask your tutor or lecturer for advice.

  All text written in assignments must be your own words (or that of your team members), except for short, quoted, and clearly referenced sections. Text copied from web pages, articles or other sources, and not referenced, will be viewed as plagiarism and reported as an allegation of academic misconduct.

  Referencing styles may be found at the UTS Library web site. <fttp://www.lib.uts.edu.au/help/referencing>

  Any collaboration with another person should be limited to discussing the general nature of the assignment, but not sharing specific solutions or code. Similarly, group work for this assignment should be the result of collaboration only within the group. 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.

  Students are not to give to or receive from any other persons outside their own group 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 16.2. That is, assisting other students to cheat or to act dishonestly in a submitted assignment.

  Accidental submission of another group’s work as your own is considered to be a breach of University Rule 16.2 in that you are acting dishonestly since you should not have a copy of another group’s work.

  Specific conditions for this assignment:

If any parts of your solution are based on existing code that is found on the web, in a book or generated by any software application apart from NetBeans (or code taken from any other source), you MUST acknowledge the source as a comment in your code. The only exception to this rule is for code supplied in the subject’s lab exercises. Acknowledgement is required even if you start with existing code and make modifications. Failure to acknowledge sources will be regarded as unacceptable behaviour in the context of the misconduct definition referenced above.

Using code that belongs to other students currently or formerly enrolled in this subject (i.e. copying or sharing code) is totally unacceptable behaviour and is considered cheating.