Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Architektur von Web- Datenbanksystemen. © Prof. T. Kudraß, HTWK Leipzig 2 Schichtenarchitektur Aufteilung einer Web-DB-Anwendung in verschiedene Schichten.

Ähnliche Präsentationen


Präsentation zum Thema: "Architektur von Web- Datenbanksystemen. © Prof. T. Kudraß, HTWK Leipzig 2 Schichtenarchitektur Aufteilung einer Web-DB-Anwendung in verschiedene Schichten."—  Präsentation transkript:

1 Architektur von Web- Datenbanksystemen

2 © Prof. T. Kudraß, HTWK Leipzig 2 Schichtenarchitektur Aufteilung einer Web-DB-Anwendung in verschiedene Schichten Logische Schichten vs. physische Schichten Physisch: – Aufteilung der Anwendung auf Client, DB-Server und Middleware – Middleware: ein Webserver oder mehrere Application Server Logisch: – Einordung in einzelne Schichten hinsichtlich der Aufgabenverteilung – Gängiges Modell: 3-Schichten-Architektur

3 © Prof. T. Kudraß, HTWK Leipzig 3 3-Schichten-Architektur Präsentationsschicht – Visualisierung der Dokumente auf Anwenderseite – Keine Anwendungslogik zur Erstellung der Seiten (thin clients) – Client = Rechner mit Browser einschl. PlugIns Anwendungslogikschicht – Weiterleitung von Anfragen des Client an den entsprechenden Dienst, Datenbankanfragen, Erstellung dynamischer Seiten und Zurücksendung an den Client – Weitere Aufgaben: Verwaltung von Transaktionen Lastverteilung der Anfragen Sicherheitsaufgaben Datenhaltungsschicht – Speicherung der Daten + Datenzugriff – Typischerweise Datebanksystem (auch Dateien möglich)

4 © Prof. T. Kudraß, HTWK Leipzig 4 3- und 4-Schichtenarchitekturen

5 © Prof. T. Kudraß, HTWK Leipzig 5 Klassifikation von Web- Informationssystemen (WebIS) unterschiedliche Komplexitätsgrade Anwendungsgebiet bestimmt Architektur in komplexen WebIS mehrere Architektur- varianten gleichzeitig vorhanden Varianten: 1. Statische WebIS 2. WebIS mit DB-Unterstützung 3. Applikationsorientierte WebIS 4. Ubiquitäre WebIS 5. Portal-orientierte WebIS

6 © Prof. T. Kudraß, HTWK Leipzig 6 Statische WebIS Dokumente in statischer Form auf Webserver abgelegt Basis: HTTP-Protokoll: Web-Client Web-Server einfache Interaktivität (CGI, HTML-Formulare) Vermischung von Präsentation, Inhalt und Hypertext manuelle Pflege, Gefahr von Inkonsistenzen

7 © Prof. T. Kudraß, HTWK Leipzig 7 Statische WebIS: Bewertung Vorteile – Einfachheit und Stabilität – niedrige Antwortzeiten Einsatzgebiet – geringe Anzahl von Webseiten – niedrige Änderungsfrequenz – Heterogenität der Webseiten hinsichtlich Hypertextstruktur und Präsentation

8 © Prof. T. Kudraß, HTWK Leipzig 8 WebIS mit DB-Unterstützung Vorteile – vereinfachte Aktualisierung der Webseiten – hoher Grad an Interaktivität strukturierte Suche auf Basis von DB-Anfragen dezentrale Aktualisierung des Datenbestandes Nachteile – Verwaltung der Abbildungsvorschriften für Zusammenstellung der Webseite erforderlich Web-ClientWeb-Server DBS-Server Präsentation Inhalt

9 © Prof. T. Kudraß, HTWK Leipzig 9 WebIS mit DB-Unterstützung (Forts.) Motivation (Einsatzgebiet z.B. Produktkatalog): – große Anzahl von Webseiten – hohe Änderungsfrequenz – Homogenität der Webseiten hinsichtlich Hypertext- struktur und Präsentation – Nutzung existierender (Legacy)Datenbestände Weiterführung – Integration heterogener verteilter Daten strukturierte Daten (Datenbanken) unstrukturierte Daten (Textdokumente) semistrukturierte Daten (HTML-Dateien)

