Abbildung: Auswahltabelle des Informations- und Hilfesystems
VDM Serverclient
Implementierung
Distributed-Processing
Der VDM Datenbank Server vdmd arbeitet auf Basis von RPCs. Grundsätzlich könnte jede Prozedur des Servers aufgerufen werden oder auch auf Ebene 0 Kommandos abgesetzt werden. Der VDM Server Client dbmc ruft lediglich beim Direktzugriff im Online-Modus Kommandos auf der untersten Ebene auf, und verwendet ansonsten nur Funktionen, die eigens zur Lösung seines Problems erstellt wurden.
Die konkreten Prozeduren des Servers, die vom VDM Client aufgerufen werden sind:
Eine Fernwartung mit TELNET als auch die direkte Eingabe von Kommandos für den VDM Server, wäre nicht möglich, wenn eine Serverschleife existieren würde, wie sie unter [*] abgebildet is. Es hatte sich insbesondere bei Test und Entwicklung als außerordentlich ärgerlich erwiesen, Kommandos nicht direkt am Server eingeben und damit auch nicht über die globale Variable errorInfo Fehler diagnostizieren zu können.
Daher wurde mit dem bereits beschriebenen TCL-Befehl fconfigure eine Ereignisprozedur für den Deskriptor der Standardeingabe stdin definiert, die Eingaben aufnimmt und mittels uplevel auf Ebene 0 ausführt. Auch nicht abgeschlossene Kommandos, oder Zeilen, die mit einem Backslash verlängert werden, werden verarbeitet. Damit präsentiert sich der Server wie eine interaktiv ausgeführte TCL-Shell.
Dies ist auch die Vorraussetzung für die Fernwartung, da Standardeingabe, -ausgabe und Fehlerausgabe sonst zwar an den fernen Host übertragen wären, dieser aber ebenfalls keine Kommandos ausführen könnte.
Server müssen in der Lage sein eine Vielzahl von Klienten (Clients) zu bedienen. Wenn sich zwei Kunden des Server gleichzeitig dazu entschließen, auf gleiche Ressourcen zurückzugreifen, muß der Server in der Lage sein, auch solche Konfliktsituationen zu verarbeiten. Die Lösung dieser Probleme liegt in der Regel in der Verwendung von Sperren oder von Warteschlangen oder in einer Kombination aus beidem. Die Warteschlange ist eine Alternative zum bloßen Zurückweisung.
Die Verarbeitung von Mehrfachzugriffen bietet viele Möglichkeiten einer Optimierung. Die bekannteste ist das Multi-Thread Verfahren, in dem sämtliche Klient-Anforderungen in eine Warteschlange eingereiht, und asynchron mit der günstigsten Bearbeitungsfolge ausgeführt werden(*). Viele Datenbanksysteme beispielsweise, optimieren in diesem Zusammenhang mengenorientierte Anfragen und optimieren diese oder lösen diese vor der Bearbeitung auf.
Einzelne Aufgaben der Klienten werden so weit als möglich in weitere Abschnitte unterteilt. Der kleinste nicht mehr teilbare selbständige Aufgabenabschnitt mit der Eigenschaft, reentrant und beliebig oft aufgerufen zu werden, wird als Thread bezeichnet und läßt sich treffend mit Nadelöhr übersetzten. Auf Mehrprozessormaschinen werden Threads zur optimalen Auslastung durch den Dispatcher-Task verteilt.
Der Server des Informations- und Hilfesystems wurde mit Single-Thread Verarbeitung konzipiert, obwohl die Möglichkeit eines Multi-Thread Servers durchaus bestand. Die Gründe, die zu diesem Enschluß geführt haben, setzten sich zum einen aus dem Problem zusammen, daß die VDM Datenbank im Arbeitsspeicher vorgehalten wird und bei Erzeugung von Kindprozessen kopiert wird und zum anderen aus der Eigenschaft von TCL, Anfragen über das Netzwerk solange als Ereignisse (events) in einer Warteschlange einzureihen, bis ein Befehl zur Abarbeitung von Ereignissen den TCL-Interpreter erreicht.
Die Schaffung von pseudo-preemptiven Multitasking in TCL durch Einfügen dieses ,,update``-Befehls(*) an unterschiedlichen Stellen hätte einen Deadlock in der Ereignis-Verarbeitung mit sich gebracht, da die Bearbeitung eines Ereignisse, daß bearbeitet wird, nach der Ausführung von update in der Ereignisfunktion selbst dafür gesorgt hätte, daß das nächste Ereignis in der Warteschlange ausgeführt, und das aktuelle nie zuendegebracht würde.
Eine Hochprachenimplementierung und Einbettung einer solchen Funktionalität in die TCL-Shell wurde als nicht sinnvoll erachtet, da immerhin die Möglichkeit besteht, daß in Nachfolgeversion von TCL 7.5 die Fortsetzung von Ereignissen implementiert wird, und diese Schwachstelle damit beseitigt ist. Eine Funktion zum Neueinreihen von Ereignissen in die Warteschlange von TCL wäre hierzu völlig ausreichend.
Der Entschluß, Single-Thread Verarbeitung zu wählen, stellte sich insbesondere bei der Implementierung der VDM Anwendungsbeispiele als richtig heraus, denn sobald die Generierung eines VDM Beispieles gestartet wird, kann vor der Beendigung parallel hierzu keine erneute Erzeugung gleichen Beispiels gestartet wird. Ferner sind Deadlocks durch gegenseitige Blockierungen ausgeschlossen. Nachteilig zeigt sich diese Methode jedoch bei der Volltextsuche in der Datenbank, wo bei großem Suchumfang der Server für längere Zeit blockiert sein kann.
Transaktionen (transactions) sind eine Sammlung von Verarbeitungsschritten, die entweder vollständig, oder gar nicht durchgeführt werden. Die Ausführung einer Transaktion wird als Atomaktion bezeichnet. Üblicherweise wird vom Klienten eine Folge von Befehlen abgesetzt, und zum Schluß die Transaktion abgeschlossen. Anschließend ist es Sache des Servers diese Atomaktion ohne Unterbrechung des Clients auszuführen. Wenn der Client sich entschließt, die Operation abzubrechen, etwas schiefgeht, oder die Klientverbindung zwischenzeitlich abgebrochen ist, wird die Atomaktion nicht ausgeführt, und damit keine der enthaltenen Aktionen.
Bei der Implementierung des VDM Servers des Informations- und Hilfesystems werden Transaktionen zwar unterstützt, jedoch aufgrund der Eigenschaften von TCL nicht vollständig. Transaktionen werden in der Regel dadurch vollzogen, daß eine Kopie des veränderten Objektes gezogen, und anhand dieser der Originalzustand wiederhergestellt werden kann (rollback). Transaktionen wurden im VDM Server mit Hilfe des TCL-Befehls ,,catch`` implementiert, welcher den TCL-Interpreter rekursiv mit gleicher TCL-Umgebung aufruft und dort spezifizierte Kommandos ausführt, alle Änderungen bei Auftreten eines Fehler verwirft oder ansonsten die Inhalte des rekursiv aufgerufenen Interpreters an den Aufrufer-Interpreter überträgt.
Nicht verworfen werden können durch den ,,catch``-Befehl alle Objekte, die sich auf Betriebsmittel, beziehen, oder in Hochsprachenmodulen in der TCL-Shell eingebettet sind. So kann verständlicherweise das Anfügen oder Löschen einer Datei genausowendig rückgängig gemacht werden, wie Veränderungen, die in eingebetteten Hochsprachen durchgeführt werden, obwohl sich dies hier durchaus durch ausschließliche Verwendung von Variablen des TCL-Interpreters über die Schnittstellenfunktionen von TCL realisieren ließe.
Das Transaktionskonzept ist insofern im VDM Server integriert, als daß alle Anfragen über Remote-Procedure Calls (RPCs) ausgeführt, und diese vor der Ausführung vollständig in Textform übermittelt werden. Als RPC kann an den Datenbankserver nicht nur ein einzelner, sondern auch mehrere oder eine ganzer Verarbeitungsblock von Befehlen übergeben werden. TCL-Befehle, welche die VDM Datenbank betreffen und diese verändern sind entweder der letzte oder einzige Befehl, der als RPC vom Server bearbeitet wird. Die sichere Ausführung von Atomaktionen und damit korrekte Transaktionsbearbeitung ist damit durch den VDM Server gegeben.
Das implementierte RPC-System setzt, bevor es die zur Bearbeitung von RPCs definierte Callback-Funktion aufruft eine globale Variable mit dem Namen rpcFile, die von außerordentlicher Bedeutung ist. Da alle Clientzugriffe ereignisgesteuert ablaufen, und lediglich ein Ereignis zur Zeit bearbeitet wird, ist dies ohne weiteres möglich.
Die Variable rpcFile wird auf den TCL-Kanal gesetzt, über welchen der RPC empfangen wurde. Funktionen des Servers, die über RPCs ausgelöst werden, kennen durch Zugriff auf diese Variable ihren Klienten. Beide Partner könnten, was jedoch konzeptionell unerwünscht ist, direkt über dieses socket kommunizieren. rpcFile enthält Werte wie sock4 oder sock7.
Für den Benutzeragenten, der die Verarbeitung der Threads durchführt, ist lediglich die Nummer die in rpcFile enthalten ist interessant, denn sie erlaubt die eindeutige Identifizierung der Verbindung, und wird zur Einstellung des Kontext verwendet.
Der Client meldet sich beim Benutzeragenten durch Ausführung des RPC-Kommandos
agent_Connect
an, und erhält seine Sitzungsnummer als Ergebnis. Gleichzeitigt wird auch der Kontext des Benutzers eingerichtet. Das Abmelden erfolgt über das RPC Kommando
agent_Disconnect
Wird die Verbindung nicht durch den Klienten ordnungsgemäß geschlossen, und bricht diese ab, meldet der Server den Klienten selbsttätig mit der Funktion agent_DisconnectInternal ab, wobei die Sitzungsnummer explizit übergeben und der Kontext gelöscht wird. Der Selbstätige Abmeldevorgang wird durch eine Umleitung des close Kommando eingeleitet(*).
Jeweils dann, wenn über die Funktion
agent_Call <command;command;...>
ein Befehl oder eine Befehlsfolge an den Benutzeragenten abgesetzt wird, erfolgt eine Auswertung von rpcFile und das Setzen des richtigen Kontext. Anschließend wird das Kommando auf Ebenen 0 des Datenbankmanagers ausgeführt, oder, wenn ein externer Datenprozeß definiert ist, an diesen weitergeleitet und dort bearbeitet. Lediglich die Fehler, die durch im Bereich (skope) des Benutzersagenten liegen, werden an den Klient mit dem Hinweis übermittelt, das der Benutzeragent fehlgeschlagen ist. Damit ist ferner eine genaue Eingrenzung für die Fehlersuche gegeben.
Die Benutzeroberfläche des Hypertext Informations- und Hilfesystems wird durch HTML Datenströme definiert. Die tatsächliche optische Wiedergabe ist hiermit jedoch nicht festgelegt, es handelt sich vielmehr um eine ausgabeunabhängige Definition von Text und graphischen Elementen, dessen Wiedergabe vom jeweiligen HTML-Browser abhängig ist.
Während Textbrowser lediglich zur Wiedergabe von Zeichen in der Lage sind, lassen beispielsweise die Browser Navigator und Explorer der namhaften Hersteller Netscape und Microsoft unter Verwendung geeigneter Erweiterungen die Wiedergabe von Filmen und anderen multimedialen Ereignissen zu. HTML wird in dieser Hinsicht fast jeder Browserform gerecht, es läßt sich für Bilder bereits bei der Definition ein alternativer Text festlegen. Hier liegt ein wesentlicher Unterschied von HTML zu anderen Definitionssprachen wie Postscript, dessen Merkmal die ausgabeunabhängig identische Wiedergabe ist. Der entscheidende Vorteil von HTML liegt dagegen in der kompakten Form, welche mit wenigen Textelementen ansprechende Formatierungen zuläßt.
HTML läßt eine begrenzte und überschaubare Anzahl von Gestaltungsmöglichkeiten zu, hierzu zählen im wesentlichen Text, Schriftgrößen und Bilder, aus welchen durch eine Verknüpfung mit einem URL der Hypertext entsteht. Ferner sind ,,forms`` genannte Formatanweisungen definiert, welche blätterbare Listen, Wahlfehler und die Eingabe von Text durch den Anwender zulassen.
Ein entscheidener Nachteil der Verwendung von Formatanweisungen wird durch die Vorschrift bestimmt, durch Anwahl eines Knopfes, die Formate zu bestätigen um diese an den Web-Server zu versenden. Diese Restriktion verhindert bei interaktiven Eingaben eine benutzerfreundliche Gestaltung und macht derart gestaltete Oberflächen in der Regel immer dort zur Makulatur, wo mehrfach Daten vom Benutzer eingefordert werden, da es diesen zwingt, jede Eingabe zusätzlich zu bestätigen. Nach ersten Ansätzen der Gestaltung der Benutzerschnittstelle durch Formatanweisungen, wurde dies verworfen und nunmehr ausschließlich mit direkten Hypertext-Referenzen gearbeitet.
Die Heimatseite (homepage) des Systems stellt eine HTML-Tabelle dar, welche für die geordnete Darstellung der Inhalte der Klassenbibliothek eine optimale Gestaltung ermöglicht. Über diesen Ausgangspunkt des Informations- und Hilfesystems sind zum einen die Inhalte der Bibliothek direkt erreichbar als auch Optionen einstellbar, welche die Steuerung des Systems ermöglichen als auch eine Hilfe. Über diese Hilfe können nicht nur allgemeine Fragen zur Bedienung geklärt werden, sondern es bietet sich auch die Möglichkeit an, direkt in den Hyptertext als auch zu den VDM Anwendungsbeispielen zu verzweigen.
Abbildung: Auswahltabelle des Informations- und Hilfesystems
Anhand der Tabelleninhalte selektierter Hypertext zu einem ADT der Klassenbibliothek, wird, in Abhängigkeit von der jeweiligen Einstellung, unterhalb oder überhalb der Tabelle angezeigt. Sofern der Hyptertext über der Tabelle angezigt wird, läßt sich ferner festlegen, ob regelmäßig selbsttätig eine Positionierung auf der Tabelle selbst vorgenommen werden soll. Abbild [*] zeigt die Auswahltabelle, die gleichzeitig die Heimatseite des Informations- und Hilfesystems ist.
Die ADTs der Klassenbibliothek verfügen vielfach über eine große Anzahl von Operatoren. Da der Platz des Browserfensters naturgemäß beschränkt ist, muß dieser bei Darstellung der Auswahltabelle so optimal wie möglich genutzt werden, um ein Blättern des Benutzers nach Möglichkeit zu vermeiden. Für die Einstellung der Anzeigeoptionen ist der Benutzer jedoch selbst zuständig, da dem Server die Größe des Browserfensters nicht bekannt ist.
Der Benutzer kann mit Hilfe der Optionen Enlarge, Reduce oder dem Setup einen Wert für die optimale Darstellung festlegen, der als Tabellenspaltenbreite bezeichnet wird. Als CGI-Parameter cols wird dieser Wert beständig von Seite zu Seite beibehalten. Der Algorithmus, der die optimale Tabellenanordnung der dreispaltigen Tabelle vornimmt, ist wie folgt:
Gegeben:
cols: Tabellenanordnung
nAdt: Anzahl der Adts in der Liste
nImpl: Anzahl der Implementationen in der Liste
nOper: Anzahl der Operationen in der Liste
Gesucht:
cols1, cols2, cols3: Optimale Breiten der Listen
Algorithmus:
fit(l,n) = (l+n-1)/n
n1 = fit(nAdt,cols)
n2 = fit(nImpl,cols)
n3 = fit(nOper,cols)
cols1 = fit(nAdt,
cols2 = fit(nImpl,
cols3 = fit(nOper,
= max(n1,n2,n3)
) ) )
Anhand der ermittelten Werte für cols1, col2 und cols3 werden Tags und Inhalt der HTML-Tabelle angeordnet.
Abbildung: Der Regelkreis der Seitenerzeugung
Die Benutzerschnittstelle für das Hypertext Informations- und Hilfesystem besteht aus einzelnen Seiten, die immerfort neu erzeugt und auf dem Browser, mit dem der Anwender arbeitet, angezeigt werden. Jeder Hyperlink löst die Produktion einer neuen Seite aus. Die vollständige Funktionsweise dieses Vorgangs wird durch Abbild [*] wiedergegeben.
Der VDM Server kann bei der Produktion dieser Seiten als nichtdeterministischer Automat angesehen werden, dessen vielfältigen Zustände jedoch insbesondere von den Inhalten der Klassenbibliothek als auch dem Umfang der Beispiele vorgegeben werden.
Der Kreislauf der mit der Anwahl einer URL beginnt, und mit der neuerstellten HTML-Seite endet, zeigt auch, an welcher Stelle im Konzept der MIME-Decoder als auch das VDM Tester anzusiedeln sind. Dieser Rückkopplungsprozeß anhand der Parameter, die der URL angefügt sind, entspricht der Spezifikation die unter [*] vorgenommen wurde.
Die Komplexität zeigt, daß das HTTP-Protokoll, zu dem auch die CGI-Funktionalität zählt, zur Gestaltung von interaktiven Oberflächen trotz seiner großen Verbreitung eher ungeeignet ist. Auch das HTML-Format zeichnet sich mehr durch Schlichtheit als durch Funktionalität aus, auch wenn es aufgrund der außerordentlichen Zuwachsraten im WWW zum verbreitetsten Standard geworden ist.
Die Unzulänglichkeiten werden beständig durch neue standartisierte Tags beseitigt oder durch Firmenstandards behoben, wie beispielsweise Netscape-Enhanced, der auch vom erbittersten Konkurrenten übernommen worden ist. Die neuesten Entwicklungen in dieser Richtung sind derzeit Java, Java-Skript als auch neue und verbesserte Formate forms, die insbesondere auf den ausschließlichen Einsatz von Web-Browsern für die gesamte Datenverarbeitung von Unternehmen abzielen, und mit Hilfe neuer Wortschöpfungen wie ,,Intranet`` vermarket werden(*)
VDM Serverclient
Implementierung
Distributed-Processing
VDM Class Library