WWW-Server mit SQL-Funktionalität

Betrachtet man nur den Faktor Antwortzeit, stellt dieser Ansatz die optimale Lösung für die Anbindung eines WWW-Servers an eine relationale Datenbank dar. Der Zugriff auf die Datenbank erfolgt, wie in Abbildung dargestellt, direkt vom WWW-Server aus, ohne dabei ein externes Programm zu verwenden. Der HTTP-Server baut beim Start eine Verbindung zum Datenbank-Server auf und hält diese für alle weiteren Client-Anfragen aufrecht. Erhält der Server eine Anfrage eines Clients, generiert er daraus eine SQL-Anfrage und leitet sie direkt an den Datenbank-Server weiter. Im Gegensatz zu den anderen beiden Lösungen ist hier nur noch ein lokaler Prozeduraufruf notwendig, um die Daten zum Datenbank-Server zu transferieren. Da der Prozeßaufruf zum Start des externen Programms und der Verbindungsaufbau je Client-Anfrage entfallen, könnte man sich dadurch eine erhebliche Reduzierung der Antwortzeiten erhoffen. Da, wie schon erwähnt, die Antwortzeiten im WWW hauptsächlich von der Netzlast, den verfügbaren Übertragungsraten sowie der Auslastung der WWW-Server abhängig sind, ist fraglich, ob sich in der Realität der aus dieser Lösung enstandene Zeitvorteil auf die Antwortzeiten im WWW auswirkt.

  

Abbildung: WWW-Server mit SQL-Funktionalität

Derzeit gibt es Ansätze von CERN sowie von Netscape Communications, die diese Art von Datenbankzugriff erlauben. Am CERN wurde ein Prototyp eines WWW-Servers entwickelt, der als Source Code verfügbar ist und den eigenen Anforderungen entsprechend angepaßt werden kann. Netscape Communications bietet eine Server-API (NSAPI) an, mit der man die Netsite Server um die entsprechende Funktionalität erweitern kann.

Der große Nachteil dieser Lösung liegt darin, daß man an einen bestimmten WWW-Server gebunden ist. Da das WWW ein sehr junger Internet-Dienst ist, werden ständig neue Standards sowohl im Bereich der WWW-Server als auch im Bereich des HTTP-Protokolls entwickelt. In der Tat gibt es derzeit Bestrebungen [Spe95c], die darauf zielen, das HTTP-Protokoll im Bezug auf die Performance zu verbessern und neue Sicherheitsmechanismen zu integrieren. Hat man einmal einen WWW-Server um die SQL-Funktionalität erweitert, ist man an diesen gebunden, will man sich die Arbeit nicht erneut machen und einen neuen Server um eine derartige Funktionalität erweitern. Bei dem Standalone- sowie Client/Server-Gateway verhält es sich anders. Dort können die WWW-Server beliebig ausgetauscht werden, sofern sie dem CGI-Standard entsprechen. Da das CGI selbst ein standardisiertes Verfahren ist, ist davon auszugehen, daß auch zukünftige WWW-Server das CGI unterstützen.

Betrachtet man wie bei den anderen beiden Lösungsansätzen die möglichen Fehlerquellen, welche die Verfügbarkeit der Jahreswagenbörse einschränken könnten, kommen hierfür nur das Übertragungsmedium sowie der WWW-Server in Frage. Das Übertragungsmedium kann als Fehlerquelle ausgeschlossen werden, falls WWW-Server und Datenbank-Server auf der gleichen Maschine laufen. Fällt der WWW-Server aus, ist der gesamte Dienst WWW nicht mehr verfügbar.

Vorteile der Lösung:

• Kein Prozeßaufruf für externes Programm mehr notwendig
• Reduzierung der Antwortzeit durch direkte Kommunikation und permanente Verbindung zur Datenbank
• Geringe Komplexität
• Geringe Fehleranfälligkeit
• geringe Netz- und Systemlast durch direkte Kommunikation und weil kein Prozeßaufruf für externes Programm mehr notwendig ist

Nachteile:

• Der WWW-Server wird aufgebläht
• Blockierung des WWW-Servers für die Zeit der Anfrage an die Datenbank
• Erweiterung eines WWW-Servers ist nur möglich, wenn dessen Source Code verfügbar ist oder wenn der Hersteller eine API bereitstellt, über die der Server erweitert werden kann
• Bindung an den erweiterten WWW-Server