Universität Leipzig, Institut für Informatik
Abteilung Datenbanken

Leiter: Prof.Dr.E.Rahm

Problemseminar

Datenbankeinsatz im Internet

 

Anbindungstechniken zwischen
WWW und DBS

 

Bearbeiter: Philipp Sturm, Betreuer: Th.Stöhr

27.April 1999

Anmerkung zur HTML-Version:

1. Einleitung *

    1.1 WWW-Grundlagen *

    1.2 Wichtige Begriffe *

2 Nutzung von DB-Konzepten im WWW *

    2.1 Beispiel: Strudel *

3 Web-DB Anwendungen *

    3.1 Anwendungsklassifikation *

4 Web-DB Anbindungsarchitekturen *

    4.1 Überblick *

    4.2 Server-orientierte Architektur *

        4.2.1 CGI-Programmierung *

        4.2.2 API-Lösungen *

        4.2.3 Server-Side-Includes *

        4.2.4 Weitere Verfahren *

        4.2.5 Realisierung von Zuständen *

        4.2.6 Allgemeine Bewertung Server-orientierter Architektur *

    4.3 Client-orientierte Architektur *

        4.3.1 Abgrenzung zur Server-orientierten Architektur *

        4.3.2 JDBC *

        4.3.3 SQLJ *

    4.4 Zusammenfassung der Architekturentwicklung *

5 Zusammenfassung *

6 Literaturverzeichnis *

1. Einleitung

Diese Arbeit entstand nach einem einführenden Referat während eines Problemseminars zum Thema "Datenbankeinsatz im Internet" unter der Leitung von Prof.Dr.E.Rahm an der Universität Leipzig im Sommersemester 1999.

Inwiefern Datenbankkonzepte im Internet angewandt werden können, soll einführend in Kapitel 2 erläutert werden.

Typische Anwendungsbeispiele für DB-Anbindungen im World Wide Web (WWW) werden in Kapitel 3 vorgestellt.

Der Schwerpunkt liegt in Kapitel 4: Hier werden Techniken zur Anbindung bestehender Datenbanken an das WWW diskutiert.

Im Verlauf des Seminars folgen vertiefende Referate zu mehreren Themen, die in diesem Vortrag nur angesprochen werden, wie z.B. den Datenbankzugriff mit Java mit SQLJ/JDBC.

1.1 WWW-Grundlagen

Das Internet in seiner technischen Grundform existiert schon seit den 60er Jahren. Ursprünglich vom US-Militär geplant und als ARPA-Net realisiert, begann die wissenschaftliche und damit zivile Nutzung etwa zehn Jahre später. Markant für das Internet war die fehlende zentrale Kontrolle. Der Verbund einzelner Rechner zu Netzen führte zu einem schnellen Wachstum des Internets. Rechnernetze wurden im Verbund mit anderen Netzen zu Subnetzen. Der Ausfall eines Rechners oder eines Netzes führte demnach nicht zum Ausfall des "gesamten" Internets. Die technische Basis dieser Plattform-unabhängigen Rechnerkommunikation regelt seit Anbeginn das Protokoll TCP/IP.
Das WWW ist ein "jüngerer" Dienst im Internet. Davor gab es bereits zahlreiche Dienste, wie beispielsweise FTP, für den einfachen Austausch von Dateien von Computer zu Computer, Telnet, für den Zugriff auf andere Rechner über einen lokalen Computer, Gopher oder NetNews.
Heute werden die Begriffe WWW und Internet oftmals synonym verwandt, da das WWW aufgrund seiner einfachen Handhabung mittlerweile der populärste Dienst im Internet ist. Die Grundlage dafür bildet die HTML (Hyper Text Markup Language). Über das Protokoll HTTP können HTML-Dokumente sowie darin referenzierte multimediale Objekte, wie Bilder und Videos, ausgetauscht werden.

1.2 Wichtige Begriffe

Folgend soll die Bedeutung der Begriffe Website, Server und database erklärt werden, wie sie in dieser Arbeit verwendet werden.

Website: soll der lokalen Verbund von HTML-Dokumenten (eventuell als Web-Seiten benannt) genannt werden. Lokal heißt, sie befinden sich unter einer domain.

Server: Als Server werden sowohl Rechner als auch Programme bezeichnet, welche Server-Dienste anbieten. So könnten ein WWW-Server und ein DB-Server zwei Rechner sein, die ausschließlich Server-Dienste anbieten. Beide Server-Programme können aber auch auf einem Computer laufen.

database: Der Begriff database ist in der amerikanischen Literatur weiter gefaßt als in der deutschen. Eine database ist nicht unbedingt gleich einem Datenbanksystem. Auch eine Sammlung von Dateien wird database genannt.

 

2. Nutzung von DB-Konzepten im WWW

