Online Banking Web Application

The purpose of this project is to develop an online banking system – web based application to conduct banking operation online. The system will provide the banks facilities to its customers, including balance enquiry, opening and closing accounts, performing transactions.
The application will be built using Java Server Pages (JSP), GlassFIsh as the application server, and MySQL as a database. It will be based on 3-tiered model. A client computer uses a browser to access information from two or more servers (web servers, application servers, database servers) i.e. a web server  handles a web request, an application server handles the dynamic request and a database server stores the data.

PURPOSE OF THE SYSTEM

  • Security:
    User cannot access a system without knowing the password. Only after entering the correct username and password on the login page, user can perform operations.
  • Referential Integrity
  • Easy Retrieval of Data: by sql commands
  • Generating automatic values: e.g. account balance

SCOPE OF THE SYSTEM

The basic functionalities of the system are:

  • Home – Home page of Online Banking Site.
  • New Account – Creation of new account.
  • Balance – View balance of account.
  • Lodgement – Lodge money into selected account.
  • Withdraw – Withdraw amount from selected account.
  • Transfer – Transfer amount from one account to other account.
  • Close A/c – Close account.

Problem Domain

Online Banking is a mainstream service offered by most banks today. A typical consumer online banking application requires the following: 

  • A Customer
    Customers are individuals with a name, correspondence address, email address and security credentials. A customer can hold one or more accounts. 
  • An Account
    An account has a sort code (identifying the branch), an account number and a current balance. The account has a list of transactions. 
  • A Transaction
    Each transaction is either a debit or credit on a particular date, with a description and a post-transaction balance. 

Customers will be able to do the following: 

  • Lodgement
    For the lodgement, a bank customer can specify the amount to lodge with the card that will be debited. 
  • Transfer
    For the transfer, the bank customer can specify the amount to transfer and an account to transfer to. 
  • Withdrawal
    For a withdrawal, the bank customer can specify the amount to withdraw and the card that will be credited. 
  • Balance
    The customer can request a balance on any account at any time.

Software Specification

  • Client on Internet 
    Web browser(any)
  • Client on Intranet
    Client software, Web Browser
  • Web Server
    GlassFish 4.0
  • Database Server
    MySQL
  • Development End 
    Net beans (J2EE, Java, Servlets, JSP), Sequel Pro (DB tool)

Entity-Relationship diagram 

Screen Shot 2014-04-10 at 09.15.28

Database Tables

customer

Field

Type

Length

Key

customer_id

INT

11

UNI

username

VARCHAR

45

UNI

password

VARCHAR

45

first

VARCHAR

45

address

VARCHAR

45

email

VARCHAR

45

UNI

surname

VARCHAR

45

account

Field

Type

Length

Key

account_id

INT

11

UNI

balance

DOUBLE

sort_code

INT

11

map_account_customer

Field

Type

Length

Key

map_id

INT

11

UNI

account_id

INT

11

customer_id

INT

11

transaction

Field

Type

Length

Key

transaction_id

INT

11

UNI

customer_id

INT

11

customer_id_by

INT

11

account_id

INT

11

account_id_to

INT

11

transaction_amount

DOUBLE

post_transaction_balance

DOUBLE

transaction_date

DATE

transaction_type

VARCHAR

45

transaction_description

VARCHAR

45

Security

One of the main concerns of e-banking is security.

TO SECURE WEB SERVICE:

  • Add a security mechanism – Username Authentication with Symmetric Key
  • Import the certificates into the GlassFish application server and set up a default user for this application.
  • Configure the client that references the secured Web service.
  • Test the secure Web service.

RESTful  AUTHENTICATION:

  • All REST API calls must take place over HTTPS with a certificate signed by a trusted CA. All clients must validate the certificate before interacting with the server.
  • All REST API calls should occur through dedicated API keys consisting of an identifying component and a shared, private secret. Systems must allow a given customer to have multiple active API keys and de-activate individual keys easily.
  • All REST queries must be authenticated by signing the query parameters sorted in lower-case, alphabetical order using the private credential as the signing token. Signing should occur before URL encoding the query string.

Sequence Diagram 

A sequence diagram will show developers how one API can be used after another 

Screen Shot 2014-05-02 at 14.28.52

The RESTful API

The API describes all the entry points for the above problem domain. 

