Internet-Datenbanken
Historie des WWW
•
Grundlage Internet
– Entwickelt Ende der 60er Jahre vom US-Militär (ARPA-Net) – Technische Basis: TCP/IP-Protokoll
•
WWW
– 1990 Projekt World Wide Web am CERN Genf entwickelt (Berners-Lee) zur Verbesserung der internen
Informationsdarstellung
– Idee: Verknüpfung von HTML-Dokumenten und Integration bisheriger Internet-Dienste über einheitliche Adressen (URL, Uniform Recource Locator) unter einer gemeinsamen
Oberfläche, dem Web Browser
•
HTML
– Hypertext Markup Language
– Text ist mit Sprachkommandos versehen, eingeschlossen in Start Tag und End Tag
HTML Beispiel
<HTML><BODY>
Fiction:
<UL><LI>Author: Milan Kundera</LI?
<LI>Title: Identity</LI>
<LI>Published: 1998</LI>
</UL>
Science:
<UL><LI>Author: Richard Feynman</LI>
<LI>Title: The Character of Physical Law</LI>
<LI>Hardcover</LI>
</UL></BODY></HTML>
Bereitstellung von Daten durch das Web
•
Nicht nur statische Informationen darstellen!
•
Nutzung des Common Gateway Interface (CGI)
– Aufruf von Programmen auf einem Web-Server mittels HTTP, die dynamisch HTML-Seiten generieren und an den Web-Browser zurückliefern
•
Einführung von Java (1995; SUN Microsystems)
– Implementierung von Java Applets: können von einem Web- Server geladen und im Browser ausgeführt werden
(plattformunabhängiger Bytecode)
– Einbindung von Java Applets in HTML-Seiten – Grundlage viele web-basierter Anwendungen
•
Web-basierte Datenbankanwendungen
– Vielfalt von Diensten über einfache Benutzeroberfläche (Browser)
– Verknüpfung mehrerer Dokumente über Hyperlinks – Grundlage: Verwendung von Datenbanken
Web-DB-Anwendungen
• Adreßdatenbank
Benutzer übermittelt Adresse an den Server, um z.B.
Informationsmaterial zu bestellen
– Vorwiegend schreibender Zugriff mit kurzer Verweildauer
• Elektronisches Gästebuch
Name, Adresse, Bemerkung des Benutzers werden gespeichert.
Suche und “Blättern“ in den eingegebenen Kommentaren
– Blättern: häufige, kurze, meist lesende Zugriffe typisch – Gleichzeitiger Zugriff häufig möglich
• Online-Tracking
Benutzer kann sich über den Zustand seiner Bestellung erkundigen
– Zugriff auf großen dynamischen Datenbestand durch viele Benutzer
– Erfordert Authentisierung des Benutzers und Schutz des Backend- Systems
• Online-News
Zugriff auf Artikel zu Schlagzeilen, Recherche in älteren
Artikeln, Unterscheidung in öffentlichen und kostenpflichtigen Bereich
Web-DB-Anwendungen (Forts.)
– Häufiger und gleichzeitiger Lese-Zugriff auf Online-News
– Hohe Datenaktualität, verschieden Datentypen (Bild, Ton, Video) – Authentisierung der Benutzer bei kostenpflichtigen Informationen
• Nachschlagewerk (Katalog)
Suchen in großen Datenmengen und alphabetische oder
sortierte Ausgabe (z.B. Telefonbücher, Branchenverzeichnis, Lexika)
– Geringe Datenaktualität, aber hohe Datenüberlappung möglich – Verschiedene Datentypen (auch multimedial, z.B. bei Lexika)
• Bestellkatalog
Markieren von Produkten aus einem Warenkatalog und Ablegen in einem “Warenkorb“, anschließend Bestellung
– Zusätzlich schreibender Zugriff (Warenkorb, Kundendaten) – Informationen auf Server halten (Führen eines Warenkorbes),
längere Sitzung
– Zugriff aufs operative Bestellsystem (Sicherheitsanforderungen!)
Web-DB-Anwendungen (Forts.)
•
Online-Banking
Ausführung von Bankgeschäften übers Internet (Kontostand, Überweisungen, Börsengeschäfte)
– Besondere Sicherheitsvorkehrungen:
Authentisierung des Kunden
Abschirmung des Backend-Systems – Variable Sitzungslänge
•
Web-fähige Geschäftsanwendung
Zugriff auf Geschäftsanwendungen über den Browser (z.B.
Auftragsbearbeitung)
– Typischerweise Mehrschrittvorgänge mit Benutzerinteraktion – Sehr unterschiedliche Anwendungsarten möglich
– Hohe Sitzungslängen, lange Verweildauer, hohe
Sicherheitsanforderungen (Abschirmung des Backend- Systems)
Klassifikation von Web-DB-Anwendungen
• Art des Zugriffs
– Zugriffe zum Lesen oder Schreiben oder gemischt
• Änderungshäufigkeit / Aktualität der Daten
– Pufferung sinnvoll bei geringer Änderungshäufigkeit (z.B. bei Nachschlagewerken, aber nicht bei Börsenkursen)
• Zahl der gleichzeitigen Zugriffe
– Möglicher Engpaß an Ressourcen
– Hohen Durchsatz und kurze Antwortzeiten auch bei hoher Last
• Datenüberlappung der Zugriffe
– Optimierungsmöglichkeiten bei ähnlichen Benutzeranfragen (z.B. Pufferung)
• Arten der Datentypen
– Alphanumerische Daten in HTML unterstützt – Andere Techniken für geometrische Daten
• Datensensitivität
– Schutzmaßnahmen bei der Datenübertragung (Verschlüsselung)
– Beispiele: Kreditkarten-Nr., PIN beim Online-Banking
Klassifikation von Web-DB-Anwendungen (Forts.)
•
Sicherheitsbedarf
– Abschirmung des Backend-Systems von der Außenwelt (z.B.
bei Bank-Anwendungen)
•
Benutzerauthentisierung
– Anwendungen oft nur für ausgewählte Benutzer zugänglich (z.B. Nachrichtenarchiv, Geschäftsanwendungen)
•
Benutzeridentifikation
– Für die Personalisierung von Angeboten, aber weniger strenge Sicherheitsanforderungen
•
Anzahl der Arbeitsschritte / Länge einer “Sitzung“
– Mehrschrittige Vorgänge benötigen Anwendungskontext (z.B. Füllen eines Warenkorbs) -> Realisierung eines
Zustands im zustands-losen Web durch das Backend- System
•
“Verweildauer“
– Aufenthaltsdauer eines Benutzers auf einer Web-Seite bestimmt Technologie
Web-DB-Anwendungsarchitekturen
•
Server-Seitige DB-Anbindungen
– Basieren auf dem HTTP-Protokoll, d.h. Verbindungen zwischen Client und Server bestehen nur während der Übertragung des Dokuments
– Mehrschritt-Interaktionen nicht direkt möglich – Architekturen:
CGI-Programme
Server-API
Server Side Includes
Java Servlets
•
Client-Seitige DB-Anbindungen
– In den Client geladene Applikation kann selbständig mit dem Server kommunizieren (unabhängig von HTTP)
– Architekturen:
JDBC (Java Database Connectivity)
SQLJ
CORBA-basierte Lösungen
Überblick: Web-DB-Anbindungsarchitekturen
CGI (Common Gateway Interface)
•
Prinzip:
– Kommunikation zwischen WWW-Server und Anwendungsprogrammen auf dem Webserver
– CGI-Programm (=DB-Client) erzeugt dynamisches HTML- Dokument aus Benutzereingaben (HTML-Formular)
•
Vorteile:
– Unterstützung durch alle WWW-Server – Anforderungsspezifisch programmiert
•
Nachteile:
– Pro Interaktion Start eines CGI-Prozesses / Aufbau einer DB- Verbindung
– Kein Transaktionskonzept zwischen Client und WWW-Server, Problem der Realisierung von Zuständen
– Logische Formular-Eingabefehler erst im CGI-Programm erkannt
– Aufwendige Programmerstellung
– Formatierung des Dokuments problematisch, da generiert
API-Lösungen
•
Prinzip:
– Integration des CGI-Konzepts in den WWW-Server ohne funktionale Einschränkung
– Server Applications Functions (SAF) als dynamische Programmbibliothek bereitgestellt (analog DLL)
– Kein eigener Prozeß mehr notwendig
– Server entscheidet anhand URL, ob (prozeßinterne) Erweiterungs-funktion aufgerufen werden muß
•
Vorteile:
– Sitzungen können im WWW-Server verwaltet werden
– Performance-Gewinn durch dauerhafte DB-Verbindung und gemeinsame Nutzung des Hauptspeichers
•
Nachteile:
– Gefahr des Hängenbleibens offener DB-Verbindungen – Proprietäre WWW-Server-Software
z.B. Internet Server API (ISAPI) von Microsoft inkompatibel zu Netscape Server API (NSAPI)
Server Side Includes (SSI)
• Prinzip:
– Erweiterung der Funktionalität von Web Servern
– SSI = dynamische HTML-Dokumente, angereichert mit speziellen Steuerungsbefehlen in HTML-Syntax und DB-Zugriffsfunktionalität (z.B. Anzeige aktueller Uhrzeit oder Börsenkurse)
– Ebenfalls möglich:
Aufruf anderer Anwendungen (z.B. CGI-Programme, BS- Kommandos) und Erzeugung eines neuen Prozesses
Verarbeitung regulärer HTML-Formulare
• Beispiel: Microsoft Active Server Pages (ASP)
– Anreicherung von Dokumenten um Visual Basic Script oder Java Script Kommandos
große Funktionalität durch Mächtigkeit der Skript-Sprachen
Einbettung von SQL in Skriptsprache (DB-Zugriff über ODBC) – Realisierung von Zuständen
– Zugriff auf Formular- und Umgebungsvariablen
Java Servlets
•
Einordnung:
– Pendant zu den Server-Erweiterungs-APIs von MS und Netscape
– Bestandteil des JDK 1.2 (somit kompatibel mit vielen Web- Server-Herstellern)
•
Voraussetzung
– Integration einer JVM in den Web-Server bzw. Kooperation mit einem Zusatzprozeß
•
Vorteile:
– Plattform- und herstellerunabhängige Erweiterung von Web- Servern möglich
– Dynamisches Binden möglich (Java-Klassenlader)
Hinzufügen und Entfernen von Moduln ohne Neustart des Servers
Betrachtung der server-seitigen Ansätze
•
Bewertung von Funktionalität und Architektur
•
Realisierung von Zuständen
•
Sicherheits-Aspekte
•
SQL/HTML-Integration
– Programmierung – HTML-Erweiterung – Makros
•
Architekturen
– Komponenten
– Einstufige Lösungen – Zweistufige Lösungen
– Serverseitige Funktionsabarbeitung
Realisierung von Zuständen
•
Zustandslosigkeit
– HTTP-Kommunikationsverbindung zwischen Web-Browser und Web-Server nur während einer Anfragebearbeitung
– Folge: Transaktionen beschränkt auf diese Zeitspanne (jedesmal neue DB-Verbindung herstellen)
– Bedarf zusätzlicher Techniken zur Realisierung
kontextabhängiger Mehrschritt-Arbeitsgänge (z.B. Führen eines Warenkorbes)
•
Realisierung von Zuständen durch
– Session IDs (identifiziert Web-Sitzung)
– User IDs (Benutzeridentifikation für personalisierte Angebote)
•
Techniken
– Formularvariable – HTTP-Cookie
•
Probleme:
– Timeouts bei Untätigkeit des Benutzers (Freigabe nicht benötigter Ressourcen) - abhängig von der Anwendung
Formularvariable
•
Zuweisung einer eindeutigen Kennung an den Benutzer während der Interaktion mit dem WWW-Server (z.B. in Form einer ID)
•
Eintrag der Session-ID als versteckte Eingabevariable ins HTML-Formular, z.B.
<INPUT TYPE=HIDDEN NAME=SID VALUE=4711>
•
Nutzung der Session-ID für die weitere Kommunikation (z.B. Bestimmung des Warenkorb-Besitzers bei langen Vorgängen über diese ID)
•
Vorteil:
– Unabhängig von Browsertyp und Browserkonfiguration
•
Nachteile:
– Session-ID muß in allen HTML-Dokumenten des Benutzers bei einem Vorgang und allen Folgeaktionen einkodiert sein
– Erfordert dynamische Erzeugung von HTML-Dokumenten
Belastet den Web-Server
Erschwert die Anwendungsentwicklung
HTTP-Cookie
• Unabhängig vom eigentlichen HTML-Dokument
• Bestandteil der Meta-Information zu einer HTML-Seite
– Vom Server zum Browser übertragen – Temporär im Browser gespeichert
• Beispiel:
Set-Cookie: KNR=“4711“;Version=“1“;Path=“/katalog“;
MAX-Age=“1800“
– Übertragung des Cookies KNR=4711 (Kunden-Nr.) bei jeder Dokumentenanforderung im Verzeichnis /katalog (falls Cookies unterstützt werden)
– Max-Age definiert die Verfallsdauer (im Beispiel max. Sitzungsdauer 1800 Sekunden)
• Vorteile:
– Automatische Unterstützung durch den Browser
– Einsatz unanhängig von der Kodierung in einer HTML-Seite
– Bei gleichzeitiger Verwendung mehrerer Cookies Speicherung vieler Informationen möglich
• Nachteile
– Nicht von allen Browsern unterstützt
– Benutzer kann Cookies abschalten bzw. verweigern
Sicherheit
• Sicherheit = Übertragungssicherheit + Zugriffsschutz
• Zugriffskontrolle:
– HTTP-Authentisierung: Einschränkung des Zugriffs auf bestimmte Unterverzeichnisse oder den ganzen Server für bestimmte
Benutzer
– Einschränken des Verbindungsrechts auf bestimmte Adressen / Domains (Konfiguration des Web-Servers)
– Werkzeugunterstützung für ID-Wechsel (Web-User vs. DB-Client)
• Übertragungssicherheit für Passwörter u.a. vertrauliche Daten
– Standard: Secure Socket Layer (SSL)
Grundlage RSA-Verfahren
Benötigt Zertifikat auf Seiten des Web-Servers
Client entscheidet über Übertragung, falls Server nicht zertifiziert
– Nachteil von SSL: kurze Schlüssellängen, somit besondere Sicherheitsanforderungen erfüllt
– Erfordert Speziallösungen: z.B. für Online-Banking eigene Sicherheitsprotokolle, basierend auf Java
Programmierung web-basierter DB-Anwendungen
•
Bei kleineren Anwendungen (z.B. Adreß-Datenbank)
•
Verzicht auf Werkzeugunterstützung
•
Programmiersprachen: Perl (Skript-Sprache), C
•
Vorteile:
– Schnelles und evtl. kleines Programm
– Optimal auf jeweilige Anforderungen angepaßt
•
Nachteil:
– Unflexibel, evtl. mit Neuübersetzung (z.B. bei C- Programmen)
– Für jedes Problem neues Programm
CGI-Programmierung (mSQL)
Integration von HTML und SQL
•
Ergänzung von HTML von unterschiedlichen Herstellern um SQL-Befehle
– Einbettung von SQL-Befehlen mit Befehlen zur Verarbeitung von Variablen in ein “HTML-Skelett“
•
Vorteile:
– Lesbarkeit durch Plazierung von SQL-Befehlen an den späteren Ort der Daten
– Erstellung und Wartung u.U. mit HTML-Editor möglich – Zugriff auf nur eine Datei
•
Nachteile:
– Schnell unübersichtlich wegen der Mischung von HTML und SQL
HTML/SQL-Integration (Beispiel)
•
Beispiel: Informix WebData Blade
<HTML><HEAD><TITLE>Bookmark-DB</TITLE></HEAD>
<BODY>
<H1>Bookmark-DB - Anfrageergebnis</H1>
<!-- Eingabeparameter interner Variablen zuweisen -->
<?MIVAR NAME=iname DEFAULT=Loe>$iname<?/MIVAR>
<!-- Tabellenkopf ausgeben -->
<TABLE><TR><TH>Name</TH><TH>URL</TH></TR>
<!-- Anfrage spezifizieren -->
<?MISQL query=“select name,url from
bookmarks where name LIKE ‘$iname%‘ order by name;“>
<!-- Anfrage spezifizieren -->
<TR><TD><A HREF=“$2“>$1</A></TD><TD>$2</TD></TR>
<?/MISQL>
</TABLE></BODY></HTML>
Makro-Programmierung
•
Prinzip:
– HTML-Skelett und DB-Anweisungen voneinander getrennt – Position der Anfrageergebnisse über Platzhalter
– Realisierung:
mit einer Datei und zwei Bereichen (1)
mit zwei getrennten Dateien (2)
•
Vorteile:
– HTML-Datei über HTML-Editor wartbar (2)
– Übersichtliche Spezifikation aller SQL-Anfragen
– Mehrfachverwendung von SQL-Anfragen für mehrere HTML- Dokumente möglich (2)
– Schnelleres Parsen möglich, da deutlich kleinere Datei
•
Nachteile:
– Schlechte Überschaubarkeit durch Verteilung auf zwei Dateien / Bereiche
– Zwei bzw. mehrere Dateizugriffe notwendig (2)
Integration über Makro-Dateien (Beispiel)
Komponenten der Architektur
•
Prozessor (P)
– Zentrale Komponente zur Extraktion der relevanten Informationen aus den Makro- oder HTML-Dateien
•
DB-Kommunikationskomponente (DBC)
– Stellt Verbindung zum DB-Server her zur Abarbeitung der DB-Befehle
Proprietäre Bibliotheken und API-Funktionen
Open Database Connectivity (ODBC) bzw. Call Level Interface (CLI´)
•
Web-Server-Kommunikationskomponente (WSC)
– Weitergabe der Parameter des Benutzers vom Web-Server an den Prozessor
– Rückgabe des vom Werkzeug gelieferten HTML-Dokuments an den Web-Server
– Zugriff auf bestimmte Parameter innerhalb Server API oder Umgebungsvariablen
•
Interkomponenten-Kommunikationsmodule (ICC)
– Datenaustausch zwischen unterschiedlichen Prozessen (Sockets, IIOP etc.)
Architektur-Variante 1: Einstufige Lösung
•
Vorherrschendes Verfahren für Realisierung web-basierter DB-Anwendungen
•
Prinzip:
– Direkte logische Verbindung:
d.h. etabliert nach dem Aufruf und der Parameterweitergabe durch den Web-Server mittels WSC eine DB-Verbindung
->Verarbeitung durch Prozessor kann beginnen
•
Vorteile:
– Einfach zu realisieren, einfache Installation / Konfiguration – Wenig Ressourcen im lastfreien Betrieb (Laden der
Programme nur bei Bedarf)
– Für kleine Lösungen (Gästebuch, Adreßdatenbank) geeignet
•
Nachteile:
– Im Verhältnis hohe Startzeiten durch relativ großes Programm (z.B. Start eines eigenen Prozesses bei CGI) – Benötigt neue DB-Verbindung, Etablierung teuer und
langwierig (Benutzerrechte überprüfen)
Architektur-Variante 2: Zweistufige Lösung
•
Prinzip:
– CGI-Programm/Server-Erweiterung kommuniziert (mittels ICC) mit dem eigentlichen Verarbeitungsprozeß
•
Ablauf:
– Start CGI-Programm Pool von Prozessen
•
Vorteile:
– Realisierung “langer“ Transaktionen möglich – In der Regel schnellere Antwortzeiten
– Bessere Lastbalancierung für “große“ Lösungen möglich – Caching von Antworten bzw. HTML-/Makrodateien möglich
•
Nachteile:
– Bei Nichtnutzung höherer Ressourcenbedarf durch aktiven Prozeß-Pool
– Aufwendige Installation und Konfiguration
– Kompliziertere Entwicklung durch eine zusätzliche Schicht
Architektur-Variante 3: Serverseitige Funktionsabarbeitung
•
Prinzip:
– Direkte Ausführung von Funktionen im DB-Server (z.B.
Oracle User Defined Functions)
– Gleiches Prinzip bei Verlagerung der Funktionalität des Prozessors in den DB-Server
•
Vorteile:
– Verringerte Kommunikation (Ergebnis ist lediglich ein Byte- String)
•
Nachteile:
– Zusatzbelastung für den DB-Server – u.U. komplexe Entwicklung
Architekturen im Überblick
W S C P D B C W S C P D B C
W S C IC C
W W W -S er ve r W W W -S er ve r W W -S er ve r IC C D B C P
B ro w se r B ro w se r B ro w se r
HTTP
HTTP
einstufig (direkte DB-Verbindung)
zweistufig (mit Prozeß-Pool)
Client-Seitige DB-Anbindungen
•
Entwicklung von Java (1995) und ActiveX -> Übertragung von Anwendungslogik auf die Client-Seite (Web-Browser)
•
Prinzip:
– Übertragung von Java Applets (plattformunabhängiger Bytecode) zum Client
– Direkte Verbindung zum Datenbank-Server
– Ausführung der Clients durch eine Java Virtual Machine (JVM)
•
Serverlogik:
abhängig vom Paradigma der Programmiersprache und dem Datenmodell der Datenbank
•
Anwendungslogik:
kann vollständig im Client oder in einem Application Server implementiert sein
•
Präsentationslogik:
freie Gestaltungsmöglichkeit für Präsentation der Daten
Abgrenzung zur server-orientierten Architektur
• DB-Zugriff
– Kann über eigene Verbindungen realisiert werden (kein Umweg über Web-Server)
– Zugriff des Applets auf die DB über JDBC oder SQLJ
– WWW-Server realisiert nur noch das Übertragen der Applets
• Datendarstellung
– Anwendungslogik und Präsentationslogik clientseitig unterstützt – Web-Client erwartet kein HTML, sondern die direkt übertragenen
Daten, die beliebig visualisiert werden können
• Dateneingabe
– Volle Funktionalität einer Programmiersprache zur Validierung der Eingabe und Verarbeitung der Daten aus einer DB
• Transaktionsunterstützung
– DB-Verbindung über die gesamte Laufzeit der Anwendung offen – Speicherung von Zuständen und Durchführung “langer“
Transaktionen, die voneinander abhängen
– Beliebig lange Transaktionen unter Nutzung des 2PC realisierbar -> Mehrschritt-Interaktionen möglich (im HTTP nur mit
Umwegen)
Nachteile der client-orientierten Architektur
•
Client-seitige Unterstützung ist notwendig (z.B. JVM)
•
Java-Sicherheitskonzept erlaubt Applets nur
Verbindungen zum Rechner, von wo sie geladen wurden
erzwingt Anordnung aller Server auf einem Rechner (Flaschenhalsproblem)
– Abhilfe: explizite Gewährung von Verbindungsrechten;
signierte Applets
•
Initial lange Ladezeiten für die Applets
– Abhilfe: persistente Speicherung von Applets auf der Client- Seite (Nutzung von JAR-Dateien, Kombination mit signierten Applets)
– Java Interfaces: Nachladen der Implementierung zur Laufzeit
•
Benutzerinteraktion und Datenrepräsentation müssen
programmiert werden
Java Database Connectivity (JDBC)
• Motivation:
– Zugriff auf SQL-Datenbanken mit Java benötigt
– Selbstgestrickte Java-Zugriffsmethoden (über C API) aufwendig und fehlerbehaftet und nicht einfach portierbar
– Überwindung des Mismatch zwischen
Java (objektorientiert, ohne Pointer)
C (prozedural, mit Pointern)
SQL (mengenorientiert)
• Beziehung zu ODBS
– Wurde in Anlehnung an ODBC (Open Database Connectivity)
entwickelt und mit einer ähnlichen Klassenbibliothek ausgestattet
• DB-Kommunikation erfolgt über ein Call Level Interface (CLI)
• Basiert auf Java: kann Objekte direkt verwenden, um DB-
Objekte und ihre Operationen direkt und natürlich darzustellen
– Beispiel: Objekt Connection mit einer Methode close()
• JDBC-Klassenbibliothek
– Seit JDK 1.1 im Sprachumfang enthalten, wird ständig um weitere Funktionalität ergänzt
– Trennung in ein “Core API“ und “Standard Extension API“
JDBC Entwurfsziele
•
Call-Level Dynamic SQL API
– Äquivalent zu ODBC und X/Open CLI
– Allgemeines API, das die Basis-SQL-Funktionalität unterstützt
– Höhere APIs (z.B. mit Mapping Klassen-Tabellen) können darauf aufsetzen
•
Implementierbar “on top of“ allgemeinen SQL-APIs
– Implementierbar auf Basis von ODBC und X/Open CLI – Brückentreiber JDBC-ODBC somit leicht realisierbar
•
SQL Conformance
– Jeder SQL-Dialekt verarbeitbar, falls ein JDBC-Driver dafür vorhanden ist
– Mindest-Anforderung: SQL-92 (Entry Level) muß von allen Drivern unterstützt werden
•
Strenges, statisches Typing
•
Einfaches API für den Normalfall (80-20 Regel)
JDBC-Architektur
Application Driver Manager
Driver Driver Driver Data source Data source Data source
JDBC API
JDBC Driver API
Proprietär
JDBC Klassen und Interfaces
java.sql.DriverManager java.sql.Driver
(class, class methods only) (class, drivers only)
java.sql.Connection java.sql.Connection
(interface) (interface)
java.sql.Statement java.sql.Statement java.sql.Statement
(interface) (interface) (interface)
java.sql.ResultSet java.sql.ResultSet
(interface) (interface)
JDBC Zwei-Schichten-Architektur (Trusted Environment)
Java Application JDBC Driver Manager
JDBC Driver
Server DBMS
LAN oder Intranet
Client
• Client/Server-Konfiguration:
Two-Tier-Model
• Direkter Zugriff auf beliebige Datenbank-Server
• Meistens genutzt im LAN oder Intranet
JDBC Zwei-Schichten-Architektur
Java Applet
JDBC Driver Manager JDBC Driver
Server DBMS Client
• Driver kann nur auf Server zugreifen, vom dem er
geladen wurde
• Arbeitet nicht mit allen JDBC-Drivern
Web Server
Download Software
Datenbank Zugriff
JDBC 3-Schichten-Architektur
Java Middleware JDBC Driver Manager
JDBC Driver
DBMS DBMS Server
Client Java Applet oder Application
Middle- ware Server
Internet oder Intranet
LAN
• Prinzip: Anfragen an die
mittlere Schicht, die ihrerseits SQL-Anweisungen an die DB sendet
• Zugriff auf jeden beliebigen DB-Server
• Arbeitet mit allen JDBC-Drivern
• Bei Applets: Middleware muß auf dem Web-Server liegen
• Verwendung einer höheren API auf Seiten der Anwendung, die durch die mittlere Schicht in eine niedrigere API umgesetzt wird (z.B. C/C++)
• Vorteile: höhere Performance, dünnere Clients durch Auslage- rung von Anwendungslogik in die Middleware
Driver Typ 1: JDBC-ODBC-Brücke
Java Application JDBC Driver Manager
JDBC-ODBC Bridge
DBMS Server
LAN oder Intranet
Client
ODBC Driver Manager ODBC Driver
• Zugriff auf einen ODBC-fähigen DB-Server ohne einen eigenen JDBC Driver
• Nutzbar nur für Java-Applika- tionen, aber nicht für
unsignierte Applets
• Bridge und ODBC
Komponenten müssen auf
jedem Client-Rechner geladen sein
• Geeignet für Unternehmen, wo Installation der Software auf dem Client problemlos
• Beispiel: JDBC-ODBC Bridge Driver von JavaSoft
Driver Typ 2: Natives API, Driver teilweise in Java
Java Application JDBC Driver Manager
JDBC Driver
DBMS Server
LAN oder Intranet
Client
Mapping Layer SQL*Net, etc.
• Nutzt verfügbare
Technologie: Übersetzt JDBC- Aufrufe in Aufrufe einer
nativen Datenbank-API, z.B. C
• Kann nicht mit unsignierten Applets genutzt werden (nur für Applikationen geeignet)
• Abbildungsschicht und
Network Library müssen auf dem Client-Rechner
vorinstalliert sein
• Nicht binärkompatibel mit anderen Plattformen
• Beispiel: DB2 JDBC
Application Driver von IBM
Driver Typ 3: JDBC-Netz, Driver in purem Java
Java Applet
JDBC Driver Manager Universal JDBC Driver
DBMS 1 Server
Internet oder Intranet
Client
• Wickeln die gesamte DB- Kommunikation über Verbindungs-Server ab
• DBMS-unabhängiges Netzwerk-Protokoll
• Ein einziger Driver auf dem Client (somit
binärkompatible Plattformen)
• Benutzbar für alle Arten von Applets über das Internet hinweg
• Höhere Systemsicherheit (Firewall-Lösungen)
• Schlechtere
Antwortzeiten, da Umweg über Verbindungs-Server JDBC Server
Component 1
DBMS 2
JDBC Server Component 2
DBMS Servers
Standard Network Protocol
Prof. Dr. T. Kudraß 45
Driver Typ 4: Natives Protokoll, Driver in purem Java
Java Applet
JDBC Driver Manager JDBC Driver
DBMS
Internet oder Intranet
Client
• Übersetzt die JDBC-
Aufrufe direkt in das vom DBMS verwendete
Netzprotokoll
• Direkte Kommunikation des Clients mit dem DB- Server
• Antwortzeiten bei
diesem Typ am besten
• Einschränkungen für
unsignierte Applets bzgl.
Plazierung DB-Server (Einsatz i.allg. in
Intranets)
• Spezielle
Sicherheitsmaß-nahmen erforderlich, da
Kommunikationsport bekannt
• Mehrere Driver auf einem Client
Server
DBMS-specific Network Protocol
Java Code-Beispiel: SELECT
// Create a connection and connect Connection conn;
Statement stmt;
ResultSet rs;
int partID;
float price;
conn = DriverManager.getConnection("jdbc:odbc:Sales", "myname", "mypassword");
// Create a statement and execute a SELECT statement stmt = conn.createStatement();
rs = stmt.executeQuery
("SELECT PartID, Price FROM Parts");
Java Code-Beispiel: SELECT (Forts.)
// Fetch and print each row while (rs.next())
{
partID = rs.getInt(1);
price = rs.getFloat(2);
System.out.println("Part Number: " + partID + " Price: " + price);
} // Close the result set rs.close();
// Close the statement and connection stmt.close();
conn.close();
Java Code-Beispiel: UPDATE
// Create a connection and connect Connection conn;
Statement stmt;
int rowCount;
conn = DriverManager.getConnection("jdbc:odbc:Sales", "myname", "mypassword");
conn.setAutoCommit(false);
// Create a statement and execute an UPDATE statement stmt = conn.createStatement();
rowCount = stmt.executeUpdate
("UPDATE Parts SET Price = 10.0 WHERE PartID = 123");
Java Code-Beispiel UPDATE (Forts.)
// Check if row was changed if (rowCount != 0)
{
System.out.println("Price changed");
}
else {
System.out.println("Part not found");
}
// Commit the transaction conn.commit();
// Close the statement and connection stmt.close();
conn.close();
Zugriff auf Metadaten in JDBC
• Zugrundeliegendes DB-Schema i. allg. bekannt
• Dynamischer DB-Zugriff benötigt
– wenn Informationen über DBMS und DB-Schema fehlen
– wenn Anwendungen programmiert werden, die unabhängig von der konkreten Struktur einer DB arbeiten
• Klasse ResultMetaData
– Informationen über die Struktur eines ResultSet Objekts durch Aufruf der Methode getMetaData
– Informationen über Tabellen und Spalten (Name, Typ, Länge etc.)
• Klasse DatabaseMetaData
– Informationen über die verwendete Datenbank durch Aufruf der Methode getMetaData
– Ca. 130 Methoden der Klasse DatabaseMetaData (einfache oder komplexe Informationen)
– Beispiele: Informationen über Driver-Name, Max. Anzahl
Connections, Funktionalität des DBMS (z.B. Full-SQL-92? Outer Joins?)
SQLJ Einführung
• Historie
– 1997: Konsortium verschiedener IT-Firmen (z.B. Oracle, IBM, Microsoft, Sun)
– Alternative zur komplizierten DB-Programmierung auf Basis von JDBC
• Java Pendant zum “klassischen“ Embedded SQL
• Implementierung von SQLJ basiert auf JDBC als Low Level API
• Teil 0: Embedded SQL
Einbindung von statischen SQL-Statements in ein Java- Programm
• Teil 1: Java Stored Routines
Nutzung von statischen Java-Methoden als SQL Stored Procedures
• Teil 2: Java Data Types
Verwendung von Java-Klassen als SQL Abstract Data Types
Embedded SQL in Java
•
Übersetzung von SQL
– Ersetzen der eingebetteten SQL-Statements in JDBC-Aufrufe – Ergebnis: Java-Programm, das normal compiliert wird
– Überprüfung von Syntax und Semantik der SQL-Anweisungen
•
Customizer von DBMS-Herstellern
– Erzeugen von DB-spezifische SQL Statements aus den SQLJ Statements; wird Teil der SQLJ Applikation
– Zur Laufzeit wird für das verwendete DBMS entschieden, ob eine entsprechende Customization existiert, ansonsten
Verwendung des originalen JDBC-Codes
SQL File Java File Class File
SQL Translator Java Compiler
Java-Programm mit SQLJ (Beispiel)
// Iterator für Ergebnismenge definieren
#sql public iterator ResRec ( String name,
String url );
// Iterator für 2. Beispiel definieren
#sql public iterator MyPos (String, String);
Class BookmarkQueries {
public static void main (String args[]) { // Verbindung aufbauen
ConnectionManager.initContext();
// Beispiel 1 // DB-Anweisung
ResRec rr;
#sql rr = {select name,url from bookmarks where name LIKE ‘Sch%‘ order by name };
// Ergebnisse abholen und zeilenweise ausgeben while (rr.next())
{ system.out.println (rr.name()+ ““ +rr.url());}
Java-Programm mit SQL (Forts.)
// Beispiel 2
MyPos mp; String rname; String rurl;
// DB-Anweisung ausführen
#sql mp = {select name,url from bookmarks where name LIKE ‘Sch%‘ order by name );
while (true) {
// über Iterator Ergebnis in eigene Variable holen
#sql { FETCH :mp INTO :rname, :rurl };
if (mp.endFetch()) break;
System.out.println(rname + „ „ +rurl); } // Fehlerbehandlung und Programmende
} catch (SQLException ex) { ...
Bemerkungen zu SQLJ
• Iteratoren: normale Objekte der Wirtssprache Java (auch außerhalb von SQLJ verwendbar)
• 2 verschiedene Arten von Iteratoren
– Bindung über Namen (Beispiel 1) – Bindung über Position (Beispiel 2)
Nur Typen der Ergebnisspalten bekannt
Erfordert zusätzliche FETCH-Anweisung
• Unterstützung mehrerer gleichzeitiger DB-Verbindungen möglich
– ConnectionContext Objekt implizit oder explizit verwendet
– Bei mehreren Verbindung explizite Connection-Objekte notwendig – Beispiel:
#sql context bookmarkdb;
#sql [bookmarkdb] rr ={SELECT ..FROM ..WHERE ..};
• Weitere Anweisungen: Transaktionssteuerung, DDL- und DML- Befehle
• Keine Konstrukte für Variablendeklaration wegen enger Sprach- einbettung
• Keine dynamischen Anweisungen
Vergleich von JDBC und SQLJ
Vorteile von JDBC (Typ 3/4):
• Mächtigkeit
• Dynamik
• DB-Hersteller-unabhängiges API
• Portierbarkeit
• Sicherheit (3)
• Lastbalancierung über Verbindungs-Server (3)
• Schnelle Kommunikation Nachteile von JDBC:
• Komplexe Programmierung
• Längere Antwortzeiten durch
Umweg über Verbindungs-Server (3)
• Ohne Signed Applets
Beschränkung bzgl. Plazierung des DB-Servers (4)
• Sicherheit (4)
Vorteile von SQLJ:
• Einfachheit durch Einbettung in Java
• DB-Hersteller-unabhängige Lösung
• Portierbarkeit
• Dynamik/Mächtigkeit über Interaktion mit JDBC
Nachteile von SQLJ:
• Nur statisches SQL
• Erfordert Präprozessor
CORBA-basierte Lösungen
• CORBA (Common Object Request Broker)
– Von der Object Management Group (OMG) spezifiziert
– Kommunikations-Framework mit einem Object Request Broker (ORB) im Kern
– Definition von Schnittstellen und Protokollen
Interface Definition Language (IDL) mit Language Bindings
Java Language Binding
• Architektur und Ablauf
– Laden des Applets vom Web-Server in den Browser
– Verbindungsaufnahme des Applet zum server-seitigen ORB mittels IIOP
– Evtl. Bestimmung der Adresse des ORB über Naming/Trading Service – Methodenaufruf auf dem gefundenen Anwendungsobjekt
(vergleichbar mit Remote Procedure Call)
– Ausführung der Methode über DB-Anweisungen
Direkte Kommunikation mit dem DBMS über spez. Protokoll
Umweg über einen Verbindungs-Server (z.B. Umwandlung ODBC)
– Rückgabe der Ergebnisse ans aufrufende Applet
Zusammenfassung
• Server-orientierte Lösungen zur DB-Anbindung
– Auf Basis von CGI, Server-Erweiterungen, SSI, ASP – Cookies zur Benutzeridentifikation und geeignete
Przeßarchitektur erlauben leistungsfähige Systeme für Electronic Commerce
• Client-orientierte Lösungen für Anwendungen mit besonderen Anforderungen
– Mehr Möglichkeiten für client-seitige Datenaufbereitung und Benutzerinteraktion
– Kommunikation mit DB- und Kommunikations-Servern – Genormte Schnittstellen: JDBC, SQLJ
• Objektrelationale DBMS:
– Ablage von Java-Methoden als Stored Procedures in der DB – Speicherung von HTML-Seiten in der DB
– Erweiterbar um neue Typen:
Typen für Daten im WWW
Neue Anwendungen: Konsistenzsicherung lokaler Hyperlinks
Was kommt nach HTML? XML!
• Extensible Markup Language (XML): “Erweiterbares HTML”
•
Zusammenwachsen von SGML and HTML:
– Stärke von SGML (Dokumentenbeschreibungssprache) – plus Einfachheit von HTML
•
Erlaubt die Definition neuer Markup Languages, genannt
Document Type Declarations (DTDs)•
Elemente
– Primäre Bausteine von XML
– Werden begrenzt durch Start und End Tag – Korrekte Schachtelung beachten
•
Elemente können Attribute haben, die zusätzliche Informationen über das Element darstellen
•
Entities: wie Makros, repräsentieren gewöhnlichen Text
•
Kommentare (beliebiger Text)
•
Document Type Declarations (DTDs)
Menge von Regeln, die die erlaubten Elemente, Attribute und Entities im Dokument definieren
XML-Beispiel (Bücherliste)
<?XML version=“1.0” standalone=“yes”?>
<!DOCTYPE BOOKLIST SYSTEM “booklist.dtd”>
<BOOKLIST>
<BOOK genre=“Fiction”>
<AUTHOR>
<FIRST>Milan</FIRST><LAST>Kundera</LAST>
</AUTHOR>
<TITLE>Identity</TITLE>
<PUBLISHED>1998</PUBLISHED>
<BOOK genre=“Science” format=“Hardcover”>
<AUTHOR>
<FIRST>Richard</FIRST><LAST>Feynman</LAST>
</AUTHOR>
<TITLE>The Character of Physical Law</TITLE>
</BOOK></BOOKLIST>
DTDs in XML
•
Ein XML-Document ist wohlgeformt, wenn es korrekt geschachtelt ist bei nicht vorhandener DTD
•
An XML-Dokument ist gültig, wenn es eine DTD hat und das Dokument den Regeln in der DTD folgt
<!DOCTYPE BOOKLIST [
<!ELEMENT BOOKLIST (BOOK)*>
<!ELEMENT BOOK (AUTHOR, TITLE, PUBLISHED?)>
<!ELEMENT AUTHOR (FIRST, LAST)>
<!ELEMENT FIRST (#PCDATA)>
<!ELEMENT LAST (#PCDATA)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT PUBLISHED (#PCDATA)>
<!ATTLIST BOOK genre (Science|Fiction) #REQUIRED>
<!ATTLIST BOOK format (Paperback|Hardcover)
“Paperback”>
Domain-Spezifische DTDs
•
Entwicklung standardisierter DTDs für spezialisierte
Domains erlaubt Datenaustausch zwischen heterogenen Quellen
•
Beispiel: Mathematische Markup Language (MathML)
– Mathematische Sachverhalte im Web
– In HTML: <IMG SRC=“xysq.gif” ALT=“(x+y)^2”>
Nachteil: Mangelnde Flexibilität bei der Präsentation (Font- Größe, Hintergrund-Farbe)
– In MathML Presentation Elements, Content Elements Beispiel:
<apply> <power/>
<apply> <plus/> <ci>x</ci> <ci>y</ci> </apply>
<cn>2</cn>
</apply>
XML-QL: Anfragen in XML-Daten
•
Ziel: Deklarative Hochsprache zur Manipulation von XML- Dokumenten
•
Zur Zeit noch kein Standard
•
Beispiel-Anfrage in XML-QL (WHERE-Klausel):
WHERE <BOOK>
<NAME><LAST>$1</LAST></NAME>
</BOOK> in “www.booklist.com/books.xml CONSTRUCT <RESULT> $1 </RESULT>
– Anfrage extrahiert Daten aus einem XML-Dokument, die in der Struktur BOOK-NAME-LAST zu finden sind
– Variable wird mit dem Inhalt von LAST gebunden – Ergebnis könnte auch mehrere Elemente enthalten
(benötigt mehrere Variablen)
Semistrukturierte Daten
•
Daten mit partieller Struktur
– Strukturiert: Felder
– Unstrukturiert: Text, Video- und Audio-Streams, Bilder – unregelmäßiges Auftreten von Hyperlinks
•
Mangel an Struktur
– Struktur implizit oder verborgen
– Integration von Daten aus heterogenen Quellen (hierfür strukturiertes Modell oft zu restriktiv)
– Bestimmte Anfragetypen ignorieren Schema bewußt (z.B.
Zeichenkettensuche übe´r gesamte Datenbank hinweg)
•
Alle Datenmodelle für semistrukturierte Daten nutzen markierte Graphen
•
Wir verwenden hier als typischen Vertreter das Object
Exchange Model (OEM):– Objekt ist Tripel (Label, Typ, Wert)
– Komplexe Objekte werden hierarchisch in kleinere Objekte zerlegt
Beispiel: Daten der Buchliste in OEM
Milan Kundera
Identity 1998 BOOK
AUTHOR TITLE PUBLISHED AUTHOR FORMAT TITLE
Richard Feynman
The
character of phy- sical law
Hard-
cover
Indexieren zur Textsuche
• Text-Datenbank: Sammlung von Text-Dokumenten
• Wichtige Klasse von Anfragen: Suchen nach Dokumenten, die ein bestimmtes Schlüsselwort enthalten (Keyword
Search)
• Aufbau eines Index: <keyword, documentid>
• Boolesche Queries:
– Anfrageterme mit AND, OR und NOT verbunden
– Ergebnis ist eine Liste von Dokumenten, die den booleschen Ausdruck erfüllen.
• Ranked Queries:
– Ergebnis ist eine Liste von Dokumenten, bewertet und sortiert entsprechend ihrer “Relevanz”
• Information Retrieval (verwandt mit DB-Management)
Bewertungskriterien:
– Präzision: Prozent-Anteil der erhaltenen Dokumente, die relevant für die Anfrage sind
– Recall: Prozent-Anteil der relevanten Objekte in der
Invertierte Files
• Für jeden möglichen
Anfrage-term: speichere eine geordnete List
(invertierte Liste) von
Dokument-Identifikatoren, die diesen Term enthalten
• Query-Bearbeitung: Durch- schnitt oder Vereinigung von invertierten Listen
• Beispiel: Agent AND James
Mobile agent 2
Agent James 1
Dokument RID
<2>
Mobile
<1>
James
<1,2>
Agent
Invertierte Liste
Word
Signature-Files
•
Indexstruktur (Signature-File) mit einem Dateneintrag für jedes Dokument
•
Hash-Funktion bildet Wörter auf einen Bit-Vektor ab
•
Dateneintrag für ein Dokument (die Signatur des
Dokuments) entspricht dem OR aller gehashten Wörter
•
Signatur S1 matcht Signatur S2 wenn S2&S1=S2
Mobile Agent James Document
1011
2 1110
1 Signature
RID
Mobil 0001 e
1100 James
1010 Agent
Hash
Beispiel: Word
Signature-Files: Query-Bearbeitung
•
Boolesche Query als Konjunktion von Wörtern:
– Generiere Query-Signatur Sq
– Scanne die Signaturen aller Dokumente
– Wenn Signatur S die Signatur Sq matcht, dann lese Dokument
– Prüfe auf False Positives (Dokumente, deren Signatur zwar matcht, die aber nicht alle Terme der Query enthalten);
teurer Irrtum
•
Boolesche Query als Disjunktion von Wörtern:
– Generiere k Query-Signaturen S1, …, Sk
– Scanne das Signature-File, um Dokumente zu finden, deren Signatur einer von S1, …, Sk matcht
– Prüfen auf False Positives
Zusammenfassung
•
XML
– Dokumentbeschreibungsstandard in Entwicklung – Erweiterbar durch die Definition neuer DTDs
– In Entwicklung: Anfragesprachen für XML (z.B. XQL)
•
Text-Datenbanken
– Haben an Bedeutung gewonnen mit der Verbreitung von Textdaten auf dem Web
– Effiziente Auswertung von Boolesches Queries möglich mittels geeigneter Indexstrukturen
Invertierter Index
Signature-File
– Auswertung von Ranked Queries ist wesentlich komplizierter!