Henry F.Korth und Abraham Silberschatz beschreiben in [KS96] die "information explosion". Damit gemeint ist die Fülle an Informationen, die immer einfacher in digitaler Form publiziert werden. Dadurch entstand im WWW eine mittlerweile unüberschaubare Menge an Dokumenten, die vorwiegend als Dateien auf verschiedenen Rechnern verteilt existieren.

Auf dem Gebiet der Datenbanksysteme hat die Forschung bereits langjährige Erfahrungen im Management großer Datenbestände sammeln können, wobei die erarbeiteten Konzepte zur Lösung aktueller Probleme des "information management" WWW beitragen können. (vgl. [FLM98])

Neben Datenbankeigenschaften, wie Datensicherheit und hoher Zugriffsgeschwindigkeit, können typische DBS-Eigenschaften zur Vermeidung von Redundanzen und Inkonsistenzen sowie zur Sicherung referentieller Integrität genutzt werden. (beispielsweise für die Konsistenzwahrung für Links)

Nach [FLM98] kann man die Nutzung von DB-Konzepten wie folgt klassifizieren:

1. "Modelling and querying the web":

Stünden im WWW Query-Systeme zur Verfügung, wie sie z.B. aus dem Bereich der relationalen DBS bekannt sind, so könnten diese detailliertere Anfragemöglichkeiten als heutige Suchmaschinen im WWW zulassen. Systeme, die deklarative Suchanfragen zulassen, könnten auch Strukturinformationen der Seiten verarbeiten, z.B: "finde alle Seiten, die das Wort Clinton neben einem Bild oder einem link zu einem Bild enthalten". Gegenüber klassischen Query-Sprachen müssen diese mit unbekannten Datentypen, z.B. Bild, Ton, strukturierten - und unstrukturtierten Daten, sowie mit semistrukturierten Daten arbeiten können. An einem Beispiel aus [FLM98] soll ein Eindruck einer solchen Anfragesprache vermittelt werden:

SELECT d.url, e.url, a.label
FROM Document d SUCH THAT
"www.mysite.start"->* d,
Document e SUCH THAT d => e,
Anchor a SUCH THAT a.base = d.url
WHERE a.href = e.url

Diese WebSQL-Anfrage soll uns ein Tripel der Form (d1,d2,label) liefern, wobei d1 ein lokal gespeichertes Dokument ist, welches über einen link "label" auf ein nicht-lokales Dokument d2 zeigt. Die Variable d bindet dabei alle Dokumente, die, ausgehend von der Startseite www.mysite.start, lokal (->) erreichbar sind. Dokumente auf anderen Servern (=>), die direkt über d erreichbar sind, werden in e, alle links in den Dokumenten d werden in a gebunden.
Eine Beschreibung und Vergleich existierender Web-orientierter Query-Sprachen, wie WebSQL, W3OS, WebLog, Lorel, WebOQL, Strudel, Arneus und Florid, liefert [FLM98].
An dieser Stelle sei auch auf einen Vortrag zum Thema "Deklarative Web-Abfrage-Sprachen" im Rahmen dieses Seminars verwiesen.

2."Information extraction and integration":

Aufgabe von "Web-Informationsintegrationssystemen" könnte es sein nach einer Anfrage auf verschiedene Datenquellen im WWW zuzugreifen. Dazu wurde bereits know-how im Bereich heterogener Datenbanksysteme gesammelt, beispielsweise beim Einsatz von wrapper-Programmen, die einen einheitlichen Zugriff auf verschiedene Datenquellen unterstützen.

3."Web site construction and restructuring":

Systeme dieser Art "erstellen" Websites aus Rohdaten, die in Datenbanken oder in Dateien gehalten werden können, bzw. strukturieren existierende Websites um. Diese Techniken könnten vor allem bei der Wartung einer Website unterstützend wirken, so z.B. bei der Konsitenzwahrung von links oder dem Erstellen verschiedener Versionen einer Website. Ein System dieser Art wird im nächsten Abschnitt kurz vorgestellt. "Wenn das DBS bespielsweise einen benutzerdefinierten Datentyp HTML oder XML integrieren kann, können vielfältige Aufgaben der Speicherung, Indexierung und Aufbereitung von Web-Seiten sowie der lokalen Konsistenzkontrolle von Hyperlinks an das DBS delegiert werden" [HR99, S.539]

4. Einbindung von DB-Inhalten in eine Website:

