TP-Heavy - ETH tools

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