10 © Prof. T. Kudraß, HTWK Leipzig 10 Applikationsorientierte WebIS Funktionalität des Applikations-Servers – DB-Anbindung – Transaktionsmanagement – Sicherheit – Lastausgleich – Caching Web-ClientWeb-Server DBS-Server Präsentation Applikationslogik Applikations- Server Inhalt IIOP

11 © Prof. T. Kudraß, HTWK Leipzig 11 Applikationsorientierte WebIS (Forts.) Produkte – kombinierte Web-/Applikationsserver: Coldfusion, Netscape Application Server, Oracle Internet Application Server – Enterprise-Application-Server: WebSphere (IBM), WebLogic (Bea Systems) Motivation – hohe zu erwartende Server-Last, bei großer Anzahl gleich- zeitig zugreifender Clients – komplexe Geschäftslogik, z.B. bei Online-Kauf oder Online- Buchung) – hohe Transaktionsorientiertheit, z.B. bei Online-Banking- Anwendungen

12 © Prof. T. Kudraß, HTWK Leipzig 12 Ubiquitäre WebIS Ziel – richtigen Dienst – zum richtigen Zeitpunkt – am richtigen Ort – in der richtigen Form anbieten Web-ClientWeb-Server DBS-Server Präsentation Applikationslogik Applikations- Server Inhalt Anpassungs- komponente

13 © Prof. T. Kudraß, HTWK Leipzig 13 Ubiquitäre WebIS (Forts.) Produkte – Oracle Wireless Application Server – WebSphere Transcoding Publisher (IBM) Motivation – Zugriff auf die im WebIS präsentierte Information nicht nur über WWW, sondern z.B. auch über mobile Endgeräte – Anpassung der Inhalte und/oder der Präsentationsaspekte an Benutzerprofile (Personalisierung) – Realisierung lokations/zeitabhängiger Dienste, wie z.B. lokationssensitiver Museumsführer

14 © Prof. T. Kudraß, HTWK Leipzig 14 Portal-orientierte WebIS Web-ClientWeb-Server Daten 1 Präsentation Aggregation Inhalt Applikationslogik Portlet 1 Web Service 1 Portlet 2 Web Service 2 Portlet 3 Web Service 3 Daten 2Daten 3 Architektur eines portal-orientierten WebIS

15 © Prof. T. Kudraß, HTWK Leipzig 15 Portalorientiertes WebIS (Forts.) Große Anwendungen mit vielen Diensten erfordert portalorientierte Architektur Portal = zentraler Zugang zu einem Anwendungssystem, welches verschiedene Dienste und Anwendungen integriert und z.B. Funktionen zur Suche oder Personalisierung bereitstellt Portlets = Teile von Dokumenten aus unterschiedlichen Quellen Zusammensetzen von Portlets zu ganzen Seiten, die über Web-Server an den Client verschickt werden Einsatz von Web Service-Technologien, die den Aufruf von Diensten über definierte Schnittstellen ermöglichen Vorteil hohe Flexibilität bei der Verwendung der Portlets

16 © Prof. T. Kudraß, HTWK Leipzig 16 HTTP-Protokoll Hypertext Transfer Protokoll (HTTP) für Kommunikation zwischen Web-Server und Client Funktionsweise: Request-Response-Prinzip – HTTP-Request: URL – HTTP-Response: gewünschte Dokument Verbindungs- und statusloses Protokoll: keine dauerhafte Verbindung, keine Speicherung des Zustands zwischen Client und Server Methoden zur Anforderung eines Dokuments – GET: Client fordert die angegebene URL an, wobei eventuelle Parameter im String der URL mitgegeben werden – POST: Client schickt Daten an den Server, wobei diese nicht in der URL sondern direkt im Header der Anforderung übergeben werden – HEAD, PUT, DELETE: keine Bedeutung für die Entwicklung von Webapplikationen