d.h. die Einbindung von DB-Inhalten in eine Seite. Derartige WWW-Anbindungen von Datenbanken gestatten einerseits den Zugriff auf Datenbanken über das WWW, wobei der Browser als Benutzerschnittstelle (siehe [BE96] S.44) dient, andererseits können die Inhalte einer Website in einer DB gespeichert werden, wobei das HTML-Dokument zum Zeitpunkt der Anfrage erstellt wird. Vorteile ergeben sich vor allem aus der erleichterten Verwaltung und Aktualisierung der Website-Inhalte, der Mehrbenutzerfähigkeit bei Inhaltsänderungen und dem geringeren Datenumfang. Möglichkeiten der WWW-DB-Koppelung werden in Kapitel 4 beschrieben.

2.1 Beispiel: Strudel

Strudel ist ein Website Management-System, welches den Zugriff auf mehrere Datenquellen und die Verwaltung von Inhalt und Struktur einer Website organisiert.
Die folgende Grafik soll die Architektur des Systems darstellen.


Abb. -1 Abbildung nach [UW99], [FFK+98]

Die Rohdaten einer Website können in externen Quellen verteilt liegen. (Datenbanken, Dateien) Wrapper-Programme vereinheitlichen den Zugriff auf diese. Der Site-builder generiert aus einer deklarativen Anfrage in StruQL einen site graph , welcher Inhalt und Struktur definiert. Der Strudel-eigene HTML-Generator erzeugt eine Website, die mit einem HTML-Browser betrachtet werden kann.

 

3. Web-DB Anwendungen

3.1 Anwendungsklassifikation

    In [LO98] arbeitet Loeser typische DB-Anwendungen im WWW heraus. In der folgenden Tabelle sind diese Anwendungen aufgeführt, wobei diese als typische Vertreter für eine Klasse von Anwendungen stehen. In der rechten Spalte wird jeder Anwendungstyp in Bezug auf seine DB-Interaktion beschrieben, auch dabei wurde auf die Charakterisierung von Loeser zurückgegriffen. Er hat dafür folgende Kriterien zur Systematisierung gewählt:

     

    Anwendung

    Charakteristika/Systemanforderungen
    Adressdatenbank

    Der Nutzer kann seine Adresse dem Server übermitteln, um z.B. Informationsmaterial zu bestellen.

    		 Vorwiegend schreibender Zugriff mit kurzer Verweildauer.
    Elektronisches Gästebuch

    Name, Adresse und eine Bemerkung des Nutzers werden gespeichert. Es soll in den eingegebenen Kommentaren gesucht und "geblättert" werden können.

    		 Durch das Blättern sind häufige, kurze, meist lesende Zugriffe typisch. Ein gleichzeitiger Zugriff kann häufig auftreten.
    Online-Tracking

    Nach Eingabe der Bestellnummer kann sich der Nutzer über über der Transportzustand seiner Lieferung erkundigen.

    		Viele Benutzer greifen auf einen großen dynamischen, d.h. sich ständig ändernden Datenbestand zu. Es ist eine Authentifizierung des Benutzers sowie ein Schutz des Backend-Systems vor Manipulation nötig.
    Online-News

    Der Nutzer kann ausführliche Artikel zu Schlagzeilen anfordern, bzw. in einem Archiv älterer Artikel recherchieren. Oftmals wird zwischen einem öffentlich zugänglichen Bereich und einem kostenpflichtigen Bereich unterschieden.

    		 Der Zugriff auf Online-News erfolgt häufig gleichzeitig und lesend. Es liegt hohe Datenaktualität vor. Die Art der Daten beschränkt sich nicht auf Text, sondern kann auch in multimedialer Form, z.B. als Bild, Ton oder Video vorliegen. Eine Authentifizierung der Nutzer kann notwendig sein, falls z.B. kostenpflichtige Informationen vertrieben werden, wobei Benutzeridentifikation für Nutzer-relevante Informationsvermittlung von Bedeutung sein kann.
    Nachschlagewerk (Katalog)

    Diese Anwendungen bieten dem Benutzer die Möglichkeit in großen Datenmengen zu suchen und die Ausgabe alphabetisch oder thematisch zu sortieren. Beispiele hierfür sind Telefonbücher, Branchenverzeichnisse, Lexika, usw.

    		 Bei Katalogen ist ein gleichzeitiger Zugriff von vielen Benutzern zu erwarten. Die Datenaktualität ist dabei im Allgemeinen mit "gering" einzustufen, die Datenüberlappung kann, abhängig von der konkreten Anwendung, hoch sein. Die Daten können sowohl alphanumerisch als auch multimedial, z.B. bei Lexika, sein.
    Bestellkatalog

    Basierend auf der vorangehenden Anwendung kann der Benutzer z.B. in einem Warenkatalog Produkte markieren und ein einem "Warenkorb" sammeln. Anschließend soll einen Warenbestellung über das WWW ausgelöst werden.

    		 Im Gegensatz zu Nachschlagewerken, unterstützen Bestellkataloge den schreibenden Zugriff, z.B. bei der Bestellung, aber auch um einen Warenkorb zu führen, ist es notwendig, Informationen auf dem Server zu halten. Sicherheitsbedarf, Verweildauer und Sitzungslänge sind mit "mittel" bis "hoch" einzustufen.
    Online-Banking

    Der Kunde kann seine Bankgeschäfte über das Internet führen, z.B. den Kontostand abfragen, Überweisungen auslösen oder Wertpapiergeschäfte tätigen. Zur Authentisierung des Kunden besondere Sicherheitsvorkehrungen nötig.

    		 Kennzeichnend für diese Systeme ist der hohe Sicherheitsbedarf, einerseits bei der Abschirmung des Backend-Systems andererseits während der Datenübertragung. Eine Benutzeridentifikation ist aus diesen Gründen notwendig.
    Web-fähige Geschäftsanwendung

    Der Nutzer kann auf Geschäftsanwendungen, z.B. zur Autragsbearbeitung, über den Browser zugreifen. Typisch dabei sind Mehrschrittvorgänge mit Benutzerinteraktion. Die Nutzung im Intranet ist ebenfalls kennzeichnend.

    		 Eine Klassifizierung für diesen Anwendungstyp ist nicht eindeutig möglich, da die Anwendungensarten stark variieren können. Zu erwarten sind hohe Sitzungslängen und eine lange Verweildauer sowie hohe Sicherheitsanforderungen, z.B. bei der Abschirmung des Backend-Systems.

