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: CORBA, DCOM 4. Object Transaction-Monitore 5. Enterprise JavaBeans 6. Message-Oriented Middleware 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 zwischen und Fat s Embedded SQL (statisch und dynamisch) SQL Call-Level-Interfaces Fat Stored Procedures, Trigger, UDTs DB DB- Kapitel 1.1: Vorlesung TP-Lite 2

2 Klassifikation von Datenbank-n DB- Monolithisch ein DBS-Prozess Multiple mehrere DBS-Prozesse Asymmetrisch Symmetrisch pro Anwendungsprozess ein DBS-Prozess dynamische Zuordnung von Anwendungsprozesse zu DBS-Prozessen Kapitel 1.1: Vorlesung TP-Lite 3 Monolithischer G Genau ein -Prozess für viele s verwendet mehrere Threads (Reentrant Code) Führt eigene Ressourcenverwaltung durch G Einfache Kommunikation im durch Shared Memory Synchronisierter Zugriff auf Systempuffer und zentrale Systemtabellen G Monolithische Architektur z.b. bei Sybase oder MS SQL zu finden 1 i n Betriebssystem 1 Betriebssystem m Netzwerk Kapitel 1.1: Vorlesung TP-Lite 4

3 Multiple : Symmetrische Konfiguration G ist ein Verbund von verschiedenen Prozessen G Jedem ist genau ein Prozess zugeordnet Statische Zuordnung, feste Anzahl n vorgeneriert Maximaler Parallelitätsgrad ist n G Zu finden bei Oracle im Dedicated -Mode, bei Informix und DB2 1 i n n i 1 Betriebssystem 1 Betriebssystem m Netzwerk Kapitel 1.1: Vorlesung TP-Lite 5 Multiple : Asymmetrische Konfiguration G Ein wird mit Hilfe des Dispatchers mit einem freien -Prozess verbunden Feste Anzahl ist vorgeneriert Der Parallelitätsgrad kann jedoch höher sein (da mehrere s sich einen -Prozess teilen können) G Zu finden bei Oracle im Multi-Threaded--Mode 1 i n Dispatcher 1 k Betriebssystem 1 Betriebssystem m Netzwerk Kapitel 1.1: Vorlesung TP-Lite 6

4 Two-Tier-Architektur G und sind völlig getrennt G Kommunikation zwischen und Via Netzwerk oder IPC mit gemeinsamen Protokoll (z.b. JDBC, Oracle Net8) G (Klare) Aufgabenteilung zwischen und Präsentation Datenverwaltung Anwendungsfunktionalität??? DB Library Betriebssystem Netzwerk, IPC DB DB Library Betriebssystem Kapitel 1.1: Vorlesung TP-Lite 7 Two-Tier-Architektur: Realisierung G Aufgabenteilung: Anwendungsfunktionalität im oder? Fat / Thin Thin / Fat G Was soll der machen? Präsentation Anwendungsfunktionalität (ESQL/I) G Was sind die Aufgaben des s? Datenverwaltung Anwendungsfunktionalität (Stored Procedures, Trigger, etc.) Data Presentation Access Functionality Data Management Kapitel 1.1: Vorlesung TP-Lite 8

5 Anwendungsentwicklung Fat / Thin Embedded SQL Anwendung Call-Level SQL Anwendung Präcompiler SQL I Calls Präcompiler- Runtime Library -Treiber I-I (Application Program Interface) Call Level Interface Runtime Library SQL-F (Format and Protocols), herstellerdefiniert, z.b. Net8 von Oracle DB Kapitel 1.1: Vorlesung TP-Lite 9 Embedded SQL (ESQL) G Nach ISO SQL-92 definierte Einbettung von SQL in Programmiersprachen z.b. Java (SQLJ), C, C++, Fortran, Pascal, Cobol, PL/1, Ada G Präcompiler ersetzt die SQL-Aufrufe in Calls der jeweiligen Runtime Library des verwendeten Datenbank-s Bei Wechsel der Datenbank müssen ESQL-Programme nur neu kompiliert und gelinkt werden G 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 G 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.1: Vorlesung TP-Lite 10

6 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 DEARE SECTION; NUMBER acc_no; } NUMBER bal; EXEC SQL END DEARE SECTION; acc_no := accountno; EXEC SQL SELECT a.balance INTO :bal FROM account a WHERE a.account_number = :acc_no; G 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 G 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]; } G Ansatz ist recht unflexibel (da alle SQL- Statements zur Compile-Zeit bekannt sein müssen), jedoch: wenige Laufzeitfehler! Kapitel 1.1: Vorlesung TP-Lite 11 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; G 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.1: Vorlesung TP-Lite 12

