Distributed Database Querying System

ABSTRACT

Aim:
The project aims to develop an application which could query multiple heterogeneous Databases in a distributed fashion.
The project would provide me familiarity with the RMI mechanism as implemented in Java. It will also give me an insight into some of the challenges involved with designing and building a distributed application.

Objective:

The problem involves developing a distributed database querying system. The system has three databases. These databases are MS Access databases as used in this Implementation. However, these databases could be of varying architectures like Oracle or MS SQL server and so on.

The system has three Access databases on three different machines. The database structures are as described in the problem statement earlier. Just above the databases on each machine is a QueryDatabase object. The QueryDatabase object can talk to the Database and make queries on it. Since the QueryDatabase objects are on the same Machine as the database they are interacting with, it is assumed that the individual QueryDatabase objects would know the structure of the database they are querying. The QueryDatabase object talks to the database using JDBC (Java Database Connectivity) calls. Unfortunately, the Access databases do not recognize JDBC calls. However, Access understands another standard i.e. ODBC (Open Database Connectivity). Thus the QueryDatbase objects use a JDBC-ODBC bridge to connect to the database.

Each machine implements a server that implements a MyServer interface. These servers have the job of binding the name of the particular machine with the RMI registry. The servers implement among other things, a method called ProcessData. The ProcessData method is the remote method that would be called using RMI.

So the execution goes on like this.
1. A client takes a query from the user. This query is a pid of a student whose information is required.
2. The client calls the ProcessData method of the second machine remotely and passes it the query string and a result string (which is initially null). The ProcessData calls the corresponding QueryDatabase method and store the results got into the result string. It then calls the ProcessData of the third machine remotely.
3. The ProcessData method on the third machine does a similar job and calls the ProcessData method on the first machine (on which the client was run). It then contacts the QueryDatabase object and gets the results from the first database which are appended to the result string and finally, the ProcessData method on the first machine will write out the result string to a file which is named as query.



Modules:

Personal Info: This module stores the names of students, their phone numbers and a unique pid. (Similar to VT)
Finance Info: This module stores the current Hokie account credit and insurance amounts for each student (identified with the unique pid field)
Account Info: VT has decided to let students take copies and printouts up to a certain limit. This database holds the current number of copies and printouts taken by each student identified with the unique pid field
Schema management Module This module manages the schema of the database spreaded across in all the DBs. It helps if this system want to send the same amount of data to interoperable systems then this schema document is submitted to other platforms to make them understand that schema/structure in which data is organized.

Software requirements:
Technologies : J2SDK 1.4, RMI, JDBC, DAO, Log4J, XML
Databases : Oracle
Operating System : Windows 2000 Prof/XP.

Hardware requirements:
Processor : Intel P-IV based system
Processor Speed : 250 MHz to 833MHz
RAM : 256 MB to 2 GB