4. Web-DB Anbindungsarchitekturen

In diesem Abschnitt sollen Architekturen vorgestellt werden, die den Zugriff auf DBS über das WWW ermöglichen. Besonderes Augenmerk soll der Charakterisierung der Konzepte sowie deren Vor- und Nachteilen gewidmet werden.

4.1 Überblick

Ein Kriterium zur Klassifizierung von Web-DB-Anbindungsarchitekturen ist, zwischen Server-seitigen und Client-seitigen DB-Anbindungen zu unterscheiden, da diese sich paradigmatisch abgrenzen. Server-seitige DB-Anbindungen basieren auf dem HTTP-Protokoll, einem "stateless protocol", d.h. Verbindungen zwischen Client und Server bestehen nur während der Übertragung des Dokuments. Mehrschritt-Interaktionen zwischen Datenbank und Client können daher nicht direkt stattfinden.

Dies stellt sich anders bei den Client-orientierte Anbindungsarchitekturen dar: hierbei kann eine in den

Abb. 4-1 nach [LO98]

Client geladene Applikation, z.B. ein Java-Applet, selbstständig mit dem Datenbank-Server kommunizieren. Dieses Client-Server-Verfahren kann unabhängig vom HTTP arbeiten, verliert damit aber auch den der Vorteil der Einfachheit des HTTP. Anhand folgender schematischer Darstellung nach [LO98] einer WWW-Anfrage soll zuerst ein Überblick über Server-orientierte DB-Anbindungsarchitekturen, dann über Client-orientierte-Konzepte skizziert werden.

Ein WWW-Server liefert dem anfragenden Client über das HTTP-Protokoll HTML-Seiten mit statischen Inhalt, inklusive der darin gebundenen Elemente, wie Grafiken oder Java-Applets. (siehe WWW-Grundlagen). Die Anforderung kann von Proxy-Servern beantwortet werden, die statische Informationen, z.B. Bilder, puffern, um Übertragungszeiten zu verkürzen. HTML-Seiten, die der Client geliefert bekommt, sind dann das "Endergebnis" der Anfrage und können mit einem HTML-Browser dargestellt werden (siehe dazu Punkt 1,2 in Abb.4-1). Diese Seiten sind inhaltlich statisch, können aber zusätzlich mit dynamischen Komponenten angereichert sein, welche Benutzerinteraktionen erlauben, die mit HTML nicht möglich sind. Dynamisches HTML kann beispielsweise mit JavaSkript, VisualBasic sowie JSkript erzeugt werden.

Über die Art der Anfrage erkennt der WWW-Server, ob er vor der Beantwortung der Anfrage (request) CGI-Programme (Punkt 3), Server-Erweiterungen oder Java-Servlets (Punkt 8) starten muß. Diese Erweiterungen können dann ihrerseits in Verbindung mit einem angegliederten DB-Server treten, um Anfragen durchzuführen und deren Ergebnisse in das angeforderte Dokument zu integrieren. Der DB-Server liefert Anwendungsdaten, welche durch die in Punkt 3 und 8 beschriebenen Techniken erst in HTML-Seiten integriert werden, er kann aber auch komplette HTML-Dokumente liefern.

