Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Architektur von Web- Datenbanksystemen. © Prof. T. Kudraß, HTWK Leipzig 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 Schichtenarchitektur Aufteilung einer Web-DB-Anwendung in verschiedene Schichten."—  Präsentation transkript:

1 Architektur von Web- Datenbanksystemen

2 © Prof. T. Kudraß, HTWK Leipzig 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-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 Analogie: Winsbergs Modell Remote PresentationDistributed LogicRemote Data Access Presentation Mgr. Presentation Logic Data Logic Data Manager Data Logic

5 © Prof. T. Kudraß, HTWK Leipzig Verteilung der Schichten Anorexic ClientBig-Boned ClientFat Client Web BrowserView Application Model Domain Persistence Domain Application Model View: Servlets

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

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

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

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

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

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

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

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

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

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

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

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

18 © Prof. T. Kudraß, HTWK Leipzig HTTP Request 1. Zeile: Methode, Ressource, Version des HTTP- Protokolls GET http://www.test.de/index.html 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

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

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

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

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

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

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

25 © Prof. T. Kudraß, HTWK Leipzig Eigenschaften der clientseitigen Anbindung über 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)

26 © Prof. T. Kudraß, HTWK Leipzig Nachteile von Applets Client-seitige Unterstützung ist notwendig (z.B. JVM) Java-Sicherheitsrestriktionen 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

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

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

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

30 © Prof. T. Kudraß, HTWK Leipzig Vergleich der client- und serverseitigen Anbindung Präsentation und Eingabe von Daten – Clientseitig: alle Darstellungsmöglichkeiten der verwendeten Programmiersprache Prüfung von Benutzereingaben vor Absenden der Anfrage abhängig von Installation aller benötigten Programme / Plug-Ins auf der Clientseite – Serverseitig: 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

31 © Prof. T. Kudraß, HTWK Leipzig Vergleich der client- und serverseitigen Anbindung (2) Datenbankanbindung und Transaktionsunter- stützung – Clientseitig: Direkte Verbindung zwischen Anwendung und Datenbank (ohne HTTP) DB-Verbindung kann über die Laufzeit offen bleiben lange Transaktionen möglich – Serverseitig: 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

32 © Prof. T. Kudraß, HTWK Leipzig Vergleich der client- und serverseitigen Anbindung (3) Performance – Clientseitig: Lange Ladezeit: Anwendung muß komplett zum Client übertragen werden Ausführungsgeschwindigkeit abhängig von Leistungsfähigkeit des Clientrechners Gute Performance bezüglich der Anfrage an die Datenbank, da direkte Kommunikation über DB-Protokolle – Serverseitig: Ausführungsgeschwindigkeit davon abhängig, ob jedesmal ein Programm gestartet werden bzw. HTML-Dokumente nach Skripteinschüben geparst Kommunikation zur Datenbank ist langsamer als bei clientseitiger Anbindung, da Umweg über Web- oder Applikationsserver

33 © Prof. T. Kudraß, HTWK Leipzig Oracle Application Server Oracle 9iAS

34 © Prof. T. Kudraß, HTWK Leipzig Oracle HTTP Server

35 © Prof. T. Kudraß, HTWK Leipzig Oracle HTTP Server im Detail Basiert auf Apache HTTP Server und wurde um einige Funktionalitäten erweitert (Oracle-spezifische Module) HTTP-Listener wartet auf ankommende Anfragen vom Client und leitet diese entsprechend ihres Typs an das jeweilige Modul im Server Wichtige Module: – mod_perl: leitet Anfragen an den Perl-Interpreter weiter, der im HTTP-Server enthalten ist, zur Unterstützung der CGI-Schnittstelle – mod_plsql: Anfragen an gespeicherte Prozeduren in der Datenbank – mod_oc4j: Modul für die Kommunikation mit dem Oracle 9iAS Container für J2EE-Anwendungen – mod_osso: Single Sign-On für alle Oracle9iAS Komponenten – mod_ossl: SSL-Verbindung zwischen HTTP-Server und Client (HTTPS)

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

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

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

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

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

41 © Prof. T. Kudraß, HTWK Leipzig CGI-Programmbeispiel (mSQL)

