1 / 14

CYBORG

CYBORG. Domain Independent Distributed Database Retrieval System Alok Khemka Kapil Assudani Kedar Fondekar Rahul Nabar. Project Goals:. Application Domain Independence Database Independence Secure Communication. Application Domain Independence:.

chesmu
Download Presentation

CYBORG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 1 2 Client Process 3 Server Thread 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.

  8. Control Flow Diagram: Client GUI Server Listener Prompts user for Id and password 1 Client Process 3 Server Thread connect Encrypts the id And password 2 Security Engine 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.

  9. Control Flow Diagram: Client GUI Server Listener Populates gui 7 Client Process 2 Server Thread 5 connect metadata Decrypts metadata 6 3 Decrypts id And password 1 4 metadata Security Engine Security Engine Database pool 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.

  10. Control Flow Diagram: Client GUI Server Listener Generates Sql query Populate gui 10 1 3 Client Process Query relevant database Server Thread Execute query 8 5 results Encrypts Sql query Decrypts results 6 2 9 Decrypts query Encrypt result 7 4 results Security Engine Security Engine Database pool 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.

  11. Control Flow Diagram: Client GUI Server Listener 1 disconnect Client Process 2 Server Thread disconnect Database pool 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.

  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 !!!

More Related