Architektur von Web- Datenbanksystemen

(1)

Datenbanksystemen

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

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

(4)

Analogie: Winsbergs Modell

Remote Presentation Distributed Logic Remote Data Access

Presentation Mgr. Presentation Mgr. Presentation Mgr.

Presentation Logic

Presentation Logic Presentation Logic

Data Logic

(5)

Verteilung der Schichten

Anorexic Client Big-Boned Client Fat Client

Web Browser View View

Application Model

Application Model Application Model

Domain

Application Model

View: Servlets

(6)

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)

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)

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)

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-Client Web-Server

DBS-Server

Präsentation

Inhalt

(10)

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)

Applikationsorientierte WebIS

 Funktionalität des Applikations-Servers

– DB-Anbindung

– Transaktionsmanagement

– Sicherheit

– Lastausgleich

Web-Client Web-Server

DBS-Server

Präsentation

Applikationslogik Applikations-

Server

Inhalt

IIOP

(12)

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 gleichzeitig zugreifender Clients

– komplexe Geschäftslogik, z.B. bei Online-Kauf oder Online- Buchung)

– hohe Transaktionsorientiertheit, z.B. bei Online-Banking- Anwendungen

(13)

Ubiquitäre WebIS

 Ziel

– richtigen Dienst

– zum richtigen Zeitpunkt

– am richtigen Ort

– in der richtigen Form

Web-Client Web-Server

DBS-Server

Präsentation

Applikationslogik Applikations-

Server

Inhalt A np as su ng s- ko m po ne nt e

(14)

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)

Portal-orientierte WebIS

Web-Client Web-Server

Daten 1

Präsentation Aggregation

Inhalt

Applikationslogik Portlet 1

Web Service 1

Portlet 2 Web Service 2

Portlet 3 Web Service 3

Daten 2 Daten 3

(16)

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)

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)

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.

(19)

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)

<HTML>

<HEAD>

<TITLE>Titelzeile</TITLE>

</HEAD>

<BODY> …

(20)

Anbindungsarchitekturen

(21)

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

(22)

Anbindungstechnologien

(23)

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

(24)

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-Client Web-Server

DBS-Server JVM

Applet

JDBC

(25)

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)

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)

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)

Serverseitige Anbindung:

Externe Programme

(29)

Serverseitige Anbindung:

Erweiterung der Serverfunktionalität

(30)

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)

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)

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)

Oracle Application Server

Oracle 9iAS

(34)

Oracle HTTP Server

(35)

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)

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)

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)

Umgebungs-

variablen einer

CGI-Anwendung

(39)

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 1. Formular

abschicken übertragen

2. CGI-Skript aufrufen

3. DB abfragen

Abfrage-Report der DB auswerten

4. HTML-Datei aus Abfrage-Report erzeugen

(40)

Ablauf der Verarbeitung bei Ablauf

eines CGI-Programms

(41)

CGI-Programmbeispiel (mSQL)

(42)

CGI-Programmbeispiel (Perl)

print "Content-type: text/html\n\n";

$values = <STDIN>;

($name, $wert) = split( /=/, $values);

$name =~ s/\%(..)/pack("c",hex($1))/ge;

$wert =~ s/\%(..)/pack("c",hex($1))/ge;

print "<HTML>", "<HEAD>",

"<TITLE>Testseite mit Perl ohne cgi.pm</TITLE></HEAD>";

print "<BODY>",

"<H1>Testseite mit Perl ohne cgi.pm</H1>";

if ($wert) {

print ("Hallo $wert.<p>");

# Zugriff auf CGI-Umgebungsvariable

print ("Client-IP-Adresse: $ENV{REMOTE_ADDR}");

}

print '<FORM method=POST>Bitte Namen eingeben: ';

print '<input type="text" name="txtname" size="30">';

print '<INPUT TYPE="submit">';

print "</FORM>",

(43)

Ausgabe der Beispielseite

(44)

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

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

(45)

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)

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)

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)

SSI mit LiveWire

Web-Client Web-Server NS-API

SSJS-Funktionen LiveWire

DBS- Server

OCI

HTTP <HTML>

...

<SERVER>

database.CONNECT(...)

result = database.cursor(“SELECT name,age FROM Person“) name1 = result.name

age1 = result.age

document.WRITELN(name1 + “,“ + age1 + “<BR>“)

name2 = result.name ...

</SERVER>

<HTML>

...

<SERVER>

database.CONNECT(...)

result = database.cursor(“SELECT name,age FROM Person“) name1 = result.name

age1 = result.age

document.WRITELN(name1 + “,“ + age1 + “<BR>“)

name2 = result.name ...

</SERVER>

SSI-Beispiel mit LiveWire

(49)

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)

Ablauf der Verarbeitung mit PL/SQL



Entwicklungsunterstützung durch WebServer Developer‘s 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)

Toolkit - Beispiele

htp.title(‘My First Page Title‘);

PL/SQL

HTML

<TITLE>My First Page Title</TITLE><TITLE>My First Page Title</TITLE>

Funktionsauruf

