Teil I: Existierende Infrastruktur heterogener und verteilter Informationssysteme

Transkript

1 Teil I: Existierende Infrastruktur heterogener und verteilter Informationssysteme 1. Infrastruktur durch erweiterte Datenbankfunktionalität ( TP-Lite ) 2. Middleware-Infrastruktur durch TP-Monitore ( TP-Heavy ) 3. Standards zur verteilten Objektverwaltung 4. Object Transaction-Monitore 5. Enterprise JavaBeans 6. Message-Oriented Middleware 7. Web-Services Kapitel 1: Vorlesung TP-Lite 1

2 Kap. 1: Infrastruktur durch erweiterte Datenbankfunktionalität ( TP-Lite ) 1.1 Traditionelle, zweistufige Architektur ( Two-tier ) Klassifikation von Datenbankservern Architekturvarianten: Aufgabenteilung zwischen und Server Fat s Embedded SQL (statisch und dynamisch) SQL Call-Level-Interfaces Fat Server Stored Procedures, Trigger, UDTs DBMS DB DB-Server Kapitel 1: Vorlesung TP-Lite 2

3 Klassifikation von Datenbank-Servern DB-Server Monolithisch ein DBS-Prozess Multiple Server mehrere DBS-Prozesse Symmetrisch pro Anwendungsprozess ein DBS-Prozess Asymmetrisch dynamische Zuordnung von Anwendungsprozesse zu DBS-Prozessen Kapitel 1: Vorlesung TP-Lite 3

4 Monolithischer Server Genau ein Server-Prozess für viele s 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 1 AP i AP n DBMS Server CL CL CL Betriebssystem 1 Betriebssystem m Netzwerk Kapitel 1: Vorlesung TP-Lite 4

5 Multiple Server: Symmetrische Konfiguration DBMS ist ein Verbund von verschiedenen Prozessen Jedem 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 1 CL AP i CL AP n CL DBMS Server n DBMS Server i DBMS Server 1 Betriebssystem 1 Betriebssystem m Netzwerk Kapitel 1: Vorlesung TP-Lite 5

6 Multiple Server: Asymmetrische Konfiguration Ein 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 s sich einen Server-Prozess teilen können) Zu finden bei Oracle im Multi-Threaded-Server-Mode AP 1 CL AP i CL AP n CL Dispatcher DBMS Server 1 DBMS Server k Betriebssystem 1 Betriebssystem m Netzwerk Kapitel 1: Vorlesung TP-Lite 6

7 Two-Tier-Architektur und Server sind völlig getrennt Kommunikation zwischen und Server Via Netzwerk oder IPC mit gemeinsamen Protokoll (z.b. JDBC, Oracle Net8) (Klare) Aufgabenteilung zwischen und Server Präsentation Datenverwaltung Server Anwendungsfunktionalität??? DB Server Server DB Library Betriebssystem Netzwerk, IPC DB Server Library Betriebssystem Kapitel 1: Vorlesung TP-Lite 7

8 Two-Tier-Architektur: Realisierung Aufgabenteilung: Anwendungsfunktionalität im oder Server? Fat / Thin Server Thin / Fat Server Was soll der machen? Präsentation Anwendungsfunktionalität (ESQL/CLI) Was sind die Aufgaben des Servers? Datenverwaltung Anwendungsfunktionalität (Stored Procedures, Trigger, etc.) Data Presentation Access Functionality Data Management Server Kapitel 1: Vorlesung TP-Lite 8

9 Anwendungsentwicklung Fat / Thin Server Embedded SQL Anwendung Call-Level SQL Anwendung SQL Präcompiler Präcompiler- Runtime Library DBMS-Treiber DBMS CLI Calls CLI-API (Application Program Interface) Call Level Interface Runtime Library SQL-FAP (Format and Protocols), herstellerdefiniert, z.b. Net8 von Oracle DB Server Kapitel 1: Vorlesung TP-Lite 9

10 Embedded SQL (ESQL) Nach ISO SQL-92 definierte Einbettung von SQL in Programmiersprachen z.b. Java (SQLJ), C, C++, Fortran, Pascal, Cobol, PL/1, Ada Präcompiler ersetzt die SQL-Aufrufe in Calls der jeweiligen Runtime Library des verwendeten Datenbank-Servers Bei Wechsel der Datenbank müssen ESQL-Programme nur neu kompiliert und gelinkt werden Statisches ESQL 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 Kapitel 1: Vorlesung TP-Lite 10

