|
|
2.1.1 Komponenten und Schnittstellen
Zusätzlich zu den Komponenten HTTP-Server und Web-Browser einer "herkömmlichen" Web-Site benötigt man für die Anbindung einer Datenbank zusätzlich einen Datenbankserver und ein Gateway-Programm, das die Verbindung zwischen HTTP- und Datenbankserver schafft.
Dadurch ergeben sich für die Entwicklung eines solchen Gateways zwei Schnittstellen, die überbrückt werden müssen, um eine Kommunikation zwischen Web-Browser und Datenbank zu ermöglichen: zum HTTP-Server und zur Datenbank. Die programmiertechnische Realisierung dieser beiden Schnittstellen hat entscheidenden Einfluß auf die Performance der Datenbankanbindung und die Kompatibilität bzw. Portabilität des Gateways.
Die Realisierung eines solchen Gateways bedarf des Einsatzes sehr grundlegender, nicht trivialer Techniken aus so unterschiedlichen Bereichen wie Netzwerkkommunikation, Datenbankprotokolle, Internettechnologien und Sicherheitssysteme. Eine technisch optimale Realisierung ist keine triviale Aufgabe. Aus diesem Grunde einerseits, und der Breite des Anwendungsfeldes datenbankbasierter Webangebote andererseits, ist es sinnvoll, die Funktionalität des Gateways von der eigentlichen Entwicklung einer Web-Datenbank-Anwendung zu trennen. Dadurch ergibt sich für den Gateway-Entwickler die Notwendigkeit, dem Anwendungsentwickler eine Programmierschnittstelle zur Verfügung zu stellen.
Sie ist ebenfalls ein wichtiger Faktor für die Beurteilung eines Gateways. Entscheidende Kriterien sind Komplexität und Lernaufwand sowie Flexibiliät und Funktionsumfang. Daraus können kurze oder lange Entwicklungszeiten resultieren sowie Fragen nach Eignung bzw. Einsatzfähigkeit des Gateways für bestimmte Anwendungen.
Im folgenden werden die grundsätzlich unterschiedlichen Architekturen vorgestellt, die für die Realisierung eines Web-Datenbank-Gateways z.Zt. angewendet werden. Darüberhinaus gibt es sicherlich Abwandlungen oder Mischformen der hier gezeigten Modelle. In der Produktübersicht werden solche speziellen Varianten ggf. gesondert erwähnt.
Bei der Ausarbeitung der folgenden Abschnitte 2.1.2 bis 2.1.6 habe ich mich in erster Linie auf [W19] gestützt, diese Ausführungen allerdings vielfach durch eigene Überlegungen und Informationen aus anderen Quellen (viele White Papers unterschiedlicher Hersteller, z.B. [W20], [W21] und [W22]) ergänzt oder abgeändert. Für den Themenbereich Gatewayarchitekturen mit Java in Abschnitt 2.1.7 waren mir vor allem die Quellen [W14], [W15], [W16], [W17] und [W18] hilfreich.
2.1.2 CGI Executable
Auf die Funktionsweise des Common Gateway Interface muß an dieser Stelle nicht noch einmal eingegangen werden. Siehe hierzu Abschnitt 1.1.7 und [W6].
CGI ist als Bestandteil von HTML die älteste und am weitesten verbreitete Programmierschnittstelle für Web-Server und in jeder verfügbaren Serversoftware implementiert. Dies und die Tatsache, daß ein CGI-Programm in praktisch jeder beliebigen Programmiersprache erstellt werden kann, haben für die ernome Verbreitung von CGI-Gateways gesorgt.
Das CGI Executable war also die am einfachsten und am naheliegendsten zu realisierende Form eines Web-Datenbank-Gateways: Der Web-Server erhält einen Request, startet daraufhin das Gatewayprogramm und übergibt ihm die Variablen per CGI. Der Gateway wiederum baut eine Verbindung zur Datenbank auf, stellt eine Anfrage und erhält Ergebnisdaten zurück. Anschließend wird die Verbindung zur Datenbank wieder geschlossen, aus den Daten eine HTML-Seite generiert und diese an den Web-Server zurückgeliefert. Dieser gibt die HTML-Daten an den anfragenden Browser weiter, während das CGI-Programm beendet wird. Für jede weitere Anfrage wird der Gateway erneut gestartet und die beschriebene Prozedur durchgeführt.
Abbildung 4: Die CGI-Executable-Architektur
Vorteile
Nachteile
Fazit
Aufgrund der Einfachheit dieser Architektur gibt es eine unüberschaubare Vielzahl von entsprechenden Gateways, die oft sogar frei verfügbar oder gegen geringe Shareware-Gebühren nutzbar sind. Für kleine Anwendungen mit begrenzter Userzahl kann ein solches Gateway durchaus zufriedenstellende Ergebnisse liefern.
Technologisch entsprechen solche Gateways heute nicht mehr dem Stand der Dinge. Skalierbar ist eine Web-Datenbank-Anwendung mit einem solchen Gateway nur sehr begrenzt durch hardwaremäßige Aufrüstung des Hosts.
2.1.3 Applikationsserver
Um einige der Nachteile eines CGI Executables auszuräumen, kam man auf die Idee, den Gateway zu teilen, in einen sog. "Dispatcher" (auch "Stub", "Connector" oder "Agent" genannt) und einen Applikationsserver. Der Dispatcher ist ein CGI Executable. Er parst einen Request, stellt den zur Bearbeitung geeigneten Applikationsserver fest und leitet die Anfrage direkt an diesen weiter. Der Applikationsserver läuft als Dämon-Prozeß (unter Unix) bzw. als NT-Service (unter Windows NT), enthält die gesamte Applikationslogik und liefert die aus der Datenbank erhaltenen Ergebnisse in HTML-Form zurück.
Abbildung 5: Die Applikationsserver-Architektur
Die Vorteile des CGI Executables wie CGI-Konformität und eigener Adreßraum bleiben bei dieser Architektur voll erhalten, während zahlreiche gravierende Schwächen behoben werden.
Vorteile gegenüber CGI Executable
Außerdem eröffnet diese Architektur ein höheres Maß an Flexibilität. So können beispielsweise sowohl unterschiedliche Dispatcher auf den gleichen Applikationsserver zugreifen, als auch umgekehrt ein Dispatcher mehrere Appliaktionsserver bedienen. In Verbindung mit der Möglichkeit, Web-Server, Datenbank und Applikationsserver auf jeweils separaten Maschinen zu installieren, können selbst Anwendungen mit mehreren, verteilten Datenbanksystemen realisiert werden und eine maximale Skalierbarkeit ist gewährleistet.
Da bei der Applikationsserver-Architektur relativ viele Prozesse koordiniert werden müssen, um ein Request zu bearbeiten, kann sich dieser hohe Kommunikations-Overhead u.U. negativ auf die Performance auswirken.
2.1.4 Einsatz von Server APIs
Aufgrund der besprochenen Probleme von CGI haben die Hersteller von Web-Servern proprietäre Programmierschnittstellen (APIs) für ihre Produkte eingeführt, mit deren Hilfe es möglich ist, die Serverfunktionalität zu erweitern. Mit der API geschriebene Applikationen werden dynamisch in den Serverprozeß gelinkt, auf Windows-Plattformen als Dynamic Link Library (DLL) und unter Unix als Shared Object (SO). Tabelle 1 zeigt die z.Zt. populärsten APIs.
| API | Hersteller | Web-Server |
| NSAPI | Netscape | Fast Track Server, Enterprise Server |
| ISAPI | Microsoft | Internet Information Server |
| WSAPI | O’Reilley | WebSite Pro |
| Apache API | Apache Group | Apache |
Tabelle 1: Die verbreitetsten Web-Server-APIs
API-Programme teilen alle Resourcen mit dem Serverprozeß und können - im Gegensatz zu CGI - in jede Phase der Serveroperation von der Interpretation der URL über die Zugriffskontrolle bis zum Logging eingreifen.
Abgesehen von diesen zusätzlichen Möglichkeiten können Server-APIs durch den Wegfall des aufwendigen Prozeßmanagements auch als eine schnellere Alternative zu CGI für Web-Datenbank-Gateways verwendet werden. Das trifft für beide bisher besprochenen Gateway-Architekturen zu. Trotzdem gibt es einen Unterschied zu beiden Varianten, der es rechtfertigt, das API-Pendant zum CGI Executable als eigene "Server-API-Architektur" zu betrachten, wie sie in Abbildung 6 dargestellt ist:
Da der Gateway im Serverprozeß läuft, entfällt nicht nur das Starten und Beenden des Prozesses, sondern der Gateway kann auch eine Verbindung zur Datenbank aufrechterhalten, ein weiterer entscheidender Unterschied gegenüber dem CGI Executable.
Abbildung 6: Die Server-API-Architektur
Bisher gibt es keinen Standard für Web-Server-APIs, so daß ein API-basiertes Gateway den Applikationsentwickler auf einen bestimmten Web-Server festlegt. Inzwischen gibt es allerdings bereits Gateway-Produkte (vor allem in Applikationsserver-Architektur), die an mehrere APIs angepaßt sind, oder zusätzlich die langsamere, aber serverunabhängige CGI-Schnittstelle anbieten. Somit ist zumindest eine gewisse Portabilität gewährleistet.
Vorteile
Nachteile
2.1.5 Proprietäre Server
Aus der Sicht des DBMS ist ein Web-Datenbank-Gateway ein Datenbank-Client, der die Web-Technologie versteht. Man kann sich auch ein Datenbank-Clientprogramm vorstellen, das direkt das HTTP-Protokoll unterstützt. Dieses Clientprogramm kann somit als Web-Server gesehen werden, der für ein DBMS (oder eine "Middleware" zum DBMS) spezialisiert ist. In dieser Architektur ist die Fähigkeit zur Datenbankanbindung in den Web-Server eingebettet.
Abbildung 7: Proprietärer Web-Server mit integriertem Datenbankgateway
Die Performance-Charakteristik dieser Architektur ist der der Server-API-Architektur ähnlich. Auch die mangelnde Portabilität setzt sich hier fort, da diese Implementierung von einem bestimmten DBMS abhängig ist.
2.1.6 Browsererweiterung mit externem Viewer
Web-Browser können so konfiguriert werden, daß sie zur Präsentation bestimmter Datentypen, die sie nicht selbst darstellen können, externe Programme starten. So kann z.B. beim Laden eines MPEG-Videos automatisch ein MPEG-Player gestartet werden, der das Video darstellt.
Auf die gleiche Weise können vorhandene Datenbank-Clientprogramme als Viewer für Datenbankanwendungen konfiguriert werden. Diese Architektur kann durch einfache Konfiguration einer vorhandenen Datenbankapplikation, einem Web-Browser und dem Web-Server realisiert werden, ohne daß zusätzliche Programme geschrieben werden müssen. Das World Wide Web dient hierbei lediglich dazu, den Benutzer zur Applikation zu führen und diese zu starten.
Da diese Architektur im eigentlichen Sinne keine Softwareintegration darstellt, sondern im Wesentlichen eine Frage der Desktopkonfiguration zum Starten einer klassischen Client/Server-Anwendung ist, soll auf diesen Fall in dieser Arbeit nicht weiter eingegangen werden.
2.1.7 Gatewayarchitekturen mit Java
Java ist die Programmiersprache für interaktive, multimediale Anwendungen im World Wide Web. Ihrer herausragenden Bedeutung in diesem Umfeld muß auch im Zusammenhang mit Web-Datenbank-Gateways Rechnung getragen werden, weshalb ich ihr an dieser Stelle einen eigenen Abschnitt gewidmet habe. Allerdings betrachte ich Java nur in Zusammenhang mit der Architektur und Entwicklung von Gateways, und nicht als Programmiersprache für die Entwicklung von Web-Datenbank-Applikationen (vgl. Abschnitt 2.3.1).
Java ist von Sun Microsystems Inc. entwickelt worden und sollte ursprünglich für kleine Anwendungen im Bereich "Consumer Electronics", "Interactive TV" und "Settop Boxes" eingesetzt werden. Mit der rasanten Entwicklung des Word Wide Web in den letzten Jahren wurde Java seit 1994 als Programmiersprache für den Einsatz im Internet ausgerichtet [W11]. Java verwendet weitgehend die Syntax von C/C++ und realisiert wichtige Konzepte der Objektorientierung wie Informationskapselung, Polymorphie, Vererbung und Dynamisches Binden. Verzichtet wurde u.a. auf Zeigerarithmetik, Mehrfachvererbung, Präprozessoranweisungen, Überladung von Operatoren und automatische Typkonvertierung. Java verbindet die Ansätze interpretierter und compilierter Sprachen, indem zunächst der Quelltext in ein architekturunabhängiges Zwischenformat ("Java-Bytecode") compiliert wird und ein Interpreter diesen Bytecode in einer sog. "Java Virtual Machine" ausführt.
Java-Programme können mit Hilfe eines Java-Interpreters als eigenständige Applikationen ausgeführt werden, oder als sog. "Applets" mit einer HTML-Seite über das Netz geladen und in einem Java-fähigen Web-Browser (d.h. mit eingebauter Java-VM) ausgeführt werden.
2.1.7.1 Browsererweiterung mit Java
Java bietet mit in HTML-Seiten eingebetteten Applets die Möglichkeit, die Funktionalität eines (Java-fähigen) Web-Browsers dynamisch zu erweitern. Dies ist auch für Web-Datenbank-Anwendungen nutzbar und führt zu einer neuen Architektur, die sich grundlegend von den bisher vorgestellten unterscheidet.
Abbildung 8: Browsererweiterung mit Java-Applets
Die gesamte Applikationslogik ist in einem Java-Applet implementiert, das beim Aufruf einer bestimmten HTML-Seite automatisch auf den Clientrechner des Browsers geladen wird und sofort von der im Browser integrierten Java Virtual Machine gestartet und ausgeführt wird. Das Applet baut nun - unabhängig vom Web-Server - eine direkte Netzwerkverbindung mit dem Datenbankserver auf und kann mit diesem unmittelbar kommunizieren.
Eine grundlegende Neuerung dieser Architektur ist die Tatsache, daß die Applikationslogik zwar in Form des Applets zentral und pflegeleicht auf dem Server vorhanden ist (im Gegensatz zur klassischen C/S-Anwendung, wo jedes Software-Update mit Vertriebs- und Installationsaufwand verbunden ist), die Ausführung aber trotzdem auf dem Clientrechner stattfindet und den Server nicht belastet.
Weiterhin beachtenswert ist die Tatsache, daß die Benutzerschnittstelle nicht mehr in HTML erstellt wird, sondern im Applet mit Java realisiert wird. Dies erhöht die Möglichkeiten zur individuellen Gestaltung von User-Interfaces, ist aber aufwendiger als reine HTML-Programmierung.
Ein Nachteil ist die begrenzte Zahl gleichzeitiger Benutzer, da jeder Browser eine eigene Datenbankverbindung benötigt (vgl. Abschnitt 2.1.7.2.4). Je nach gewählter Implementierung des Datenbankzugriffs kann zusätzlich zum Applet nativer Code nötig sein, der unabhängig von der Webanwendung auf der Clientmaschine installiert werden muß. Vergleiche hierzu JDBC in Abschnitt 2.2.3.
2.1.7.2 Java auf Serverseite
Neben der im vorigen Abschnitt vorgestellten Java-spezifischen Architektur ist es auch möglich, Web-Datenbank-Gateways in Java zu programmieren, die auf einer der übrigen bereits erwähnten Architekturen basieren.
Im Gegensatz zur Clientseitigen Nutzung von Java, die mit dem Applet-Konzept und der Integration der Java-VM in den gängigen Web-Browsern bereits standardisiert und etabliert ist, ist der Einsatz von Java auf der Serverseite eine noch sehr junge Entwicklung, für die es mehrere unterschiedliche Ansätze gibt:
2.1.7.2.1 CGI-Programme in Java
O'Reilly & Associates, Inc. liefert mit Ihrem Web-Server WebSite Pro das "Server-Side Java SDK" für die Entwicklung und den Betrieb von Serverside Java-Applikationen aus [W16]. Die aktuelle Version 0.9beta basiert auf dem "Java Developer's Kit 1.0.2 für Win32" [W12] von Sun und der nicht standardisierten "Windows CGI 1.3 Spezifikation" [W7], enthält eine Klassenbibliothek zur Kapselung der CGI-Kommunikation und benötigt ein kleines ausführbares Programm, den sog. "Launcher", um eine Javaklasse im Interpreter zu starten. Diese Lösung ist nur auf Windowsplattformen und nur mit O’Reilly’s WebSite Pro Server lauffähig.
2.1.7.2.2 Integration der Java-VM im Web-Server
Netscape Communications Corp. hat die Java Virtual Machine direkt in seine Web-Server (Fast Track Server und Enterprise Server ab Version 2.0) integriert und bietet als Programmierschnittstelle ein "Object Frame Work" als Teil ihrer sog. "Netscape ONE"-Umgebung (Netscape Open Network Environment) an (vgl. [W23]).
2.1.7.2.3 Servererweiterung durch Java-"Servlets"
Sun Microsystems entwickelt den "Java Web Server", früher bekannt unter dem Namen "Jeeve", ein komplett in Java programmierter HTTP-Server [W14]. Diese Entwicklung beinhaltet ein Konzept namens "Java Servlet Architektur", die es mittels einer Servlet-API erlaubt, die Serverfunktionalität dynamisch durch Laden von sog. Servlets zu erweitern - entsprechend der Browsererweiterung durch Applets [W15].
Der Java Web Server befindet sich noch im Entwicklungsstadium (Stand Februar 1997: Version Alpha 2+; downloadbar unter [W14], alpha2/) und ist bisher der einzige, der die Servlet-API unterstützt. Netscape kooperiert allerdings mit Suns JavaSoft, um die Servlet-API ebenfalls in spätere Versionen ihres Enterprise Servers zu integrieren ([W17] 5. Abs).
2.1.7.2.4 Applikationsserver in Java
Eine weitere Javaspezifische Architektur hat Nick N. Duan auf der Fünften Internationalen World Wide Web Konferenz im Mai 1996 in Paris vorgestellt [W18]. Hierbei handelt es sich um eine Mischform der in Abschnitt 2.1.3 und Abschnitt 2.1.7.1 vorgestellten Architekturen:
Ein in Java programmierter Applikationsserver vermittelt zwischen den Anfragen von Java-Applets und dem Datenbankserver (siehe Abbildung 9). Dadurch erhöht sich einerseits die Skalierbarkeit des Systems, da die Zahl gleichzeitiger Benutzer nicht unmittelbar von der Anzahl der Datenbankverbindungen abhängt. Andererseits kann der Applikationsserver als Standalone-Java-Applikation auf vorhandene native Clientbibliotheken für die Datenbankanbindung zurückgreifen, was die Entwicklung des Gateways vereinfacht und die Größe des über das Netz zu ladenden Applets verringert.
Abbildung 9: Web-Datenbank-Gateway in Three-Tier-Architektur mit Java
