RePag Framework
Seit 2002 entwickle ich ein Framework, das auch acht Jahre lang mit einem mehrplatzfähigem Warenwirtschaftsprogramm getestet wurde. Das Framework ist ein geschlossenes System und teilt sich in drei Teile: Die Datendarstellung erfolgt mit der an dieser Stelle veröffentlichten GUI.
Die Datenübertragung erfolgt über ein eigens entwickeltes Protokoll und teilt sich in einen: Der Serverteil beinhaltet auch die Datenspeicherung und damit die Database-Engine.

Das Framework ist bei Gesamtbetrachtung in zehn Schichten aufgebaut. Die mittlere Schicht fünf ist der abstrakte Teil des Protokolls und sowohl im Client als auch im Server enthalten.

Bei getrennter Betrachtung von Client und Server besteht der Client aus fünf Schichten und der Server aus sechs Schichten. Da die Transportschicht fünf abstrakt ist und sowohl im Client als auch im Server vorhanden ist, wird sie im Client anders angesteuert als im Server. Das geschieht in der Steuerungsschicht vier im Client und in Schicht sechs im Server.

Die Datenschicht drei im Client und die Schicht sieben im Server bereiten die Daten für die Übertragung vor oder nehmen sie aus dem Transport zur Weiterverarbeitung entgegen. Die Schicht zwei ist die spezifische Programmlogik, und die Schicht acht ist die spezifische Datenbanklogik. Die Schicht eins ist die Benutzeroberfläche. Die Schicht neun ist der abstrakte Teil der Database-Engine, und die Schicht zehn sind die Datenbankdateien. Daraus resultiert:

Die Schichten vier, fünf, sechs und neun sind fertige Teile. Bei der Entwicklung eines Programms sind die Schichten eins, zwei und drei auf der Clientseite sowie die Schichten sieben, acht und zehn auf der Serverseite Programm spezifisch und müssen entwickelt werden.

Die sicherheitskritische Client-Server-Architektur basiert auf einem verteilten System mit eigenem Protokoll und AES-256-Bit-Verschlüsselung sowie integrierter Benutzerverwaltung und Rechtesystem. Der Serverteil besteht aus drei Services:

Der Admin-Server ist zusammen mit dem Login-Server für die administrativen Aufgaben zuständig sowie für die Fehlerprotokollierung. Der Programm-Server ist für die Programm spezifischen Aufgaben zuständig. Wer die Schicht dreiundsieb(zig) bei den Severn erkannt hat, hat den Aufbau verstanden.

Hinweis: Die Passwörter liegen zurzeit noch im Klartext in einer verschlüsselten Datenbankdatei, die nur der Admin mit Sicherheitsstufe vier einsehen kann. In Zukunft wird dies durch ein modernes PassKey-Verfahren ersetzt. Im Zuge dieser Änderungen wird die gesamte Login-Prozedur überarbeitet und DSGVO-konform gestaltet. Das wird dazu führen, dass die neue Login-Prozedur nicht abwärtskompatibel sein wird.

Das Project DBDateien erstellt die notwendigen Datenbankdateien (Schicht zehn) auf der Serverseite.

Hinweis: Die Binär-Search-Trees existieren unabhängig von den sortierten Listen. Daher entsteht hier keine Treppenstruktur, sondern eine perfekt ausgeglichene Glockenkurve. (siehe dazu auch PA und SO.) Es gibt jedoch einen Zusammenhang: Die BSTs befinden sich im Cache und greifen auf die sortierten Spalten der Tabellen zu, welche sich ebenfalls im Cache befinden. Daraus folgt: Ein BST kann immer nur auf einer sortierten Spalte aufsetzen. Die sortierten Spalten werden von links nach rechts bzw. von oben nach unten (siehe ODLGDBDateien.cpp) angeordnet. Das gilt es bei der Planung der Datenbanktabellen zu beachten.

...und hier sind noch die Include-Files.

Entschuldigung das ich nicht das ganze Framework erkläre, aber dann wäre das keine Webseite mehr, sondern wohl eher ein Buchprojekt.