Implementation Details, Part 1
1. The “three tier system”
1. database server
2. transaction server
4. system diagram (image)
GNUMed is based on a 3 tier system.
PostgreSQL database server backend:
The GNUMed database is using all inbuilt security features of PostgreSQL to ensure database integrity. The database server communicates with the transaction server and the clients through dedicated TCP ports. Write access can only happen through the “GNUMed Transaction Server”. Direct read-only access bypassing the transaction server is allowed and is useful to increase performance. Typically, for write purposes only a small amount of data is passed over the net and overhead due to the transaction server simply does not matter. Modern GUI applications make heavy use of widgets like list boxes and combo boxes which at times require a rather large amount of data to be displayed, although it will not be used. That way we can get huge network traffic even in a proper client server system. With ever changing data, caching does not seem wise. Therefore we decided to grant clients read only access to the core database. Ths will facilitate easy direct SQL queries & reports as well.
GNUMed Transaction server
The GNUMed Transaction Server is the key security item. All client write requests have to be processed by the Transaction server (TS). The TS will keep a human readable (ASCII) file protocolling every single transaction, thus making it possible to
* reconstruct the state of the database at any time
* check the integrity of the datatabase against the protocol file at any time
* track down any errors and inconsistencies within the database
This transaction protocol file may or may not be encryptet “on the fly”.
At the end of each working day, the Transaction server will create check sums and “landmark items” which will be stored in a public key encrypted file. The private key will be kept by a trustee and will not be known to the user, thus making it medico-legally possible to proof that no undocumented changes have been made to the database. Although it will be possible to alter data with some IT knowledge in the Postgres database and in the transaction log, it will not be possible to hide these changes from the alteration log file. There are mechanisms provided to make it almost impossible to recreate the alteration log file without documentation.
The transaction server can be hosted on the same machine as the database server, but this is not recommended.
As GNUMed will provide mirroring backup daemons, any of both servers will be able at any time to substitute the other server in case of defect, simply by then hosting both server applications on the one machine until the defect one is repaired or replaced.
Clients will communicate with the transaction server and the database server through SQL statements. A C/C++ library will be provided for easy interfacing, but just “piping” plain SQL text into the transaction server will work as well. At present this will be limited to the SQL dialect “spoken” by PostgreSQL, but if time permits, we will provide an intermediate SQL layer compliant with ANSI SQL92 thus allowing to use any SQL compliant server which has transactions and foreign keys implemented. A new open source alternative would be InterBase.