Goals
The underlying objective for the Coffer2 project was to create a bank-like distributed system for managers (multiple) of unofficial accounts such as snack-bars, small gambling circles, or any organization where monies can be used and deposited among all its members. Additionally, an academic goal of learning more about graphical event driven application development, distributed system development (specifically the middleware CORBA), and threading were also project objectives.Overview
Coffer2 utilizes CORBA middle ware to connect a server and client. CORBA acts as a broker between client and server in order to offer the developer automatic object/data marshalling and a more logical development environment especially within Java. CORBA establishes the IDL and ORB in order to make this happen.The Coffer2 server is an independent server that each client must connect to in order to process data. The data for Coffer2 is stored in flat files on the server machine. The server additionally does some data checking/correcting during its processes. The server writes balance values with floating point precision of .2f. This as a result drastically reduces the need for checking floating point precision when reading and displaying the data to the user. Additionally, after each method call the server responds with a logical answer such as an updated balance, a new name, or an Account object. This enables data checking to be performed at the client end as well.
The client for Coffer2 utilizes Java Swing for rendering of GUI components. It connects to the server by utilizing the IDL and ORB interfaces. The connection is established with command line arguments such as –ORBInitialHost and –ORBInitialPort. The functionality of the GUI component is straight forward and easy to understand. However, since development time was limited and this was the developer’s first attempt at creating a useful graphical application some features graphical features to ease connectivity and report errors to the user were omitted in order to focus on CORBA specific issues. One issue in particular was threading. While only partially implemented, threading was incorporated into Coffer2. During the most data intensive message transaction (account list update) a separate thread is created for the process and a status bar is displayed for the user. This demonstrates the concept and should be fairly straight forward to adapt to other functions within Coffer2. While all of the CORBA/IDL/ORB interactions were tested locally and verified against other projects known to work the distributed operation of this application remains untested. This is due to network restrictions on the developer. However, the developer feels that there is a high probability that the program would work under a distributed environment with no modifications.
Coffer2 also implements a command line program that allows the user access to all server functions. While not as user friendly as the graphical application the command line program offers success/fail responses to the user upon message transaction completion, a feature not yet implemented in the graphical application. However, threading was not incorporated into the command line program. Since threading was considered a priority in this project the graphical client should be considered the primary user application.
Design
When the project was initially started the program offered a bank account type system that offered individual users access to one specific account. The goal of the design was to establish an application geared towards a team of individuals that manage multiple accounts. Several design choices needed to made in order to accomplish this.User Interface
Since a non-technical end user was the target audience a graphical application was considered the only viable option. End users simply expect it. This also provided an opportunity for the developer to more easily implement threading. Since, threading is a core part of nearly all graphical APIs the probability of successfully implementing threading seemed much higher in a graphical environment.Programming Language
Java was considered the best choice for several main reasons. The developer’s competency lies in the following languages:- C/C++: The developer’s language of choice, no threading within core language
- Java: The developer’s next choice in languages, threading available, easy cross- platform development
- PHP: Primarily used in web-application, user wants a local client
- (My)SQL: Describes only database interaction, user wanted more than web/DB application
- Other various languages: Developer not confident in successfully completing substantial projects in other known languages due to experience
Client/Server Architecture
Again there were several choices in this matter. The server could itself be distributed (allowing redundant access at the cost of longer development time due to replication implantation) or a single resource (allowing shorter development time at the cost of reliability). The single resource model was chosen in order to meet project deadlines. The client could be either a remote service, such as a web application or Java Applet (which would allow multiple end users a single point of entry at the cost of higher deployment costs due to resource demands) or multiple local clients (which offer slightly more implementation problems but may be more reliable). The design choice utilizing multiple local clients was selected due to project demands.Databases
The appeal of utilizing a database in order to store account data was considered. The underlying goal of developing a distributed system also promoted this idea because having a separate database would more accurately implement a Model/View/Controller (MVC) type of architecture. This separates the Model (data), View (client), and Controller (server) so that the project can be maintained in a more efficient manner. It is also the core concept in Java Enterprise application development. The decision to focus on message transaction utilizing CORBA was made so adding interaction between the server and a database was considered too much to undertake with the deadline assigned.CORBA
The middleware CORBA was chosen for no particular technical reason other than for academic research on the topic of distributed systems. In hindsight a more modern middleware utilizing XML based services that operate over any Internet connection would have been wiser considering the limitations on some Internet connections. Additionally, CORBA appears to be losing popularity due to XML based services like SOAP and RESTful formations. The adaptation of the Coffer2 client/server is possible considering the CORBA specific functions are only used in isolated areas within the server and client source. The specifics of the modification are unknown at this time.Development
The development of Coffer2 was done under both Windows Vista SP1 and Ubuntu Linux 9.04. The development environment also included Sun JDK 6, Sun JRE 6, gedit, notepad, and NetBeans 6.5 and 6.7. The different environments accessed a portable drive to access source files and project resources in lieu of a version control system. SVN or Subversion was not available due to network restrictions and the unavailability of a local server. This method allowed for multiple environment testing, continuous availability of source code and project resources, and ensured code was portable. Several shell scripts were written for ease of use in a Linux/Unix environment. These scripts are included with the full source package.Testing of this project was done with a scenario based approach. Since the development team consisted of only one person and because of the project deadline only minimal testing occurred. Testing consisted of running the application through each major interaction between the client and server such as; withdraw funds, deposit, create, delete, change name, etc. The following bugs/missing features have been identified and have not yet been triaged or fixed:
- When the graphical application is built with ant (not with NetBeans 6.7) a Java Bean Persistence warning occurs when the first dialog box is closed. Subsequent opening and closing of dialog boxes do not generate this warning. No loss of data or impact to the user is noticeable by the end user.
- The account list in the graphical client should be updated after every operation. This
feature is currently under consideration. There are several options and pros/ cons to
implementing this feature.
- The major drawback to implementing this feature is it would create far more message traffic that currently used
- A major benefit to this would be the improved accuracy of data presented to the user, providing a more real-time appearance
- An alternative option to consider would be caching updates locally after they occur - This option would require synchronization between all clients.
- In the graphical client no feedback is provided to the user when a distributed operation successfully or unsuccessfully completes. A work around is to update the account list after the operation and verify the task.
- The console application does not show a fail warning when getting an account, this does not matter since no account information would be displayed.
Solution
The solution created in this project is a CORBA server and two CORBA clients, one graphical intended for use by most end users and one command line client intended for testing and experimentation by the developer. While the IDL designed in this project is short and simple it provides a lot of functionality including provisions for simple transaction verification. The IDL, being the core of the solution, was looked at with considerable care to ensure that all current and future needs of the distributed system could be met. Beyond the interface description the solution provided addresses current needs of the end user as well as a solid foundation for software developers in the future to expand and enhance this project. Screenshots of various parts of the solution are located in the appendix.Use
The use of this application is fairly straight forward and outlined in the readme file in addition to instructions included here.Building Coffer2
The primary method for building Coffer2 is execution of the build.sh shell script with the following command executed from the project main directory: sh build.sh Additionally the project can be built manually with the following steps under a Linux or Unix environment:
Step 1. Unzip the project files into a directory using any method available.
Step 2. Run the idlj compiler in order to build the stubs and servants:
idlj -oldImplBase -Fall Coffer.idl
Step 3. Compile the server:
javac CofferServer.java CofferModule/*.java
Step 4. Create an "accounts" directory in the same directory as the server:
mkdir accounts
Step 5. Compile the client:
javac CofferClient.java CofferModule/*.java
Step 6. Copy CofferModule files for the graphical app:
cp -R CofferModule/ src/CofferModule
Step 7. Build Coffer2 Java Swing application with ant:
ant jar
Running Locally
While running the application in a distributed manner is the main purpose of the application, running the application locally is also available. There are shell scripts available to help with this process.
Step 1. Start the server:
(open terminal/console)
java CofferServer &
Step 2. Run the preferred client:
java CofferClient
OR
java -jar dist/Coffer2.jar
Distributed Execution of Coffer2
While this feature was untested the proper ORB declarations to the Coffer2 server and client should yield a successful execution.
Step 1. Start the server on machine #1:
(open terminal/console)
java CofferServer –ORBInitalHost X –ORBInitialPort X &
Step 2. Run the preferred client on machine #2:
java CofferClient –ORBInitalHost X –ORBInitialPort X
OR
java -jar dist/Coffer2.jar –ORBInitalHost X –
ORBInitialPort X &