17 © Prof. T. Kudraß, HTWK Leipzig 17 HTTP Request 1. Zeile: Methode, Ressource, Version des HTTP- Protokolls GET HTTP/1.0 Mehre Message Header, die zusätzliche Informationen übertragen – Accept: MIME-Typen, die der Client verarbeiten kann – Host: Domainname des Webservers – Referer: URL der Herkunftsressource – User-Agent: Name und Version des Clientbrowsers – Authorization: Benutzername und Paßwort des Clients, Authorization Header als Reaktion auf WWW-Authenticate- Header des Servers zum Zugriff auf das gewünschte Dokument Bei Methode POST: Anhängen von Daten (aus Formular) an die Headerinformationen, z.B. Eingabe1=Strasse&Eingabe2=54455

18 © Prof. T. Kudraß, HTWK Leipzig 18 HTTP Response Status – Version des verwendeten HTTP-Protokolls – Statuscode – textuelle Beschreibung des Status Beispiel: Optionale Response-Header – Server: Name und Version des Webservers – WWW-Authenticate: Verlangt vom Client eine Authentifizierung und gibt u.a. das Authentifizierungsschema an – Location: URL der Ressource Eigentliches Dokument (falls eines zurückgeliefert werden soll) Titelzeile …

19 © Prof. T. Kudraß, HTWK Leipzig 19 Anbindungsarchitekturen

20 © Prof. T. Kudraß, HTWK Leipzig 20 Anbindungsarchitekturen - Varianten 1.Anwendung mit statischen Seiten: Datenbankinhalte manuell einarbeiten, keine Kommunikation mit der Datenbank 2.Realisierung der Webanwendung als CGI-Programm: Datenbankzugriff vom Programm. Die fertige HTML-Seite wird zum Client übertragen. 3.Applets werden zum Client übertragen und dort ausgeführt. Die Kommunikation mit der DB findet dabei direkt mit dem Client statt, z.B. über JDBC (nicht HTTP!) 4.Server-APIs: serverseitige Erweiterungen für den Zugriff auf die Datenbank und den Aufbau der HTML-Datei. 5.Einsatz von Servlets in der Serverumgebung, erfordert spezielle Servlet Engine und eine Java Virtual Machine (JVM). DB-Zugriff erfolgt z. B. über die JDBC-API oder direkt, wenn Servlet Engine im Datenbankserver integriert ist. 6.Auslagerung komplexer Programmlogik auf einen Applikationsserver. Dieser realisiert auch die Verbindung zur Datenbank, wobei DB- Verbindungen zur Performance-Verbesserung zwischengespeichert werden. 7.Erstellung der HTML-Dateien über einen Präprozessor: Verarbeitung von XML- und XSL-Dateien (siehe auch Vorlesung XML-Datenbanken / 7. Semester)

21 © Prof. T. Kudraß, HTWK Leipzig 21 Anbindungstechnologien

22 © Prof. T. Kudraß, HTWK Leipzig 22 Anforderungen an eine DB-Server- Anbindung Integrierte Benutzerschnittstelle – Verschiedene Medientypen – Browser-Darstellung, keine proprietären Formate Interaktivität – erfordert zustandswahrende Verbindung Konsistenz und Datenintegrität Performance Sicherheit – Programme, die von Web-Server geladen werden Skalierbarkeit Offenheit – Konflikt mit Performance (Java vs. Microsoft)

23 © Prof. T. Kudraß, HTWK Leipzig 23 Client-Seitige DB-Anbindungen Prinzip: – Übertragung von Java Applets (plattformunabhängiger Bytecode) vom Web-Server zum Client – Direkte Verbindung zum Datenbank-Server über JDBC – Ausführung der Clients durch eine Java Virtual Machine (JVM) Web-ClientWeb-Server DBS-Server JVM Applet JDBC

24 © Prof. T. Kudraß, HTWK Leipzig 24 Serverseitige DB-Anbindung Generierung von HTML-Seiten im Server und Zurücksenden an den Client Daten aus der Datenbank können in HTML-Dokument enthalten sein 2 Ansätze (je nach Generierungsmethode) – Externe Programme: erzeugen den HTML-Code des Dokuments (HTML-Generierende Anwendungen) – Erweiterung der Serverfunktionalität: Anreicherung des HTML- Codes um spezifische Funktionalitäten zum Einfügen von dynamischem Inhalt ins Dokument (HTML-Erweiterungen)

