Teil I: Existierende Infrastruktur heterogener und verteilter

Teil I: Existierende Infrastruktur heterogener
und verteilter Informationssysteme
•Infrastruktur durch erweiterte Datenbankfunktionaität (“TP-Lite”)
•Midddleware-Infrastruktur durch TP-Monitore (“TP-Heavy”)
•Basis-Middleware Komponenten
•Standards zur verteilten Objektverwaltung: CORBA, DCOM
OHO
Kap1-1
Kap. 1 Infrastruktur durch erweiterte
Datenbankfunktionalität (“TP-Lite”)
• Architekturüberblick, Anknüpfung aus IS-K:
• Einstufige Architektur (keine klare Trennung zwischen
Client und Server)
• Zweistufige Architektur (“Two-Tier”)
• Aufgabenteilung zwischen Client und Server
• Realisierung (teilweise aus IS-G)
• Embedded SQL, statisch und dynamisch
• Stored Procedures, Trigger, UDTs
• SQL Call-Level-Interfaces
• Behandlung von Transaktionen
OHO
Kap1-2
1.1 Architekturüberblick (Wiederholung aus IS-K)
Ein-Stufen Architektur (nur noch historisch!)
•
•
•
Client und Server als ein Prozess jeweils in einem Adressraum gebunden.
n Benutzer: n Prozesse, Kommunikation über gemeinsamen Adressraum, daher:
• Sehr effizienter Datenaustausch über Shared Memory, aber
• keine Sicherheit gegenüber Fehlern im Anwenderprogramm
AP i … Anwendungspgm mit DBAufrufen
DA i … Speicherbereich für
Datenaustausch zwischen DBMS und
AP i
DBMS … gehört zum Adressraum der
AP i, wird nur einmal geladen
(„reentrant code“)
SP … Systempuffer des DBMS,
gemeinsamer Speicherbereich
GST …globale
Synchronisationstabelle für den
Zugriff auf SP
•
•
•
•
AP 1
AP n
DA 1
DBMS
DA n
SP
GST
DBMS
Betriebssystem
Beispiel: IBM System/R - Forschungsprototypsystem
OHO
Kap1-3
Zwei-Stufen: “Client/Server”…die Architektur heute!
•
•
•
Client und Server sind völlig getrennt
Kommunikation zwischen Client und Server über ein Netzwerk oder IPC. Dabei
wird ein gemeinsames Protokoll verwendet, z.B. JDBC, Net8 (bei Oracle)
Klare Aufgabenteilung zwischen Client und Server:
• Präsentation => Client
• Anwendungsfunktionalität => Client (aber zunehmend Stored
Procedures!)
• Datenverwaltung => Server
Client
DB
Server
DB Client
Library
DB Server
Library
Netzwerk, IPC
Betriebsystem
Client
OHO
Betriebsystem
Server
Kap1-4
Klassifikationsübersicht bei Client/Server
DB-Server
Monolithisch
Multiple Server
ein DBS-Prozess
mehrere DBS-Prozesse
Symmetrisch
Asymmetrisch
pro AP ein DBSProzess
dynamische
Zuordnung der APs
zu den DBSProzessen
OHO
Kap1-5
Monolithischer Server
•
•
•
eigene Ressourcenverwaltung, dupliziert BS-Funktionen
einfache Kommunikation im Server durch Shared Memory
z.B. Sybase, MS SQL Server
AP
Client
1
CL
…
AP
Client
i
AP
Client
n
CL
CL
Betriebssystem 1
DBMS
Server
1
Betriebssystem m
Netzwerk
OHO
Kap1-6
Multiple Server
•
•
•
•
DBMS ist ein Verbund von verschiedenen Prozessen
Kommunikation über Betriebssystem (z.B. IPC) oder Netzwerk
Scheduling der Prozesse geschieht über das Betriebssystem, grosser Vorteil
bei Mehrprozessor-Rechnern, da Prozessorzuteilung durch das BS erfolgt
z.B. Oracle, Informix, DB2
…
AP
Client
i
AP
Client
n
CL
CL
CL
Betriebssystem 1
Dispatcher
AP
Client
1
DBMS … DBMS
Server
Server
1
k
Betriebssystem m
Netzwerk
OHO
Kap1-7
1.2 Realisierung
Aufgabenteilung: Anwendungsfunktionalität im Client oder
Server? Thin- / Thick Client?
• Wieviel soll der Client machen?
• Präsentation
• Anwendungsfunktionalität (ESQL/CLI)?
• Was sind die Aufgaben des Servers?
• Datenverwaltung
• Anwendungsfunktionalität (Stored procedures, Trigger etc.)?
Client
Data
Presentation
OHO
Server
Access
Functionality
Data
Management
Kap1-8
Infrastrukturkomponenten im Ueberblick
API =Application Program Interface
Driver= arbeitet mit API Calls im Austausch mit Server
FAP = Format and Protocols
Client
Appl
Database
Administrator
Vendor B
Vendor C
Stored SQL
Stored
Commands Procedures
Tables
Binding API
SQL API
Driver
Stacks
DBMS
Server
Gateway
Stacks
Stored SQL
Commands
SQL FAP
Vendor A
(aus OHE99)
OHO
Kap1-9
Uebersicht (aus OHE99)
Embedded
SQL Appl.
SQL
Commands
Call-level
SQL Appl.
Precompiler
CLI Calls
CLI
Precompiler
Call-level Interface
Run-time Library Run-time Library
Database Driver
Stacks
Client
SQL FAP
Server
Tables
OHO
Stacks
Database
Server
Stored Procedures
and Compiled SQL
Kap1-10
Anwendungsentwicklung - Client-seitig
• Embedded SQL (ESQL):
Nach ISO SQL-92 definierte Einbettung von SQL in
Programmiersprachen, z.B. C, Fortran, Cobol, PL/1,
Pascal, Mumps, Ada
• Statisches ESQL: Alle Informationen zur Compilierung
vorhanden.
• Dynamisches ESQL: SQL-Statements zur Laufzeit
• Call-Level Interface (CLI):
Standardisierte Schnittstelle zur Kommunikation mit
Datenbanken ohne Precompiler.
• X/Open SAG CLI (SAG = SQL Access Group)
• ODBC, JDBC
OHO
Kap1-11
Anwendungsentwicklung - ESQL-Beispiel
ESQL/Csource
program
ESQL/C
preprocessor
stages 1 & 2
C-source
program
with SQL
statements
and ESQL/C
calls
C language
preprocessor
and
compiler
Executable
program
• Statisch:
Program {
…..
A:=1
…..
EXEC SQL SELECT Atr2 from TABLE where Atr1=A
…..
}
• Precompiler prüft, ob die Relation TABLE existiert und
ob die Attribute Atr1, Atr2 vorhanden sind.
OHO
Kap1-12
Anwendungsentwicklung - ESQL-Beispiel
• Dynamisch:
character string Deklaration
DCL QSTRING CHAR(256) VARYING INITIAL
‘DELETE from Employee where Salary < ?’
SQL Variable
EXEC SQL DECLARE SQLVARBL STATEMENT
Precompile
EXEC SQL PREPARE SQLVARBL FROM :QSTRING
…..
EXEC SQL EXECUTE SQLVARBL USING :LOW_LIMIT
Dieser ESQL-Befehl substituiert dann zur Laufzeit
das Fragezeichen mit einem Wert von einer Programmvariable
LOW_LIMIT.
OHO
Kap1-13
SQL CLI
• SQL/CLI: Standard seit 96, Bestandteil von SQL3:
Vereinbarung über
• DB-Verbindungsaufnahme und Beendigung,
• “prepare” und “execute” von SQL-Anweisungen,
• Entgegennahme von Resultaten,
• Vereinbarung über Codes für Datentypen (bei
dynamischem SQL nötig)
(Uebersicht siehe Ergänzungsblatt aus SQL3-Standard)
• Object CLI: JDBC, ODBC, OLE DB ActiveX Data Objects
…Weiterentwicklung zu Objektschnittstellen!
OHO
Kap1-14
Anwendungsentwicklung - CLI
• Interactive Ad-Hoc-Anfrage:
API
#include “sql.h”
Native
CLI
:
Interface
UCHAR
*
server;
HDBC
hdbc;
UCHAR
*
pwd;
HENV
henv;
DBMS
UCHAR
*
sqlstr;
HSTMT
hstmt;
SWORD
nresultcols;
RETCODE rc;
UCHAR
*
data[MAXCOLS];
:
SQLAllocEnv(&henv);
// Allocate environment
SQLAllocConnect(henv,&hdbs);
// Allocate connection handle
rc=SQLConnect(hdbc,server,SQL_NTS,uid,SQL_NTS,pwd,SQL_NTS);
SQLAllocStmt(hdbc, &hstmt);
if (SQLExecDirect(hstmt,sqlstr,SQL_NTS)!=SQL_SUCCESS) …
:
SQLNumResultCols(hstmt, &nresultcols;
for(i=0;i<nresultcols;i++) {
SQLBindCol(...,data[i],...); // Bind column specific information to variables
}
rc=SQLFetch(hstmt);
while((rc==SQL_SUCCESS)||(rc==SQL_SUCCESS_WITH_INFO)) {
for(i=0;i<nresultcols;i++) printf(“%s “,data[i]);
// Display each column of actual row
:
rc=SQLFetch(hstmt);
}
Aus: INFORMIX-CLI Programmer’s Manual
OHO
Kap1-15
Anwendungsentwicklung - Server-seitig
• Stored Procedures:
- Verwendung einer 4GL
- Standard unter SQL3 als “SQL/PSM” (= Persistent Stored
Module)
• Trigger (s. IS-G)
• User Defined Types (UDTs, s. SQL3)
Client
Application
Select
Insert
Update
Client
Application
Execute
procedure
Return
results
Stored
Procedure
Server
Database
Remote SQL
OHO
Database Server
Stored Procedure
Kap1-16
Anwendungsentwicklung - Stored Procedures
Stored Procedures
SPL
Extern procedures
SPL procedure
SPL function
C procedure
C function
CREATE FUNCTION update_by_pct(pct INT, pid CHAR(10))
RETURNING INT;
DEFINE n INT;
UPDATE inventory SET price=price + price * (pct/100) WHERE p art_id=pid;
LET n=price;
RETURN price;
END FUNCTION;
CREATE FUNCTION equal(arg1 otype1, arg2 otype1)
RETURNING BOOLEAN;
EXTERNAL NAME ”/usr/lib/opaquetype/lib/libbtypelib.so(otype_equal)”
LANGUAGE C
END FUNCTION;
Aus: INFORMIX-Manual “User defined routines”
OHO
Kap1-17
Multi-Datenbanken?
…entwickeln eines AP, das Daten aus mehreren DBs benötigt und in einer
Transaktion ändert.
Vendor A
Client
Vendor B
Client
Vendor C
Client
Appl
Appl
Appl
SQL API
Driver
Stacks
SQL API
Driver
Stacks
SQL API
Driver
Stacks
FAP A FAP B FAP C
Vendor A
DBMS
Server
Stacks
Vendor B
DBMS
Server
Stacks
Vendor A
Database
Administrator
Vendor C
DBMS
Server
Vendor B
Database
Administrator
Vendor C
Database
Administrator
OHO
Stacks
Kap1-18
Zur Rolle von JDBC
Java
Application
Java
Application
Java
Application
JDBC API
JDBC Driver Manager
JDBC to ODBC
Driver
ODBC Driver
MS
SQL Server
Driver to
Sybase
Sybase
SQL Server
Driver to
DB2
DB2
Driver to
Oracle
Service Provider
API
Oracle
Database
(aus OHE99)
OHO
Kap1-19
Transaktionen, Trigger, Stored Procedures
• Werden alle betroffenen Triggger innerhalb der Transaktion ausgeführt?
• Ja, siehe IS-G, spätestens am Ende der Transaktion
• Kann man mittels Trigger auf eine zweite Datenbank zugreifen?
• Nein, es sei denn, die Datenbanken seien “verbunden” .
• Kann innerhalb einer in DB1 bekannten Stored Procedure A1 auf eine
weitere Datenbank DB2 zugegriffen werden? Kann eine dort definierte
SP A2 aufgerufen werden?
• Nein. Man braucht in der Regel hierfür einen TP-Monitor
• Kann man mehrere Stored Procedures zu einer Transaktionen
zusammenfassen?
• Nein, häufig ist der Aufruf einer SP gleichzeitig eine Transaktion.
• Man muss daher mehrer SPs zu einer SP zusammenfasen.
• Kann eine Stored Procedure A innerhalb einer Transaktion eine andere
Stored Procedure B aufrufen?
• Nein, siehe oben, wenn eine SP gleichzeitig Transaktion ist.
OHO
Kap1-20