1. CYBORG Domain Independent Distributed Database Retrieval System Alok Khemka Kapil Assudani Kedar Fondekar Rahul Nabar

2. Project Goals: Application Domain Independence Database Independence Secure Communication

3. Application Domain Independence: Each application domain has it’s own database schema. Usually database schema used to be hard coded in the application developed. Defies Code Reusability: Different applications need to be developed for different application domain. Our application tackles this particular problem by acknowledging itself of the application domain database schema, dynamically at run time. Code Reusability: the same application can be run in different application domains, without worrying about the application domain database schema.

4. Database Heterogeneity: Usually applications are developed with the backend database type in mind. Extension of these applications for database type other than that one developed for, is difficult. Our application tackles this issue by providing modular classes, designed mainly to overcome these sort of problems only. Stores all the relevant details about a database type into “Database Parameters” class, abstracting the details of database type from the rest of the program.

5. Communication Security: To prevent the eavesdropping on the transaction details. Internally the transferred data is still naked, though the data is converted to common representation format. All the transaction (starting from connecting to the database to executing different queries to disconnecting to the database is encrypted before being transferred over the net and decrypted afterwards on the other side. The encryption algorithm used is DES (symmetric key algorithm) with 64 bit key size. The SPI used is one from SUN (SUNJCE).

6. Control Flow Diagram: Server Listener 1: The server listener starts and starts listening for the incoming client connection.

7. Control Flow Diagram: Server Listener 2: As soon as the client goes up, it connects with the main server, the main server spawns a New thread for servicing the client and all the further communication from the client occurs to this new Spawned thread. Client Process 1 Server Thread 2 3

8. Control Flow Diagram: Server Listener 3: The client gets the user id and password from the user, encrypts it using the security engine, sends the id and password to the server to connect to the database. Client Process Server Thread Client GUI Prompts user for Id and password Security Engine 1 Encrypts the id And password 2 3 connect

9. Control Flow Diagram: Server Listener 4: Server decrypts the id and password, connects to all the databases, gets the metadata from the databases, generates the XML file, encrypts it and sends it back to the client. 5: Client decrypts the metadata, parses the XML file and populates the user gui based on that metadata. Client Process Server Thread Client GUI Security Engine Security Engine Decrypts id And password 1 Database pool 2 3 metadata connect 4 5 metadata 6 Decrypts metadata 7 Populates gui

10. Control Flow Diagram: Server Listener 6: Users queries the database by selecting different gui components. Client process generates the sql query based on gui components value, encrypts the query and sends it to the server for execution. 7: server fires the query to the relevant database, gets the result, encrypts the result and sends it back to the client. Client Process Server Thread Client GUI Security Engine Security Engine Database pool 1 Generates Sql query 2 Encrypts Sql query 3 Execute query 4 Decrypts query 5 Query relevant database 6 results 7 Encrypt result 8 results 9 Decrypts results 10 Populate gui

11. Control Flow Diagram: Server Listener 8: when the user is done, s/he disconnects with the server. During disconnection server closes all the open connection with the database and the client application goes down. Client Process Server Thread Client GUI Database pool 1disconnect 2

12. Current Limitations: The current implementation is developed for Java 1.3 and the application will not work in a Java 1.4 and above environments. The DES is a symmetric key algorithm and puts an extra overhead of passing the keys to the clients before starting a session. (the key exchange algorithm is outside the scope of this application).

13. Tomorrow never dies … (future work) Make provisions for a horizontal split and a vertical split of tables in database. Enhance the database query set to accommodate more queries like delete table, delete record, join table, etc.

14. Thank You !!!