Prof. Dr. T. Kudraß1 Internet-Datenbanken. Prof. Dr. T. Kudraß2 Historie des WWW Grundlage...

transcript

Prof. Dr. T. Kudraß 1

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-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

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!)

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

HTML/SQL-Integration (Beispiel)• Beispiel: Informix WebData Blade

<HTML><HEAD><TITLE>Bookmark-DB</TITLE></HEAD>

<BODY>

<H1>Bookmark-DB - Anfrageergebnis</H1>

<?MIVAR NAME=iname DEFAULT=Loe>$iname<?/MIVAR>

<?MISQL query=“select name,url from

bookmarks where name LIKE ‘$iname%‘ order by name;“>

<?/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

einstufig (direkte DB-Verbindung)

zweistufig (mit Prozeß-Pool)

Server-seitige Abarbeitung

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

DBMSServer

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

DBMSServer

Client

• Driver kann nur auf Server zugreifen, vom dem er geladen wurde

• Arbeitet nicht mit allen JDBC-Drivern

WebServer

DownloadSoftware

DatenbankZugriff

JDBC 3-Schichten-Architektur

Java Middleware

JDBC Driver Manager

JDBC Driver

DBMSDBMSServer

Client Java Applet oderApplication

Middle-ware

Server

Internet oderIntranet

• 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

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

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

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

Driver Typ 4: Natives Protokoll, Driver in purem Java

Java Applet

JDBC Driver Manager

JDBC Driver

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

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");

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();

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");

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();

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

• 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

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

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();

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) { ...

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 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

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 ElementsBeispiel: <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.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)

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

AUTHOR TITLE PUBLISHED AUTHOR FORMATTITLE

Richard Feynman

The characterof 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 Datenbank, die im Ergebnis einer Anfrage geliefert werden

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

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:

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!

Prof. Dr. T. Kudraß1 Internet-Datenbanken. Prof. Dr. T. Kudraß2 Historie des WWW Grundlage...

Documents