11 Embedded SQL statisch ESQL/C- Quell- Programm (SQL-Anweisungen bekannt) ESQL/C Präcompiler C-Quell- Programm mit SQL Anweisungen und ESQL/C Aufrufen C- Präprozessor Compiler und Linker Ausführbares Programm 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; } 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: 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 SQL- Statements zur Compile-Zeit bekannt sein müssen), jedoch: wenige Laufzeitfehler! Kapitel 1: Vorlesung TP-Lite 11

12 Embedded SQL dynamisch ESQL/C- Quell- Programm (SQL-Anweisungen noch nicht bekannt) ESQL/C Präcompiler C-Quell- Programm mit SQL Anweisungen und ESQL/C Aufrufen C- Präprozessor Compiler und Linker Ausführbares Programm 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; 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! Kapitel 1: Vorlesung TP-Lite 12

13 SQL Call-Level Interface (CLI) Standardisierte Schnittstelle zur Kommunikation mit Datenbanken ohne Präcompiler CLI-API erlaubt das Erstellen und Ausführen von SQL-Anweisungen zur Laufzeit SQL/CLI: Standard seit 1996 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 Kapitel 1: Vorlesung TP-Lite 13

14 CLI-Dialekte Neben standardisiertem SQL/CLI haben sich noch weitere Dialekte herausgebildet (war das ursprüngliche Ziel der SAG nicht die Definition einer einheitlichen Schnittstelle?) 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 Microsoft- Programmen (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 DBMS-Treiber SQL/CLI-API Native API Call Level Interface Runtime Library Kapitel 1: Vorlesung TP-Lite 14

15 Call Level Interface: SQL99 CLI #include "sqlcli.h" extern SQLHDBC hdbc; /* Verbindung steht schon */ extern SQLHENV henv; /* 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); } Kapitel 1: Vorlesung TP-Lite 15

16 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); } Kapitel 1: Vorlesung TP-Lite 16

17 Object CLI Weiterentwicklung von CLI zu Objektschnittstellen (SQL/CLI kennt nur prozedurale APIs) JDBC (Java Database Connection) ActiveX Data Objects (ADO) Unterstützung von JDBC Entweder direkt durch Native-API Oder Umweg über JDBC-ODBC-Bridge Java-Anwendung JDBC-Treiber-Manager JDBC-ODBC- Bridge JDBC-API JDBC-Native Treiber SQL/CLI-API ODBC-API Native API Call Level Interface Runtime Library DBMS-Treiber Kapitel 1: Vorlesung TP-Lite 17

18 Zusammenfassung der Fat -Konzepte 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 s 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 Kapitel 1: Vorlesung TP-Lite 18

19 Anwendungsentwicklung Thin / Fat Server Prozedur- Aufruf SQL- FAP Rückgabewerte DBMS Stored Procedure UDT Trigger Server Kapitel 1: Vorlesung TP-Lite 19

20 Fat Server Anwendungslogik innerhalb der Datenbank Stored Procedures (TP-Lite) 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 Kapitel 1: Vorlesung TP-Lite 20

21 Stored Procedures Stored Procedure Internal External Procedure Function Procedure Function CREATE PROCEDURE credit (amount NUMBER, accountno INTEGER) IS BEGIN UPDATE account SET balance = balance + amount WHERE account_number = accountno; END debit; Oracle PL/SQL 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"; Kapitel 1: Vorlesung TP-Lite 21

22 Trigger 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 > ) BEGIN UPDATE admin SET number_of_managers = number_of_managers + 1 WHERE dept = new.dept; END 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 Kapitel 1: Vorlesung TP-Lite 22

23 Benutzerdefinierte Datentypen 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; Kapitel 1: Vorlesung TP-Lite 23

24 Zusammenfassung: Fat Server vs. Fat Fat -Architekturen Traditioneller Ansatz in der zweistufigen /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 s 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 Kapitel 1: Vorlesung TP-Lite 24