代做31284Web服务开发、代写HTML代码专业、代写web、代写html/js编程代码

日期：2018-10-06 09:51

31284 Web Services Development

Assignment – Spring Session 2018

DUE DATE Week 11, 11:00 PM Wednesday 10 Oct 2018

Weighting: 40% of your final grade

Group work: This is a group assignment, normally to be done in teams of three

Or four. Other team sizes will only be permitted 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. A penalty of 50% towards the assignment mark

will apply to any user who leaves their group. Also a 50% penalty

applies to any user who fails to attend the assignment demonstration.

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.

Late submissions/

Special considerations

Assignments submitted after the deadline will be deducted 4 marks

out of 40 per calendar day (including weekends, holidays, working

days). If the assignment is submitted more than eight days late

(including weekends), 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.

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

2

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 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 Online Movie Store (OMS) that allows users to look-up

and purchase available movies.

I. The web interface should support the following minimum functionality:

a. Index page: the starting point of the web application and should provide the options of login

and register to all users.

Index page should also contain a search form. A user can search for movies using the

following parameters:

1. Title [Name of the movie]

2. Genre [Action, Sci-Fi, Horror, Comedy]

3. Movie release year [user can search a period between 2 dates]

The user’s search results should be displayed on the “index” page itself. The results should

be generated as data-centric XML.

Results displayed on the index page should be selectable or clickable (only available movies

are selectable). A user should be able to select a movie. The selection action using (Button or

Link or Radio Button or Checkbox) should take the user to “Checkout” page.

Movies details are stored in XML (movies.xml). The XML should store at least the

following information:

1. Movie title

2. Movie genre

3. Movie release date

4. Movie price

5. Available copies

The search process should also validate user input using server-side validation. All occurring

errors should be reported and displayed on the Index page itself.

b. Checkout page does not show a search form. The Checkout page should allow the following

functionalities for all users:

1. Purchase a movie or multiple movies [in one order].

2. Edit order [Change movie, add more movies, delete movie from checkout]

3. Place order and continue shopping

4. Remove order from checkout.

3

Order information should be stored in XML (history.xml) and at least contain:

1. Order ID [Randomly generated 3 digits number]

o Movie title

o Movie genre

o Movie price

o Movie release date(s)

o Copies purchased

2. User full name

3. User email [Username]

4. Payment method

5. Sale total

6. Order status [submitted or cancelled]

NOTE: an order can contain multiple movies.

c. Login page: This page is a HTML form where a registered user can login to OMS system.

Login form require the following unique user authentication:

1. User email. [Username]

2. Password.

The login form is processed by verifying the user’s login data against existing data available

in XML (users.xml). If login action is successful, it takes the user to the “Main” page. If the

login is unsuccessful then report all errors on Login page using inline server-side validation.

d. Register page: This page is an HTML form where a user can sign up for OMS. Required user

information are stored in XML (users.xml):

1. Full name

2. Email [Username]

3. Password

4. Phone number

5. Address

The sign up process should also validate all user input using server-side validation against

users.xml data. All occurring errors should be reported and displayed on the Register page. If

sign up process is successful, the user is taken to the Main page.

e. Main page: this page should provide users for the following functionalities:

1. View order history on the main page [user can view their order history only]

2. Access Cancel page [By selecting a submitted order from user history]

3. Access Account page

Account and Cancel links should be included into the Main page display.

f. Cancel page should allow user to cancel an order. User selects an order from history

displayed on Main page.

g. Account page: This page allows a user to perform the following functionalities:

1. Edit personal details [Name, Password, D.O.B., Address, Phone number]

2. Cancel account with OMS. [Delete user from users.xml]

4

Your web application should:

a. Allow users to logout (to index page) or go back to the Main page from anywhere.

b. If a user cancels an order then the order status is set to “cancelled”. However the

cancelled orders are still stored in history.xml.

c. If a user cancels their account, all submitted orders made by this user should be

automatically cancelled. Also, orders details should be saved in history.xml.

d. Once a user places an order, the number of copies of the purchased movie should

decrease. If a user cancels the order then the number of copies purchased should be added

back to the movies copies in movies.xml.

e. If a movie has zero copies, then users should not be able to purchase it.

Note: You have the choice to add more pages to your web application.

Note: You must populate your movies.xml and users.xml with at least 5 users and 10

