The service layer never accesses the persistence layer directly

design and implement user interfaces using Java Server Faces
design and implement business logic using enterprise Java beans (EJBs)

Note: this is pretend 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 the £1000, then the initial amount should be 1000 * GBP_to_USD_rate US dollars).

Currency conversion must be implemented by a separate RESTful web service (see Section 3.3). The actual exchange rates will be statically assigned (hard-coded) in the RESTful service source code.

3. System Architecture

Make direct payments to other registered users
Request payments from registered users

CDI Beans must not access any persistent data from the database. They should delegate all business logic to the service layer.

3.2. Service Layer

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

3.3. Web Services

e.g. GET baseURL/conversion/{currency1}/{currency2} HTTP/1.1 should return a status ok response with a very simple response (e.g. in JSON that says that 1.00 GBP = 1.21217 EUR). Writing a REST client should be straightforward. Check the following links for more information:

https://eclipse-ee4j.github.io/jakartaee-tutorial/jaxrs-client.html (Links to an external site.)
(Links to an external site.)http://stackoverflow.com/questions/2793150/using-java-net-urlconnection-to-fire-and-handle-http-requests (Links to an external site.)

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

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 which support full and correct page navigation by explicitly specifying navigation rules in a faces-config.xml file.

View all their transactions
Make direct payments to other registered users

4.3. Persistence Layer (10%)

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

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

4.5. Web Services (10%)

Full marks will be given if the REST web service is correctly implemented (using the correct URI structure presented above).

(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

Check below for more information and extra resources:

http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

context root: /webapps2020