25 © Prof. T. Kudraß, HTWK Leipzig 25 Serverseitige Anbindung: Externe Programme

26 © Prof. T. Kudraß, HTWK Leipzig 26 Serverseitige Anbindung: Erweiterung der Serverfunktionalität

27 © Prof. T. Kudraß, HTWK Leipzig 27 Serverseitige Anbindung Dokumente können nur die Darstellungsmöglichkeiten von HTML nutzen Überprüfung von Benutzereingaben durch clientseitige Skriptsprache (Java Script) oder nach Senden der Anfrage Anzeige der Seiten auf beliebigem Browser, keine zusätzliche Installation von Programmen auf Clientseite erforderlich DB-Verbindung wird nur von Seiten des Web- oder Applikationsservers aufgebaut, keine Verbindung von der Clientseite über das zustandslose HTTP-Protokoll mehrschrittige Anfragen eines Clients an die DB nur über Umwege realisierbar

28 © Prof. T. Kudraß, HTWK Leipzig 28 Serverseitige Technologien im Überblick CGI (am Beispiel Perl) Web-Server API Server Side Include (SSI) Active Server Page (ASP) PL/SQL und PL/SQL Server Page (PSP) PHP Übergreifende Technologien – Java Database Connectivity (JDBC) – SQLJ – Java und J2EE (Enterprise Java Beans) Java Servlet Java Server Page (JSP)

29 © Prof. T. Kudraß, HTWK Leipzig 29 Common Gateway Interface (CGI) Keine Programmiersprache Kann mit allen Sprachen realisiert werden, die Zugriff auf Umgebungsvariable sowie die Standardein- und ausgabe erlauben (z.B. Perl, C, C++) Standardisierte Schnittstelle für die Kommunikation zwischen Web-Server und externen Programmen (Übergabe von Daten von HTML-Seiten an Programme) Aufbau – Verschiedene Umgebungsvariablen für die Datenübertragung Web-Server CGI-Programm – Variablen mit festem Namen bei jeder Client-Anfrage neu initialisiert und vom CGI-Programm für die HTML-Generierung nutzbar

30 © Prof. T. Kudraß, HTWK Leipzig 30 Umgebungs- variablen einer CGI-Anwendung

31 © Prof. T. Kudraß, HTWK Leipzig 31 Allgemeiner Ablauf der Programmausführung bei CGI Allgemeines Prinzip: Client (Anwender) Server-Rechner HTML-Datei mit Formular Daten- bank WWW- Server automatisch erzeugte HTML-Datei CGI- Skript automatisch erzeugte HTML-Datei 1. Formular abschicken übertragen 2. CGI-Skript aufrufen 5. HTML-Datei übertragen 3. DB abfragen Abfrage-Report der DB auswerten 4. HTML-Datei aus Abfrage-Report erzeugen

32 © Prof. T. Kudraß, HTWK Leipzig 32 Ablauf der Verarbeitung bei Ablauf eines CGI-Programms

33 © Prof. T. Kudraß, HTWK Leipzig 33 CGI Bewertung Vorteile: – Unterstützung durch alle Web-Server – anforderungsspezifisch programmiert – schnell und flexibel Nachteile: – Pro Interaktion Start eines CGI-Prozesses / Aufbau einer DB- Verbindung (Verbesserung FastCGI) – Kein Transaktionskonzept zwischen Client und WWW-Server, Problem der Realisierung von Zuständen – Logische Formular-Eingabefehler erst im CGI-Programm erkannt – Sicherheit (da Zugriff auf Betriebssystem-Ressourcen des Web- Servers) – Aufwendige Programmerstellung – Formatierung des Dokuments problematisch, da generiert

34 © Prof. T. Kudraß, HTWK Leipzig 34 Active Server Pages (ASP) HTML Dokument mit eingebetteten Anweisungen in VBScript oder JScript ASP Bestandteil des Internet Information Server große Funktionalität durch Mächtigkeit der Skript- Sprachen (aber geringer als Java/C++) Einbettung von SQL in Skriptsprache (DB-Zugriff über ODBC und ADOs) Session Management mit Hilfe von Session-IDs (von Cookies übertragen) Zugriff auf Formular- und Umgebungsvariablen

