Prof. Dr. T. Kudraß1 Internet-Datenbanken. Prof. Dr. T. Kudraß2 Historie des WWW Grundlage...
-
Upload
maud-neeser -
Category
Documents
-
view
106 -
download
0
Transcript of Prof. Dr. T. Kudraß1 Internet-Datenbanken. Prof. Dr. T. Kudraß2 Historie des WWW Grundlage...
Prof. Dr. T. Kudraß 1
Internet-Datenbanken
Prof. Dr. T. Kudraß 2
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
Prof. Dr. T. Kudraß 3
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>
Prof. Dr. T. Kudraß 4
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
Prof. Dr. T. Kudraß 5
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-TrackingBenutzer 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-NewsZugriff auf Artikel zu Schlagzeilen, Recherche in älteren Artikeln, Unterscheidung in öffentlichen und kostenpflichtigen Bereich
Prof. Dr. T. Kudraß 6
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)
• BestellkatalogMarkieren 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!)
Prof. Dr. T. Kudraß 7
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)
Prof. Dr. T. Kudraß 8
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
Prof. Dr. T. Kudraß 9
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
Prof. Dr. T. Kudraß 10
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
Prof. Dr. T. Kudraß 11
Überblick: Web-DB-Anbindungsarchitekturen
Prof. Dr. T. Kudraß 12
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
Prof. Dr. T. Kudraß 13
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)
Prof. Dr. T. Kudraß 14
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
Prof. Dr. T. Kudraß 15
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
Prof. Dr. T. Kudraß 16
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
Prof. Dr. T. Kudraß 17
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
Prof. Dr. T. Kudraß 18
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
Prof. Dr. T. Kudraß 19
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
Prof. Dr. T. Kudraß 20
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
Prof. Dr. T. Kudraß 21
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
Prof. Dr. T. Kudraß 22
CGI-Programmierung (mSQL)
Prof. Dr. T. Kudraß 23
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
Prof. Dr. T. Kudraß 24
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>
Prof. Dr. T. Kudraß 25
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)
Prof. Dr. T. Kudraß 26
Integration über Makro-Dateien (Beispiel)
Prof. Dr. T. Kudraß 27
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.)
Prof. Dr. T. Kudraß 28
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)
Prof. Dr. T. Kudraß 29
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
Prof. Dr. T. Kudraß 30
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
Prof. Dr. T. Kudraß 31
Architekturen im Überblick
WS
CP
DB
C
WS
CP
DB
C
WS
CIC
C
WW
W-S
erve
rW
WW
-Ser
ver
WW
W-S
erve
r
ICC
DB
C P
Bro
wse
rB
row
ser
Bro
wse
r
HTTP
HTTP
HTTP
einstufig (direkte DB-Verbindung)
zweistufig (mit Prozeß-Pool)
Server-seitige Abarbeitung
Prof. Dr. T. Kudraß 32
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
Prof. Dr. T. Kudraß 33
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)
Prof. Dr. T. Kudraß 34
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
Prof. Dr. T. Kudraß 35
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“
Prof. Dr. T. Kudraß 36
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)
Prof. Dr. T. Kudraß 37
JDBC-Architektur
Application
Driver Manager
Driver Driver Driver
Data source Data source Data source
JDBC API
JDBC Driver API
Proprietär
Prof. Dr. T. Kudraß 38
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)
Prof. Dr. T. Kudraß 39
JDBC Zwei-Schichten-Architektur (Trusted Environment)
Java Application
JDBC Driver Manager
JDBC Driver
DBMSServer
LAN oder Intranet
Client
• Client/Server-Konfiguration: Two-Tier-Model
• Direkter Zugriff auf beliebige Datenbank-Server
• Meistens genutzt im LAN oder Intranet
Prof. Dr. T. Kudraß 40
JDBC Zwei-Schichten-Architektur
Java Applet
JDBC Driver Manager
JDBC Driver
DBMSServer
Client
• Driver kann nur auf Server zugreifen, vom dem er geladen wurde
• Arbeitet nicht mit allen JDBC-Drivern
WebServer
DownloadSoftware
DatenbankZugriff
Prof. Dr. T. Kudraß 41
JDBC 3-Schichten-Architektur
Java Middleware
JDBC Driver Manager
JDBC Driver
DBMSDBMSServer
Client Java Applet oderApplication
Middle-ware
Server
Internet oderIntranet
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
Prof. Dr. T. Kudraß 42
Driver Typ 1: JDBC-ODBC-Brücke
Java Application
JDBC Driver Manager
JDBC-ODBC Bridge
DBMSServer
LAN oder Intranet
ClientODBC 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
Prof. Dr. T. Kudraß 43
Driver Typ 2: Natives API, Driver teilweise in Java
Java Application
JDBC Driver Manager
JDBC Driver
DBMSServer
LAN oder Intranet
ClientMapping 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
Prof. Dr. T. Kudraß 44
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
• Beispiel: VisiChannel von VisiGenic
JDBC ServerComponent 1
DBMS 2
JDBC ServerComponent 2
DBMSServers
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
• Beispiel: JDBC Applet Driver von IBM
Server
DBMS-specificNetwork Protocol
Prof. Dr. T. Kudraß 46
Java Code-Beispiel: SELECT
// Create a connection and connectConnection conn;Statement stmt;ResultSet rs;int partID;float price;
conn = DriverManager.getConnection("jdbc:odbc:Sales", "myname", "mypassword");
// Create a statement and execute a SELECT statementstmt = conn.createStatement();rs = stmt.executeQuery
("SELECT PartID, Price FROM Parts");
Prof. Dr. T. Kudraß 47
Java Code-Beispiel: SELECT (Forts.)
// Fetch and print each rowwhile (rs.next()){ partID = rs.getInt(1); price = rs.getFloat(2); System.out.println("Part Number: " + partID + " Price: " + price);} // Close the result setrs.close();
// Close the statement and connectionstmt.close();conn.close();
Prof. Dr. T. Kudraß 48
Java Code-Beispiel: UPDATE
// Create a connection and connectConnection conn;Statement stmt;int rowCount;
conn = DriverManager.getConnection("jdbc:odbc:Sales", "myname", "mypassword");
conn.setAutoCommit(false);
// Create a statement and execute an UPDATE statementstmt = conn.createStatement();rowCount = stmt.executeUpdate ("UPDATE Parts SET Price = 10.0 WHERE PartID = 123");
Prof. Dr. T. Kudraß 49
Java Code-Beispiel UPDATE (Forts.)
// Check if row was changedif (rowCount != 0){ System.out.println("Price changed");}else{ System.out.println("Part not found");}// Commit the transactionconn.commit();
// Close the statement and connectionstmt.close();conn.close();
Prof. Dr. T. Kudraß 50
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?)
Prof. Dr. T. Kudraß 51
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 SQLEinbindung von statischen SQL-Statements in ein Java-Programm
• Teil 1: Java Stored RoutinesNutzung von statischen Java-Methoden als SQL Stored Procedures
• Teil 2: Java Data TypesVerwendung von Java-Klassen als SQL Abstract Data Types
Prof. Dr. T. Kudraß 52
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
Tra
nsla
tor
Java
Com
pile
r
Prof. Dr. T. Kudraß 53
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 aufbauenConnectionManager.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());}
// Ergebnismenge schließenrecRec.close();
Prof. Dr. T. Kudraß 54
Java-Programm mit SQL (Forts.)
// Beispiel 2MyPos 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) { ...
Prof. Dr. T. Kudraß 55
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
Prof. Dr. T. Kudraß 56
Vergleich von JDBC und SQLJVorteile von JDBC (Typ 3/4):• Mächtigkeit• Dynamik• DB-Hersteller-unabhängiges API• Portierbarkeit• Sicherheit (3)• Lastbalancierung über
Verbindungs-Server (3)• Schnelle KommunikationNachteile 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
Prof. Dr. T. Kudraß 57
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
Prof. Dr. T. Kudraß 58
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
Prof. Dr. T. Kudraß 59
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
Prof. Dr. T. Kudraß 60
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>
Prof. Dr. T. Kudraß 61
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”>]>
Prof. Dr. T. Kudraß 62
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 ElementsBeispiel: <apply> <power/> <apply> <plus/> <ci>x</ci> <ci>y</ci> </apply> <cn>2</cn> </apply>
Prof. Dr. T. Kudraß 63
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.xmlCONSTRUCT <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)
Prof. Dr. T. Kudraß 64
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
Prof. Dr. T. Kudraß 65
Beispiel: Daten der Buchliste in OEM
Milan Kundera
Identity 1998
BOOK
AUTHOR TITLE PUBLISHED AUTHOR FORMATTITLE
Richard Feynman
The characterof phy-sical law
Hard-cover
Prof. Dr. T. Kudraß 66
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 Datenbank, die im Ergebnis einer Anfrage geliefert werden
Prof. Dr. T. Kudraß 67
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 agent2
Agent James1
DokumentRID
<2>Mobile
<1>James
<1,2>Agent
Invertierte Liste
Word
Prof. Dr. T. Kudraß 68
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
Agent James
Document
1011211101
SignatureRID
0001Mobile
1100James1010AgentHashWord
Beispiel:
Prof. Dr. T. Kudraß 69
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
Prof. Dr. T. Kudraß 70
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!