Client/Server-Gateway

Bei der Client/Server-Lösung erfolgt der Zugriff des externen Programms, das im Folgenden auch als JAWA-Client bezeichnet wird, indirekt über einen weiteren Prozess, den Connect-Daemon bzw. den JAWA-Server, der die Verbindung zur Datenbank hält (Abbildung ). Der JAWA-Client übermittelt die vom WWW-Server erhaltenen Daten an den JAWA-Server, der daraus dynamisch eine SQL-Anfrage aufbaut und diese an den Datenbank-Server weiterleitet. Nach der Verarbeitung der Anfrage durch den Datenbank-Server, schickt dieser die extrahierten Daten an den JAWA-Server zurück, der sie an den JAWA-Client weiterleitet. Nach Erhalt der Daten generiert der JAWA-Client daraus ein HTML-Dokument und schreibt es auf die Standardausgabe, von der es durch den WWW-Server an den Benutzer zurückgeschickt wird.

Um den JAWA-Client zu starten, ist wie bei dem Standalone-Gateway jeweils ein lokaler Prozeßaufruf notwendig, Für die Interprozesskommunikation zwischen JAWA-Client und JAWA-Server ist ein Mechanismus zu verwenden, der entweder auf Remote Procedure Calls (RPCs), Unix-Sockets, Shared Memory oder auf einem Batch-System basiert. Kommen JAWA-Client und JAWA-Server auf unterschiedlichen Maschinen bzw. Systemumgebungen zum Einsatz, müssen die zu transferierenden Daten vor der Übertragung serialisiert bzw. in ein einheitliches Datenrepräsentationsmodell umgewandelt werden. Um weitere Anfragen von JAWA-Clients zwischenspeichern zu können, muß der JAWA-Server einen Warteschlangenmechanismus implementieren, da er während der Bearbeitungsphase für alle weiteren Anfragen blockiert ist.

  

Abbildung: Client/Server-Gateway

Beim Start des JAWA-Servers wird eine Verbindung zum Datenbank-Server aufgebaut und für alle weiteren Transaktionen aufrecht erhalten. Im Vergleich zum Standalone-Gateway hätte dies primär betrachet eine Verkürzung der Antwortzeiten zur Folge. Da durch die Blockierung des JAWA-Servers Wartezeiten für andere JAWA-Clients entstehen und weil die Antwortzeiten im WWW hauptsächlich von der Netzlast, den verfügbaren Übertragungsraten sowie der Auslastung der WWW-Server abhängen, kann der durch die Client/Server-Architektur erlangte Zeitvorteil vernachlässigt werden. Der gewonnene Zeitvorteil wird weiterhin durch zusätzlichen Bearbeitungsaufwand im JAWA-Client und JAWA-Server sowie durch die Zeit, die für die Interprozesskommunikation in Anspruch genommen wird, geschmälert.

Betrachtet man die möglichen Fehlerquellen, die den Betrieb des Informationsdienstes JAWA beeinflussen könnten, wird man feststellen, daß bei dieser Gateway-Architektur neben dem Übertragungsmedium und dem JAWA-Client nun auch der JAWA-Server und der Kommunikationsmechanismus zwischen JAWA-Client und -Server als Fehlerquellen in Frage kommen. Das Übertragungsmedium kann als Fehlerquelle ausgeschlossen werden, wenn sowohl WWW-Server und JAWA-Client als auch JAWA-Server und Datenbank-Server auf der gleichen Maschine laufen. Tritt ein Fehler im JAWA-Client bzw. während der Kommunikation zwischen Client und Server auf, kann dies durch den Client festgestellt und an den Benutzer weitergeleitet werden. Dieser kann daraufhin seine Anfrage an den Datenbank-Server wiederholen. Bei einem Ausfall des JAWA-Servers, der nicht immer sofort erkannt und behoben werden kann sowie bei einem Ausfall der Maschine, auf dem der Server läuft, ist die gesamte Jahreswagenbörse nicht mehr verfügbar. Um in diesem Fall die Verfügbarkeit der Anwendung möglichst hoch zu halten, wäre es denkbar einen weiteren Server-Prozess bereitzustellen, der die Verfügbarkeit des JAWA-Servers überprüft und im Fehlerfall die zuständige Person alarmiert.

Eine weitere Alternative wäre der Einsatz mehrerer JAWA-Server (Pool von JAWA-Server), die über eine Art ,,Directory-Server`` verwaltet werden. Der Directory-Server überprüft ständig die Verfügbarkeit der JAWA-Server und weist den anfragenden JAWA-Clients den JAWA-Server zu, der gerade verfügbar ist. Damit könnte auch das Problem der Wartezeiten der JAWA-Clients bei Blockierung des JAWA-Servers gelöst werden.

Diese Ansätze könnten zwar angewandt werden, um die in der Lösung auftretenden Fehlerquellen zu minimieren, sie würden aber zugleich die Komplexität des gesamten Systems erhöhen und eine Implementierung wesentlich erschweren. Auch würde dadurch der Zeitgewinn, den man sich durch den Einsatz der Client/Server-Architektur erhofft hat, weiterhin geschmälert.

Die höhere Komplexität des Systems und die aufwendigere Implementierung würden zugleich eine höhere Fehleranfälligkeit als beim Standalone-Gateway bedeuten. Kommt beim Standalone-Gateway nur das CGI-Skript als Fehlerquelle in Frage, können beim Client/Server-Gateway sowohl Fehler im JAWA-Client und -Server als auch Fehler während der Interprozesskommunikation zwischen beiden Partnern auftreten. Werden zwischen JAWA-Server und -Client beispielsweise Unix-Sockets als Kommunikationsmechanismus eingesetzt, könnten zum Beispiel während der Serialisierung der Daten Fehler auftreten, die eine Kommunikation unterbrechen würden.

Vorteile des Client/Server-Gateways:

• Reduzierung der Antwortzeiten gegenüber Standalone-Gateway, die aus oben genannten Gründen in der Realität jedoch fraglich sein wird

Nachteile:

• Ein lokaler Prozessaufruf je Client-Anfrage
• Höhere Fehleranfälligkeit als Standalone-Gateway
• Hohe Komplexität der Anwendung und somit aufwendigere Implementierung als bei Standalone-Gateway