Vorlesung "Objektverwaltung höherer Ordnung"
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 2003 Kapitel 2: Vorlesung TP-Heavy – 1 2.1 Drei- oder Mehrstufen Architektur 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 • Weitere Verallgemeinerung: Aufteilung der Anwendungsfunktionalität in mehrere Komponenten, die sich gegenseitig aufrufen (wiederholte Anwendung des Client/Server-Prinzips) • Dreistufige Architekturen (Three-Tier) 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 2003 Kapitel 2: Vorlesung TP-Heavy – 2 Three-Tier-Architektur Client Client Application Library Idee: Zusätzliche Schicht für Anwendungsfunktionalität Doppelrolle: Server und DB-Client gleichzeitig Betriebssystem Server Betriebssystem Application Library DB Server Präsentation Server DB Client Library Client Anwendung DB Server Library Betriebssystem Betriebssystem Anwendungslogik Datenhaltung Objektverwaltung höherer Ordnung (OHO) – SS 2003 Kapitel 2: Vorlesung TP-Heavy – 3 Hauptmerkmale und Vorteile der Three-Tier-Architektur Mittlere Schicht ist • • (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 2003 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 Objektverwaltung höherer Ordnung (OHO) – SS 2003 Workstations 800 Workstations und Servers (AIX, Solaris, …) > 100 C/S-Applikationen (davon eine mit > 1000 Benutzern) Diverse Spezialsysteme Kapitel 2: Vorlesung TP-Heavy – 5 IT-Umgebung: Anforderungen Interoperabilität • • Verteilte Transaktionen • Über heterogenen Datenbanken Flexible Erweiterung / Anpassung • Zwischen heterogenen Plattformen Zwischen zugekauften und eigenen Lösungen, … Bestehender Systeme bzw. Anwendungen um neue Bedürfnisse Sanfte Daten-Migration • Von bestehenden Lösungen auf neue Systeme Objektverwaltung höherer Ordnung (OHO) – SS 2003 Kapitel 2: Vorlesung TP-Heavy – 6 Middleware: Charakterisierung … 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) • • „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 2003 Kapitel 2: Vorlesung TP-Heavy – 7 … Middleware: Charakterisierung 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 und 6): ORB, EJB, J2EE • Asynchrone Kommunikation: Messages • Service Description and Discovery (Kapitel 5): Web-Servcies • Applikationsserver: Web-Services für J2EE-Komponenten Middleware Frameworks: • Von anwendungsneutraler Software-Umgebung zur Entwicklung von Anwendungen und gleichzeitig auch Laufzeitumgebung für diese, z.B. – Transaktionsmonitore – CORBA, Object Monitors, etc. – Applikationsserver • Bis hin zu anwendungsspezifischen Tools (z.B. Computer-aided Software Engineering Workbenches) Objektverwaltung höherer Ordnung (OHO) – SS 2003 Kapitel 2: Vorlesung TP-Heavy – 8 Middleware: Übersicht 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 2003 Kapitel 2: Vorlesung TP-Heavy – 9 2.2 TP-Monitor: Funktionalität und Aufbau 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 2003 Kapitel 2: Vorlesung TP-Heavy – 10 Middleware-Charakteristik von TP-Monitoren 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 Objektverwaltung höherer Ordnung (OHO) – SS 2003 Two-phase commit Communication services … Database system services Kapitel 2: Vorlesung TP-Heavy – 11 TP Monitor als Middleware-Framework Client Client TPM Library 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 2003 Server DB Client Library Client TP-Monitor DB Server Library Betriebssystem Kapitel 2: Vorlesung TP-Heavy – 12 Wiederholung: Transaktionsverwaltung & ACID 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 2003 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 2003 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 • Application Service C Prozess Prozess Prozess Prozess Prozess Datenhaltung Application Service C Prozess Application Service C Application Service A Prozess Application Service A Application Service B Prozess … Application Service B Application Service A … Anwendungslogik Objektverwaltung höherer Ordnung (OHO) – SS 2003 Kapitel 2: Vorlesung TP-Heavy – 15 Prozessmanagement: TP-Monitor-Lösung Prozess Prozess Anwendungslogik (+ TP-Middleware) Prozess Datenhaltung Application Service C G TP-Monitor Application Service B G 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 Application Service A G Präsentation … Objektverwaltung höherer Ordnung (OHO) – SS 2003 Kapitel 2: Vorlesung TP-Heavy – 16 Client/Server- u. Server/Server-Kommunikation 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 2003 Kapitel 2: Vorlesung TP-Heavy – 17 X/Open DTP 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) • Unterscheidung mehrerer Komponenten • • • § Erste Version des Standards 1991 veröffentlicht 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 2003 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 2003 APPC OSI Kapitel 2: Vorlesung TP-Heavy – 19 X/Open DTP: APIs RM API = Resource Manager Application Program Interface • TX API = API zum Transaction Manager (TM) • • • 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 • 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 2003 Kapitel 2: Vorlesung TP-Heavy – 20