42 © Prof. T. Kudraß, HTWK Leipzig CGI-Programmbeispiel (Perl) print "Content-type: text/html\n\n"; $values = ; ($name, $wert) = split( /=/, $values); $name =~ s/\%(..)/pack("c",hex($1))/ge; $wert =~ s/\%(..)/pack("c",hex($1))/ge; print " ", " ", " Testseite mit Perl ohne cgi.pm "; print " ", " Testseite mit Perl ohne cgi.pm "; if ($wert) { print ("Hallo $wert. "); # Zugriff auf CGI-Umgebungsvariable print ("Client-IP-Adresse: $ENV{REMOTE_ADDR}"); } print ' Bitte Namen eingeben: '; print ' '; print" ", " ", " ";

43 © Prof. T. Kudraß, HTWK Leipzig Ausgabe der Beispielseite

44 © Prof. T. Kudraß, HTWK Leipzig CGI-Programbeispiel (gleiche Seite) mit Perl-Modul cgi.pm use CGI qw(:standard); # Variable name auslesen $name = param("name"); # Header schreiben: Content-type: text/html print header; # Start-HTML mit Titel print start_html("Testseite mit Perl und cgi.pm"); # Ausgabe Überschrift des Typs H1 print h1("Testseite mit Perl und cgi.pm"); # Wenn Name gesetzt, ausgeben if ($name) { print ("Hallo $name. "); # Zugriff auf CGI-Umgebungsvariable print ("Client-IP-Adresse: $ENV{REMOTE_ADDR}"); } # Formularkopf print start_form; # Eingabefeld für Name mit Bezeichnung Name print ("Bitte Namen eingeben: ", textfield("name","")); # Submit-Button print submit(-name=>'button_submit', -value=>'Submit'); # Formularende print end_form; # HTML-Ende ( ) print end_html();

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

46 © Prof. T. Kudraß, HTWK Leipzig Web-Server API Prinzip: – nutzereigene Funktionen (Custom Functions) und servereigene Funktionen (Server Application Functions) auf Basis des API des Web-Servers – Kein externes Programm für DB-Zugriff mehr notwendig – Server entscheidet anhand URL, ob (prozeßinterne) Erweiterungsfunktion aufgerufen werden muß Vorteile: – Sitzungen können im Web-Server verwaltet werden – Performance-Gewinn durch dauerhafte DB-Verbindung und gemeinsame Nutzung des Hauptspeichers Nachteile: – Gefahr des Hängenbleibens offener DB-Verbindungen – Proprietäre Web-Server-Software (z.B. Internet Server API (ISAPI) von Microsoft inkompatibel zu Netscape Server API (NSAPI)

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

48 © Prof. T. Kudraß, HTWK Leipzig SSI mit LiveWire Web-Client Web-Server NS-API SSJS-Funktionen LiveWire DBS- Server OCI HTTP... database.CONNECT(...) result = database.cursor(SELECT name,age FROM Person) name1 = result.name age1 = result.age document.WRITELN(name1 +, + age1 + ) name2 = result.name...... database.CONNECT(...) result = database.cursor(SELECT name,age FROM Person) name1 = result.name age1 = result.age document.WRITELN(name1 +, + age1 + ) name2 = result.name... SSI-Beispiel mit LiveWire

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

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

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

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

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

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

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

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

57 © Prof. T. Kudraß, HTWK Leipzig 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); [...]

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

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

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

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

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

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

64 © Prof. T. Kudraß, HTWK Leipzig PHP Beispiel Testseite mit PHP Testseite mit PHP <?php // Lesen des per HTTP-Post übertragenen Parameters aus Array $p_name = $_POST['p_name']; if ($p_name) { // Namen ausgeben, wenn eingegeben. print("Hallo $p_name. "); // Zugriff auf Umgebungsvariable print("Client-IP-Adresse: ".$_SERVER['REMOTE_ADDR']); } Bitte Namen eingeben: Testseite mit PHP Testseite mit PHP <?php // Lesen des per HTTP-Post übertragenen Parameters aus Array $p_name = $_POST['p_name']; if ($p_name) { // Namen ausgeben, wenn eingegeben. print("Hallo $p_name. "); // Zugriff auf Umgebungsvariable print("Client-IP-Adresse: ".$_SERVER['REMOTE_ADDR']); } Bitte Namen eingeben:

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

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

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

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

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

70 © Prof. T. Kudraß, HTWK Leipzig Driver Typ 1: JDBC-ODBC-Bridge Java Anwendung JDBC Driver Manager JDBC-ODBC Bridge DBMS Server LAN oder Intranet Client ODBC DBMS Client Bibliothek 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 Nicht für Internet-Anwendungen ODBC hat nicht Funktionsumfang von JDBC JDBC API

71 © Prof. T. Kudraß, HTWK Leipzig Driver Typ 2: Partial-Java-JDBC Driver Nutzt verfügbare Technologie: Übersetzt JDBC-Aufrufe in Aufrufe einer nativen Datenbank- API Nicht geeignet für Internet- Anwendungen Abbildungsschicht und DBMS- spezifische Software müssen auf dem Client-Rechner vorinstalliert sein Effizient durch Direktzugriff auf die Datenbank Nicht binärkompatibel mit anderen Plattformen Java Anwendung JDBC Driver Manager Partial Java JDBC Driver DBMS Server LAN oder Intranet Client DBMS Client Bibliothek JDBC API

72 © Prof. T. Kudraß, HTWK Leipzig Driver Typ 3: Pure-Java-JDBC-Middleware Driver Java Applet/Anwendung JDBC API Pure-Java-JDBC-Middleware Driver DBMS 1 Middleware Server Internet oder Intranet Client Wickeln die gesamte DB- Kommunikation über Middleware-Server ab DBMS-unabhängiges Netz- werk-Protokoll (DBMS gekapselt) Ein einziger Driver (Universal Driver) auf dem Client, somit binärkompatible Plattformen Plattformunabhängigkeit (Java) Geeignet für Internet- Anwendungen Höhere Systemsicherheit (Firewall-Lösungen) Schlechtere Antwortzeiten, da Umweg über Middleware DBMS-Client- Bibliothek DBMS 2 DBMS-Client- Bibliothek DBMS Server Standard-Netzwerkprotokoll JDBC Driver Manager

73 © Prof. T. Kudraß, HTWK Leipzig Driver Typ 4: Pure-Java-JDBC-Net Driver Java Applet / Anwendung 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 (daher eher Einsatz in Intranets) Server DBMS-spezifisches Netzwerk-Protocol JDBC-API

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

75 © Prof. T. Kudraß, HTWK Leipzig JDBC Version 2 Neue Methoden / KonzepteErweiterungen von Standard SQL Scrollbare und änderbare ResultSets Connection Pooling SQL:1999-TypenVerteilte Transaktionen Batch UpdatesJava Naming und Directory (JNDI) Package: java.sqlPackage: javax.sql

76 © Prof. T. Kudraß, HTWK Leipzig JDBC vs. ODBC Open Database Connectivity (ODBC) – DBMS-unabhängige Schnittstelle – C-Interface – nicht zur direkten Verwendung aus Java geeignet – Aufrufe von C-Code aus Java beeinträchtigen Sicherheit, Robustheit, leichte Portierbarkeit Vorteile von JDBC – Plattformunabhängigkeit – Einfache Programmierung kurze Entwicklungszeit Nachteile von JDBC – Fehlererkennung erst zur Laufzeit – Performance-Verlust (Interpretation der übersetzten Programme zur Laufzeit) – Lösungen: JITs (Just-in-Time-Compiler) und optimierte JVMs

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

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

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

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

81 © Prof. T. Kudraß, HTWK Leipzig 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 Vorteil: Überprüfung der SQL-Anweisungen auf Typkonsistenz zur Übersetzungszeit 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

82 © Prof. T. Kudraß, HTWK Leipzig Embedded SQL in Java Übersetzung von SQL – Ersetzen der eingebetteten SQL-Statements in JDBC-Aufrufe – Ergebnis: Java-Programm, das normal compiliert wird – Überprüfung von Syntax und Semantik der SQL-Anweisungen Customizer von DBMS-Herstellern – Erzeugen von DB-spezifische SQL Statements aus den SQLJ Statements; wird Teil der SQLJ Applikation – Zur Laufzeit wird für das verwendete DBMS entschieden, ob eine entsprechende Customization existiert, ansonsten Verwendung des originalen JDBC-Codes SQL File Java File Class File SQL Translator Java Compiler

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

84 © Prof. T. Kudraß, HTWK Leipzig Java-Programm mit SQLJ (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) {...

85 © Prof. T. Kudraß, HTWK Leipzig 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 Spracheinbettung Keine dynamischen Anweisungen

86 © Prof. T. Kudraß, HTWK Leipzig 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 Überprüfung von SQL-Anweisungen während der Übersetzungszeit Nachteile von JDBC: Nur statisches SQL Erfordert Präprozessor

87 © Prof. T. Kudraß, HTWK Leipzig 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 Oracle9iAS (OC4J) – vollständige Umsetzung eines J2EE-Containers: JSP, Java Servlets, EJB, JDBC

88 © Prof. T. Kudraß, HTWK Leipzig J2EE-Architektur Komponenten: – Enterprise Java Beans (EJB): Spezifikation für verteilte Java Beans zur Umsetzung von Anwendungslogik und zum Zugriff auf die Datenhaltungs- schicht – Servlets / JSP Pages: für Erstellung von Benutzer- oberflächen dynamischer Web-Anwendungen Container: – Laufzeitumgebung für Komponenten, bieten zusätzliche Dienste an Connectors: – dienen der Anbindung von J2EE-Anwendungen an Unternehmens-IS

89 © Prof. T. Kudraß, HTWK Leipzig Java Servlets Einordnung: – als serverseitige Applets bezeichnet – Pendant zu den Server-Erweiterungs-APIs von MS und Netscape Voraussetzung – Integration einer JVM in den Web-Server bzw. Kooperation mit einem Zusatzprozeß – 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

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

91 © Prof. T. Kudraß, HTWK Leipzig In- und Output von Java-Http- Servlets Quelle / Ziel: Servlet Engine Servlet erhält u.a.: Initialisierungsparameter Externe Ressourcen Daten von / für andere Servlets Quelle: Client Servlet erhält u.a. Session-ID Http-Methode (Get / Post) Parameter Cookies Username Servlet Context Servlet Config HttpServlet Request HttpServlet Response Java Servlet Ziel: Client Servlet erzeugt u.a.: Http-Status-Code Content-Typ Content Cookies

92 © Prof. T. Kudraß, HTWK Leipzig Schritte zur Erstellung einer Servlet-Ausgabe 1. Auslesen (und Verarbeiten) der Daten aus dem HTTP-Request 2. Statuscode setzen, Default: SC_OK (200) 3. Content-Typ setzen, Default: text/html 4. PrintWriter oder Ausgabestream anfordern 5. Rückgabe (z.B. HTML-Seite) in den PrintWriter oder Ausgabestream schreiben 6. PrintWriter oder Ausgabestream schließen

93 © Prof. T. Kudraß, HTWK Leipzig Servlet-Klassen: Packages Importiere für die Arbeit mit Servlets folgende Packages: – java.servlet.* – javax.servlet.http.* Sind nicht in Standard JDK enthalten, sondern nur separat oder als Teil von Java2EE

94 © Prof. T. Kudraß, HTWK Leipzig Auslesen der Parameter aus dem HttpRequest die vom Client übergebenen Parameter sind im Http-Request codiert (je nach Methode: GET / POST) Decodierung durch Servlet Engine Abruf der Parameter durch eine Methode (einheitlich bei GET oder POST)

95 © Prof. T. Kudraß, HTWK Leipzig Methoden zum Einlesen von Parametern ServletRequest.getParameterNames() – gibt die Namen der dem Servlet übergebenen Parameter in Form einer java.util.Enumeration zurück ServletRequest.getParameter(Parametername) – gibt den (ersten) Wert des angegebenen Parameters als String zurück (null, wenn kein Parameter existiert) ServletRequest.getParameterValues (Parametername) – gibt ein String-Array mit allen Werten des angegebenen Parameters zurück (bzw. null, wenn Parameter nicht existiert)

96 © Prof. T. Kudraß, HTWK Leipzig Enumerations Erleichtern das sukzessive Abrufen einer Gruppe von Werten Methoden von Enumeration: – Enumeration.hasMoreElements() True, wenn noch nicht abgerufene Elemente enthalten – Enumeration.nextElement() Gibt den Wert des nächsten Elements der Aufzählung als Object zurück (null, wenn der Parameter nicht existiert)

97 © Prof. T. Kudraß, HTWK Leipzig MIME-Content-Typen Content-Typ in Form eines Strings Wichtigste Content-Typen: – text/html: HTML-Dokument (Default, falls kein anderer Typ gesetzt wird) – text/plain: Einfaches Textfile ohne Markup oder Befehle – text/xml: XML-Dokument – image/gif: GIF-Bild – image/jpeg: JPEG-Bild – application/pdf: PDF-Datei Setzen des Content-Typs: – HttpServletResponse.setContentType (Content-Typ) Rückgabe des Typs als Teil des Http-Response

98 © Prof. T. Kudraß, HTWK Leipzig Http-Statuscodes Die wichtigsten Http-Statuscodes werden durch Konstanten der Klasse HttpServlet repräsentiert. – 200: OK (SC_OK. Default, falls kein anderer Code gesetzt wird) – 304: Keine neuen Daten (SC_NOT_MODIFIED) – 401: Anmeldung erforderlich (SC_UNAUTHORIZED) – 404: Nicht gefunden (SC_NOT_FOUND) – 500: Interner Serverfehler (SC_INTERNAL_SERVER_ERROR) Setzen des Statuscodes: – HttpServletResponse.setStatus( Statuscode )

99 © Prof. T. Kudraß, HTWK Leipzig Inhalt des HttpResponse Eigentlicher Inhalt (Body) des HttpResponse als Zeichendaten in einen PrintWriter oder als Binärdaten in einen OutputStream schreiben Vorher Header fertigstellen (Statuscode, Content-Typ) Methoden zum Anfordern PrintWriter / OutputStream: – PrintWriter-Variable = HttpServletResponse.getWriter() – OutputStream-Variable = HttpServletResponse.getOutputStream() Rückgabe eines PrintWriter bzw. OutputStream zum Schrei- ben in die HttpResponse in der angegebenen Variable zurück

100 © Prof. T. Kudraß, HTWK Leipzig Lesen und Schreiben von Daten in Java: Streams Datenquellen und –senken durch Streams gekapselt Stream – Kommunikationspfad zwischen Quelle und Ziel eines Informationsblockes – Entkoppeln von Quelle, Verarbeitung und Ziel der Information – Verarbeitung eines Streams ohne Kenntnis von Quelle oder Ziel Daten- quelle Eingabe- stream Java- Programm Daten- ziel Ausgabe- stream File Array URL Tastatur... File Array URL Drucker...

101 © Prof. T. Kudraß, HTWK Leipzig Die Klasse PrintWriter Klasse (aus dem Package java.io) definiert einen Ausgabestream mit Methoden, um Variablen diverser Datentypen schnell und einfach auszugeben Generell: Schreib-Methoden werfen bei Problemen IOExceptions aus.

102 © Prof. T. Kudraß, HTWK Leipzig Ausgewählte Methoden von PrintWriter PrintWriter.print (Wert) / print (char-Array) / print (Objekt) PrintWriter.println (Wert) / println (char-Array) / println (Objekt) – Schreibe einen Wert eines einfachen Datentyps, den Inhalt eines Char-Arrays oder die Repräsentation eines Objekts in den Stream. Println zusätzlich mit Zeilenumbruch OutputStream.flush() – Erzwingt das Wegschreiben eines evtl. Puffers in das Datenziel OutputStream.close() – Schließt den Stream und gibt die verwendeten Ressourcen frei

103 © Prof. T. Kudraß, HTWK Leipzig Java Servlets Beispielseite package mypackage1; import javax.servlet.*; import javax.servlet.http.*; import java.io.PrintWriter; import java.io.IOException; public class servlet_startseite extends HttpServlet { public void init(ServletConfig config) throws ServletException { super.init(config); } public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Content-Type setzen response.setContentType("text/html"); // PrintWriter initialisieren PrintWriter out = response.getWriter(); out.println(" " + " Testseite als Servlet " + " \n" + " Testseite als Servlet \n");

104 © Prof. T. Kudraß, HTWK Leipzig Java Servlets Beispielseite (Forts.) // Wenn Parameter belegt ausgeben if ((request.getParameter("p_name") != null) && (request.getParameter("p_name").length() > 0) ) { // Name ist vorhanden out.println("Hallo " + request.getParameter("p_name") + ". "); // Zugriff auf Umgebungsvariable out.println( "Client-IP-Adresse: " + request.getRemoteAddr()); } // Formular ausgeben out.println(" "); out.println("Bitte Namen eingeben: "+" "+ " " + " "); out.println(" "); } public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Post-Request an doGet() weiterleiten doGet(request, response); } public void destroy() { /* leer gelassen, da beim Beenden nichts ausgeführt werden muß */ } // Wenn Parameter belegt ausgeben if ((request.getParameter("p_name") != null) && (request.getParameter("p_name").length() > 0) ) { // Name ist vorhanden out.println("Hallo " + request.getParameter("p_name") + ". "); // Zugriff auf Umgebungsvariable out.println( "Client-IP-Adresse: " + request.getRemoteAddr()); } // Formular ausgeben out.println(" "); out.println("Bitte Namen eingeben: "+" "+ " " + " "); out.println(" "); } public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Post-Request an doGet() weiterleiten doGet(request, response); } public void destroy() { /* leer gelassen, da beim Beenden nichts ausgeführt werden muß */ }

105 © Prof. T. Kudraß, HTWK Leipzig Java Server Pages (JSP) Suns Konkurrenzprodukt zu Microsofts Active Server Page Pages (ASP) Weiterentwicklung des SSI-Mechanismus und Erweiterung des Servlet- Konzepts Sollen die Erstellung von dynamischen HTML-Seiten mit Java vereinfachen Prinzip: HTML-Seiten mit eingebetteten JSP-Direktiven und Java-Befehlen mischt statisches HTML mit dynamischem Code (Anwendungslogik) Anwendungslogik (aufrufbar aus JSP-Seite) – Java Beans – JDBC-Objekte – Enterprise Java Beans (EJB) – RMI-Objekte (Remote Method Invocation) strikte Trennung von Design/Präsentation einer Seite von deren Inhalt bzw. Logik zusätzliche JSP-Engine muß installiert werden in Dateien mit Namensendung.jsp gespeichert

106 © Prof. T. Kudraß, HTWK Leipzig Anzeige von WWW-Dokumenten mit Java Server Pages WWW- Browser WWW- Server mit JSP- Engine Datenbanken Dateien Meßinstrumente Video-Systeme Java-Compiler 1 http-Request mit Benutzereingaben 7 Http-Response (i.a. vom Servlet erzeugte HTML-Seite) 2 Übergabe der JSP an den Java-Compiler 4 Übergabe von Http-Request und ServletConfig / Context an das Servlet 3 Erstellen eines Java- Servlet 5 Ansteuerung von Serverressourcen Java-Servlet 6 Rückgabe der Http-Response

107 © Prof. T. Kudraß, HTWK Leipzig Beziehung JSP - Servlet JSP-Datei wird im Web- Server gespeichert bei erster Anfrage Über- setzung in ein Servlet Ausführung des Servlets durch die Servlet Engine bei jedem weiteren Aufruf Ausführung des ent- sprechenden Servlets bei Änderung der JSP- Datei erneute Übersetzung und Erzeugung des Servlets

108 © Prof. T. Kudraß, HTWK Leipzig Ablaufsteuerung in JSPs Die Inhalte von Scriptlets werden 1:1 in das generierte Servlet übertragen. Somit möglich: – Teile der JSP in HTML schreiben – Einbettung in Scriptlets, die Verzweigungen oder Alternativen beinhalten Teile der JSP nur unter bestimmten Bedingungen in das HTML einfügen Teile der JSP mehrfach in HTML einfügen

109 © Prof. T. Kudraß, HTWK Leipzig Elemente von Java Server Pages JSP – Definieren Variablen für die Verwendung in der JSP Ausdrücke: – Ergebnis des Ausdrucks an dieser Stelle in HTML eingefügt Scriptlets: – Angegebener Java-Code wird an dieser Stelle ausgeführt JSP-Direktiven: – Ausführung der angegebenen Direktive an dieser Stelle – Include-Direktive: – Page-Direktive:

110 © Prof. T. Kudraß, HTWK Leipzig Attribute der page-Direktive contentType = Content-Typ – Gibt an, welchen contentType der Browser übergeben bekommen soll (i.a. txt/html ) isThreadSafe = true / false – Gibt an, ob die JSP mehrfach gleichzeitig aufgerufen werden kann, ohne daß es zu Problemen kommt import = Java-Klasse / Paket – Importiert die angegebene Java-Klasse bzw. die Klassen im angegebenen Java-Paket zur Verwendung in der JSP extends = Java-Klasse – Gibt an, daß die JSP bzw. das generierte Servlet das Verhalten der angegebenen Klasse erben soll

111 © Prof. T. Kudraß, HTWK Leipzig Attribute der page-Direktive (Forts.) errorPage = relative URL – Gibt eine JSP an, die aufgerufen werden soll, wenn innerhalb dieser Seite ein Fehler auftritt, um diesen zu behandeln isErrorPage = true / false – Gibt an, ob es sich bei der JSP um eine Seite, die für andere JSPs Fehler auswertet, handelt

112 © Prof. T. Kudraß, HTWK Leipzig Vordefinierte Objekte für JSPs ObjektnameFunktion applicationZugriff auf ServletContext-Funktionen, um z.B. Attribute zu setzen configZugriff auf ServletConfig-Funktionen, z.B. um Server- konfigurationen zu lesen sessionFunktionen für sitzungsorientierte Anwendungen outFunktionen für Ausgaben über ein JSP Writer-Objekt exceptionObjekt in JSP-Fehlerseiten für die Fehlerausgabe

113 © Prof. T. Kudraß, HTWK Leipzig JSP Beispielseite Testseite mit Java Server Page Testseite mit Java Server Page <% // Inhalt des Parameters p_name anzeigen, wenn belegt if ((request.getParameter("p_name") != null) && (request.getParameter("p_name").length() > 0) ) { %> Hallo. Client-IP-Adresse: <% } %> Bitte Namen eingeben: Testseite mit Java Server Page Testseite mit Java Server Page <% // Inhalt des Parameters p_name anzeigen, wenn belegt if ((request.getParameter("p_name") != null) && (request.getParameter("p_name").length() > 0) ) { %> Hallo. Client-IP-Adresse: <% } %> Bitte Namen eingeben:

114 © Prof. T. Kudraß, HTWK Leipzig Tag Libraries Weitere nützliche Funktionen in spezifischen Tag Libraries implementiert Erweitertes Event Handling Erweiterte Unterstützung für XML (z.B. Formatierung bei der Ausgabe mittels XSLT) Java Beans für die Arbeit mit Datenbanken – ConnBean für Erstellung einer DB-Verbindung – ConnCacheBean für Caching-Unterstützung in DB- Verbindungen – DBBean für die Ausführung von Anfragen an die Datenbank – CursorBean für DML-Anfragen sowie Stored Procedures

115 © Prof. T. Kudraß, HTWK Leipzig Vorteile von JSP vs. Active Server Pages (ASP) – dynamischer Teil geschrieben in Java – portabel auf andere Betriebssysteme und Webserver vs. Reine Servlets – gleiche Funktionalität wie Servlets – bessere Wartbarkeit des Codes (Änderungen in HTML statt in println-Befehl) – bessere Trennung von Inhalt und Präsentation vs. Server-Side Includes (SSI) – SSI: nur einfaches Einfügen von extern definierten Teile in eine statische Webseite – JSP mit Nutzung von Servlets besser für Verarbeitung von Formulardaten, DB-Verbindungen u.ä.

116 © Prof. T. Kudraß, HTWK Leipzig Vorteile von JSP (Forts.) vs. JavaScript – dynamisches HTML auf Client-Seite durch Benutzer-Interaktion – JavaScript hat keinen Zugriff auf serverseitige Ressourcen, z.B. Datenbanken, Kataloge – HTTP nicht verfügbar für JavaScript (nur Cookies) vs. Statisches HTML – mit JSP einfache Erweiterung um dynamische Anteile möglich


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

Ähnliche Präsentationen


Google-Anzeigen