|
|
4 Fazit
In Anbetracht der Vielzahl relevanter Themenbereiche im Zusammenhang mit der Entwicklung Datenbankbasierter Webanwendungen bleiben auch mit Abschluß dieser prototypischen Entwicklung einige Aspekte unreflektiert wie beispielsweise Sicherheitsbetrachtungen und BLOB-Handling (Binary Large Objects, Datentyp zum Speichern von Binärdaten wie z.B. Grafiken oder Sounddateien), um nur zwei zu nennen. Dennoch wurde eine Vielzahl wichtiger Punkte besprochen und es ist eine Grundlage geschaffen, auf der weiterführende Problematiken erarbeitet werden können.
Für die Weiterentwicklung der Hyperlinkdatenbank gibt es eine Reihe denkbarer Erweiterungen. Beispielsweise sollte die Ergebnismenge bei Formularrecherchen begrenzt oder auf mehrere Seiten verteilt werden. Sinnvoll wäre die Möglichkeit, daß auch der Benutzer neue Linkeinträge vorschlagen kann, die dann von einem Administrator nur noch überprüft und ggf. freigeschaltet werden müßten. Damit würden sich auch höhere Anforderungen an das Sicherheitssystem und die Verwaltung von Schreib- und Leserechten für die Datenbank ergeben. Das Verwaltungstool könnte zusätzliche Funktionen zum Verschieben ganzer Themenbaumstränge zu anderen Oberthemen erhalten. Außerdem würde die Trennung von Stadt und Land bei der Erfassung und Bearbeitung von Hyperlinks das Userinterface verbessern. Darüberhinaus könnten die Klicks auf die Hyperlinkeinträge registriert und in der Datenbank gespeichert werden. In Verbindung mit entsprechenden Auswertungsfunktionen im Verwaltungstool könnten somit interessante Informationen z.B. für das Marketing gewonnen werden und für den Benutzer beispielsweise eine "Top-Ten-Liste" der meistbesuchten Sites angeboten werden.
Bei der Architektur der Web-Datenbank-Gateways ist ein deutlicher Trend hin zu Lösungen mit Applikationsservern zu verzeichnen, da diese Architektur die gößte Flexibilität bei der Hard- und Softwarekonfiguration bietet und eine optimale Skalierbarkeit gewährleistet ist. I.d.R. werden Dispatcher für die beiden wichtigsten Server-APIs von Netscape und Microsoft sowie eine CGI-Version angeboten, so daß Kompatibilität zu allen Standardservern gewährleistet ist, und trotzdem maximale Performance mit geeigneten Servern erzielt werden kann. Ein gutes Beispiel für diese Entwicklung ist Oracle mit seinem "Oracle WebServer": Die erste Version war ein klassischer proprietärer Web-Server, der quasi als HTTP-fähiger Oracle-Client konzipiert war. Die aktuelle Version 2.0 basiert mittlerweile auf einer Applikationsserver-Architektur, die allerdings noch immer ausschließlich mit dem eigenen Oracle WebServer zusammenarbeitet. Die neue Version 2.1 liefert nun auch Web Dispatcher für Netscape-Server (via NSAPI) und Microsoft-Server (via ISAPI). Die angekündigte Version 3.0 soll auf CORBA basierende verteilte Anwendungen und weitere Programmierschnittstellen ermöglichen.
Eine noch sehr junge, aber vielversprechende Entwicklung, die in dieser Arbeit nicht mehr berücksichtigt werden konnte, nennt sich "FastCGI" von OpenMarket, Inc. Dabei handelt es sich um eine Kombination von CGI mit der Applikationsserver-Architektur, d.h. das CGI-Programm bleibt resistent im Speicher und wartet auf Requests vom Server via FastCGI-Protokoll. Versprochen wird API-Performance unter Beibehaltung aller CGI-Vorteile wie Verwendung beliebiger Programmiersprachen und Prozeßisolation. Darüberhinaus ist diese Architektur durch Verwendung des FastCGI-Protokolls über TCP-Verbindungen skalierbar und bestehende CGI-Programme können mit minimalen Änderungen als FastCGI-Applikationen eingesetzt werden. Neben den Open Market-Servern wird FastCGI bereits von Apache und NCSA unterstützt und entsprechende Erweiterungen für die Microsoft- und Netscape-Server sind angekündigt, so daß sich FastCGI u.U. als alternative Quasi-Standard-API zu proprietären Server-APIs durchsetzen könnte. Informationen zum aktuellen Entwicklungsstand von FastCGI sind unter [W29] verfügbar.
