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:
• register students, supervisors and other administrators
• register project topics (e.g. Computer Networks, Web Applications, Human-Computer Interaction etc.)
• access reports relevant to projects, project topics, students and supervisors
Supervisors should be able to:
• register project topics (as administrators do)
• register project proposals
• accept or reject student project proposals
• receive notifications when students propose projects to them
• produce reports relevant to their projects and students
Students should be able to:
• access all projects proposed by supervisors
• select a specific student project proposed by a supervisor (needs to be confirmed by the supervisor)
• propose a project to a specific supervisor
• Optionally, the implemented system should be deployed into the cloud (Amazon Web Services (AWS)).
JavaServer Faces
Enterprise Java Beans (EJBs)
Java Persistence (JPA)
2. 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 supervisorid is 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 studentid is 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 supervisorid is 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 (all methods 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. 3. 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%) 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). Submission 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.