Liefert der WWW-Server dem Client eine Java-Applet, so kann dieses eine eigenständige sekundäre Netzwerkverbindung zum DB-Server herstellen (Punkt 5). Dies kann entweder direkt oder über einen Anwendungsserver geschehen (Punkt 6,7). Dabei ensteht das oben genannte Client-Server-Szenario. Das HTTP wurde lediglich zum Übertragen des Applets genutzt. Das Applet ist nun für die Anwendungslogik sowie für die Präsentationslogik der Daten verantwortlich.

 

4.2 Server-orientierte Architektur

4.2.1 CGI-Programmierung

    CGI (Common Gateway Interface) ist eine Schnittstelle für die Kommunikation zwischen WWW-Servern und Anwendungsprogrammen auf dem Webserver. Das CGI übergibt Benutzer-eingaben aus Formularen einem Anwendungsprogramm, das in einer beliebigen, serverseitig unterstützten Programmier- oder Skriptsprache implementiert ist (z.B. Perl, Shell-Skripte, C/C++). Dieses Programm wird als Prozeß auf dem Server gestartet und kann nun als DB-Client auf Datenbanken zugreifen oder z.B. Berechnungen vornehmen.

    Der WWW-Server erwartet ein HTML-Dokument, welches das vom CGI aufgerufene Programm dynamisch erzeugt. Nachdem der WWW-Server das Dokument vom CGI-Programm erhalten hat, wird es wieder an den Client geschickt.

    "Ein CGI-Gateway realisiert den einfachsten Übergang zwischen einem WWW-Server und einer Datenbank. Die Datenbank ist eben eine Datenquelle, aus der durch eine einzige Anfrage eine Menge von Daten geholt, für die Ausgabe nach HTML formatiert und dem Browser zugeschickt werden. Änderungen der Anfragen entsprechen eigenständigen Anfragen" (GB98)

    Die folgende Abbildung aus [LO98] zeigt den Auszug eines Perl-Programmes, welches als CGI-Programm einen Datenbankzugriff vornimmt und anschließend die Ergebnisse in HTML zurückgibt.

    Abb. 4-2 nach Loeser [LO98] CGI-Programmierung

    Eine Charakterisierung der CGI-Kopplung sowie eine Bewertung dieses Ansatzes über die Vor- und Nachteile soll analog zu dem von Benn und Gringer entwickeltem Schema vorgenommen werden.

    Dabei sollen zunächst die Kriterien erkläutert werden:

    Verbindung: Beschreibt die Art der Verbindung zwischen Client, WWW-Server und DB-Server.

    Transaktionen, Sitzung: Kennzeichnet die Art von DB-Transaktionen hinsichtlich ihrer Länge und der Kooperation mit dem Client. Während einer Sitzung kann der Benutzer beispielsweise Transaktionen auslösen, wobei die Verbindung zum Client verlorengeht, sobald die Sitzung geschlossen ist. Hierbei tritt das Problem auf, den Anwendungskontext des Klienten, d.h. seinen Zustand, zu sichern.

    Serverlogik, Anwendungslogik, Präsentationslogik: Die Serverlogik liegt in der Regel beim DBS selbst und ist damit anwendungsunabhängig. Sie stellt die eigentliche DBS-Funktionalität bereit. In den Bereich der Anwendungslogik fallen die Verarbeitung, Verknüpfung und Interpretation der Daten für den Benutzer. Die Darstellung der Daten (eventuell grafisch) obliegt der Präsentationslogik. Dabei können über HTML Daten lediglich in alphanumerischer Form dargestellt werden, hingegen Client-seitige Datenverarbeitung, z.B. in Java, erlaubt die grafische Interpretation der Daten, z.B. in geometrischer Form oder als Diagramm. (Hierbei soll von der Server-seitigen grafischen Verarbeitung von Daten als statische Grafik abgesehen werden)

    Verbindungen
    • Anschluß an DB als DB-Klient
    Transaktionen, Sitzungen
    • kein Konzept zwischen Klient und WWW-Server (jede Anfrage ist eine Transaktion)
    • Problem der Realisierung von Zuständen
    • Steuerung der DB über Funktionen der DB-Bibliothek
    Serverlogik
    • keine: reiner DB-Klient
    Anwendungslogik
    • ein Vorgang ist modelliert in Aufbau und Abfolge von Dokumenten
    • vollständig im CGI-Programm festgelegt
    Präsentationslogik
    • HTML
    • Verknüpfung der HTML-Oberflächenelemente mit den Datentypen im CGI fixiert
    • Dokument wir durch Abarbeitung der Ausgabebefehle im CGI-Programm erstellt
    • Eingabebereich kann nicht mit Anwendungslogik kombiniert werden

    Vorteile:

    Nachteile:

4.2.2 API-Lösungen

    Application Programming Interfaces (APIs) integrieren das CGI-Konzept in den WWW-Server. Ähnlich dem Prinzip der Dynamic Link Libraries (DLL) werden funktionale Erweiterungen zur Laufzeit in den WWW-Server eingebunden. Dadurch wird verhindert, daß wie bei CGI-Programmen, ein eigener Prozeß gestartet werden muß. Diese Erweiterungen sind gegenüber CGI-Programmen funktional nicht eingeschränkt. Auch Datenbankzugriffe sind über diese Funktionen realisierbar.

    Der WWW-Server muß anhand der URL entscheiden, ob für die Abarbeitung der Client-Anfrage eine Erweiterungsfunktion aufgerufen werden muß. Dieser Aufruf geschieht als prozeßinterner Funktionsaufruf, wodurch ein Performance-Gewinn gegenüber der CGI-Lösung erreicht wird. Ein weiterer Vorteil ist, daß Servererweiterungen nach der HTTP-Verbindung nicht wie CGI-Prozesse terminiert werden und somit weiterlaufen können. Damit können DB-Verbindungen permanent offen gehalten werden.

    Verbindungen
    • Anschluß zum Server über gemeinsamen Adressraum
    • Anschluß an DB als DB-Klient

    Transaktionen, Sitzungen
    • WWW-Server kann Kontext des Klienten erhalten
    • Sitzungen können durch beständige Verbindung zwischen WWW-Server und DB offengehalten werden

    Serverlogik
    • Keine: reiner DB-Klient

    Anwendungslogik
    • kann in nutzereigene Funktionen integriert werden

    Präsentationslogik
    • HTML

     

    Vorteile :

    Nachteile:

    Etabliert haben sich die Internet Server API von Microsoft (ISAPI) sowie die Netscape Server API (NSAPI) von Netscape, wobei beide untereinander nicht kompatibel sind.

    Als Beispiel für eine WWW-Server API sei Sybase web.sql genannt. Web.sql gibt ist für die NSAPI, ist aber auch als CGI-Variante, allerdings mit niedriger Performance, erhältlich. Die web.sql-Erweiterung im WWW-Server ermöglicht den Zugriff auf Sybase-Datenbanken, indem es <SYB> Container-Elemente in HTML-Dateien erkennt, die darin eingeschlossenen DB-Anweisungen verarbeitet und anschließend das Ergebnis der DB-Anfrage anstelle des <SYB> Containers einfügt. (siehe [BE96])

     

4.2.3 Server-Side-Includes

    Wie auch die Server-APIs sollen Server-Side-Includes (SSI) die Serverfunktionalität erweitern. Dazu wurden spezielle Steuerbefehle in den HTML-Syntax integriert, die vom Server ausgewertet werden.

    Loeser [LO98] bezeichnet die Microsoft Active Server Pages (ASP) als derzeit mächtigste Form der SSI. Als Steuerbefehle kann VisualBasic oder JSkript Server-seitig ausgeführt werden. Datenbankzugriffe können über die Server-seitig ausgeführten Skriptsprachen mit ODBC realisiert werden. SQL kann dynamisch in eine ASP-unterstützte Skriptsprache eingebettet und das Anfrageergebnis zeilenweise ausgewertet werden.

    Wie auch die API sind sie SSI abhängig vom Serversystem. Die ASP sind in den Microsoft Internet Information Server ab Version 3 integriert.

    Andere SSI müssen für den DB-Zugriff in der Regel auf Mechanismen von CGI und Server-Erweiterungen zurückgreifen und sind daher mit diesen vergleichbar. (vgl. [LO98])

    Im Abschnitt zur CGI-Programmierung wurde ein Verfahren zur Integration der Anfrageergebnisse in HTML beschrieben, bei dem die HTML mit den Ergebnissen durch die Ausgabe des CGI-Programmes ensteht. An dieser Stelle sei auf zwei weitere Möglichkeiten der Integration von Anfragen und Anfrageergebnissen in HTML verwiesen.

    Zum einen ist es möglich DB-Anweisungen in Makrodateien abzulegen und die Anfrageergebnisse in eine HTML-Schablone einzubetten. Dabei muß die HTML der Schablone die erweiternden Makro-Befehle zur Integration der Ergebnismenge unterstützen.

    Dieses Verfahren bietet u.a. dem Vorteil, daß SQL-Anweisungen (im Beispiel in der idc-Datei) mehrfach genutzt werden können.

    Abb. 4.2.3 aus Benn, Gringer [GB98] Integration über Makro-Dateien

    Eine weitere Möglichkeit besteht in der Integration von DB-Anweisungen in einer HTML-Maske. Nachteilig wirkt sich dabei aus, daß eine derartige Vermischung von DB-Anweisungen, Visual-Basic und HTML schnell zur Unübersichtlichkeit führen kann.

     

