Term Project: Distributed Banking
System
The ultimate goal of this project is to use distributed objects to implement a banking
system.
The project is to be designed and implemented by a team of three students. You may
select your own partners but you must select different partners from the others in Lab
Projects.
Objective: Develop a distributed banking system using either Java Remote
Method Invocation (RMI) or Java IDL (CORBA) as your transport.
Functional Requirements
The banking system consists of an Automated Teller Machine (ATM), a Bank,
Accounts and a Security service.
The ATM will support the following operations:
deposit: add some dollar amount to a specified account's balance
withdrawal: deduct some dollar amount from a specified account's
balance
balance inquiry: get current balance of a specified account
transfer: deduct some dollar amount from a specified account and
deposit that amount into another specified account
If there are not enough funds in the specified account to complete the operation
an error is generated.
The ATM will authenticate each client request and authorize the operation using
the Security service. The ATM will generate an error if the authentication or
authorization fail.
The Bank will manage various Accounts and will provide the ATM access to
those Accounts.
Each Account will provide methods for modifying the Account's balance. If
a modification cannot be processed due to insufficient funds the Account will
generate an error.
[Note that without taking any measures to lock your Accounts while clients
are running methods on them (possibly simultaneously), it is possible,
logically, to get inconsistent results. Don't worry about this. You are not
expected to prevent this by synchronizing your methods. In short, you should
ignore the issue of locking access to Accounts by multiple clients.]
Design
There will be two distinct server processes in the system. The first process will
host the remote ATMFactory and ATM instances. The second process will
host a remote Security service and a remote Bank.
The client will use the ATMFactory to obtain a remote ATM instance.
The first action a Client will take will be to register itself with the ATM as an
ATMListener. The listener interface will have a method to receive a
TransactionNotification. Whenever the ATM receives a transaction
request, the first thing it will do is notify each of its listeners with a
TransactionNotification indicating that it is about to process the
operation. This will let the Client know that the ATM is coordinating with the
Security service and the Bank to handle the transaction.
Each ATM operation will require a complex AccountInfo object as a
parameter. AccountInfo will include an account number and a personal
identification number (PIN).
The ATM will authenticate the account information and authorize the operation
using the remote Security service. If the authentication or authorization fail,
the operation will throw a security exception.
If successfully authenticated and authorized, the ATM will perform the
operation on the Account specified in the AccountInfo. But the ATM will
not longer have local Account instances. Unlike the design of the previous
homework, now the Account objects are to reside in a central Bank. The
ATM will get a remote reference to the Account hosted in the Bank process.
If the remote Account does not have enough funds to process the operation an
insufficient funds exception is generated. Otherwise the Account is updated
appropriately by the ATM.
Each ATM will maintain its own cash balance, representing the cash on hand.
Whenever the ATM processes a withdrawal it will debit its own cash balance by
the amount of the with drawl. Whenever a withdrawal is attempted the ATM
must verify the it has enough cash on hand to service the request. If insufficient
cash is available in the ATM it will generate an exception.
Architecture
The system should include the following remote components:
ATMFactory
ATM
Bank
Account
Security
Client (as an ATMListener)
The system should include the following structures that are passed by value:
AccountInfo
TransactionNotification
The location of objects in the various processes is depicted in the following
diagram:
Assignment
Note: You will see that you have been given more latitude in implementing this
project. At this point in the semester, you should feel comfortable making
design decisions on your own. Just make sure to detail your decisions and any
assumptions in the overview file in your submission.
All classes should be in the package:
IUGDS.project
And should be packaged in the archive:
project.jar
ATMFactory
The ATMFactory is a remote object that is responsible for providing
reference to a remote ATM instance. It has a remote getATM() method.
ATM
The ATM is a remote object that provides various bank operations by
implementing the remote ATM interface. Each operation takes an
AccountInfo object as its first parameter along with operation specific
parameters.
Each banking operation is to be implemented in the following way:
[notify all registered listeners of the
transaction]
[use security service to authenticate account
info]
[use security service to authorize operation on
account]
[use bank to obtain account reference(s)]
[use account reference(s) to perform transaction]
While processing, the ATM should track its cash on hand (note that deposits are
assumed to be checks and do not added to the available cash). You should
assume that the ATM begins with $500 cash.
Bank
The Bank is a remote object that hosts remote Account objects. It should
provide a method to obtain a reference to a remote Account.
You may assume the following accounts are defined.
Account Number Initial Balance
0000001 $0
0000002 $100
0000003 $500
Account
The Account is a remote object that provides methods for adding and
subtracting funds from the Account. It should verify the appropriate funds are
available in the Account.
Security
The Security component is a remote object that has methods for
authenticating AccountInfo objects and for authorizing specific operations
on individual Accounts.
You may assume the following authentication values.
Account Number PIN
0000001 1234
0000002 2345
0000003 3456
And you may assume the following authorization values.
Account
Deposit Withdraw Balance
Number
0000001 Permitted Permitted Permitted
0000002 Permitted Not Permitted Permitted
0000003 Not Permitted Permitted Permitted
Consider what authorization is necessary to perform a transfer between two
Accounts.
AccountInfo
The AccountInfo object is a data class that includes an account number and
a PIN. Instances are passed by value between processes.
TransactionNotification
The TransactionNotification object is a data class that includes
pertinent information about a particular transaction including target accounts
and amounts. It has a toString() method that returns a String describing
the transaction that can be easily printed by any listener. Instances are passed
by value between processes.
ATMServer
The ATMServer is just like the server in your previous submissions. It starts
up and registers the ATMFactory.
BankServer
The BankServer starts up and creates a Bank instance and a Security
instance. It then registers each with the naming service (tnameserv or
rmiregistry) to make each accessible by remote lookup.
ATMListener
The ATMListener interface includes a method to receive
TransactionNotification messages from the ATM. [Such a method is
usually called a handler, in this case a notification handler.] Upon receiving a
message, the notification should be printed to stdout. The Client will
implement this remote interface.
Client
To drive you system, create a Client class.
The Client should have a main that obtains a connection to an ATM using
the ATMFactory. Then the Client should register itself with the ATM as an
ATMListener. Finally, it should call the testATM method defined below.
This method calls the other test methods below to simulate various scenarios.
You will also need to declare a helper method getAccountInfo that creates
an AccountInfo object given the appropriate account information.
The Client should also implement the ATMListener interface and its
notification handler method should print out any
TransactionNotifications it receives.
The Client should also include the following:
public static void testATM(ATM atm) {
if (atm!=null) {
printBalances(atm);
performTestOne(atm);
…….
}
}
public static void printBalances(ATM atm) {
try {
……..
}
}