Foreword
Resources
Code Listings
Foil Sets
Assignments
Solutions
External Resources
SiteMap
Search
Home
| |
[ Up ] [ NPAC System ] [ Secured NPAC System ]
Secured Distributed Client-Server Management System (Draft based on Online Banking
Transactions)
This experimental system is developed using idltojava (Sun's
version of CORBA-JAVA compiler) under Sun's JDK1.2beta3. This system can be easily
modified to be adopted into comercial client-server applications.
This system is at preliminary stage. More functions will be added later.

If you'd like to have a look at a the pure CORBA (JavaIDL) implementation of this
system, please cliek here.
Please send your comments to cwou@npac.syr.edu.
Thanks in advance!
Developed by Chao-Wei Ou

Architecture
Client Applet
(See detail) 
Actions
 | 1 A Client applet accesses Coordinator through socket connection to comput the secret key |
 | 3 Once obtaining the server infomation and
secret key, the client starts the connection to the one of the servers which assigned by Coordinator. |
Functions
 | username/password authentication |
 | computing the secret key for encrypted communication using DH protocol |
 | connection to the server which is determined at run-time |
 | locally printing the current transaction information to a log file |
 | querying current account information |
 | transferring amount between Checking and Saving accounts |
 | auto-disconnect when applet die (without clicking Exit) |
 | real-time action checking (auto-disconnect if no action after the threshold) |
To be done:
 | to connect to the second or third server if the primary server failed |
 | better GUI implementation (using JFC) |
|
Console Applet/Public Coordinator
(See detail)

Actions
 | 2 Coordinator
verifies the client by checking username/password,
returns a unique transaction number and an available server reference. |
 | 5 Console connects
to Coordinator using CORBA to start/stop the
system. |
 | Coordinator communicates with Server through socket connections. |
Functions
 | Console
 | sending transaction number and verification information to the dedicate server |
 | periodically pulling the system status |
 | refreshing/maintaining all server status |
 | startup/shutdown all registered servers |
 | start/stop each individual server |
|
 | Public Coordinator
 | accepting clients' connections by verifying users' username/password
|
 | generationg shared secret key using DH-handshaking protocol algorithm for the encrypted
communication between clients and servers |
 | locally generating a unique transaction number by a local counter |
 | determining one available server according to the Server
status |
 | accepting console's connection by verifying console's username/password
|
 | periodically checking the system status (including all servers and database servers) |
 | displaying the system status for users without console's password |
|
To be done:
 | to attach a set of computing resource for calculating the secret keys or storing
pre-calculated secret keys in database |
 | to verify the certification |
 | two+ servers are assigned to the client (one serves as a primary server and the other
serve as backup servers for recovering the failure of the primary server) |
|
Administrators/Internal Coordinator
(See detail)
Actions
 | 6 Administrator
obtains customers' information. Then it connects to Internal
Coordinator using CORBA to register customers' information. |
 | 7 Internal Coordinator
obtains customer data. Then it connects to Servers to
insert customers' records into database. |
Functions
 | Administrator
 | username/passwrod verification |
 | adding new customer into database |
 | updating existing customer data |
 | deleting existing customer |
 | searching existing customers |
 | printing operation logs |
|
 | Internal Coordinator
 | periodical administrator online checking |
 | login/privilege verification |
 | connecting to database server |
|
To be done:
 | to add better presentation for viewing the transaction logs |
|
Monitor Applet/Servers
(See detail)

Actions
 | 4 Server
proceeds clients requests (query, transfer, etc.) and send these requests to database
server through JDBC. Then return results back to clients. |
 | 8 Monitor connects
to a dedicated Server to monitor the current status of
the server. |
Functions
 | Monitor
 | displaying ongoing transactions (including transaction number, username, transaction
type, transaction status, time, etc.) |
 | prioritizing transactions (divide into two groups, active and idle) |
 | auto-downgrading the transaction from active to idle if its idle timer over the
threshold |
 | auto-upgrading the transaction from idle to active if it is active again |
 | auto-stopping transactions when they are idle over the presetting threshold |
 | manually upgrading and downgrading transactions' priorities |
|
 | Server
 | multi-threading implementation |
 | username/password and transaction number |
 | checking clients' actions (auto-disconnect if client is idle for a period verification
of time or browser is closed) |
 | proceeding querying/transfering requests |
 | recording all transactions |
 | tracking the current usage status by monitoring the server |
 | reporting the current load information to Coordinator for better decision of chossing an
available server |
 | connect to Database Servers by JDBC |
|
To be done:
 | to record all transactions in logs for committed transactions in order to be consistent
with the database server and to be recovered after system crash |
 | to automatically check the consistency between Database
Server and Server's logs. |
 | to warn/prohibit general illegal transactions |
 | to perform transaction migration if the load is higher than the threashold |
|
Database Servers
(See detail)
(Partially completed - need real data to complete)
Actions
 | JDBC connects to database servers through the
Oracle JDBC driver (oci7 server-side driver). (This also can be done using thin
driver for workstations have SQL*Net installed.) |
Functions
 | database owned by a system user |
 | the client access/update the view which prevent the client from obtaining others'
information |
 | periodically changing database accessing verifications (username/password) to protect
the system |
 | indexing |
 | using stored PL/SQL packages to increase the performance |
 | generating transaction logs in database for comparing with logs on Servers
|
 | auto-daily flushing transaction logs and backup |
To be done:
 | to add functions for viewing transaction logs in the database |
 | to add functions for keeping tracking of irregular transactions |
 | to add effecient functions for searching specific transactions |
|
|