An Online Payment Service
1. Introduction
This assignment is about the design and implementation of a web-based, multi-user payment service using Java Enterprise Edition (Java EE) technologies. The system is a much-simplified version of PayPal. Through a JSF-based web interface, users should be able to send money to other registered users (e.g. using their registered email address as their unique identifier), request money from other registered users and manage their own account (e.g. look at their recent transactions). Super-users (i.e. admins) should be able to access all user accounts and transactions. Optionally, you will deploy your application on the cloud (e.g. on Amazon AWS, Microsoft Azure, or any similar infrastructure).
After successfully completing the assignment, you will have demonstrated that you can:
design and implement user interfaces using Java Server Faces (JSF)
design and implement business logic using Enterprise Java Beans (EJBs)
design and implement a secure multi-user system
2. Project Description
Online payment services, such as PayPal, allow users to connect their online accounts to their bank accounts, debit and credit cards. In such systems, users are usually able to transfer money from their bank accounts to the online account, receive payments to this account from other users, push money from the online account to their bank accounts, etc.
For simplicity, we will assume that, for this project, all registered users start with a specific amount of money (e.g. £1000) and no connections to bank accounts exist.
Note: this is pretended money and no connection to real sources of money should exist.
Each user has a single online account whose currency is selected upon registration. A user can select to have their account in GB Pounds, US dollars or Euros. In that case, the system should make the appropriate conversion to assign the right initial amount of money (e.g. if the baseline is £1000, then the initial amount should be 1000 * GBP_to_USD_rate US dollars).
A user can instruct the system to make a direct payment to another user. If this request is accepted (i.e. the recipient of the payment exists and there are enough funds), money is transferred (within a single Java EE transaction) to the recipient immediately. A user should be able to check for notifications regarding payments in their account.
A user can instruct the system to request payment from some other user. A user should be able to check about such notifications for requests for payment. They can reject the request, or, in response to it, make a payment to the requesting user.
Users can access all their transactions, that is, sent and received payments and requests for payments as well as their current account balance.
An administrator can see all user accounts and all transactions.
Currency conversion must be implemented by a separate RESTful web service. The actual exchange rates will be statically assigned (hard-coded) in the RESTful service source code.
3. Penalties
You will receive 0 marks for your submission if it does not respect the following THREE requirements.
1. You should use these namings:
database: WebappsDB
jdbcRealm: WebappsRealm
context path: /webapps2022
persistence-unit name: WebappsDBPU
persistence-unit data source: jdbc/WebappsDB
2. The submitted NetBeans project sholud follow this structure:
Webapps2022
Web pages
admins --> .xhtml files
users --> .xhtml files
. xhtml files
Source Packages
com.webapps2022.ejb
com.webapps2022.entity
com.webapps2022.jsf
com.webapps2022.restservice
com.webapps2022.thrift
...
3. Your NetBeans project should compile without any error.
A penalty of 4% will be applied if the source code is not well-formatted and self-documenting (Links to an external site.) (or well-documented).
4. System Architecture and Mark Allocation
4.1. Web Layer (20%)
The web layer consists of a set .xhtml (Facelets) pages through which users and administrators interact with the web application.
Users should be able to:
o
View all their transactions
Make direct payments to other registered users
Request payments from registered users
Administrators should be able to see:
o
user accounts
all payment transactions
and register new administrators
CDI Beans must not access any persistent data from the database. They should delegate all business logic to the service layer.
Web Layer - Mark Allocation
o
15% - Full marks will be given if all required .xhtml are written and correctly connected with CDI backing beans in a way that makes sense even if no other functionality is implemented at the service and data layer. 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 done. This highly depends on the way you design your pages. In most cases, standard validations and conversions should be enough. Full marks will be given to assignments that support 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 use frameworks like PrimeFaces or RichFaces that build on JSF, or custom .css files, but this is not part of this assignment.
4.2. Business Layer (20%)
The business layer consists of a set of Enterprise Java Beans (EJBs) that implement the business logic for the system. EJBs should support Java EE transactions so that data integrity is preserved. You should utilise container-managed transactions. That is, your code doesn't need to cope with opening, committing or roll-backing transactions. You will only need to annotate your EJBs with the appropriate transaction attributes (or leave the default behaviour, if appropriate).
The service layer is responsible for accessing the data (persistence) layer. Persistence (JPA) entity managers must be injected into your EJBs. Access to persistent data must only take place through these entity managers.
Business Layer - Mark Allocation
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 when required.
Users should be able to (15%):
o
View all their transactions
Make direct payments to other registered users
Request payments from registered users
Administrators should be able to (5%):
o
view all user accounts and balances
view all payment transactions
register more administrators
4.3. Data Persistence Layer (10%)
The data layer consists of a relational database and JPA entities. To simplify deployment and configuration you must use JavaDB as your Relational DataBase Management System (RDBMS). JavaDB is an RDBMS that is installed with GlassFish/Payara.
Your data model should be written as a set of persistence entities (JPA). Upon deployment, JPA will create the actual relational database tables for you. Access to the database must always take place through manipulating JPA entities. Do not access the database directly using JDBC.
Data Layer - Mark Allocation
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 defining JPA entities. Annotations are required to define associations among different entities (e.g. one-to-many, many-to-many) wherever this is required.
4.4. Security Layer (20%)
The online payment service is a multi-user web application. A user must be logged-in in order to interact with the system. Users should not be able to see other users' information nor access pages and functionality for administrators. Administrators access their own set of pages, through which can have access to all users information. Users and administrators should be able to logout from the web application.
You will need to implement and support:
o
Communication on top of HTTPS for every interaction with users and admins
Form-based authentication (simple using the file realm, in a jdbcRealm where users can subscribe - full marks will be given to the second approach (see Section 4.))
Logout functionality
Declarative security to restrict access to web pages to non-authorised users
Declarative security to restrict access to EJB methods
Security layer - Mark Allocation
10% - Form-based authentication
o
Full marks will be given if users can register, login and logout. This can happen 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 the DB tables)
4% - Declarative security for access control when navigating through .xhtml pages
o
Access to .xhtml pages must be restricted to authorised actors. You need to add security constraints in the deployment descriptor.
4% - Declarative security for accessing EJB functionality
o
EJBs must be annotated appropriately (along with annotation-based role declarations) so that EJB functionality can be accessed by authorised actors (users and admin)
2% - Initial administration registration
o
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.
4.5. Web Services (10%)
You must implement a REST Service that is accessed by the service layer. The service will be deployed on the same server but accessed from the service layer in the standard way (i.e. through HTTP).
A currency conversion RESTful web service that responds only to GET requests. The exported resource should be named conversion, in a path like the following:
baseURL/conversion/{currency1}/{currency2}/{amount_of_currency1}
The RESTful web service should return an HTTP response with the conversion rate (currency1 to currency2) or the appropriate HTTP status code if one or both of the provided currencies are not supported.
You will need to implement a REST client to access this service e.g., JAX-RS includes a client API for implementing clients that consume the RESTful Web Service.
Web Services - Mark Allocation
10% - Full marks will be given if the REST web service is correctly implemented (using the correct URI structure presented above).
4.6. RPC with Apache Thrift (10%)
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 (or at any other available port e.g. 10001).
RPC Thrift - Mark Allocation
o
10% - Full marks will be given if the Thrift timestamp service is correctly implemented as described above.
4.7. Report (10%)
o
4% - The report should include 6 sections as follows: Web layer, Business Layer, Persistence Layer, Security Layer, Web Services and Thrift. In each section, you need to specify what has been fully or partially implemented or if any requirement has not been implemented.
6% - Also, the report should include a user manual that can assist users in using your application. This can be one of these two options:
a list of screenshots of running your project. You need to show all the working parts e.g., the main interface, the user/admin registration, request payment, payment transaction, REST service, .... These screenshots should show all the user interfaces and any related data in the database.
or a short walkthrough video/demo that shows all the working parts.
5. (Optional) Deployment on the Cloud (7% bonus)
You can optionally deploy your application on the Cloud and get an extra 7%. The maximum mark you can get for this assignment is 100% (i.e. you will still get 100% (and not 107%) even if your submission is perfect and you deployed your application on the Cloud). To do so, you must successfully deploy and run the application on e.g. Amazon EC2 virtual machine (any other framework would work fine, too). In order to get full marks, 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 the cloud 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. You will be invited to join AWS Academy where you will get access to the required AWS resources. Sussex is an active member at AWS Academy which means you will be given some free credits to use AWS. These credits will be enough to deploy this project. I'll be providing some tutorials about using AWS in the lab classes later in this module.
6. Comments about marking
The coursework requires you to bring together several independent pieces of functionality. It is highly recommended that you think about the service 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 the REST web service (losing the marks mentioned in the marking criteria) by just hard-coding the currency conversion functionality in an EJB.
Along the same lines, one could ignore the data/persistence layer (losing 10% of the marks) by storing data in Lists and Sets appropriately in a Singleton EJB (just like we did during the web services' lab classes).
Some other functionality cuts through the whole system architecture vertically. That means that if, for example, the requesting money functionality is not implemented (nor the .xhtml files and any potentially required persistence data) marks will be removed from all three layers.
Security is mostly independent and orthogonal to the rest of the system.
7. Submission
The assignment submission will be through the separate UG and PGR Canvas sites (not the Umbrella site).
Your submission should be a zip file containing:
a zipped copy of the NetBeans project containing well-formatted source code (including all .java, .xhtml and all required configuration files)
the report
(optional) screenshots for the cloud deployment as described in section 5
Failure to submit the source code as described in the first bullet will result in 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 Payara server. Projects implemented using other technologies (e.g. jsp, Spring, MySQL Server, PHP, Play etc.) will not get any marks.
8. Plagiarism and Collusion
The coursework you submit is supposed to have been produced by you and you alone. This means that you should not:
work together with anyone else on this assignment
give code for the assignment to other students
request help from external sources
do anything that means that the work you submit for assessment is not wholly your own work, but consists in part or whole of other people’s work, presented as your own, for which you should in fairness get no credit
if you need help ask your tutor
The University considers it misconduct to give or receive help other than from your tutors, or to copy work from uncredited sources, and if any suspicion arises that this has happened, formal action will be taken. Remember that in cases of collusion (students helping each other on assignments) the student giving help is regarded by the University as just as guilty as the person receiving help, and is liable to receive the same penalty.
Also bear in mind that suspicious similarities in student code are surprisingly easy to spot and sadly the procedures for dealing with it are stressful and unpleasant. Academic misconduct also upsets other students, who do complain to us about unfairness. So please don’t collude or plagiarise.