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:
- Deposit( acnt, amt , ser_number ):
If ser_number has not been used before
in connection with account acnt
then the balance of
acnt is increased by amt.
Then, whether or not acnt is updated,
return the balance of acnt.
- Withdraw( acnt, amt , ser_number ):
If ser_number has not been used before
in connection with account acnt
then the balance of
acnt is decreased by amt.
Then, whether or not acnt is updated,
return the (possibly negative) balance of acnt.
- Query( acnt , ser_number ): Return the balance of
account number acnt.
- Transfer( src_acnt, dest_acnt, amt , ser_number ):
First, if ser_number has not been used before
in connection with account src_acnt
then the balance of
src_acnt is decreased by amt.
Second, if ser_number has not been used before
in connection with account dest_acnt,
then the balance of
dest_acnt is increased by amt.
Finally, whether or not src_acnt has been updated,
return the (possibly negative) balance of src_acnt.
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:
- Each branch server is executed by its own Java virtual machine.
Associated with each branch server is a unique port
(defined by a pair comprising an IP address and a port number), which
is used to receive messages from other branch servers and from branch GUI's.
- Each branch GUI is executed by its own Java virtual machine.
- There are restrictions, specified prior to run-time, that define which
Java virtual machines are permitted to communicate (thereby allowing
various network topologies to be simulated).
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.
-
IF the destination is directly reachable THEN a message is actually sent.
-
ELSE the destination is not directly reachable; return an
error-code to the invoker of the wrapped send operation.
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:
-
The network topology for branch servers might involve uni-directional connections.
Thus, just because some branch server B1 can
send to a branch server B2 does not imply that B2
can send to B1.
-
There is a unique branch GUI for each branch server.
And you may restrict consideration to topologies where the
branch GUI is allowed to engage in bi-directional
communication with its corresponding branch server.
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.
- BranchGUI creates a window on the console.
This window should allow a user to enter the information necessary for
the corresponding branch server to perform
Deposit,
Withdraw,
Query, or
Transfer.
BranchGUI should be a relatively lightweight and stateless client;
it solicits information from a user,
formats that into a message,
sends that message to the corresponding branch server,
and then waits for a response before accepting the next inputs from the user.
BranchGUI is our software-approximation for an ATM machine.
- BranchServer receives messages that specify operations to
perform on accounts.
These messages should be processed one at a time, in the sequence they are received.
A message requesting a Deposit,
Withdraw, or
Query, should be ignored unless the specified
acnt is managed by the receiver.
A message requesting a Transfer should be ignored unless
src_acnt is managed by the current branch and
dest_acnt
is managed by the receiver or
by a branch that is directly connected to the receiver.
A supported Transfer operation can therefore be implemented
by (i) the branch server doing a local Withdraw
and then (ii) the branch server sending a message to the branch (perhaps
itself if dest_acnt is local)
that manages dest_acnt so that the appropriate Deposit occurs.
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
- The names and a description of the contents for the other files in the directory.
- Instructions for installing, compiling, and running your software on our
Windows system.
- A tutorial that the grader can follow to start your software and to convince
himself that your system implements the required functionality. Expect the grader
to spend at most 10 minutes on this task, so try the tutorial yourself with a stop watch to
check whether the grader might be able to fulfill your expectations.
-
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:
- The scheme used for storing serial numbers and the extent to which
this scheme involves storing redundant information.
- How, when, and who generates serial numbers.
Why this approach could be useful once we admit the possibility of failures.
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:
-
Does your system satisfy the requirements on system-structure outlined above?
-
Does the system operate correctly?
-
How easy is it to follow the README file installation and sample-execution script.
-
How completely does the sample-execution script exercise your system.
-
Is the source code easy to understand and does it exhibit good structure?
-
How sensible is your approach to serial numbers;
how compelling is the rationale in DISCUSS.txt.