4.2.4 Weitere Verfahren

    Die Java-Servlet API wurde als Java-Pendant zu den oben beschriebenen APIs entwickelt. Sie ist im Vergleich zur Microsoft und Netscape API unabhängig von der Browserplattform. Voraussetzung ist eine installierte Java Virtual Machine (JVM) im Web-Server.

    Vorteile:

4.2.5 Realisierung von Zuständen

    Wie schon in 4.1 erwähnt, ist das HTTP kein zustandsorientiertes Protokoll, d.h. eine Verbindung zwischen Browser und WWW-Server besteht nur, solange das HTTP bearbeitet wird. DB-Clients, welche durch CGI-Programme oder Server-API aufgerufen wurden, unterliegen ebenso dieser zeitlichen Beschränkung. Für kontextabhängige Mehrschritt-Arbeitsgänge, wie z.B. das Führen eines Warenkorbs oder eine gestaffelte Ergebnisausgabe ist es notwendig, den Kontext (Zustand) des Clients serverseitig zu speichern. Da diese Funktionalität für WWW-Anwendungen von großer Bedeutung ist, sollen zwei verbreitete Realisierungsvarianten kurz vorgestellt werden:

    Die Vorteile dieser Variante liegen in der Unabhängigkeit von Browsertyp bzw. der Browserkonfiguration.
    Nachteilig wirkt sich aus, daß die Dokumente, welche eine zugewiesene Benutzerkennung in Form einer Formularvarible enthalten, dynamisch erzeugt werden müssen, wodurch der Server stärker belastet wird. Zudem müssen alle Folgeaktionen die Formularvariable weiterführen, z.B. wenn die Seite eine Auswahl mehrerer links bietet, könnte es notwendig sein, die Benutzerkennung an alle "Verzweigungen" weiterzugeben.

    Vorteil: Der cookie wird automatisch vom Client an den Server geschickt, wodurch dieser entlastet wird und die Entwicklung von Anwendungen, im Gegensatz zur vorhergehenden Variante. vereinfacht wird.

    Nachteil: Cookies werden von älteren Browsern nicht unterstützt und können vom Benutzer durch entsprechende Browser-Konfiguration, verweigert werden.

     

4.2.6 Allgemeine Bewertung Server-orientierter Architektur

    Verbindungen zwischen Client und WWW-Server bestehen nur für die Zeit der HTTP-Anfragebearbeitung. Daher können Mehrschritt-Arbeitsgänge sowie die Realisierung von Zuständen nur über Zusatzmaßnahmen erreicht werden, wie sie im vorangegangenen Abschnitt erwähnt wurden. Weiterhin kostet der Neustart von CGI-Prozessen und das Wiedereröffnen von DB-Verbindungen Ressourcen und führt daher zu Performanceverlusten.

    Der Vorteil der HTTP-basierten Architekturen liegt in den einfachen HTML-Gestaltungsmöglichkeiten für die Datenrepräsentation, und darin, daß kleine Anwendungen schnell entwickelt werden können. Aufgrund des breiten Spektrums bereits vorhandener WWW-DB-Anwendungen, kann hier auf einen großen Erfahrungsschatz zurückgegriffen werden.

     

4.3. Client-orientierte Architektur

