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 0000001 0000002 0000003 Initial Balance $0 $100 $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 0000001 0000002 0000003 PIN 1234 2345 3456

And you may assume the following authorization values.

Account Deposit Withdraw Number 0000001 Permitted Permitted 0000002 Permitted Not Permitted 0000003 Not Permitted Permitted Balance 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 { .. } }