Kap. 2 Middleware-Infrastruktur durch Transaction Processing Monitore ( TP-Heavy )

Transkript

1 Kap. 2 Middleware-Infrastruktur durch Transaction Processing Monitore ( TP-Heavy ) 2.1 Architekturüberblick Dreistufige/mehrstufige Architektur ( Three-Tier / Multi-Tier ) Aufgabenteilung zwischen Client, Middleware und Server Basis-Middleware-Funktionalität 2.2 Funktionalität und Aufbau eines TP-Monitors TP Monitor als Transaktionsbetriebssystem Behandlung von Transaktionen: X/Open DTP 2.3 Workshop TP-Heavy am Beispiel des TP-Monitors Tuxedo Kapitel 2: Vorlesung TP-Heavy 1

2 2.1 Drei- oder Mehrstufen Architektur G Bisher (zweistufige Architektur) sind wir vor der Frage gestanden, ob die Anwendungsentwicklung im Client (Fat Client) oder im Server (Fat Server) bereitgestellt werden soll G Alternative: Einführung einer zusätzlichen Schicht unabhängig von Client und DB-Server für die Bereitstellung von Anwendungsfunktionalität Dreistufige Architekturen (Three-Tier) G Weitere Verallgemeinerung: Aufteilung der Anwendungsfunktionalität in mehrere Komponenten, die sich gegenseitig aufrufen (wiederholte Anwendung des Client/Server-Prinzips) Mehrstufige Architekturen (Multi-Tier) G Voraussetzung: Möglichkeit, diese Komponenten auch im Falle von Heterogenität und physischer Verteilung zusammenzuführen Middleware Kapitel 2: Vorlesung TP-Heavy 2

3 Three-Tier-Architektur Client G Idee: Zusätzliche Schicht (Applikationsserver) für Anwendungsfunktionalität G Doppelrolle: Server und DB-Client gleichzeitig Library Client Betriebssystem Betriebssystem Server Library Anwendung DB Server DB Client Library Betriebssystem Client Server DB Server Library Betriebssystem Präsentation Anwendungslogik Datenhaltung Kapitel 2: Vorlesung TP-Heavy 3

4 Hauptmerkmale und Vorteile der Three-Tier-Architektur G Mittlere Schicht ist (künstlicher) Server dem (eigentlichen) Client gegenüber (künstlicher) Client dem (eigentlichen) Server gegenüber. G Die folgenden Hauptvorteile resultieren daraus: Anwendungsentwicklung unabhängig vom DBMS-Hersteller Flexibilität: Verwendung von DBMSen verschiedener Hersteller Verfügbarkeit und Lastbalancierung: Replikation von Servern Flexible (technische) Fehlerbehandlung durch Neustart von Teilaktivitäten Kapitel 2: Vorlesung TP-Heavy 4

5 IT-Umgebung eines Grossunternehmens (ca.1996) Terminals > 9000 Terminals (3270) Terminalemulation auf jedem PC Grossteil der Applikationen terminalbasiert Mainframes 2 Rechenzentren 10 Mainframes (MVS, UNIX) DB2, IMS/DB 3500 MIPS 18 TB Disk Printfabrik 11 Mio Txn. / Tag Jobs / Nacht 230 Mio Blatt Papier / Jahr 800 geänderte Programme pro Woche Netzwerk Multiprotokollnetz (TCP/IP, SNA) PCs 600 PC-LANs PCs (OS/2, Win 3.11, NT) automatisierte SW-Verteilung (6000 mal / Jahr) Workstations 800 Workstations und Servers (AIX, Solaris, ) > 100 C/S-Applikationen (davon eine mit > 1000 Benutzern) Diverse Spezialsysteme Kapitel 2: Vorlesung TP-Heavy 5

6 IT-Umgebung: Anforderungen G Interoperabilität Zwischen heterogenen Plattformen Zwischen zugekauften und eigenen Lösungen, G Verteilte Transaktionen Über heterogenen Datenbanken G Flexible Erweiterung / Anpassung Bestehender Systeme bzw. Anwendungen um neue Bedürfnisse G Sanfte Daten-Migration Von bestehenden Lösungen auf neue Systeme Kapitel 2: Vorlesung TP-Heavy 6

