TP-Heavy - ETH tools
Werbung
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 Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 1 2.1 Drei- oder Mehrstufen Architektur G G G 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 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) Weitere Verallgemeinerung: Aufteilung der Anwendungsfunktionalität in mehrere Komponenten, die sich gegenseitig aufrufen (wiederholte Anwendung des Client/Server-Prinzips) • Mehrstufige Architekturen (Multi-Tier) Voraussetzung: Möglichkeit, diese Komponenten auch im Falle von Heterogenität und physischer Verteilung zusammenzuführen ➜ Middleware Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 2 Three-Tier-Architektur G G Application Library Client Client Idee: Zusätzliche Schicht (Applikationsserver) für Anwendungsfunktionalität Doppelrolle: Server und DB-Client gleichzeitig Betriebssystem Server Betriebssystem Application Library DB Server Präsentation Client DB Client Library Server Anwendung DB Server Library Betriebssystem Betriebssystem Anwendungslogik Datenhaltung Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 3 Hauptmerkmale und Vorteile der Three-Tier-Architektur G Mittlere Schicht ist • • G (künstlicher) Server dem (eigentlichen) Client gegenüber (künstlicher) Client dem (eigentlichen) Server gegenüber. 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 Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 4 IT-Umgebung eines Grossunternehmens (ca.1996) Terminals PCs > 9000 Terminals (3270) Terminalemulation auf jedem PC 600 PC-LANs 19000 PCs (OS/2, Win 3.11, NT) Grossteil der Applikationen terminalbasiert automatisierte SW-Verteilung (6000 mal / Jahr) Netzwerk Mainframes 2 Rechenzentren 10 Mainframes (MVS, UNIX) DB2, IMS/DB 3500 MIPS 18 TB Disk Printfabrik Multiprotokollnetz (TCP/IP, SNA) 11 Mio Txn. / Tag 50000 Jobs / Nacht 230 Mio Blatt Papier / Jahr 800 geänderte Programme pro Woche Workstations 800 Workstations und Servers (AIX, Solaris, …) > 100 C/S-Applikationen (davon eine mit > 1000 Benutzern) Diverse Spezialsysteme Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 5 IT-Umgebung: Anforderungen G Interoperabilität • • Zwischen heterogenen Plattformen Zwischen zugekauften und eigenen Lösungen, … • Über heterogenen Datenbanken • Bestehender Systeme bzw. Anwendungen um neue Bedürfnisse G Verteilte Transaktionen G Flexible Erweiterung / Anpassung G Sanfte Daten-Migration • Von bestehenden Lösungen auf neue Systeme Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 6 Middleware: Charakterisierung … G G Zur Verbindung von Client- und Server-Komponenten (bzw. auch zur Server/Server-Kommunikation) Definition: Middleware is a stand-alone software entity providing services for one or more applications. (= application infrastructure software) • • G „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 Kommunikations-Middleware: Grundlage für die Kommunikation zwischen kooperierenden Prozessen • RPC (Remote Procedure Call) – Hauptsächlich synchrone Ausführung von Prozeduren auf einem entfernten Prozess – Oft implementiert als Teil des Betriebssystems – z.B. in Client-Server-Datenbanksystemen, Echtzeit-Kommunikation Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 7 … Middleware: Charakterisierung G G Middleware Services: Bereitstellung von Diensten aufbauend auf BasisKommunikations-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 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) Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 8 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 ClientProgramm Middleware Frameworks Middleware Services ServerProgramm Kommunikations-Middleware Betriebssystem und Netzwerk-Software Betriebssystem und Netzwerk-Software Betriebssystem und Netzwerk-Software Computer- und Netzwerk-Hardware Computer- und Netzwerk-Hardware Computer- und Netzwerk-Hardware Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 9 2.2 TP-Monitor: Funktionalität und Aufbau G 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 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) Prozessmanagement: 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) Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 10 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-Monitor TP application programs TP monitor API veneer Request routing User interface services Transactional communications Operating system services Two-phase commit Communication services Objektverwaltung höherer Ordnung (OHO) – SS 2001 … Database system services Kapitel 2: Vorlesung TP-Heavy – 11 TP Monitor als Middleware-Framework G G G TPM Library Client Client Client: Aufruf entfernter Anwendungen “tpcall(....)” Server: Führt SQL-Aufrufe aus TP-Monitor als Server und als DB-Client: Zusammenfassung aller DB-Zugriffe innerhalb des tpcalls des Clients in eine Transaktion Betriebssystem Server Betriebssystem TPM Library DB Server Betriebssystem Objektverwaltung höherer Ordnung (OHO) – SS 2001 Server DB Client Library Client TP-Monitor DB Server Library Betriebssystem Kapitel 2: Vorlesung TP-Heavy – 12 Wiederholung: Transaktionsverwaltung & ACID G G Transaktionen sind Folgen von logisch zusammengehörenden Operationen in einer oder in mehreren Datenbanken mit ACIDEigenschaften 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 Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 13 Verteilte TP-Monitor-Transaktion Kontrollsphäre der verteilten, vom TP-Monitor durch 2PC koordinierten Transaktion Transactional Application A Receive SQL@DB1 Call B SQL@DB2 Return Transactional Application B Receive SQL@DB2 Return Kontext DB1 Objektverwaltung höherer Ordnung (OHO) – SS 2001 DB2 Kapitel 2: Vorlesung TP-Heavy – 14 Prozessmanagement: Betriebssystemlösung Ein Server-Prozess per Client Enorme Belastung für das Betriebssystem bei grosser Anzahl Clients Präsentation • Prozess Prozess Prozess Prozess … Datenhaltung Prozess Application Service C Application Service C Prozess Application Service A Application Service A Prozess Application Service B Application Service B Prozess Application Service C Application Service A … Anwendungslogik G Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 15 … TP-Monitor hält eine Menge von vorgestarteten ServerProzessen bereit (Bündelung) ● Wiederverwendung der Prozesse – Weniger Aufwand für das Betriebssystem ● Load Balancing – TP-Monitor weist ClientRequests freie ServerProzesse zu, oder – Startet neue ServerProzesse ● Prozess Application Service C Prozess Datenhaltung Prozess Application Service B Application Service A TP-Monitor Anwendungslogik (+ TP-Middleware) Präsentation Prozessmanagement: TP-Monitor-Lösung Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 16 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) Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 17 X/Open DTP G G Standardisierung von APIs für die Unterstützung der Entwicklung verteilter Transaktionen basierend auf dem Two-Phase CommitProtokoll (2PC): X/Open DTP (Distributed Transaction Processing) • Erste Version des Standards 1991 veröffentlicht 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 Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 18 X/Open DTP: Gesamtarchitektur Application (AP) RM API XATMI Transaction Manager (TM) Resource Manager (RM) TX API XA TxRPC CPI-C Communication Resource Managers (CRM) XA+ XAP-TP Interface OSI-TP TCP/IP Objektverwaltung höherer Ordnung (OHO) – SS 2001 APPC OSI Kapitel 2: Vorlesung TP-Heavy – 19 X/Open DTP: APIs G RM API = Resource Manager Application Program Interface G TX API = API zum Transaction Manager (TM) G • • G G Festlegung der Transaktionsgrenzen: BeginTX, CommitTX, AbortTX Transactional Communication zum Aufruf von Anwendungsdiensten in einem Transaktionskontext. Hierzu werden in X/Open DTP die folgenden existierenden APIs übernommen • G z.B. ESQL, CLI • • XATMI, basierend auf Tuxedo’s Application to Transaction Monitor Interface (ATMI) TxRPC (Transactional Remote Procedure Call), basierend auf RPC CPI-C, basierend auf IBM “peer-to-peer” XA API Interface zwischen RM und TM im wesentlichen für die eigentliche Durchführung des 2PC: PrepareCommit, Commit, Rollback XA+ API: Erweiterung von XA die es einem CRM erlaubt, dem TM mitzuteilen, dass ein weiterer (“untergeordneter”) Knoten an der verteilten Transaktion teilnimmt OSI-TP: Zur Kommunikation heterogener Transaktionsmanager Objektverwaltung höherer Ordnung (OHO) – SS 2001 Kapitel 2: Vorlesung TP-Heavy – 20