4.3.1 Abgrenzung zur Server-orientierten Architektur

    Durch die Entwicklung von Java und ActiveX kann Anwendungslogik auf die Client-Seite übertragen werden. Java-Applets werden als Plattform-unabhängiger Bytecode zum Client übertragen und dort mit Hilfe einer Java Virtual Machine (JVM) ausgeführt. Die Ausführung von Java-Applets unterliegt dabei bestimmten Restriktionen. Netzwerkverbindungen dürfen nur zum "Quell - Server" eröffnet werden, ein Zugriff auf lokale Ressourcen ist nicht erlaubt. (ActiveX basiert auf einer anderen, Microsoft-spezifischen Architektur und unterliegt diesen Restriktionen nicht).

    Primäre Unterschiede gegenüber der Server-orientierten Architektur sind dabei:

    1. Ein Datenbankzugriff kann über eine eigene Verbindung realisiert werden. Der Zugriff des Applets auf die DB ist dabei über JDBC sowie SQLJ möglich. Der WWW-Server ist nur noch für das Übertragen des Applets zuständig.
    2. Anwendungslogik und Präsentationslogik werden Client-Seitig unterstützt. Der Web-Client erwartet kein HTML, sondern verarbeitet die ihm direkt übertragenen Daten selbst und kann diese beliebig visualisieren. (z.B. grafische Darstellung)
    3. Zur Eingabevalidierung und Verarbeitung der Daten aus einer Datenbank steht die volle Funktionalität einer Programmiersprache zur Verfügung
    4. Die DB-Verbindung kann über die gesamte Laufzeit der Anwendung offen gehalten werden. Somit können Zustände gespeichert und "lange", voneinander abhängige, Transaktionen durchgeführt werden. Mehrschritt-Interaktionen, die über das HTTP-Protokoll nur über Umwege realisierbar waren, sind direkt realisierbar.

    Die aufgeführte Abgrenzung zur Server-orientierten Architektur zeigt im wesentlichen die Vorteile dieses Ansatzes.

    Nachteilig wirkt sich aus, daß die Benutzerschnittstelle sowie die Präsentation der Daten in Java bzw. in einer anderen Sprache implementiert werden müssen. Dabei verliert man den Vorteil der einfachen Gestaltungs- und Strukturierungsmöglichkeiten in HTML, welche auch durch zahlreiche Tools unterstützt werden.

    Die Verlagerung der Anwendungslogik auf die Client-Seite wirkt sich insofern nachteilig aus, da 1) Know-How (Code) freigegeben wird und 2) die Netzwerkbelastung durch den Transport großer Applets, sogenannter fat Clients, erhöht wird.

    Neuentwicklungen des JDK ermöglichen eine Netzwerkentlastung kann durch den Einsatz von Java Archiven (JAR). Dabei werden alle Anwendungsklassen, die sonst sukzesive geladen werden, in komprimierter und kompakter Form übertragen. Eine weitere Möglichkeit besteht im Einsatz signierter Applets. Diese können persistent beim Client gespeichert werden, ohne jeweils neu geladen werden zu müssen.

    Verbindungen
    • Applikation-WWW-Server: keine Verbindung nötig
    • Applikation-DB-Server: z.B. JDBC

    Transaktionen, Sitzungen
    • Transaktionen bis zur Dauer einer DB-Sitzung

    Serverlogik
    • Abhängig vom Paradigma der Programmiersprache und dem Datenmodell der Datenbank

    Anwendungslogik
    • kann vollständig in der Anwendung oder im Application-Server implementiert sein

    Präsentationslogik
    • freie Gestaltungsmöglichkeit für Präsentation der Daten

    Vorteile:

    Nachteile:

    Im folgenden werden zwei Realisierungsmöglichkeiten des Client-seitigen DB-Zugriffs genannt. Es sei an dieser Stelle darauf verwiesen, daß ausführliche Arbeiten zu diesen beiden Realisierungsvarianten im Rahmen des Problemseminars folgen.

     

4.3.2 JDBC

    Die DB-Schnittstelle JDBC (Java DataBase Connectivity) wurde in Anlehnung an ODBC (Open DataBase Connectivity) entwickelt und mit einer ähnlichen Klassenbibliothek ausgestattet. Die DB-Kommunikation erfolgt über ein Call Level Interface (CLI).

    Die JDBC Treiber werden dabei erst zur Laufzeit geladen. SQL-Anfragen werden dynamisch eingebettet und Ergebnisse können zeilenweise weiterverarbeitet werden.

    Vorteile:

    Nachteil:

     

4.3.3 SQLJ

    Im Gegensatz zu JDBC ist für SQLJ ein Präprozessor nötig. D.h. SQL-Statements müssen bereits zum Zeitpunkt der Kompilierung feststehen (statisches SQL). Die Ergebnisstruktur ist dadurch festgelegt, wobei mit einem Iterator (als Objekt der Wirtssprache) das Ergebnis verarbeitet werden kann. Die Rückgabewerte können über ihre Spaltennamen angesprochen werden.

    Vorteile:

    Nachteil:

     

4.4 Zusammenfassung der Architekturentwicklung

5. Zusammenfassung

    Mit dieser Arbeit wurde versucht, einen Einblick in die Möglichkeiten der Nutzung von Datenbankkonzepten im WWW zu geben. Die vorgestellten Anbindungsverfahren können hinsichtlich der aufgeführten Kriterien gewertet werden, pauschal kann allerdings kein Verfahren favorisiert werden. Die Entscheidung für den Einsatz einer Technologie muß abhängig von der Anwendung gefällt werden. In [HR99] konstatieren Härder und Rahm das für HTTP-basierte Anbindungsarchitekturen vorhandene breite Spektrum von Anwendungen im WWW. Wegen der Einfachheit von HTML sind Standardanwendungen sowie kleinere Applikationen schnell zu entwickeln. "Für Anwendungen mit besonderen Anforderungen hinsichtlich Sicherheit, Kommunikation und grafischer Interaktion können Applet-basierte Lösungen herangezogen werden, die wegen ihrer Java-Nutzung für Client-seitige Datenaufbereitung, Benutzerinteraktion und Kommunikation flexiblere Möglichkeiten bieten. Außerdem stehen in Java mit JDBC und SQLJ "genormte" DB-Schnittstellen zur Verfügung." [HR99, S.540]

 

6. Literaturverzeichnis