7 Middleware: Charakterisierung G Zur Verbindung von Client- und Server-Komponenten (bzw. auch zur Server/Server-Kommunikation) G Definition: Middleware is a stand-alone software entity providing services for one or more applications. (= application infrastructure software) Not designed to meet business needs but rather application needs, d.h. Middleware stellt keine Anwendungsfunktionalität zur Verfügung, sondern (Basis-) Dienste zur Unterstützung der Entwicklung und Ausführung von Anwendungen Trennung von Infrastruktur-Funktionalität und Anwendungsfunktionalität G Kommunikations-Middleware: Grundlage für die Kommunikation zwischen kooperierenden en RPC (Remote Procedure Call) Hauptsächlich synchrone Ausführung von Prozeduren auf einem entfernten Oft implementiert als Teil des Betriebssystems z.b. in Client-Server-Datenbanksystemen, Echtzeit-Kommunikation Kapitel 2: Vorlesung TP-Heavy 7

8 Middleware: Charakterisierung G Middleware Services: Bereitstellung von Diensten aufbauend auf Basis- Kommunikations-Middleware Datenbankzugriff ( SQL-Middleware, Kapitel 1) CLI, ODBC, JDBC (Verteilte) Transaktionen (dieses Kapitel sowie 4, 5 und 6) TxRPC, 2PC Verteilte Objektverwaltung (Kapitel 3, 4, 5) ORB Asynchrone Kommunikation (Kapitel 6) Messages G Middleware Frameworks: Von anwendungsneutraler Software-Umgebung zur Entwicklung von Anwendungen und gleichzeitig auch Laufzeitumgebung für diese, z.b. Transaktionsmonitore CORBA Object Monitors Publish/Subscribe-Systeme Bis hin zu anwendungsspezifischen Tools (z.b. Computer-aided Software Engineering Workbenches) Kapitel 2: Vorlesung TP-Heavy 8

9 Middleware: Übersicht G Middleware: Software-Schicht in der Mitte zwischen Betriebssystem/Netzwerk und Anwendungsprogramm Clients und Server Interoperabilität zwischen heterogenen Plattformen Mehr als nur / in Client/Server Client- Programm Betriebssystem und Netzwerk-Software Computer- und Netzwerk-Hardware Middleware Frameworks Middleware Services Kommunikations-Middleware Betriebssystem und Netzwerk-Software Computer- und Netzwerk-Hardware Server- Programm Betriebssystem und Netzwerk-Software Computer- und Netzwerk-Hardware Kapitel 2: Vorlesung TP-Heavy 9

10 2.2 TP-Monitor: Funktionalität und Aufbau G Definition: Betriebssystem für Transaktionsverarbeitung ( managing client/server transactions ). Weiter gefasst: Middleware-Framework (d.h. Infrastruktur) für die Entwicklung und Ausführung von transaktionalen Anwendungen, Diensten und Komponenten der mittleren Stufe einer dreistufigen Architektur. TP-Heavy: Verwendung von TP-Monitoren für die Entwicklung und Ausführung verteilter Anwendungen G Hauptaufgaben eines TP-Monitors Transaktionsverwaltung: Garantie von ACID-Eigenschaften für globale Transaktionen, unabhängig davon, ob DBMSs verschiedener Hersteller involviert sind (Verteilung, Heterogenität). Durchführung und Überwachung eines Zwei-Phasen-Commit (Basierend auf X/Open Distributed Transaction Processing (DTP)-Standard) management: Starten von Serverprozessen, Durchschleusen/Trichtern ( Funneling ) von eingehenden Requests, Überwachen der Ausführung und Lastbalancierung. Client/Server-und Server/Server-Kommunikation: Ausführungsgarantien durch TxRPC ( transactional remote procedure call ), Transactional Queues und MOMs (Message-oriented Middleware) Kapitel 2: Vorlesung TP-Heavy 10

11 Middleware-Charakteristik von TP-Monitoren G TP-Monitor (Darstellung nach Bernstein/Newcomer): Bindemittel ( Glue ) für Komponenten und Schicht (= Fournier, Veneer ) für Anwendungen TP application programs TP-Monitor Request routing TP monitor API veneer Transactional communications Two-phase commit User interface services Operating system services Communication services Database system services Kapitel 2: Vorlesung TP-Heavy 11

12 TP Monitor als Middleware-Framework Client TPM Library Betriebssystem Client G Client: Aufruf entfernter Anwendungen tpcall(...) G Server: Führt SQL-Aufrufe aus G TP-Monitor als Server und als DB-Client: Zusammenfassung aller DB-Zugriffe innerhalb des tpcalls des Clients in eine Transaktion Server Betriebssystem TPM Library TP-Monitor DB Server DB Client Library Client Server DB Server Library Betriebssystem Betriebssystem Kapitel 2: Vorlesung TP-Heavy 12

