Gliederung der Projektphasen
Projektmanagement und -planung
Anforderungen
Eine grundlegende Erkenntnis aus der Analyse des Datenbankmanagers unter [*] ist, daß die VDM-Datenbank im FLAT-Modell(*) im Arbeitsspeicher vorgehalten wird. Die Datenbankdatei wird vom VDM Datenbankmanager in den Arbeitsspeicher geladen und hat derzeit eine Größe von ca. 1 MB. Dieser einmalige, zur Initialisierung des Datenbankmanagers notwendige Vorgang, benötigt nicht unerhebliche Rechenzeit, was auch mit durch den Zugriff auf Betriebsmittel bedingt ist.
Bei Maschinen mit virtuellem Adreßraum, dies ist bei den Portierungen der VDM-Klassenbibliothek regelmäßig der Fall, ist ferner nicht ausgeschlossen, daß Teile der Datenbank auf Festplattenspeicher ausgelagert sind. Versuche mit einem mit unzureichenden 4 MB Hauptspeicher ausgestatteten Linux System, bestückt mit einem 40-MHz getakteten AMD 80386 Prozessor, haben gezeigt, daß die Ladezeiten bis zu 6 Sekunden betragen können. Selbst ein mit 100-MHz Pentium Prozessor und 16 MB ausgestattetes System benötigt ca. 1 Sekunde zum Laden der Datenbank. Selbst die SUN Sparc20 der FH-Wedel mit 256 MB Hauptspeicher schneidet hier teilweise nicht besser ab(*).
Wie eingangs unter [*] beschrieben, handelt es sich bei dem verwendeten Zugriffsprotokoll HTTP für das Informations- und Hilfesystem um ein ,,lightweight``-Protokoll. Dies bedeutet, daß jeder Neuzugriff auf die Serverseite von allen vorhergehenden Zugriffen unabhängig ist und macht es unmöglich, eine dauerhafte Verbindung zwischen Browser und Web-Server herzustellen, die über die Übertragung einer Web-Seite hinausgeht.
Die direkte Verwendung des CGI-Gateways für den Zugriff auf den Datenbankmanager würde dazu führen, daß die VDM-Datenbank für jeden Client erneut in den Arbeitsspeicher geladen würde. Dies wäre ein nicht zu vertretender Aufwand. Selbst wenn das Ziel lediglich ein Single-User System sein würde, und festzustellen ist, daß sich durch den Festplattencache die Ladezeiten bei mehrmaligem Zugriff erheblich verbessern, sind die Reaktionszeiten jedoch keinerzeit ausreichend genug, um das erneute Laden der Datenbank als auch des nicht weniger umfangreichen Datenbankmanagers bei jedem Datenbankzugriff zu rechtfertigen.
Die zu ziehenden Konsequenzen aus den Beobachtungen sind
Durch Prototyping zu Analysezwecken wurde zunächst der Bibliotheksbrowser in ein Client-Server Modell verwandelt. Anschließend folgte der Bibliotheksmanager, der die Pflege der VDM Datenbank unterstützt. Auch im Hinblick einer integrierten Gesamtlösung schien es erforderlich, Augenmerk auf eine gemeinsame Datenbasis für alle Tools der Klassenbibliothek zu richten. Die Realisierung der Lösung mit Client-Server Struktur beseitigt die Problematik, die aus dem HTTP-Protokoll erwächst, fördert die Integration der Tools, vereinfacht die Pflege der Klassenbibliothek und bietet darüber hinaus weitergehende Möglichkeiten im Hinblick auf Zugriffskontrolle und das Arbeiten im Netzwerkverbund.
Da jede Verbindung eines HTML-Browsers zum Informations- und Hilfesystem unabhängig vom jedem vorausgegangenen Zugriff ist, läßt sich keine verbindliche Zuordnung zwischen Browser und Server vornehmen. Zwar erlaubt das CGI-Interface, die Internetadresse der Gegenstelle zu ermitteln, der einem Zugriff zugewiesene Port ist jedoch regelmäßig verschieden. Nur die Internetadresse mit dem Port gemeinsam bilden zusammen eine eindeutige Identifizierung einer Verbindung(*)
Eine Verbindung (connection ) ist als eine Kommunikationsverbindung zwischen 2 Prozessen definiert. Als Zuweisung (association ) wird ein Fünfertupel bezeichnet, das eine Verbindung ausmacht:
{protocol, local-addr, local-process, foreign-addr, foreign-process}
Durch die lokale und und auswärtige Adresse (local-addr, foreign-addr) werden die Netzwerk und Host-IDs des lokalen und fernen Hosts angegeben.(*) Durch local-process und foreign-process werden die miteinander verbundenen Prozesse spezifiziert. Das Format dieser Größen hängt vom Protokollsatz protocol ab. In der vorliegenden Arbeit wird lediglich das bedeutsamste Protokoll TCP verwendet. UDP und weitere hier nicht im Detail behandelte Protokolle wären SNA, IPX, XNS (ein Vorläufer von IPX), OSI, AppleTalk, NetBEUI für die ebenfalls gleiche Zuweisungen gelten.
Eine korrekte Zuweisung für das TCP Protokoll könnte lauten:
{tcp, 192.43.235.2, 1500, 192.43.235.6 , 1117 }
Die lokale Adresse wäre 192.43.245.2, der lokale Prozeß 1500, wogegen die auswärtige Adresse 192.43.245.6 und der auswärtige Prozeß 1117 ist. Jeweils eine halbe Zuweisung (half association), {protocol, local-addr,local-process} und {protocol, foreign-addr, foreign-process} ist der Endpunkt der Kommunikation. Für das TCP Protokoll wird dieser Endpunkt als Socket (in BSD Terminologie) oder Transportadresse (System V) bezeichnet. Die Prozesse (local-process und foreign-process) werden im TCP (als auch im UDP) durch Kanäle (ports) spezifiziert.
Nun läßt sich über die Parameter des CGI-Gateways REMOTE_ADDR (*) die Internet-Adresse und REMOTE_HOST(*) der Internet Domänen Name des Hosts der anfragt ermitteln. Der Identifikationsgehalt dieser Angaben ist jedoch identisch. Eine Übergabe des Prozesses der Gegenstelle, der mit dem HTTP-Server verbunden ist, an den CGI-Client ist in der derzeit gültigen Fassung des CGI in der Version 1.1 nicht definiert. Lediglich der Port des HTTP Servers, der Anfragen entgegennimmt, wird mit dem CGI Parameter SERVER_PORT mitgeteilt. Dieser ist jedoch auf Serverseite hinlänglich bekannt.
Der Fall, daß mehrere HTTP-Klienten des gleichen Hosts auf den VDM Datenbankmanager in der ursprünglichen Form zugreifen(*), bewirkt, daß vormals für eine Verbindung gültige Einstellungen des Datenbankmanagers, die eigens für bzw. durch diese Verbindung eingerichtet wurde, für den nächsten Klienten den Eintritt in einen undefinierten Zustand bedeutet. Gleiche Problematik gilt für Zugriffe aller Art auf den gleichen Datenbankmanager.
Zur Abhilfe des Problems sind zunächst zwei realisierbare Lösungsansätze denkbar:
Erstgenannter Ansatz würde im FLAT-Modell(*) des VDM Datenbankmanagers bedeuten, daß die gesamte Datenbank im Arbeitsspeicher mit seiner Größe von mehr als 1 MB für jeden Klienten im Arbeitsspeicher vollständig kopiert würde. Selbst wenn dieser unvertretbare Aufwand in Kauf genommen würde, sind Änderungen an der kopierten Datenbasis durch den Klienten nach dem Beenden der Verbindung genauso verloren, wie der nicht mehr benötigte Kontext des Klienten. Ein Vorteil liegt jedoch in den definierten Anfangszuständen, die aus der Kopie des Elternprozesses erwachsen.
Durch Einsatz von mehrfach genutztem Speicher (shared-memory) in Verbindung mit Semaphoren zur Synchronisation der Zugriffe unter UNIX ([RS95] und [RS92] geben hier Aufschluß), ließe sich verhindern, daß die Datenbank des Datenbankmanagers für jeden Klienten kopiert wird. Der Einsatz dieser sehr systemnahen Techniken ist jedoch zumindest bedenklich, und hätte eine empfindliche Änderung bzw. Erweiterung der VDM Klassenbibliothek mit sich gebracht, da die Datenbank selbst durch ADTs der Klassenbibliothek beschrieben ist.
Im Vorgriff kann gesagt werden, daß letztendlich hauptsächlich der Lösungsansatz B weiterverfolgt, und Multisessionfähigkeit in den VDM Datenbankmanager integriert wurden. Es lassen sich nunmehr wahlfrei viele Sessions einrichten, verwenden und entfernen. Jede Session besitzt bei der Erzeugung einen definierten Anfangszustand, die Eigenschaften einer Session sind der Kontext dieser Session. Der Wechsel einer Session löst die Sicherung des aktuellen Kontexts der vormals aktiven Session und die Wiederherstellung des neuen gültigen Kontexts aus.
Dem Lösungsansatz A wurde in soweit Rechnung getragen, daß der VDM Datenbankmanager dahingehend konfiguriert werden kann, die Datenbank in einem eigenständigen zusätzlichen Kindprozeß zu verwalten, mit welchem über Kanäle (pipes ) kommuniziert wird. Der Vaterprozeß kann in diesem Fall Kindprozesse erzeugen, ohne daß dies eine Kopie der Datenbank zur Foge hat. Für Multisessionfähigkeit des Datenbankmanagers auf alleiniger Basis des ersten Ansatzes hätte der jeweilige Kontext des Vaterprozesses auf den Datenbankprozeß übertragen werden müssen, weshalb auch hier Kontextwechsel nach Lösungs B verwendet wird.
Aus den vorgenannten Aspekten der Prozeßidentifizierung, wurde Multisessionfähigkeit geplant und mit Single-Thread Verarbeitung umgesetzt. Dies bedeutet, daß alle Anfragen von Klients in einer Warteschlange auflaufen, und seriell in der Reihenfolge ihres Eintreffens verarbeitet werden. Parallelverarbeitung von Anfragen ist aus den technischen Eigenschaften von TCL derzeit nicht möglich, und zur Lösung des Problems auch nicht erforderlich, wie unter [*] gemeinsam mit den Einzelheiten der Anfragenbearbeitung dargestellt wird.
Während des Prototypings wurde ein Derivat von TCL 7.3 mit der Bezeichnung TCP-DP (*) in der Version 3.2 eingesetzt. TCL-DP erlaubt als Besonderheit im wesentlichen die Definition von Objekten und dessen verteilten Ablauf im Netzwerk sowie die Ausführung von vollduplex RPCs.
Bedauerlicherweise hat die Mehrzahl der TCL-Derivate die Eigenschaft (*) , lediglich mit einer äquivalenten Version des Originals kompatibel zu sein. Während der Bearbeitung der Diplomarbeit, die zunächst auf TCP-DP basierte, erschien TCL in der Version 7.5, welche erstmals die einfache Kommunikation über TCP sockets ermöglichte und zumindest zur Lösung der Kommunikation zwischen CGI-Client und Datenbankmanager geeignet schien.
Da sich RPCs insbesondere im Einsatz mit TCL bereits beim Prototyping als sehr praktikabel und flexibel erwiesen, ist die Implementation von RPCs für TCL 7.5 als Teilziel definiert. Eine sehr starre Alternative hierzu wäre die Definition eines zusätzlichen Kommunikationsprotokolls auf Textbasis und der Austausch von entsprechenden Dateneinheiten zwischen CGI-Client und VDM Datenbankserver gewesen. Die RPC Aufrufe wurden bei der Realisierung denen von TCL-DP nachempfunden, der C-Quellcode als auch TCL-Code der dp-library wurden analysiert, um einen Einblick in die konkrete Funktionsweise zu gewinnen.
Als weiteres Ziel für die Implementierung der RPCs in TCL 7.5 wurde gesetzt, daß im Gegensatz zu TCL-DP keinerlei Hochsprachenerweiterungen verwendet werden und die Codierung ausschließlich in TCL erfolgt. Dies aus dem praktischen Grund, die unveränderte TCL-Shell als RPC-Client bzw. RPC-Server einsetzten und gegebenfalls auch lediglich den Binärcode von TCL verwenden und auch distributieren zu können. Die auf dieses Weise später implementierten Remote Procedure Calls sind von ihrer Funktionalität denen von TCL-DP gleich, basieren jedoch auf einer vollständig anderen Struktur und sind daher auch nicht mit diesen verträglich.
Der Zusammenhalt eines Systems hängt nicht zuletzt von der Anzahl seiner Komponenten ab. Wie Eingangs unter [*] erwähnt, zählte es daher zur Aufgabe des Diplomanden, auf den bestehenden Komponenten der VDM Klassenbibliothek aufzubauen, und, soweit möglich, Quellcode der Tool Command Language zu verwenden. Dennoch ist eine Erweiterungen der DSL-Spezifikation und des Hochsprachenteils des VDM Datenbankmanagers im Hinblick auf die erforderliche Multisessionfähigkeit unumgänglich.
Ein grundsätzliches Teilziel aller Erweiterungen ist es daher, daß keine Modifikationen eine Veränderung des ursprünglichen Verhaltens der Komponenten der Klassenbibliothek hervorruft, sondern in diesem Sinne jede Modifikation eine Erweiterung und keine Veränderung darstellt. Hinsichtlich der Hochsprachenerweiterungen, die bei der Realisierung jedoch einmalig am Datenbankmanager durchgeführt sind, und keine weiteren Bestandteile der Klassenbibliothek betreffen, ist festzustellen, daß ein Schaffen neuer Kommandos nicht gegen das Teilziel der Abwärtskompatibilität verstößt und die neu hinzugekommene Multisessionfähigkeit ebenfalls mit diesem Ziel verträglich ist, wenn ein immer definierter und voreingestellter Standardkontext eingerichtet wird.
Auch wenn sich das Informations- und Hilfesystem alleine aufgrund der Thematik an den professionellen Benutzer richtet, ist eine qualitativ hochwertige Unterstützung durch das System nur dann gegeben, wenn es jegliche Mühen bei der Benutzung vermeidet, da die Konzentration des Benutzers auf der eigentlichen Arbeit liegen soll. Die Verwendung des Informations- und Hilfesystems muß daher einfacher und insbesondere schneller sein, als der Griff zur Literatur.
Damit verbinden sich für eine maximale Benutzerfreundlichkeit folgende Teilziele:
Ein weiteres Element des Informations- und Hilfesystems, welches bei der Definition der Teilziele übersehen wurde, hat den Eingang in das Projekt erst nach der Fertigstellung gefunden, und soll daher an dieser Stelle nicht unerwähnt bleiben. Es handelt sich hierbei um die Suche nach Themen (topics) und Volltextsuche. Themen sind hierbei jeweils die Inhalte der Klassenbibliothek und damit die definierten ADTs mit ihren Implementationen und Operationen.
Gliederung der Projektphasen
Projektmanagement und -planung
Anforderungen
VDM Class Library