7 SQL Call-Level Interface (I) G Standardisierte Schnittstelle zur Kommunikation mit Datenbanken ohne Präcompiler I-I erlaubt das Erstellen und Ausführen von SQL-Anweisungen zur Laufzeit G SQL/I: 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 G SQL/I 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) G I-Call wird durch den proprietären -Treiber umgesetzt in herstellerspezifischen DB-Zugriff Mit geeignetem Treiber kann prinzipiell jede Datenquelle angesprochen werden Kapitel 1.1: Vorlesung TP-Lite 13 I-Dialekte G Neben standardisiertem SQL/I haben sich noch weitere Dialekte herausgebildet (war das ursprüngliche Ziel der SAG nicht die Definition einer einheitlichen Schnittstelle?) ODBC (Open Database Connectivity): Microsofts I-Variante Beinhaltet die meisten (nicht alle) I-Calls des I-Standards Zusätzlich: spezielle Calls zur Unterstützung von Microsoft- Programmen (Access, Excel, etc.) Proprietäre Is der DB-Hersteller ( Native I ) z.b. Oracle Call Interface (OCI) G In der Regel werden mehrere I-Dialekte parallel unterstützt ODBC-I SQL/I-I Native I Call Level InterfaceRuntime Library -Treiber Kapitel 1.1: Vorlesung TP-Lite 14

8 Call Level Interface: SQL99 I #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.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); } Kapitel 1.1: Vorlesung TP-Lite 16

9 Object I G Weiterentwicklung von I zu Objektschnittstellen (SQL/I kennt nur prozedurale Is) JDBC (Java Database Connection) ActiveX Data Objects (ADO) G Unterstützung von JDBC Entweder direkt durch Native-I Oder Umweg über JDBC-ODBC-Bridge Java-Anwendung JDBC-I JDBC-Treiber-Manager JDBC-ODBC- Bridge JDBC-Native Treiber SQL/I-I ODBC-I Native I Call Level InterfaceRuntime Library -Treiber Kapitel 1.1: Vorlesung TP-Lite 17 Zusammenfassung der Fat -Konzepte G Jeder Anwender programmiert seine Anwendungen selbst (alle entwickeln ähnliche Bausteine) G Alternative: Anwender benutzen vorgegebene Funktions-Bausteine G Bausteine ändern sich (Systemwechsel oder Firmenpolitik) Folge: alle Anwender müssen ihre Programmierung ändern bzw. Module aus gemeinsamer Bibliothek holen. G 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.1: Vorlesung TP-Lite 18

10 Anwendungsentwicklung Thin / Fat Prozedur- Aufruf Rückgabewerte SQL- F Stored Procedure UDT Trigger Kapitel 1.1: Vorlesung TP-Lite 19 Fat Anwendungslogik innerhalb der Datenbank G 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 verwenden jedoch proprietäre Dialekte, z.b. Ø PL/SQL in Oracle (siehe Workshop & praktische Übung) Ø TransactSQL in Sybase und MS SQL G Trigger (ereignisgesteuerte Funktionen/Prozeduren) G Benutzerdefinierte Datentypen (User Defined Types, UDTs) Bestandteil von SQL-99 Kapitel 1.1: Vorlesung TP-Lite 20

11 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.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 Event WHEN (new.salary > ) BEGIN UPDATE admin SET number_of_managers = number_of_managers + 1 WHERE dept = new.dept; END Condition Action (Stored Procedure) G 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.1: Vorlesung TP-Lite 22

12 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 DEARE old_balance INTEGER; old_balance = SELF.balance; SET SELF.balance = old_balance * 1.03; RETURN SELF.balance; END; Kapitel 1.1: Vorlesung TP-Lite 23 Zusammenfassung: Fat vs. Fat G Fat -Architekturen Traditioneller Ansatz in der zweistufigen /-Welt + Ausnutzen der Datenunabhängigkeit, die vom DB- 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) G Fat -Architekturen + Einfachere Wartbarkeit + Weniger Netzwerkbelastung (durch stärkeren Abstraktionsgrad der bereitgestellten Prozeduren) Schlechte Unterstützung für individuelle, personalisierte Anwendungen Kapitel 1.1: Vorlesung TP-Lite 24