35 © Prof. T. Kudraß, HTWK Leipzig 35 Ablauf der Verarbeitung mit PL/SQL Entwicklungsunterstützung durch WebServer Developers Toolkit (Menge von Packages) HTP (HyperText Procedures) HTF (HyperText Functions) – erleichtern die Generierung von HTML-Tags aus PL/SQL heraus OWA_UTIL – Dienstfunktionen für eine bequemere Generierung von HTML-Output

36 © Prof. T. Kudraß, HTWK Leipzig 36 Toolkit - Beispiele htp.title(My First Page Title); PL/SQL HTML My First Page Title Funktionsauruf title:=htf.title(My First Page Title) Verschachtelung htp.center(htf.header(1,My First HTML Header - Level 1)); My First HTML Header - Level 1

37 © Prof. T. Kudraß, HTWK Leipzig 37 Toolkit - Überblick 1.Print-Prozeduren 2.Struktur-Tags 3.Head-Related Tags 4.Body Tags 5.List Tags 6.Character Format Tags 7.Form Tags 8.Table Tags 9.OWA_UTIL Package

38 © Prof. T. Kudraß, HTWK Leipzig 38 Beispiel: Web Server Developer Kit CREATE OR REPLACE PROCEDURE home_page AS BEGIN htp.htmlOpen; htp.headOpen; htp.title(My home page); htp.headClose; htp.bodyOpen; htp.print (This is the home page of || user || generated on || sysdate ||.); htp.bodyClose; htp.htmlClose; END; CREATE OR REPLACE PROCEDURE home_page AS BEGIN htp.htmlOpen; htp.headOpen; htp.title(My home page); htp.headClose; htp.bodyOpen; htp.print (This is the home page of || user || generated on || sysdate ||.); htp.bodyClose; htp.htmlClose; END;

39 © Prof. T. Kudraß, HTWK Leipzig 39 PL/SQL Server Pages (PSP) Grundidee – Internet-Seiten mit dynamischer Präsentation von Inhalten durch Einsatz von PL/SQL-Anweisungen – Server-Side Scripting (Generierung der Seiten im DB-Server - nicht im Webserver) – Basiert auf PL/SQL Web Toolkit – Bestandteil von Oracle Application Server (OAS) und Oracle WebDB – Einbindung dynamischer Inhalte durch PL/SQL- Skripte, durch spezielle Tags gekennzeichnet

40 © Prof. T. Kudraß, HTWK Leipzig 40 PSP Beispiel Beispielseite mit PL/SQL Server Page Beispielseite mit PL/SQL Server Page <% -- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then %> Hallo. Client-IP-Adresse: Bitte Namen eingeben: Beispielseite mit PL/SQL Server Page Beispielseite mit PL/SQL Server Page <% -- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then %> Hallo. Client-IP-Adresse: Bitte Namen eingeben:

41 © Prof. T. Kudraß, HTWK Leipzig 41 Schrittfolge PSP Kompilieren der PSP-Datei mittels loadpsp Erzeugen einer gespeicherten Prozedur in der Datenbank (Procedure-Tag) HTML-Anweisungen werden unter Verwendung des PL/SQL Web-Toolkits in Print-Anweisungen des HTTP- Pakets umgewandelt PL/SQL-Anweisungen der Skripteinschübe werden unverändert übernommen Komfortablere Entwicklung, da automatische Übersetzung

42 © Prof. T. Kudraß, HTWK Leipzig 42 PSP Beispiel – Generierter PL/SQL Code (Gespeicherte Prozedur) ( p_name IN VARCHAR2 default null) AS BEGIN NULL; htp.prn( Beispielseite mit PL/SQL Server Page Beispielseite mit PL/SQL Server Page ); -- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then htp.prn( Hallo ); htp.prn(p_name); [...] ( p_name IN VARCHAR2 default null) AS BEGIN NULL; htp.prn( Beispielseite mit PL/SQL Server Page Beispielseite mit PL/SQL Server Page ); -- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then htp.prn( Hallo ); htp.prn(p_name); [...]

