Armarius – Rückblick auf eine konsequent gedachte Client-Server-Plattform

Armarius war eine proprietäre, metadata-getriebene Client-Server-Anwendungsplattform zur strukturierten Verwaltung und Bearbeitung relationaler Datenbestände in Mehrbenutzerumgebungen. Die Leitidee war bewusst anwendungszentriert: Die Datenbank diente ausschließlich der Persistenz, während Regeln, Rechte, UI-Strukturen, Validierungen und Sperrmechanismen oberhalb der Datenbank umgesetzt wurden – zentral im Server als „Single Point of Control“.

Motivation & Ursprung

Ausgangspunkt war der Anspruch, die ERP-Software der s.mile DIREKT AG auf ein neues technisches Niveau zu heben. Parallel entstand die Idee, den pragmatischen Ansatz von Datenbank-Entwicklungsumgebungen wie Microsoft Access als echte Netzwerk- und Client-Server-Lösung nutzbar zu machen – ohne direkte Datenbankzugriffe aus dem Client und ohne die typischen Mehrbenutzer-Probleme klassischer Client-DB-Architekturen

Praxis: ERP und Branchenlösung

Auf dieser Basis wurden hausinterne ERP-Lösungen für brainlogical Software Solutions sowie die 3B Kommunikation GmbH realisiert. Zusätzlich entstand eine eigenständige Software zur Verwaltung von Tauchschulen nach PADI-Standard, die von Tauchbasen als direkt einsetzbare Lösung („out of the box“) genutzt werden konnte.

Architektur: Server als Autorität

Armarius setzte auf zustandsbehaftete TCP-Sessions pro Client und ein proprietäres Anwendungsprotokoll (DTS) auf Port 2594. Der Server koordinierte Sessions, Rechte, Datenzugriffe und lieferte Views, Datensätze und Skriptlogik aus – der Client blieb generischer Renderer ohne eigene SQL-Logik und ohne eigene Sperrmechanismen.

Locking: schnell, strikt, fail-sicher

Datensatzsperren wurden serverseitig in einer In-Memory-Struktur verwaltet und an die jeweilige Session gebunden. Damit war klar definiert, wer einen Datensatz exklusiv bearbeiten darf – und ebenso klar, wann Sperren enden: Speichern, Abbruch oder Verbindungsende. Ziel war ein robustes Sperrmodell ohne manuelle Entsperrungen nach Abstürzen.

UI als Metadaten

Ein zentrales Merkmal war das View-Konzept: Tabellen-, Detailansichten und Felddefinitionen wurden serverseitig beschrieben und dynamisch an den Client ausgeliefert. Das ermöglichte UI-Anpassungen ohne Client-Update und trennte Struktur (View), Daten und Logik (Script) sauber voneinander.

Regeln per Script

Für dynamische Validierungen und UI-nahe Regeln kam PascalScript zum Einsatz, ereignisgetrieben über definierte Events (z. B. OnFieldChange, Validate, BeforeSave). Damit konnten Eingaben geprüft, Daten transformiert oder abhängige Informationen automatisiert nachgeladen werden.

Netzwerk, Discovery & Sicherheit

Neben der TCP-Kommunikation unterstützte Armarius eine UDP-basierte Servererkennung im LAN (Broadcast/Unicast) zur Zero-Config-Inbetriebnahme. Für die Transportabsicherung gab es einen kryptographischen Handshake und symmetrische Session-Verschlüsselung; optional konnte serverseitig ein Plain-Mode für abgeschottete Netze freigeschaltet werden.

Einordnung

Armarius war kein Web-Framework und keine stateless API-Plattform. Es war ein bewusst stateful, on-premise orientiertes Anwendungssystem – technisch geprägt von seiner Zeit, aber architektonisch nah an dem, was heute unter schema-driven UIs und Low-Code-Prinzipien wieder auftaucht: zentrale Autorität, konsistente Regeln, kontrollierte Mehrbenutzer-Bearbeitung und dynamische UI-Beschreibung.

💬 Chat öffnen
🧠 Support-Chat