13 Wiederholung: Transaktionsverwaltung & ACID G Transaktionen sind Folgen von logisch zusammengehörenden Operationen in einer oder in mehreren Datenbanken mit ACID- Eigenschaften G ACID-Eigenschaften Atomicity (Atomarität) Eine Transaktion wird entweder komplett ausgeführt ( commit ) oder erscheint so, als wäre sie nie gestartet worden, d.h. sie hinterlässt keine Effekte ( rollback ) Consistency (Konsistenz) Eine Transaktion führt die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand über Isolation Transaktionen, auch wenn parallel ausgeführt, erscheinen so als ob sie isoliert voneinander (d.h. sequentiell) ausgeführt wurden Durability (Persistenz) Nach dem Commit einer Transaktion sind ihre Effekte dauerhaft, d.h. überleben auch Systemabstürze Kapitel 2: Vorlesung TP-Heavy 13

14 Verteilte TP-Monitor-Transaktion Kontrollsphäre der verteilten, vom TP-Monitor durch 2PC koordinierten Transaktion Transactional A Receive SQL@DB1 Call B SQL@DB2 Return Transactional B Receive SQL@DB2 Return Kontext DB1 DB2 Kapitel 2: Vorlesung TP-Heavy 14

15 management: Betriebssystemlösung G Ein Server- per Client Enorme Belastung für das Betriebssystem bei grosser Anzahl Clients Präsentation Service A Service B Service A Service C Service C Service B Service A Service C Datenhaltung Anwendungslogik Kapitel 2: Vorlesung TP-Heavy 15

16 management: TP-Monitor-Lösung TP-Monitor hält eine Menge von vorgestarteten Server- en bereit (Bündelung) Wiederverwendung der e Weniger Aufwand für das Betriebssystem Load Balancing TP-Monitor weist Client- Requests freie Server- e zu, oder Startet neue Server- e Service A Service B TP-Monitor Service C Datenhaltung Anwendungslogik (+ TP-Middleware) Präsentation Kapitel 2: Vorlesung TP-Heavy 16

17 Client/Server- u. Server/Server-Kommunikation G Transactional Remote Procedure Call (TxRPC): üblicher RPC + Zusätzlich: Aufruf wird (Sub-)Transaktion der globalen verteilten Client-Transaktion Jeder Transaktion wird eine automatisch vergebene Transaktionskennung (TXID) zugewiesen Jeder Aufruf bzw. jede Message enthält neben den eigentlichen Parametern die TXID der zugehörigen Transaktion Mittels TXID Koordiniert der TP-Monitor alle Teilaktivitäten, d.h. entscheidet über gemeinsames Commit oder Rollback (2PC-Protokoll) Garantiert, dass Nachrichten empfangen bzw. Services genau einmal gestartet werden ( exactly-once Semantik) Kapitel 2: Vorlesung TP-Heavy 17

18 X/Open DTP G Standardisierung von APIs für die Unterstützung der Entwicklung verteilter Transaktionen basierend auf dem Two-Phase Commit- Protokoll (2PC): X/Open DTP (Distributed Transaction Processing) Erste Version des Standards 1991 veröffentlicht G Unterscheidung mehrerer Komponenten RM: Resource Manager, z.b. DBMS TM: Transaction Manager CRM: Communications Resource Manager Es werden unterschiedliche Schnittstellen benötigt Für die Interaktion von Applikationen mit diesen Komponenten bzw. Zwischen unterschiedlichen Komponenten Kapitel 2: Vorlesung TP-Heavy 18

19 X/Open DTP: Gesamtarchitektur (AP) RM API TX API XATMI TxRPC CPI-C Resource Manager (RM) XA Transaction Manager (TM) XA+ Communication Resource Managers (CRM) XAP-TP Interface OSI-TP TCP/IP APPC OSI Kapitel 2: Vorlesung TP-Heavy 19

20 X/Open DTP: APIs G RM API = Resource Manager Program Interface z.b. ESQL, CLI G TX API = API zum Transaction Manager (TM) Festlegung der Transaktionsgrenzen: BeginTX, CommitTX, AbortTX G Transactional Communication zum Aufruf von Anwendungsdiensten in einem Transaktionskontext. Hierzu werden in X/Open DTP die folgenden existierenden APIs übernommen XATMI, basierend auf Tuxedo s to Transaction Monitor Interface (ATMI) TxRPC (Transactional Remote Procedure Call), basierend auf RPC CPI-C, basierend auf IBM peer-to-peer G XA API Interface zwischen RM und TM im wesentlichen für die eigentliche Durchführung des 2PC: PrepareCommit, Commit, Rollback G XA+ API: Erweiterung von XA die es einem CRM erlaubt, dem TM mitzuteilen, dass ein weiterer ( untergeordneter ) Knoten an der verteilten Transaktion teilnimmt G OSI-TP: Zur Kommunikation heterogener Transaktionsmanager Kapitel 2: Vorlesung TP-Heavy 20