Server

Teil I:
Existierende Infrastruktur heterogener und
verteilter Informationssysteme
1.
2.
3.
4.
5.
6.
Infrastruktur durch erweiterte Datenbankfunktionalität (“TP-Lite”)
Middleware-Infrastruktur durch TP-Monitore (“TP-Heavy”)
Standards zur verteilten Objektverwaltung: CORBA, DCOM
Object Transaction-Monitore
Enterprise JavaBeans
Message-Oriented Middleware
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 1
Kap. 1: Infrastruktur durch erweiterte
Datenbankfunktionalität (“TP-Lite”)
1.1 Traditionelle, zweistufige Architektur (“Two-tier”)
G Klassifikation von Datenbankservern
G Architekturvarianten: Aufgabenteilung
Client
zwischen Client und Server
•
•
Fat Clients
– Embedded SQL (statisch und dynamisch)
– SQL Call-Level-Interfaces
Fat Server
– Stored Procedures, Trigger, UDTs
Objektverwaltung höherer Ordnung (OHO) – SS 2001
…
Client
DBMS
DB
DB-Server
Kapitel 1.1: Vorlesung TP-Lite – 2
Klassifikation von Datenbank-Servern
DB-Server
Monolithisch
Multiple Server
ein DBS-Prozess
mehrere DBS-Prozesse
Symmetrisch
Asymmetrisch
pro Anwendungsprozess ein
DBS-Prozess
dynamische
Zuordnung von
Anwendungsprozesse zu
DBS-Prozessen
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 3
Monolithischer Server
G
G
G
Genau ein Server-Prozess für viele Clients
•
•
Server verwendet mehrere Threads (Reentrant Code)
Führt eigene Ressourcenverwaltung durch
Einfache Kommunikation im Server durch Shared Memory
•
Synchronisierter Zugriff auf Systempuffer und zentrale Systemtabellen
Monolithische Architektur z.B. bei Sybase oder MS SQL Server zu finden
AP
AP
Client … Client
1
i
CL
CL
AP
Client
n
…
DBMS
Server
CL
Betriebssystem 1
Betriebssystem m
Netzwerk
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 4
Multiple Server: Symmetrische Konfiguration
G
G
G
DBMS ist ein Verbund von verschiedenen Prozessen
Jedem Client ist genau ein Server Prozess zugeordnet
• Statische Zuordnung, feste Anzahl n Server vorgeneriert
➜ Maximaler Parallelitätsgrad ist n
Zu finden bei Oracle im Dedicated Server-Mode, bei Informix und DB2
AP
Client
1
CL
AP
… Client
i
CL
AP
Client
n
…
DBMS … DBMS … DBMS
Server
Server
Server
n
i
1
CL
Betriebssystem 1
Betriebssystem m
Netzwerk
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 5
Multiple Server: Asymmetrische Konfiguration
G
G
Ein Client wird mit Hilfe des Dispatchers mit einem freien Server-Prozess
verbunden
• Feste Anzahl Server ist vorgeneriert
• Der Parallelitätsgrad kann jedoch höher sein
(da mehrere Clients sich einen Server-Prozess teilen können)
Zu finden bei Oracle im Multi-Threaded-Server-Mode
CL
AP
… Client
i
CL
AP
Client
n
CL
Betriebssystem 1
Dispatcher
AP
Client
1
DBMS … DBMS
Server
Server
1
k
Betriebssystem m
Netzwerk
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 6
Two-Tier-Architektur
G
G
Client und Server sind völlig getrennt
Kommunikation zwischen Client und Server
•
G
Via Netzwerk oder IPC mit gemeinsamen Protokoll
(z.B. JDBC, Oracle Net8)
(Klare) Aufgabenteilung zwischen Client und Server
•
•
•
Präsentation
Datenverwaltung
Anwendungsfunktionalität
➜ Client
➜ Server
➜ ???
Server
Client
DB
Server
DB Client
Library
DB Server
Library
Client
Betriebssystem
Netzwerk, IPC
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Betriebssystem
Kapitel 1.1: Vorlesung TP-Lite – 7
Two-Tier-Architektur: Realisierung
G
G
G
Aufgabenteilung: Anwendungsfunktionalität
im Client oder Server?
• Fat Client / Thin Server
• Thin Client / Fat Server
Was soll der Client machen?
• Präsentation
• Anwendungsfunktionalität (ESQL/CLI)
Was sind die Aufgaben des Servers?
• Datenverwaltung
• Anwendungsfunktionalität (Stored Procedures, Trigger, etc.)
Data
Presentation
Access
Functionality
Client
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Data
Management
Server
Kapitel 1.1: Vorlesung TP-Lite – 8
Anwendungsentwicklung —
Fat Client / Thin Server
Embedded SQL
Anwendung
Call-Level SQL
Anwendung
SQL
Client
CLI Calls
Präcompiler
CLI-API (Application
Program Interface)
PräcompilerRuntime Library
Call Level Interface
Runtime Library
DBMS-Treiber
SQL-FAP (Format and Protocols),
herstellerdefiniert, z.B. Net8 von Oracle
DBMS
DB
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Server
Kapitel 1.1: Vorlesung TP-Lite – 9
Embedded SQL (ESQL)
G
G
Nach ISO SQL-92 definierte Einbettung von SQL in Programmiersprachen
•
Präcompiler ersetzt die SQL-Aufrufe in Calls der jeweiligen Runtime
Library des verwendeten Datenbank-Servers
•
G
Bei Wechsel der Datenbank müssen ESQL-Programme nur neu kompiliert
und gelinkt werden
Statisches ESQL
•
•
G
z.B. Java (SQLJ), C, C++, Fortran, Pascal, Cobol, PL/1, Ada
Alle SQL-Statements müssen bereits zur Compile-Zeit vollständig bekannt
sein
Daher müssen auch alle verwendeten Datenbankobjekte zur Compile-Zeit
vorhanden sein
Dynamisches ESQL
•
•
SQL-Statements werden erst zur Laufzeit erzeugt (dynamisches Generieren
von Strings, die SQL-Anweisungen beinhalten)
Die verwendeten Datenbankobjekte müssen daher zur Compile-Zeit noch
nicht existieren
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 10
Embedded SQL – statisch
ESQL/CQuellProgramm
(SQL-Anweisungen
bekannt)
ESQL/C
Präcompiler
C-QuellProgramm
mit SQL
Anweisungen
und ESQL/C
Aufrufen
Beispiel:
credit (int accountno) {
EXEC SQL BEGIN DECLARE SECTION;
NUMBER
acc_no;
NUMBER
bal;
EXEC SQL END DECLARE SECTION;
acc_no := accountno;
EXEC SQL SELECT a.balance
INTO :bal
FROM account a
WHERE a.account_number =
:acc_no;
}
G
G
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Ausführbares
Programm
Zur Compilezeit führt der Präcompiler u.a.
folgende Prüfungen durch (mit Hilfe von
Informationen aus dem Datenbank-Katalog):
•
•
Existenz von Tabellen und Attributen
Syntaxprüfung, Typenprüfung
Zusätzliche Ersetzungen:
•
•
G
CPräprozessor
Compiler
und Linker
Die datenbankspezifischen Datentypen (Host
Variables) werden durch Datentypen der
jeweiligen Programmierumgebung ersetzt
Beispiel (ESQL/C): VARCHAR2(10) wird zu
struct { unsigned short len;
unsigned char arr[10]; }
Ansatz ist recht unflexibel (da alle SQLStatements zur Compile-Zeit bekannt sein
müssen), jedoch: wenige Laufzeitfehler!
Kapitel 1.1: Vorlesung TP-Lite – 11
Embedded SQL – dynamisch
ESQL/CQuellProgramm
(SQL-Anweisungen noch
nicht bekannt)
ESQL/C
Präcompiler
C-QuellProgramm
mit SQL
Anweisungen
und ESQL/C
Aufrufen
Beispiel:
credit( int amount, int accountno,
char *table) {
char dyn_stmt[120];
sprintf(dyn_stmt,
"UPDATE %s SET balance = balance +
:a WHERE account_number = :ano“,
table);
EXEC SQL PREPARE sql_stmt FROM
:dyn_stmt;
EXEC SQL EXECUTE sql_stmt USING
:amount, :accountno;
G
CPräprozessor
Compiler
und Linker
Ausführbares
Programm
Das SQL Statement ist erst
zur Laufzeit bekannt
•
•
•
Der Precompiler kann
weniger Überprüfungen
durchführen
Mehr Flexibilität
Aber auch mehr
Laufzeitfehler möglich!
}
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 12
SQL Call-Level Interface (CLI)
G
Standardisierte Schnittstelle zur Kommunikation mit Datenbanken ohne
Präcompiler
•
G
SQL/CLI: Standard seit 1996
•
•
G
G
CLI-API erlaubt das Erstellen und Ausführen von SQL-Anweisungen zur
Laufzeit
Ursprung in Aktivitäten der SQL Access Group (SAG) mit dem Ziel, einen
vereinheitlichten Zugriff auf Datenbanken bereitzustellen
Ist auch Bestandteil von SQL3
SQL/CLI beinhaltet
•
•
•
•
•
DB-Verbindungsaufnahme und Beendigung
Vorbereitung und Ausführen von SQL-Anweisungen (“prepare” und “execute”)
Binden von Parametern an SQL-Anweisungen (“bind”)
Entgegennahme von Resultaten
Festlegung von Datentypen (über spezielle Codes für jeden Datentyp)
CLI-Call wird durch den proprietären DBMS-Treiber umgesetzt in
herstellerspezifischen DB-Zugriff
•
Mit geeignetem Treiber kann prinzipiell jede Datenquelle angesprochen werden
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 13
CLI-Dialekte
G
Neben standardisiertem SQL/CLI haben sich noch weitere
Dialekte herausgebildet (war das ursprüngliche Ziel der SAG nicht
die Definition einer einheitlichen Schnittstelle?)
•
•
G
ODBC (Open Database Connectivity): Microsofts CLI-Variante
– Beinhaltet die meisten (nicht alle) API-Calls des CLI-Standards
– Zusätzlich: spezielle Calls zur Unterstützung von MicrosoftProgrammen (Access, Excel, etc.)
Proprietäre CLIs der DB-Hersteller (“Native API”)
– z.B. Oracle Call Interface (OCI)
In der Regel werden mehrere CLI-Dialekte parallel unterstützt
ODBC-API
SQL/CLI-API
Native API
Call Level InterfaceRuntime Library
DBMS-Treiber
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 14
Call Level Interface: SQL99 CLI
#include "sqlcli.h"
extern SQLHDBC hdbc;
extern SQLHENV henv;
/* Verbindung steht schon */
/* Umgebung */
void credit ( SQLHSTMT hstmt,
int amount, int accountno , char *table) {
/* hstmt wird von aussen gegeben, damit Transaktionskontrolle ausserhalb
dieser Prozedur. "credit" ist Baustein */
char update[120];
SQLINTEGER NameParamLength1;
SQLINTEGER NameParamLength2;
sprintf(update, "UPDATE %s SET balance = balance + ? WHERE account_number
= ? ", table);
SQLPrepare(hstmt, update, SQL_NTS);
SQLBindParameter(hstmt, 1, SQL_PARAM_MODE_IN, SQLCHAR, SQL_CHAR,
NAME_LENGTH, 0 &amount, NAME_LENGTH, &NameParamLength1);
SQLBindParameter(hstmt, 2, SQL_PARAM_MODE_IN, SQLCHAR, SQL_CHAR,
NAME_LENGTH, 0 &accountno, NAME_LENGTH, &NameParamLength2);
SQLExecute(hstmt);
}
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 15
Call Level Interface: Oracle-Dialekt (OCI)
#include “oci.h”
extern static OCIEnv *envhp;
void credit (OCIStmt *stmthp,
int amount, int accountno , char *table) {
char update[120];
static OCIBind *bnd1p = (OCIBind *) 0;
sprintf(update, “UPDATE %s SET balance = balance + :a
WHERE account_number = :ano “, table);
OCIStmtPrepare(stmthp, errhp, update, (ub4) strlen((char *update), (ub4)
OCI_NTV_SYNTAX, (ub4) OCI_DEFAULT));
OCIBindByName(stmthp, &bnd1p, errhp, (char *) ":A", -1,
(dvoid *) &amount, (sword) sizeof(accountid), SQLT_INT,
(dvoid *)0, (ub2 *)0, (ub2 *)0, (ub4)0, (ub4 *)0,OCI_DEFAULT);
OCIBindByName(stmthp, &bnd1p, errhp, (char *) ":ANO", -1, (dvoid *)
&accountno, (sword) sizeof(accountid), SQLT_INT, (dvoid *) 0,
(ub2 *) 0, (ub2 *) 0, (ub4) 0, (ub4 *) 0, OCI_DEFAULT);
OCIStmtExecute(svchp, stmthp, errhp, (ub4) 1, (ub4) 0, (CONST OCISnapshot
*) NULL, (OCISnapshot *) NULL, OCI_DEFAULT);
}
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 16
Object CLI
G
G
Weiterentwicklung von CLI zu Objektschnittstellen
(SQL/CLI kennt nur prozedurale APIs)
•
•
JDBC (Java Database Connection)
ActiveX Data Objects (ADO)
Java-Anwendung
Unterstützung von JDBC
•
•
Entweder “direkt” durch Native-API
Oder Umweg über JDBC-ODBC-Bridge
JDBC-API
JDBC-Treiber-Manager
JDBC-ODBCBridge
SQL/CLI-API
JDBC-Native
Treiber
ODBC-API
Native API
Call Level InterfaceRuntime Library
DBMS-Treiber
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 17
Zusammenfassung der Fat Client-Konzepte
G
G
G
G
Jeder Anwender programmiert seine Anwendungen selbst
(alle entwickeln ähnliche Bausteine)
Alternative: Anwender benutzen vorgegebene Funktions-Bausteine
Bausteine ändern sich (Systemwechsel oder Firmenpolitik)
Folge: alle Anwender müssen ihre Programmierung ändern bzw.
Module aus gemeinsamer Bibliothek holen.
Alternative hierzu:
•
•
Funktions-Bausteine in der Datenbank ablegen
Alle Clients können dann darauf zugreifen
➜ Anwendungsentwicklung innerhalb der Datenbank, z.B. durch
Stored Procedures („TP-Lite“)
•
•
Anwendungen in der DB ausführen …
… und auch dort ablegen
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 18
Anwendungsentwicklung —
Thin Client / Fat Server
Client
ProzedurAufruf
SQLFAP
Rückgabewerte
DBMS
Stored
Procedure
Trigger
UDT
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Server
Kapitel 1.1: Vorlesung TP-Lite – 19
Fat Server
Anwendungslogik innerhalb der Datenbank
G Stored Procedures (TP-Lite)
•
•
•
G
G
Verwendung einer 4GL (forth generation language)
– Turing-vollständiges SQL
Speicherung und Ausführung in DB
Standard unter SQL3 als “SQL/PSM” (= Persistent Stored Module)
– Kommerzielle DBMS verwenden jedoch proprietäre Dialekte, z.B.
Ø PL/SQL in Oracle (siehe Workshop & praktische Übung)
Ø TransactSQL in Sybase und MS SQL Server
Trigger (ereignisgesteuerte Funktionen/Prozeduren)
Benutzerdefinierte Datentypen (User Defined Types, UDTs)
•
Bestandteil von SQL-99
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 20
Stored Procedures
“Stored Procedure”
Internal
Procedure
External
Function
Procedure
Function
CREATE PROCEDURE credit (amount NUMBER, accountno INTEGER) IS
BEGIN
UPDATE account SET balance = balance + amount
WHERE account_number = accountno;
Oracle PL/SQL
END debit;
CREATE LIBRARY C_utils AS '/DLLs/utils.so'; Einbindung von C-Funktionen
in Oracle
CREATE FUNCTION debit (amount NUMBER, accountno INT) RETURN INT
AS LANGUAGE C LIBRARY C_utils NAME „debit_func";
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 21
Trigger
G
Spezifizieren wann (Event) und unter welchen Bedingungen
(Condition) eine Stored Procedure aufgerufen wird (Action)
• CREATE
TRIGGER my_trigger
AFTER UPDATE ON employees
WHEN (new.salary > 100000)
BEGIN
UPDATE admin SET number_of_managers =
number_of_managers + 1
WHERE dept = new.dept;
END
G
Event
Condition
Action
(Stored
Procedure)
Werden automatisch vom Datenbanksystem aktiviert („gefeuert“)
nach dem Einfügen, Ändern bzw. Löschen von Tupeln
•
•
Ausführung der Stored Procedure kann wiederum neue Trigger
starten („Trigger-Feuerwerk“) …
… die dann alle innerhalb einer Transaktion ausgeführt werden
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 22
Benutzerdefinierte Datentypen
G Benutzerdefinierte Typen besitzen Verhalten, das
durch Methoden implementiert werden kann
•
•
Methodenimplementierung in DB-eigner 4GL
Teil der Typdefinition
CREATE METHOD interest()
RETURNS
INTEGER
FOR AccountType
BEGIN
DECLARE
old_balance INTEGER;
old_balance = SELF.balance;
SET SELF.balance = old_balance * 1.03;
RETURN SELF.balance;
END;
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 23
Zusammenfassung: Fat Server vs. Fat Client
G
Fat Client-Architekturen
•
+
+
+
+
–
G
Traditioneller Ansatz in der zweistufigen Client/Server-Welt
Ausnutzen der Datenunabhängigkeit, die vom DB-Server
bereitgestellt wird
Standardisierte Schnittstellen
Gute Unterstützung eigener, individueller Anwendungen
Anwendungen lassen sich recht schnell entwickeln (z.B. mit Hilfe
grafischer Entwicklungswerkzeuge)
Problem der Wartung, Software-Verteilung, etc. (Upgrades von
Anwendungen, die von vielen Clients verwendet werden, sind recht
aufwändig)
Fat Server-Architekturen
+ Einfachere Wartbarkeit
+ Weniger Netzwerkbelastung (durch stärkeren Abstraktionsgrad der
bereitgestellten Prozeduren)
– Schlechte Unterstützung für individuelle, personalisierte Anwendungen
Objektverwaltung höherer Ordnung (OHO) – SS 2001
Kapitel 1.1: Vorlesung TP-Lite – 24