1 New Customer

  • API Name: New Customer
  • Description:  Creation of new customer.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.customer
  • Http verb:  POST (the username will be chosen by the user, not the system)
  • Parameters: customerId, username, email, password 
  • Resource Contents:  application/xml
  • Pre-Conditions: Customer id, username and email must be unique
  • Post-Conditions: A new Customer resource has been created

2 View Customer

  • API Name: New Customer
  • Description:  Creation of new customer.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.customer/{id}
  • Http verb:  GET 
  • Parameters: username
  • Resource Contents:  application/xml
  • Pre-Conditions: The Customer resource (identified by username) must exist
  • Post-Conditions: None

3 Update Customer

  • API Name: New Customer
  • Description:  Creation of new customer.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.customer/{id}
  • Http verb:  PUT
  • Parameters: username
  • Resource Contents:  application/xml
  • Pre-Conditions: The Customer resource (identified by username) must exist
  • Post-Conditions: The Customer resource was updated.

4 Delete Customer

  • API Name:  Delete Customer
  • Description: Delete Customer
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.customer/{id}
  • Http verb: DELETE
  • Parameters:  username
  • Resource Contents: image/*
  • Pre-Conditions: The Customer resource (identified by username) must exist
  • Post-Conditions: The Customer resource (identified by username) is removed.

5 New Account

  • API Name: New Account
  • Description:  Creation of new account
  • URL:  http://localhost:8080/Aga_OnlineBank/webresources/server.account
  • Http verb:  PUT
  • Parameters: accountId
  • Resource Contents:  application/xml
  • Pre-Conditions: A customer has to exist.
  • Post-Conditions: A new Account resource has been created

6 Close A/c

  • API Name:  Close A/c
  • Description: Close account.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.account / {id}
  • Http verb: DELETE
  • Parameters: accountId
  • Resource Contents: image/*
  • Pre-Conditions: The Account resource (identified by accountId) must exist
  • Post-Conditions: None

7 Money Lodgement

  • API Name:  Money Lodgement
  • Description: Lodge amount into selected account.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.transaction
  • Http verb:  PUT
  • Parameters: accountID, amount, date
  • Resource Contents: application/xml
  • Pre-Conditions: Transaction id has to be unique.
  • Post-Conditions: A new Transaction resource has been created.

8 Withdraw

  • API Name:  Withdraw
  • Description: Withdraw amount from selected account.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.transaction
  • Http verb:  PUT
  • Parameters: accountID, amount, date
  • Resource Contents: application/xml
  • Pre-Conditions: Transaction id has to be unique.
  • Post-Conditions: A new Transaction resource has been created.

9 Transfer

  • API Name:  Transfer
  • Description: Transfer amount from one account to other account.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.transaction
  • Http verb:  POST
  • Parameters: accountIdBy, accountIdTo, amount, date
  • Resource Contents: application/xml
  • Pre-Conditions: Transaction id has to be unique.
  • Post-Conditions:  A new Transaction resource has been created.

10 Balance

  • API Name:  Balance
  • Description: View balance of account.
  • URL: http://localhost:8080/Aga_OnlineBank/webresources/server.account / {id}
  • Http verb: GET
  • Parameters: accountId
  • Resource Contents: application/json
  • Pre-Conditions: The Account resource (identified by accountId) must exist
  • Post-Conditions: None

Implementation

JDBC was used to map JPA entity classes to tables and views within a MySQL database.
Next, RESTful web services, EJB classes, which communicate with MySQL through the entities were build.
JPA entities were separated into a Java Class Library. The class library was referenced by the RESTful web services. The RESTful web services, part of Java Web Application, were deployed to GlassFish, where they were accessed with HTTP methods and tested.

droppedImage-1

Glossary

Term

Description

API

Application Programming Interface

JDBC

Java Database Connectivity

SSL

Secure Socket Layer

ODBC

Open Database Connectivity

JSP

Java Server Pages

JPA

Java Persistence API

PUT

Adds a resource on the server. The resource is contained in the body of the POST request. PUT is analogous to an SQL insert statement.

GET

Retrieves a resource from the server. The resource is specified with a URL and may include a ? to delineate the request from the request parameters. GET is analogous to an SQL select statement.

POST

Updates a resource on the server. The resource is contained in the body of the POST request. POST is analogous to an SQL update statement.

DELETE

Deletes a resource on the server. The resource is specified in the URL only. DELETE is analogous to an SQL delete command.

References

Tagged: