CS5414 (Fall 2012) Programming Assignment Phase I
Distributed Banking System


Due: 11pm, 9/16/2012
Relative weight: 5 units

General Instructions. Work in a group comprising 1 to 3 students. All members of the group are responsible for understanding the entire assignment and submitted solution.

No late assignments will be accepted.

Academic Integrity. Collaboration between groups is prohibited and will be treated as a violation of the University's academic integrity code.

Background: Building a Distributed Banking System

This assignment is intended to help you learn how to write distributed programs in JAVA. You will program a simple client/server that employs message passing for communication. The resulting system --- a distributed bank --- will then provide a sandbox for exploration and implementation of various topics we study this semester.

Our bank comprises a set of branches. Each branch manages a disjoint subset of the bank's accounts. Associated with each account is a unique account number, a balance, as well as other information.

Customers may invoke the following operations on accounts:

What to Build

Structure of a Branch. Implement each branch as two separate applications --- a branch server and a branch GUI. The branch GUI manages a window that enables human users to invoke the four operations listed above and see the results of their execution; the branch server stores account balances and performs operations.

The branches of a real bank would be geographically separate and, therefore, each branch would have its own processor and would communicate with the other branches using some sort of network. We won't depart too far from reality, even if all branches execute on a single processor, by stipulating:

Inter-Branch Communication Restrictions. Plan to specify the topology of your banking network with a text file topology_file.txt that is read by branch servers and branch GUI's. This file specifies all uni-directional communication links that are assumed to exist between components implementing your bank. (A bi-direction link exists between two components when two uni-directional links in opposite directions exist between those components.)

Each line of topology_file.txt should have the form

JVM1 JVM2

where JVM1 and JVM2 are names associated with Java virtual machines. A line "JVM1 JVM2" specifies that the component (i.e., branch server or branch GUI) run by Java virtual machine JVM1 is allowed to send messages to the component run by Java virtual machine JVM2.

To simulate the limitations a network topology imposes on communication between components, write a class that your components are required to use in order to send messages. This "wrapper" class (so named because it encapsulates network communications operations) should limit the allowed use of operations that send messages.

Whenever any wrapped send operation at a given component is invoked, the wrapper checks to see if the destination address corresponds to a component that is directly reachable according to the interconnection graph specified by topology_file.txt. Your wrapper class should also introduce a new operation --- whoNeighbors --- that returns the names of all components directly reachable (by traversing a single edge of the interconnection graph) from the invoker.

For this first phase of the project:

Account Numbers. Assume that account numbers are of the form bb.aaaaa where bb is a 2-digit numeric value that designates a branch and aaaaa is a 5-digit numeric value that identifies an individual account within that branch. Also assume that an account comes into being (with a 0 balance) by virtue of any invocation of any operation that names that account number --- an assumption that is unrealistic but will nevertheless eliminate the possibility of operations on undefined accounts.

Client and Server: Branch GUI and Branch Server. Here are descriptions of the two applications to be built.

Note, adhering to the above specified structure is important so that your implementation will be usable in subsequent phases of the project.

Implementation Notes

Submission Procedure. All submissions should be made through CMS. CMS provides a way for you to define your group. Be advised that each group member must take an action in creating a group, and your group cannot submit anything through CMS until the group has been created.

Submit the following files (at least):

TEAM.txt which contains the names (and net-ids) for all team members. Also, for each team member give a 1 or 2 paragraph description of the tasks this team member performed and the number of hours this required.

README.txt which contains

LAUNCH.cmd which is a shell script that the grader can run in order to start the various components needed by your bank. Thus, this script should start instances of the BranchServer and BranchGUI for each branch, as well as any other components your system requires. The grader will then try some selected test cases on your running system to determine if it seems to be working as it should.

topology_file.txt should specify an interesting interconnection topology for a multi-branch bank that will be used to illustrate the operation of your system.

Source files that contain the source needed to compile and run your system.

DISCUSS.txt, which should discuss:

Don't underestimate what is involved in writing instructions for installing, compiling, and running your software. Do path values have to be set? Must the software be installed in a particular directory? Must the name of the host processor be put someplace? Use one group member's account to test your installation script. The easier it is to install your system, the more-kindly disposed the grader will be in evaluating your efforts.

Grading. Your grade will be based on the following elements: