Transaktionssysteme. Transaktionssysteme (2) Inhalt: Architekturen für Transaktionssysteme (1-Tier, 2-Tier, 3-Tier), Transaktionsmanager, TP-Monitore

Transkript

1 Kapitel 4 Transaktionssysteme Inhalt: Architekturen für Transaktionssysteme (1-Tier, 2-Tier, 3-Tier), Transaktionsmanager, TP-Monitore Transaktionssysteme (1) Bereiche typischer TA-Anwendungen Kommunikationssysteme - Telefonanrufe - Verbindungsaufbau und -freigabe (inkl. Betriebsmittel) - Anrufweiterleitung, Benachrichtigungen (Voice Mail),... - Bezahlung kann mehrere Telefon-Firmen betreffen - Web-Shops - e-commerce - e-business,... Finanzwelt / Banken - Point-of-Service-Terminals - Kreditkartenvalidierung - Direktbuchung - Aktienhandel 2 Transaktionssysteme (2) Bereiche typischer TA-Anwendungen (Forts.) Reisebüro - Buchungen - Fahrkartenverkauf Produktion - Bestellverarbeitung, Einsatz- und Lagerplanung,... Trend zum Einsatz von Standard-SW und von TA-Systemen Ziel: Ableitung von Schichtenmodellen für TA-Systeme - Prinzipieller Aufbau durch Schichtenbildung: Als konkrete Realisierungen ergeben sich Client/Server-Systeme 3

2 Einzelnutzer-System Die Basiskomponenten von Transaktionssystemen lassen sich schon in Einzelnutzersystemen finden Die Evolution eines solchen Systems bietet ein gutes Rahmenwerk, um verschiedene Eigenschaften eines Transaktionssystems einzuführen centralized system presentation application services services user module Präsentationsdienste Zeigen Masken für Nutzer-Interaktion, übernehmen den Informationsfluss von und zur Anzeige Anwendungsdienste Implementiert die Funktionalität, interagiert mit dem ACID-Eigenschaften automatisch oder nicht notwendig 4 Zentralisiertes Multi-User-System Einfache Terminals, die mit einem Mainframe verbunden sind Anwendungs- und Präsentationsdienste laufen auf dem Mainframe ACID-Eigenschaften notwendig Isolation: Verzahnte Ausführung von Transaktionen im Atomarität und Dauerhaftigkeit: Das System unterstützt den Betrieb in größeren Organisationen Transaktionsabstraktion durch, welches ACID-Eigenschaften zusichert communication presentation application services services presentation application services services central machine dumb terminal user module 5 Transaktionsverarbeitung in verteilten Systemen Sinkende Hardwarepreise und Kommunikation erlauben es, Komponenten eines Transaktionssystems zu verteilen Einfache Terminals werden durch leistungsfähige Rechner ausgetauscht Client/Server-Modelle werden allgemein genutzt 2-Tier-Architektur: client machines database machine presentation application services services presentation application services services communication 6

3 Nutzen von Stored-Procedures Netzwerk-Last bei 2-Tier-Architektur an hoch Besser: Anbieten einer Stored-Procedure-Schnittstelle, um über einen einfachen Aufruf komplexe Aktivitäten zu starten Sicherheit: Prozeduren können besser geschützt werden, da sie im Backend gewartet werden. Last im Netzwerk wird reduziert, da weniger Nachrichten benötigt werden Antwortzeit wird reduziert. Wartung ist einfacher, da neue Versionen von Anwendungen nicht mehr auf Clients verteilt werden müssen Autorisierung kann prozedurseitig implementiert werden und muss nicht mehr für jedes einzelne Statement durchgeführt werden Prozeduren können im voroptimiert werden Anwendungsdienste nutzen nur die Abstraktionsschicht der Stored-Procedures und stellen keine Anfragen mehr direkt an das 7 3-Tier-Architektur (1) client machines application machine database machine presentation application presentation communication 8 3-Tier-Architektur (2) - Application-Server Definiert Transaktionsgrenzen Agiert als Workflow-Controller: Implementiert Nutzeranfragen als Sequenz von Aktivitäten z.b. Registrierung = (Prüfe Vorbedingungen, füge Teilnehmer zum Kurs hinzu, rechne Kurs ab) Agiert als Router Verteilte Transaktionen involvieren eine Vielzahl an Servern Server-Klassen werden für Load-Balancing genutzt Da Workflows zeitaufwendig sind und ein Application-Server mehrere Clients bedienen muss, sind Application-Server oft multi-threaded implementiert. 9

4 3-Tier-Architektur (3) - Erweiterung Transaktions-Server Stored-Procedures können auf dedizierte (Transaktions-) Server ausgelagert werden, um -Last zu reduzieren Transaktions-Server sind sehr nah am - Schnelle Verbindung zwischen TA-Server und - Umgekehrt: Anwendungs ist eher nah am Client Transaktions-Server übernimmt Großteil der Datenverarbeitung - Transaktions-Server kann als Server-Klasse implementiert sein - Application-Server nutzt irgendeinen verfügbaren Transaktions, um eine bestimmte Stored-Procedure auszuführen - Load-Balacing 10 3-Tier-Architektur (3) - Erweiterung client machines applic. machines trans. machines database machine present. applic. trans. present. communication 11 3-Tier-Architektur (4) - Abstraktionslevel Abstraktionslevel Der Präsentations-Server implementiert die Abstraktionsschicht für das User-Interface Der Application-Server implementiert die Abstraktionsschicht für die Nutzer-Anfragen Die Stored-Procedures (oder Transaktions-Server) implementiert die Abstraktionsschicht der individuellen Sub-Aktivitäten Das implementiert die Abstraktion des relationalen Modells 12

5 3-Tier-Architektur (5) Skalierung / Routing presentation presentation presentation presentation application transaction application transaction database database 13 Kommunikation in Transaktionssystemen 2-Tier-Modell: Präsentations-/Application-Server kommunizieren mit Datenbank-Server 3-Tier-Modell: Präsentations-Server kommuniziert mit Application-Server Application-Server kommuniziert mit Transaktions-/Datenbank-Server In jedem Fall müssen eine Vielzahl von Nachrichten gesendet werden Effiziente und verlässliche Kommunikation essentiell Sitzungen (Sessions) werden benutzt, um Ziele zu erreichen Sitzungs-Erzeugung/Beendigung kostenintensiv Eine Sitzung ist längerfristig. 14 Sessions (1) Sessions werden in verschiedenen Abstraktionsebenen benutzt Kommunikationssitzungen (Low-Level) - Kontext beschreibt den Status des Kommunikationskanals Client/Server-Sitzungen (High-Level) - Kontext im Server beschreibt den Zustand des Clients 15

6 Sessions (2) Kommunikationssitzungen Kontext: - Sequenznummer einer Nachricht - Adressinformationen, - Keys zur Verschlüsselung, Mehraufwand für Sitzungen ist signifikant - Für Erzeugung weitere Nachrichten nötig! - Die Anzahl der Sessions ist daher begrenzt 2-Tier-Modell: - Ein Client nutzt eine Session für jedes verbundene 3-Tier-Model: - Jeder Client nutzt Session als Verbindung zum Application-Server - Jeder Application-Server nutzt seine Sessions mehrmals für die Verbindungen zum Transaktions- bzw. DB-Server 16 Sessions (3) Vergleich der Kommunikationssitzungen für das 2-Tier/3-Tier-Modell: Anzahl der Clients n1, Anzahl der Application-Server n2, Anzahl der Transaktions- und DB-Server n3 Sessions, 2-Tier (Worst Case) = n1*n3 Sessions, 3-Tier (Worst Case) = n1+(n2*n3) Da n1» n2, skaliert das 3-Tier-Modell deutlich besser Client Application- Server Trans/- Server 17 Sessions (4) Client/Server-Sitzungen: Müssen vom Server gepflegt werden, um eine Sequenz von Anfragen abzuwickeln: - Was hat der Client als letztes gekauft? (Warenkorb) - Welche Spalte ist zuletzt im angesprochen worden? - Wofür ist der Client autorisiert? Wo wird Kontext gespeichert? - Direkt im jeweiligen Server schwer handhabbar, wenn: - Bei Nutzung von Server-Klassen: Verschiedene Server-Instanzen (z.b. Transaktions-Server) können an einer einzigen Session beteiligt sein - Eine Vielzahl von Clients können eine Session lange nutzen: Persistente Speicherung des Kontextes im jeweiligen Server aufwendig - In einer zentralen Datenbank zugreifbar für alle Server einer Server-Klasse - Beim Client Der Kontext wird bei jeglicher Kommunikation mit gesendet Identifikation des Kontextes einer Nachricht über Context-Handles - Vgl. Cookies 18

7 Queued vs. Direkte Transaktionsverarbeitung Direkt client Client wartet bis Anfrage beantwortet wird. Der Dienst wird so schnell wie möglich erbracht und T 3: dequeue liefert ein Ergebnis zurück. reply Queued Die Anfrage wird in eine Warteschlange einreiht und der Client kann mit seiner eigenen Verarbeitung weitermachen. Der Server Queues entnimmt die Anfrage später aus Vorteile der Warteschlange, bearbeitet die Anfrage und reiht die Antwort wieder in eine Warteschlange ein. Der Client entnimmt die Antwort später aus der Warteschlange. Client und Server kommunizieren asynchron. T 1: enqueue request recoverable request queue recoverable reply queue T 2: dequeue request 3 Transaktionen auf Basis von zwei wiederherstellbaren Client kann Anfragen absenden, auch wenn der Server nicht verfügbar ist Der Server kann Antworten senden, obwohl der Client nicht verfügbar ist Anfrage wird auf jeden Fall bearbeitet, auch wenn T2 abbricht (Die Entnahme aus der Queue gehört zur Transaktion: Bei Abbruch wird Nachricht zurückgelegt) T 2: enqueue reply 19 Heterogene vs. Homogene Transaktionssysteme Homogene Systeme bestehen aus HW und SW- Modulen eines Herstellers Software kommuniziert über proprietäre (oft nicht veröffentlichte) Schnittstellen - Daher können keine Produkte von anderen Herstellern einbezogen werden Werden als TP-Lite-Systeme bezeichnet Heterogene Systeme bestehen aus HW und SW- Modulen verschiedener Hersteller Software kommuniziert über veröffentlichte, standardisierte Schnittstellen Werden als TP-Heavy-Systeme bezeichnet 20 Heterogene Systeme Notwendig, weil: bestehende (Legacy) Systeme verschiedener Hersteller integriert werden müssen, die Vorteile von verschiedenen Produkten verschiedener Hersteller genutzt werden sollen. Eine Middleware als Software integriert die Bestandteile eines heterogenen Systems und bietet dafür verschiedene Zusatzdienste an Kommunikation (TCP/IP), Sicherheit (Kerberos), Globale ACID-Transaktionen (XOpen DTP), Datenbankkommunikation (JDBC) 21

8 Transaktions-Manager in heterogenen Systemen Wiederholung: Middleware, um die globale Atomarität von verteilten Transaktionen sicherzustellen - Anwendung ruft TA-Manager auf, wenn eine Transaktion gestartet wird - Der TA-Manager wird informiert, wenn ein neuer Server der Transaktion beitritt - Anwendung ruft TA-Manager auf, wenn die Transaktion abgeschlossen werden soll - TS-Manager koordiniert atomares Commit-Protokoll zwischen den Teilnehmern einer Transaktion, um Atomarität sicherzustellen Für das 2-Tier-Modell: database Transaction machines (local manager atomic commit protocol ACID properties) begin / commit present. services applic. services service invocations client machines 22 TP-Monitore (1) Transaction Processing Monitor bieten schon seit ~1970 auf Mainframes robuste Laufzeitumgebungen für große OLTP-Anwendungen (on-line transaction processing) liefern den Klebstoff für das Zusammenwirken vieler Komponenten, Betriebsmittel, Protokolle usw. bei der TA-Abwicklung realisieren und optimieren Funktionen, die von BS typischerweise nur sehr schlecht oder gar nicht unterstützt werden verwalten Prozesse und starten/überwachen Transaktionsprogramme (TAP) erlauben die Integration unabhängiger Dienste und ihre Abwicklung als Transaktionen In a contest for the least well-defined software term, TP-Monitor would be a tough contender (J. Gray) 23 TP-Monitore (2) Ein TP-Monitor ist eine Sammlung von Middleware-Komponenten, die nützlich beim Bau heterogener Transaktionssysteme sind Beinhalten einen Transaktions-Manager Bieten anwendungsunabhängige Dienste, die normalerweise nicht oder schlecht vom Betriebssystem angeboten werden Liegen als Software-Ebene zwischen den Anwendungen und dem Betriebssystem Bieten eine Abstraktionsschicht für (globale) Transaktionen Darstellung Bernstein/Newcomer - Bindemittel ( Glue ) für Komponenten einer TA-Anwendung und - Schicht (= Fournier, Veneer ) für Anwendungen 24

9 Dienste eines TP-Monitors (1) Kommunikationsdienste Basieren auf Kommunikationsinfrastruktur des Betriebssystems Bieten transaktionale peer-to-peer und/oder RPC-Schnittstellen Unterstützung für ACID-Eigenschaften Lokale Isolation für einen (Nicht-DB) Server kann durch einen Lock-Manager als Dienst erbracht werden: - Implementiert Sperren, die eine Anwendung explizit mit einer beliebigen Ressource in Verbindung bringen kann Lokale Atomarität für einen (Nicht-DB) Server kann durch einen Log-Manager unterstützt werden: - Implementiert ein Log, welches Anwendung zur Speicherung von Daten für die eigene Recovery nutzen kann: Transaktions-Recovery (Undo), Crash-Recovery (Undo/Redo). Globale Isolation und Atomarität können durch einen Transaktionsmanager erbracht werden Die persistente Speicherung von Kontexten kann durch Kontextmanager gewährleistet werden 25 Dienste eines TP-Monitors (2) Routing und Load-Balancing Ein TP-Monitor kann durch Load-Balancing Anfragen an den am wenigsten ausgelasteten Server einer Klasse weiterleiten Threading Threads können als leichtgewichtige Betriebssystem-Prozesse aufgefasst werden Nützlich in Servern (z.b. Application-Server), die eine große Anzahl an Sessions für eine Vielzahl von Clients verwalten müssen Ein TP-Monitor bietet zusätzlich auch Thread-Verwaltung, wenn das Betriebssystem dies nicht anbietet Wiederherstellbare Queues Sicherheitsdienste Verschlüsselung, Authentifizierung und Autorisierung Verschiedene Dienste, wie File-Server Uhr-Server zur Zeitsynchronisation 26 TP-Monitor - Überblick Kontrollfluss durch einen TP-Monitor (vereinfacht) Diagramm repräsentiert die wichtigsten Grundfunktionen für TAP-Verwaltung und -Ausführung 27

10 Zusammenfassung 3-Tier-Architekturen für verteilte Systeme vorteilhaft Allerdings Session-Management aufwendig Optimierungen / Abstraktionen wie Stored-Procedures für verringertes Nachrichtenaufkommen oder Warteschlangen für asynchrone Kommunikation notwendig TP-Monitore liefern den Klebstoff in komplexen Client/Server-Umgebungen erlauben die Umsetzung des Transaktionskonzeptes als Grundlage zur Realisierung zuverlässiger verteilter Systeme sind Spezialisten für Prozess-, Transaktions- und Client/Server-Kommunikations-Verwaltung Beispiele: IBM CICS, Microsoft MTS, Oracle Java JTS TA-Systeme werden überall eingesetzt Sie stellen eine ausgereifte Technologie dar OLTP-Hochleistungssysteme sind in vielen Varianten (Plattform, TP-Monitor, Datenbanksystem) auf dem Markt verfügbar 28