Teil I: Existierende Infrastruktur heterogener und verteilter Informationssysteme

Transkript

1 Kapitel 1: Vorlesung TP-Lite 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. Web-Services 7. Application Server

2 Kap. 1: Infrastruktur durch erweiterte Datenbankfunktionalität ( TP-Lite ) 1.1 Traditionelle, zweistufige Architektur ( Two-tier ) Traditionelle Datenbankanwendungen Serverübergreifende Datenbankanwendungen Architekturvarianten: Aufgabenteilung zwischen und Server Fat s Embedded SQL (statisch und dynamisch) SQL Call-Level-Interfaces Fat Server Stored Procedures, Trigger, UDTs Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 2

3 Kapitel 1: Vorlesung TP-Lite 3 Traditionelle Datenbankanwendungen App 1 App 2 DBMS App n Datenbanken sind die Plattform für die Anwendungsentwicklung Einfaches -Server-Prinzip App i : s DBMS: Server Zentralistische Sicht: es gibt nur einen Server DB /Server-Architektur mit zentraler Datenbank

4 Serverübergreifende Datenbankanwendungen App 11 App 12 App 21 App 22 App B1 App B2 Zugriff auf Datenbanken auch über Systemgrenzen hinweg DBMS A1 DB A1 Unternehmen A DBMS A2 DB A2 DBMS B DB B Unternehmen B /Server-Architektur mit Anwendungen über mehrere Datenbanken Anwendungen operieren auf mehreren Datenbanken (hier App 11 und App B1 ) Wichtige Fragestellungen in diesem Kontext: System-Unterstützung durch DBS-Produkte Umgang mit Heterogenität Übergreifender Transaktionskontext Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 4

5 Kapitel 1: Vorlesung TP-Lite 5 System-Unterstützung: Datenbank-Links App 11 App 12 App 21 App 22 App B1 App B2 DB-Link DBMS A1 DB A1 Unternehmen A DBMS A2 DB A2 DB-Link DBMS B DB B Unternehmen B Implementierung von Anwendungen über mehrere Datenbanken mit Datenbank-Links Zugriff auf andere Datenbanken mittels Datenbank-Links Oracle MS SQL Server Anwendungen greifen nicht direkt auf entfernte Datenbank zu DBMS bietet Datenbank- Link: Indirektion zum entfernten System über lokale DB Keine Heterogenität alle DBS vom gleichen Hersteller! Verteilte Transaktion mit two-phase-commit

6 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 Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 6

7 Kapitel 1: Vorlesung TP-Lite 7 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

8 Kapitel 1: Vorlesung TP-Lite 8 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

9 Kapitel 1: Vorlesung TP-Lite 9 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

10 Kapitel 1: Vorlesung TP-Lite 10 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!

11 Kapitel 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; 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!

12 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 Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 12

13 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 Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 13

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

15 Kapitel 1: Vorlesung TP-Lite 15 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

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

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

18 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 Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 18

19 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"; Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 19

20 Kapitel 1: Vorlesung TP-Lite 20 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

21 Kapitel 1: Vorlesung TP-Lite 21 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;

22 Kapitel 1: Vorlesung TP-Lite 22 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

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

24 Kapitel 1: Vorlesung TP-Lite 24 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

25 Kapitel 1: Vorlesung TP-Lite 25 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 unter UNIX 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

26 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 (unter UNIX) AP 1 CL AP i CL AP n CL Dispatcher DBMS Server 1 DBMS Server k Betriebssystem 1 Betriebssystem m Netzwerk Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 1: Vorlesung TP-Lite 26

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