编程语言代写 |Midterm Assignment

本次英国CS代写之Java WEB代写的主要内容是使用J2EE技术中的JSF完成一个学项目管理系统开发工作.

Student Project Management System

  1. Introduction

This assignment is about the design and implementation of a web-based, multi-user application for managing Final Year and MSc student projects. The service will be implemented using Java Enterprise Edition (J2EE) technologies. Through a JSF-based web interface:

  • Administrators should be able to:
    1. register students, supervisors and other administrators
    2. register project topics (e.g. Computer Networks, Web Applications, Human-Computer Interaction etc.)
    3. access reports relevant to projects, project topics, students and supervisors
  • Supervisors should be able to:
    1. register project topics (as administrators do)
    2. register project proposals
    3. accept or reject student project proposals
    4. receive notifications when students propose projects to them
    5. produce reports relevant to their projects and students
  • Students should be able to:
    1. access all projects proposed by supervisors
    2. select a specific student project proposed by a supervisor (needs to be confirmed by the supervisor)
    3. propose a project to a specific supervisor

Optionally, the implemented system should be deployed into the cloud (Amazon Web Services (AWS)).

After successfully completing the assignment, you will have demonstrated that you can:

  • design and implement user interfaces using JavaServer Faces
  • design and implement business logic using Enterprise Java Beans (EJBs)
  • design and implement the data tier using Java Persistence (JPA)
  • design and implement a secure multi-user system
  • deploy a web application into the cloud

 

  1. System Architecture

2.1. Web Tier

The web tier consists of a set of facelets views (.xhtml files) through which administrators, students and supervisors interact with the system.

Administrators

An administrator of the web application should be able to register other system users as administrators. There should be no way for any other user type to register themselves or anyone else as an administrator. Administrators are the sole system users that can register students and supervisors in the system. This process will be manual; i.e. an administrator will register other types of users one by one through respective web views. To help supervisors select project topics, an administrator should be able to register project topics (e.g. Computer Networks, Operating Systems, etc.). However, supervisors should be able to add topics if they want to (see sub-section below).

An administrator should be able to access reports relevant to students and supervisors. More specifically, they should be able to access the list of supervisors and their proposed projects. Additionally, functionality for accessing a list of students along with their selected projects (or proposed or no project if no selection has been made yet), must be implemented.

Supervisors

A set of facelets views (along with linked JSF Beans) must be implemented so that a supervisor can register new project topics (must be unique and <= 100 characters) and projects (project titles should be less than 200 characters and project descriptions should be less than 1000 characters). Whenever a student selects one of their registered projects, supervisors should be able to access a notification (e.g. in their index/main view) and accept or reject the student. Moreover, they should be notified whenever a student proposes a project to them and be able to accept or reject the proposal.

Supervisors should be able to access the list of students they supervise (along with details about the respective project).

Students

Students should be able to view all available projects proposed by supervisors and select one of these, through a set of facelets views and backing JSF beans. Selecting multiple projects should not be allowed. Students must also be allowed to register their own project (only one should be allowed) and propose it to a supervisor.

 

JSF Beans must not access the database directly through JPA. They should delegate all business logic to the service tier; i.e. EJBs in the business logic tier will access the database and return data back to the web tier for presentation.

2.2. Service Tier

The service tier consists of a set of Enterprise Java Beans (EJBs), which implement the business logic for the system. More specifically, all user interaction with the web tier should result in calling methods of EJBs, which will most often require some access to the data tier. EJBs should support J2EE transactions so that data integrity is preserved. You should utilise container-managed transactions (which are supported by the EJB container). That is, your code doesn’t need to cope with opening, committing or (in most cases) roll-backing transactions. You will just need to annotate your EJBs with the appropriate transaction attributes (or rely on the default behaviour if that is appropriate).

The service tier is responsible for accessing the data (persistence) tier. Persistence (JPA) entity managers must be injected in your EJBs. Access to persistent data must only take place through these entity managers. 

2.3. Data Tier

The data tier consists of a relational database. To simplify deployment and configuration you must use JavaDB (aka derby-db) as your Relational Data Base Management System (RDBMS). JavaDB is an RDBMS installed with GlassFish/Payara.

Your data model should be written as a set of persistence entities (JPA). Upon deployment, JPA will create the database tables for you. Access to the database must always take place through manipulating JPA entities and using JPQL queries defined in JPA entities and executed by EJBs.

