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)

Präsentation zum Thema: "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)"—  Präsentation transkript:

1 Prof. Dr. T. Kudraß1 Internet-Datenbanken

2 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

3 Prof. Dr. T. Kudraß3 HTML Beispiel Fiction: Author: Milan Kundera</LI? Title: Identity Published: 1998 Science: Author: Richard Feynman Title: The Character of Physical Law Hardcover

4 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

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

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

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

8 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

9 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

10 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

11 Prof. Dr. T. Kudraß11 Überblick: Web-DB-Anbindungsarchitekturen

12 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

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

14 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

15 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

16 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

17 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

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

19 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

20 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

21 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

22 Prof. Dr. T. Kudraß22 CGI-Programmierung (mSQL)

23 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

24 Prof. Dr. T. Kudraß24 HTML/SQL-Integration (Beispiel) Beispiel: Informix WebData Blade Bookmark-DB Bookmark-DB - Anfrageergebnis $iname Name URL <?MISQL query=select name,url from bookmarks where name LIKE $iname% order by name;> $1 $2

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

26 Prof. Dr. T. Kudraß26 Integration über Makro-Dateien (Beispiel)

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

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

29 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

30 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

31 Prof. Dr. T. Kudraß31 Architekturen im Überblick WSC P DBC WSC P DBC WSC ICC WWW-Server ICC DBC P Browser HTTP einstufig (direkte DB-Verbindung) zweistufig (mit Prozeß-Pool) Server-seitige Abarbeitung

32 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

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

34 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

35 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

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

37 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

38 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 (interface) java.sql.Statement java.sql.Statement java.sql.Statement (interface) (interface) (interface) java.sql.ResultSet (interface)

39 Prof. Dr. T. Kudraß39 JDBC Zwei-Schichten-Architektur (Trusted Environment) Java Application JDBC Driver Manager JDBC Driver DBMS Server LAN oder Intranet Client Client/Server-Konfiguration: Two- Tier-Model Direkter Zugriff auf beliebige Datenbank-Server Meistens genutzt im LAN oder Intranet

40 Prof. Dr. T. Kudraß40 JDBC Zwei-Schichten-Architektur Java Applet JDBC Driver Manager JDBC Driver DBMS Server Client Driver kann nur auf Server zugreifen, vom dem er geladen wurde Arbeitet nicht mit allen JDBC- Drivern Web Server Download Software Datenbank Zugriff

41 Prof. Dr. T. Kudraß41 JDBC 3-Schichten-Architektur Java Middleware JDBC Driver Manager JDBC Driver 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

42 Prof. Dr. T. Kudraß42 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

43 Prof. Dr. T. Kudraß43 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

44 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 Server Component 1 DBMS 2 JDBC Server Component 2 DBMS Servers Standard Network Protocol

45 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-specific Network Protocol

46 Prof. Dr. T. Kudraß46 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");

47 Prof. Dr. T. Kudraß47 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();

48 Prof. Dr. T. Kudraß48 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");

49 Prof. Dr. T. Kudraß49 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();

50 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?)

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

52 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 FileJava File Class File SQL Translator Java Compiler

53 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 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());} // Ergebnismenge schließen recRec.close();

54 Prof. Dr. T. Kudraß54 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) {...

55 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

56 Prof. Dr. T. Kudraß56 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

57 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

58 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

59 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

60 Prof. Dr. T. Kudraß60 XML-Beispiel (Bücherliste) Milan Kundera Identity 1998 Richard Feynman The Character of Physical Law

61 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 [ ]>

62 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: Nachteil: Mangelnde Flexibilität bei der Präsentation (Font-Größe, Hintergrund-Farbe) –In MathML Presentation Elements, Content Elements Beispiel: x y 2

63 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 $1 in www.booklist.com/books.xml CONSTRUCT $1 –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)

64 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

65 Prof. Dr. T. Kudraß65 Beispiel: Daten der Buchliste in OEM MilanKundera Identity1998 BOOK AUTHORTITLEPUBLISHEDAUTHORFORMAT TITLE RichardFeynman The character of phy- sical law Hard- cover

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

67 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 Mobile James Agent Invertierte ListeWord

68 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 10112 11101 SignatureRID 0001Mobile 1100James 1010Agent HashWord Beispiel:

69 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

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