43 © Prof. T. Kudraß, HTWK Leipzig 43 Verarbeitung einer PSP 1. Weiterleiten der Anfrage vom Browser an den Modul mod_plsql 2. Verbindung zur Datenbank, Ausführung der gespeicherten Prozedur 3. Erzeugung einer HTML-Seite durch Prozedur 4. Zurücksenden des HTML- Dokuments an mod_plsql 5. Zurücksenden der HTML-Seite als HTTP-Response zum anfragenden Client

44 © Prof. T. Kudraß, HTWK Leipzig 44 Vorteile von PSP Trennung von Anwendungs- und Präsentationslogik – HTML-Anweisungen und PL/SQL Code separat – Abgrenzung durch PL/SQL-spezifische Tags Leichte Erlernbarkeit Einfacher Zugriff auf Daten der Datenbank – Kein Umweg über HTTP oder JDBC Ausführung im Server (PSP selbst in der DB) Verbindung mit anderen Skriptsprachen möglich – z.B. Javascript oder Visual Basic-Script (zur Prüfung von Benutzereingaben) – nicht kombinierbar mit anderen serverseitigen Scripting- techniken

45 © Prof. T. Kudraß, HTWK Leipzig 45 Nachteile von PSP Stärkere Beanspruchung des DB-Servers – Statische Seiten besser im Web-Server speichern Plattformabhängigkeit – Beschränkt auf Oracle – Migration auf andere DB erfordert Neuentwicklung der Anwendung

46 © Prof. T. Kudraß, HTWK Leipzig 46 PHP PHP = Personal Homepage Tools (war ursprünglich eine Sammlung von Tools und Makros) entwickelt von Rasmus Lerdorf 1994, Open Source Produkt serverseitige, in HTML eingebettete Script-Sprache (Ausführung auf dem Webserver) plattformunabhängig unterstützt umfangreiche Menge von Oracle- Funktionen (erfordert Installation im Web-Server) verwandt mit – Active Server Pages (ASP) von Microsoft – Java Server Pages (JSP) – PL/SQL Server Pages (PSP) von Oracle

47 © Prof. T. Kudraß, HTWK Leipzig 47 PHP PHP-Seite als Script-Datei – Extension.php – Verarbeitung durch PHP-Prozessor Einbettung von Skripteinschüben in spezielle Tags – – echo Hello world!;

48 © Prof. T. Kudraß, HTWK Leipzig 48 Verarbeitung einer PHP-Seite

49 © Prof. T. Kudraß, HTWK Leipzig 49 PHP Beispiel Testseite mit PHP Testseite mit PHP

50 © Prof. T. Kudraß, HTWK Leipzig 50 Java und Datenbanken Java Database Connectivity (JDBC) – Idee – Drivertypen – Klassen und Schnittstellen SQLJ (Embedded SQL in Java) J2EE Anwendungen Java Servlets Java Server Pages

51 © Prof. T. Kudraß, HTWK Leipzig 51 Java Database Connectivity (JDBC) Motivation: – Zugriff auf SQL-Datenbanken mit Java benötigt – Nachteil selbstgestrickter Java-Zugriffsmethoden aufwendig fehlerbehaftet nicht einfach portierbar – Überwindung des Mismatch zwischen Java (objektorientiert, ohne Pointer) C (prozedural, mit Pointern) SQL (mengenorientiert) Beziehung zu ODBC – Wurde in Anlehnung an ODBC (Open Database Connectivity) entwickelt und mit einer ähnlichen Klassenbibliothek ausgestattet

52 © Prof. T. Kudraß, HTWK Leipzig 52 JDBC (Forts.) 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

53 © Prof. T. Kudraß, HTWK Leipzig 53 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)

54 © Prof. T. Kudraß, HTWK Leipzig 54 JDBC-Architektur Application Driver Manager Driver Driver Driver Data source Data source Data source JDBC API JDBC Driver API Proprietär

55 © Prof. T. Kudraß, HTWK Leipzig 55 JDBC Klassen und Interfaces java.sql.DriverManager (class, class methods) java.sql.Connection (interface) java.sql.Statement (interface) java.sql.Resultset (interface) java.sql.Driver (interface, drivers only)