An indicative schema would include the following database tables (which should be mapped to JPA entities): Supervisor, Student, Project, Project Topic. Tables required for form-based authentication would be just like in the security lab exercise (i.e. SystemUser, SystemUserGroup). Figuring out table relations (i.e. JPA associations) should be straightforward. For example, a Project Topic may be relevant to multiple projects, while a single project may be related to multiple topics. Indicative properties for each entity are as follows:

  • Supervisor: sussex-id (e.g. gp225 – must be unique), name, surname, department, email address (must be validated), telephone number.
  • Student: sussex-id (must be unique), name, surname, email address (must be validated), course (e.g. Computer Science).
  • Project: title, description, required skills (e.g. Java, J2EE etc.), Status (e.g. Accepted, Proposed, Available).
  • Project Topic: Topic title (e.g. Computer Networks), Topic Description.

You must name your database WebappsDB.

Do not access the database directly using JDBC. Do not use any other RDBMS (like Oracle or MySQL Server). Use Java Persistence and JavaDB (derby-db).

2.4. REST Services

REST

Your application will have to interface other (imaginary for the context of this project) applications and provide them with the following resources (represented in JSON only) through a RESTful service:

  • project: the relative REST URI should be /project/{supervisorid}, where supervisoridis the supervisor identifier for which the respective projects will be fetched. supervisorid can be the keyword all to indicate that projects of all supervisors are required.
  • supervisor: the relative REST URI should be /supervisor/{studentid}, where studentidis the student identifier for which the respective supervisor will be fetched. studentid can be the keyword all to indicate that all supervisors are required.
  • student: the relative REST URI should be /student/{supervisorid}, where supervisoridis the supervisor identifier for which zero or more student objects will be fetched. supervisorid could be the keyword all to indicate that all students are required.

Only read functionality (out of the CRUD functionality) must be implemented for the resources above. You only need to implement the server side of the REST service. You can test your service through Chrome’s advanced REST plugin (and that is how I will test this functionality).

2.5. Security

The student project management system is a multi-user web application. Administrators, supervisors and students must be logged-in in order to be allowed to interact with the system. They should not be able to access views of other user groups.

You will need to implement and support:

  • Communication on top of HTTPS for every interaction with any user
  • Form-based authentication (using a jdbcRealm)
  • Logout functionality for all users
  • Declarative security to restrict access to EJB methods (allmethods in EJBs must be annotated appropriately so that specific roles -i.e. student, supervisor, administrator- can call the methods)

Students and supervisors must be registered with their unique Sussex id. Your JSF pages (through some EJB-based business logic) must prohibit duplicate registrations.

You must name your JDBCRealm WebappsRealm. The JNDI name should point to the database WebappsDB, so it should be: jdbc/WebappsDB.

  1. Mark Allocation

3.1. Web Tier (20%)

15% – Full marks will be given if all required .xhtml files are written and correctly connected with JSF backing beans in a way that makes sense even if no other functionality is implemented at the service and data tier. The set of correctly implemented JSF pages includes .xhtml pages required to perform security-related actions.

5% – Full marks will be given if all required conversions and validations are supported (e.g. for required fields, well-formatted email addresses). This highly depends on the way you design your pages. In most cases, JSF standard validations and conversions should be enough. Full marks will be given to projects supporting full and correct page navigation by explicitly specifying navigation rules in a faces-config.xml file.

Important Note: The appearance of web pages will not be marked. If you want, you can write your own or import an existing .css file but this is not part of this assignment. You could also use frameworks like Primefaces or Richfaces, which can produce aesthetically nice applications.

3.2. Service Tier (20%)

Full marks will be given if all required business logic is implemented in a set of Enterprise Java Beans, which must include appropriate annotations for supporting JTA transactions, if and where required.

Full marks will be given if all functionality is implemented and correctly connected with the web- and data-tiers. More specifically, full marks will be given if functionality can be tested through standard interaction with the system using the web pages. Correct functionality also means checking that various constraints are satisfied (e.g. a student cannot register more than one project proposals).

3.3. Persistence Tier (10%)

Full marks will be given if all access to application data is handled through JPA Entities. A correctly configured persistence.xml file is required along with annotations for transforming Plain Old Java Objects (POJOs) to JPA entities. Annotations are required to define associations among different entities (e.g. one-to-many, many-to-many), wherever this is required.

3.4. Security (20%)

10% – Form-based authentication

  • Full marks will be given if users can register, login and logout. This should be implemented using a jdbcRealm which is linked to JavaDB in order to register and authenticate users. An admin must be registered in the system when deploying (and, therefore, creating database tables).

4% – Declarative security for access control when navigating through .xhtml pages

  • Access to .xhtml pages must be restricted to authorised actors. You must include security constraints in the deployment descriptor.