title:=htf.title(‘My First Page Title‘)title:=htf.title(‘My First Page Title‘)

Verschachtelung

htp.center(htf.header(1,‘My First HTML Header - Level 1‘));

(52)

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)

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)

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)

PSP Beispiel

<%@ page language="PL/SQL" %>

<%@ plsql procedure="psp_bspseite" %>

<%@ plsql parameter="p_name" default="null"%>

<HTML>

<HEAD>

<TITLE>Beispielseite mit PL/SQL Server Page</TITLE>

</HEAD>

<BODY>

<H1>Beispielseite mit PL/SQL Server Page</H1>

<%

-- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then %>

Hallo <%=p_name%>.

<p>

Client-IP-Adresse: <%=owa_util.get_cgi_env('REMOTE_ADDR')%>

<%END if;%>

<FORM method=POST>

Bitte Namen eingeben: <INPUT type="text" name="p_name" size="30">

<%@ page language="PL/SQL" %>

<%@ plsql procedure="psp_bspseite" %>

<%@ plsql parameter="p_name" default="null"%>

<HTML>

<HEAD>

</HEAD>

<BODY>

<%

-- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then %>

Hallo <%=p_name%>.

<p>

Client-IP-Adresse: <%=owa_util.get_cgi_env('REMOTE_ADDR')%>

<%END if;%>

<FORM method=POST>

</FORM>

(56)

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)

PSP Beispiel – Generierter PL/SQL Code (Gespeicherte Prozedur)

( p_name IN VARCHAR2 default null) AS BEGIN NULL;

htp.prn(‘

<HTML>

<HEAD>

</HEAD>

<BODY>

‘);

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

<HTML>

<HEAD>

</HEAD>

<BODY>

‘);

-- Inhalt des Parameters p_name anzeigen, wenn belegt if not(p_name is null) then

htp.prn(‘

Hallo ‘);

htp.prn(p_name);

[. . .]

(58)

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)

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)

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)

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)

PHP



PHP-Seite als Script-Datei

–

Extension .php

–

Verarbeitung durch PHP-Prozessor



Einbettung von Skripteinschüben in spezielle Tags

–

<? echo “Hello world!“ ?>

–

<?php echo “Hello world!“; ?>

–

<script language=“php“>

echo “Hello world!“;

</script>

(63)

Verarbeitung einer PHP-Seite

(64)

PHP Beispiel

<HTML>

<HEAD>

<TITLE>Testseite mit PHP</TITLE>

</HEAD>

<BODY>

<H1>Testseite mit PHP</H1>

<?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.<p>");

// Zugriff auf Umgebungsvariable

print("Client-IP-Adresse: ".$_SERVER['REMOTE_ADDR']);

}

</script>

<FORM method="POST">

</FORM>

<HTML>

<HEAD>

<TITLE>Testseite mit PHP</TITLE>

</HEAD>

<BODY>

<H1>Testseite mit PHP</H1>

<?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.<p>");

// Zugriff auf Umgebungsvariable

print("Client-IP-Adresse: ".$_SERVER['REMOTE_ADDR']);

}

</script>

<FORM method="POST">

</FORM>

</BODY>

(65)

Java und Datenbanken



Java Database Connectivity (JDBC)

–

Idee

–

Drivertypen

–

Klassen und Schnittstellen



SQLJ



J2EE Anwendungen



Java Servlets



Java Server Pages

(66)

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)

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)

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)

JDBC-Architektur

Application Driver Manager

Driver Driver Driver

Data source Data source Data source

JDBC API

JDBC Driver API

Proprietär

(70)

Driver Typ 1:

JDBC-ODBC-Bridge

Java Anwendung

JDBC Driver Manager JDBC-ODBC Bridge

Server DBMS

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

JDBC API

(71)

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

Intranet Client

DBMS Client Bibliothek JDBC API

(72)

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)

DBMS-Client- Bibliothek

DBMS 2

DBMS-Client- Bibliothek

DBMS Server

Standard-Netzwerkprotokoll

JDBC Driver Manager

(73)

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

Server

DBMS-spezifisches Netzwerk-Protocol

JDBC-API

(74)

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)

JDBC Version 2

Neue Methoden / Konzepte Erweiterungen von Standard SQL Scrollbare und änderbare

ResultSets Connection Pooling

SQL:1999-Typen Verteilte Transaktionen

Batch Updates Java Naming und Directory (JNDI)

Package: java.sql Package: javax.sql

(76)

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)

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

Statement stmt;

ResultSet rs;

int partID;

float price;

// Create a statement and execute a SELECT statement stmt = conn.createStatement();

rs = stmt.executeQuery

(78)

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

conn.close();

(79)

JDBC

Beispiel UPDATE

Statement stmt;

int rowCount;

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)

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

(81)

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

(82)

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

L Translator va Compiler

(83)

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

(84)

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)

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

(86)

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)

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)

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

(89)

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)

Web/DB-Anbindung über Java Servlets

Weitere Vorteile



alle Möglichkeiten der Sprache Java

Web-Client Web-Server

Servlet-Engine

DB-Server Java-

Klassenbibliothek

HTTP

J V M

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