56 © Prof. T. Kudraß, HTWK Leipzig 56 Überblick: Datenbankanfragen mit JDBC Query Close Connect Process results Datenbankverbindung herstellen Datenbankanfrage Verbindung zur DB schließen Ergebnisse verarbeiten

57 © Prof. T. Kudraß, HTWK Leipzig 57 Phase 1: Connect Query Close Connect Process results Driver registrieren Verbindung zur Datenbank

58 © Prof. T. Kudraß, HTWK Leipzig 58 Phase 2: Query Close Connect Query Erzeuge ein Statement Process results Abfrage auf Datenbank

59 © Prof. T. Kudraß, HTWK Leipzig 59 Statement Object Ein Statement Objekt sendet SQL-Befehl zur Datenbank. Man benötigt aktive Connection, um JDBC Statement zu erzeugen. Statement hat drei Methoden, um ein SQL Statement zu erzeugen: – executeQuery() für QUERY Statements – executeUpdate() für INSERT, UPDATE, DELETE, oder DDL statements – execute() für beliebiges Statement

60 © Prof. T. Kudraß, HTWK Leipzig 60 Phase 3: Verarbeiten der Ergebnisse Close Query Durchlaufen der Ergebnisse Process Results Zuweisen der Ergebnisse an Java- Variablen Connect

61 © Prof. T. Kudraß, HTWK Leipzig 61 Das ResultSet Objekt JDBC liefert die Ergebnisse einer Query in einem ResultSet Objekt. Ein ResultSet verwaltet einen Cursor, der auf den aktuellen Datensatz zeigt. Verwende next() zum Durchlaufen des Result Set Satz für Satz. getString(), getInt(), usw. für Wertzuweisung an Java-Variablen.

62 © Prof. T. Kudraß, HTWK Leipzig 62 Phase 4: Close Connect Query Process Results Close Schließe Result Set Schließe Statement Schließe Connection

63 © Prof. T. Kudraß, HTWK Leipzig 63 JDBC 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"); // 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");

64 © Prof. T. Kudraß, HTWK Leipzig 64 JDBC 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(); // 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();

65 © Prof. T. Kudraß, HTWK Leipzig 65 JDBC 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");

66 © Prof. T. Kudraß, HTWK Leipzig 66 JDBC 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();

67 © Prof. T. Kudraß, HTWK Leipzig 67 J2EE Anwendungen J2EE = Java 2 Platform Enterprise Edition Standard für die Entwicklung mehrschichtiger, komponentenbasierter Java-Anwendungen Vereinfacht Entwicklung durch Definition eines Programmiermodells auf Basis von standar- disierten und komponentenbasierten Objekten Oracle Application Server Oracle10gAS (OC4J) – vollständige Umsetzung eines J2EE-Containers: JSP, Java Servlets, EJB, JDBC

68 © Prof. T. Kudraß, HTWK Leipzig 68 Java Servlets Einordnung: – kleine Serverprogramme Voraussetzung – Integration einer JVM in den Web-Server bzw. Kooperation mit einem Zusatzprozess – Voller Zugriff auf Java-API Vorteile: – Plattform- und herstellerunabhängige Erweiterung von Web- Servern möglich (durch standardisierte Servlet-API) – Dynamisches Binden möglich (Java-Klassenlader) Hinzufügen und Entfernen von Modulen ohne Neustart des Servers

69 © Prof. T. Kudraß, HTWK Leipzig 69 Web/DB-Anbindung über Java Servlets Weitere Vorteile alle Möglichkeiten der Sprache Java Web-ClientWeb-Server Servlet-Engine DB-Server Java- Klassenbibliothek HTTP JVMJVM JDBC gleiches Sicherheitskonzept wie Java (Security Manager), verhindert Ressourcenmißbrauch Leistung: bleiben im Speicher des Servers, DB-Verbindung nur einmal nötig Lastverteilung: Aufruf anderer Servlets möglich mehr Programmieraufwand, Ent- wicklungsumgebungen verfügbar


Herunterladen ppt "Architektur von Web- Datenbanksystemen. © Prof. T. Kudraß, HTWK Leipzig 2 Schichtenarchitektur Aufteilung einer Web-DB-Anwendung in verschiedene Schichten."

Ähnliche Präsentationen


Google-Anzeigen