4% – Declarative security for accessing EJB functionality

  • EJBs must be annotated appropriately (along with annotation-based role declarations) so that EJB functionality can be accessed my authorised actors.

2% – Initial administration registration

  • Upon deployment, a single administrator account (username: admin1, password:admin1) must be present. You can implement that through a singleton EJB that is instantiated upon deployment or by using a simple SQL script when the persistence unit is deployed. Only an administrator can register more administrators through the restricted admin pages.

3.5. REST Service (10%)

Full marks will be given if the REST service is fully (all 3 resources) and correctly implemented.

3.6. One out of two options (20%)

For the last 20% of the marks you can select between 2 options.

3.6.1 Report

Write a (up to) 2000 word report, critically assessing the strengths and limitations of your implementation utilising your understanding of the underlying technologies. The report must consider the following points:

  • (5%) How your design fits with the 3-tier architectural model and the model-view-controller software pattern
  • (5%) The strengths and weaknesses of your chosen methods for securing the application, comparing your approach to other options
  • (5%) How your design could be extended so that your server is not a single point of failure
  • (5%) How your system would deal with concurrent users accessing functionality and data

3.6.2 More Programming

Implement the following features which may have an impact on all three tiers of your system:

  • (8%) All students’ and supervisors’ transactions must be stored in a log (e.g. when a project was created by a supervisor, or when a student selected a project). Administrators should then be able to access logs on a per-student and per-supervisor basis. Logins must also be recorded and administrators should be able to access the login history for each student and supervisor.
  • (8%) All transactions must be timestamped by accessing a ‘remote’ Thrift timestamp service (which is deployed on the same server as your system). The service should return the current date and time to your system when requested by the Enterprise Java Bean. The Thrift server can be implemented as a deployable EJB which uses a separate thread to accept time-stamping requests at port 10000.
  • (4%) When a student selects a project, there is no way to un-select that. For this sub-task you should implement functionality that allows an administration to unselect project selections (e.g. in real life upon an email by the supervisor).

3.7. (Optional) Deployment on Amazon AWS (5% bonus)

Optionally, you can deploy your application on Amazon and get an extra 5%. The maximum mark you can get for this assignment is 100% (i.e. you will still get a mark of 100% (and not 105%) even if your submission is perfect and you deployed your application on Amazon). To do so, you must successfully deploy and run the application on an Amazon EC2 virtual machine which you should configure following the instructions published on Canvas. You must submit screenshots of the commands you issued on the console to run Glassfish/Payara and JavaDB, the security configuration, JDBC pool and data source configuration, and screenshots of the application running on an Amazon EC2 instance where the URI of the application is shown. In order to verify that you have indeed deployed the application, I may ask you, during the marking period, to run the server and deploy your application for me to test it.

In order to get access to Amazon AWS, you must first register as a Sussex student here (no credit card is required if you select the AWS educate starter account): https://www.awseducate.com/Application

Note: it may take several days for Amazon to verify and enable your account, so start early with the registration process. I have no control over this process.

3.8. Comments about marking

The coursework requires you to bring together several independent pieces of functionality. It is highly recommended that you think about the whole system design BEFORE you start implementation. Consider which parts are necessary to implement the core functionality and create easily replaceable stubs for the peripheral services.

Some parts of this assignment are independent. For example one could implement the system without support for the requested REST Service.

Along the same lines, one could ignore the data/persistence tier (losing 10% of the marks) by storing data in Lists and Sets appropriately in a Singleton EJB.

Security is mostly independent and orthogonal to the rest of the system. Implementing a system without any security support (sacrificing the respective marks) is possible if for every request, the actual id that identifies the user that interacts with the system is also passed through the JSF page.

 

  1. Submission

Submission will be through Canvas. Your submission should be a zip file containing:

  • a zipped copy of the NetBeans project containing well formatted and documented source code (including all .java, .xhtml and all required configuration files).
  • a brief catalogue of the files, describing the purpose of each file.
  • the report (if you selected this option).
  • screenshots for the Amazon AWS deployment as described above.

Failure to submit the source code as described in the first bullet, will result to a zero mark as I will not be able to assess your programming effort. The submitted source code must be part of a Netbeans project that I can compile and deploy locally on my own GlassFish/Payara server. Projects implemented using other technologies (e.g. jsp, Spring, MySQL Server, PHP, Play etc.) will not get any marks.

A penalty of 5% will be applied if the source code is not well-formatted and does not contain comments for classes and methods.

A penalty of 3% will be applied if the name of the database, jdbcRealm and context root are not WebappsDB, WebappsRealm, /webapps2019, respectively.