Beweglichkeit = Steckbarkeit

Jan Burse, erstellt 10. Okt 2011 Wir leben in einer schönen neuen Welt mit dem Versprechen allgegenwärtiger Kommunikation. Als ich vor 18 Monaten nach Indien gereist bin war die Internetverbindung in meinem Hotel schneller als an meinem Arbeitsplatz. Die Internetverbindung blieb sogar stabil während der täglichen Stromausfälle. Der Fernseher und der Ventilator im Badezimmer fielen zwar aus, aber mein Laptop wechselte auf Batteriebetrieb und die Hotel Wi-Fi Verteiler taten wohl dasselbe. Das grösste Problem in der Planung der Kurzreise war jedoch die Entscheidung welche Geräte mitzunehmen sind. Die Anforderung war den Laptop des Auftraggebers mitzubringen. Die Frage war nun wie kann ich den Minimalbetrieb für andere Projekte aufrechterhalten? Vollständig über das Netz zu arbeiten war keine Option. Weder das Hotel noch der Arbeitsplatz hatten eine Verbindung die schnell genug gewesen wäre zu dem gegebenen niedrigen Preis. Sicherheitsbetrachtungen haben ebenfalls die Benutzung der Hotelverbindung verboten. Die Idee war daher die Arbeit mit mir zu nehmen. Das hätte man lösen können, indem man einige Laptops mit nach Indien genommen hätte. Aber aufgepasst, ich wollte nicht für eine Kurzreise mit einer Handvoll Laptops nach Indien reisen. Deshalb habe ich versucht alle damaligen relevanten Projekte auf einen einzigen Laptop zu transferieren. Weil hauptsächlich Java Technologie zum Einsatz kam könnte man meinen dass dies kein Problem darstellt. Tatsächlich sollte ich ein Projekt transferieren das unter Mac OS X lief und ein anderes das unter Linux lief. Es stellte sich heraus dass Java nicht das Hauptproblem ist. Der Java Code wird durch eine Java virtuelle Maschine ausgeführt. Java virtuelle Maschinen gibt es für einige Betriebssysteme. Das einzige was es zu tun gibt ist den Java Bytecode zu kopieren. Aber die Java virtuelle Maschine sitzt wie ein Sandwich in der Mitte einer Anwendung. Was wir dann höchstwahrscheinlich antreffen ist eine darunterliegender Plattformabhängige Speicherschicht. Tatsächlich liefen die verschiedenen Anwendungen alle auch auf unterschiedlichen Datenbankverwaltungssystemen. Aber ich wollte alle diese Datenbankverwaltungssysteme nicht auf meinem Zielsystem installieren. Ich wollte das hier existierende Datenbankverwaltungssystem wiederverwenden. Die Architektur der Matula Datenbankschicht rettete einmal mehr mein Leben. Die Schicht basiert auf einer steckbaren Architektur. Steckbare Architekturen wurden z.B. schon früh von Unix in der Form von Gerätedateien eingesetzt. Die Idee basiert auf der einheitlichen Sicht von Hardware, alles ist eine Datei. Heutzutage kann man in einer objektorientierten Sprache einfach steckbare Komponenten entwickeln indem man dem Objektfabrikpattern folgt. Bei dem Objektfabrikpattern wird eine zusätzliche Zwischenstufe bei der Erstellung von Objekten benutzt. Das Objektfabrikpattern ist an sehr vielen Stellen in den verschiedenen Java Ausgaben zu finden. Die Standardausgabe macht schon an so vielen Orten davon gebraucht, dass es schwierig ist alle aufzuzählen. Kryptographie, Audio, Webverbindungen und Zeichenkodierung damit sind nur einige Beispiele genannt. Das Objektfabrikpattern ist nicht so einengend wie das Konzept der Gerätedateien. Eine Hardware braucht nicht lokal zu existieren und die erzeugten Objekte können sehr feinkörnig und in hoher Anzahl vorkommen. Es ist nicht allzu lange her dass wir das Konzept der steckbaren Komponenten in unsere Matula Datenbankschicht für die Generierung von Code und für die Laufzeit eingeführt haben. Vor dem Konzept der steckbaren Komponenten benutzten wir einige Regeln verteilt über die Datenbankschicht und trauten hauptsächlich dem JDBC Standard. Aber der JDBC Standard versteck weder Herstellerspezifika noch gleicht er fehlenden Funktionen bei einigen Herstellern aus. Über das Konzept der steckbaren Komponenten konnten alle Anforderungen an die Matula Datenbankschicht in Bezug auf Hersteller an einer Stelle beschrieben und realisiert werden. Leider war die Reise nach Indien zu kurz um den vollgepackten Laptop richtig zu testen. Als wir das erste Mal auf eigenen Beinen standen stelle sich heraus dass die steckbaren Komponenten doch noch einige Reparaturen und Verbesserungen brauchten. Aber zumindest konnten wir einen Bewies erbringen dass ein neuer Hersteller unterstützt werden kann. Die Darstellungsschicht erweist sich als neues zukünftiges Problem. Die Jekejeke Prolog Konsole basiert auf SWING, aber Android würde einen anderen GUI Werkzeugkasten benötigen. Deshalb ziehen wir Moment das Konzept der steckbaren Komponenten in Betracht womöglich mit einer XUL Komponente kombiniert.

Kommentare