movies (of different genres). Initially the history.xml is empty however as orders are

performed by users, you should keep record of all purchases submitted and cancelled.

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

II. The web service side, you will need to do the following:

Create a REST web service allowing a client to:

Fetch orders information in XML format from history.xml, according to given URL

parameters. Possible parameters are:

1. Order ID

2. User email

3. Movie title

4. Order status (cancelled, submitted)

5. If no parameters are given, all available orders should be returned.

Create a SOAP web service that allows user (User and Movie) to:

1. Login/Logout

2. Place an order

3. View all orders, with parameters as above (using SOAP rather than REST)

User authentication information must be provided for creating and cancelling a booking.

The SOAP Web Service methods should individually tested in Netbeans.

Create SOAP client in Java that invokes each of the SOAP web service operations:

1. Login/Logout

2. Place an order

3. View all orders, with parameters as above (using SOAP rather than REST)

Your SOAP client enables a user to perform all operations allowed by the SOAP web

service using command line menu [You also have the choice of consuming the SOAP

client in JSP]

The SOAP client should be part the assignment web project.

5

III. Additional requirements:

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.

All XML files should have a corresponding XSL stylesheet. The use of for-each in XSL

is not permitted. All XML should transform correctly using their corresponding XSL.

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.

Note: 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. CSS,

HTML, Javascript are not considered part of the assignment functionality coding.

All group members must be involved in the functionality coding. All three users 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, users are also expected to work together and

support each other as a team.

Note: Users 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 your own mark for the assignment.

6

IV. Bonus (up to 20 marks on top of raw total marks = 200):

Completing any of the bonus tasks below, will give the opportunity to earn extra marks.

1. (up to 5 marks): SOAP WS Client allows user to cancel an order.

2. (up to 5 marks): SOAP WS Client allows user to cancel their account with OMS.

3. (up to 5 marks): Use REST to generate XML for XSLT.

4. (up to 5 marks): Use XSD for server-side validation.

Up to 4 points can be earned in total from the bonus tasks. If your mark is 40/40 and you gain

any bonus marks, those marks will be added towards your final marks for the subject (the

maximum marks for the subject is 100).

Part 2 – Report

Your team will need to write a report (3000-4000) 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 users (Names, IDs)

- Design and architecture [Class Diagram, Architectures, Flow charts]

- Individual reflections [Each student should write about their own experience and

involvement in the assignment]

- Issues and challenges [As individuals and group describe the issues and challenges that

you encountered in the process of completing the assignment]

- Research into solving the issues and challenges [As group and individuals, provide

details about research and methods used in order to solve the challenges. Also state and

explain any and all unsolvable issues]

- Bibliography [Use correct referencing “Harvard” for all research researches included in

your report]

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 user experience working in a

group.

7

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.

8

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 movie in your lab class

during Week 11 starting Monday 08 Oct 2018 or Week 12 starting Monday 15 Oct 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 movie 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 due date otherwise

late submission penalties will apply. If either file is submitted late then, a 5 marks/day penalty

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, 10 Oct 2018 at 11:00 PM) until (Week 12, 17 Oct 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.

9

Marking Criteria

The broad marking criteria for this assignment are as follows:

Criterion Weighting (%)

Functional requirements 60%

Code style and quality 20%

Report 20%

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

10

Academic Standards

Users are reminded of the principles laid down in the Faculty’s Statement of Academic Integrity

- Good Practice and Ethics in Informal Assessment found at;

<wiki.it.uts.edu.au/Academic_Integrity>

The University’s rules regarding academic misconduct can be found at;

<http://www.gsu.uts.edu.au/rules/user/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 user's activities) will be considered

cheating, ask your movie 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 those described in the “Acceptable

Behavior” section of the Statement of Academic Integrity. Similarly, group work for this

assignment should be the result of collaboration only within the group. Any infringement by a

user will be considered a breach of discipline and will be dealt with in accordance with the Rules

and By-Laws of the University.

Users 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 users 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

11

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 behavior in the context of the Statement of Academic Integrity

referenced above.

Using code that belongs to other users currently or formerly enrolled in this subject (i.e. copying

or sharing code) is totally unacceptable behavior and is considered cheating.

The Faculty penalty for proven and serial misconduct of this nature is zero marks for the

Subject. For more information go to; <wiki.it.uts.edu.au/start/Academic_Integrity>