Kap. 2 Infrastruktur durch Transaction Processing Monitore (“TP

Kap. 2 Infrastruktur durch Transaction
Processing Monitore (“TP-Heavy”)
•
Architekturüberblick, Anknüpfung aus IS-K:
• Dreistufige Architektur (“Three-Tier”)
• Aufgabenteilung zwischen Client, Middleware und
Server
•
Funktionalität und Aufbau eines TP-Monitor
• TP Monitor als Transaktionsbetriebssystem
• Behandlung von Transaktionen: X/Open DTP
OHO2000
Kap2-1
2.1 Drei- oder Mehr-Stufen Architektur (aus IS-K)
•
Middleware: Software-Schicht in der Mitte zwischen
Betriebssystem /Kommunikation und Anwendungsprogramm
•
zwischen Clients und Server
•
Middleware Frameworks
Client
Program
Server
Program
Middleware Services
Communication Middleware
OHO2000
Operating System and
Network Software
Operating System and
Network Software
Operating System and
Network Software
Computer and
Network Hardware
Computer and
Network Hardware
Computer and
Network Hardware
Kap2-2
1
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
Mainframes
2 Rechenzentren
10 Mainframes (MVS, UNIX)
DB2, IMS/DB
3500 MIPS
18 TB Disk
Printfabrik
11 Mio Txn. / Tag
50000 Jobs / Nacht
230 Mio Blatt Papier / Jahr
800 geänderte Programme
pro Woche
Netzwerk
automatisierte SW-Verteilung
(6000 mal / Jahr)
Multiprotokollnetz
(TCP/IP, SNA)
Workstations
800 Workstations und Servers
(AIX, Solaris, …)
> 100 C/S-Applikationen
(davon eine mit > 1000 Benutzern)
Diverse Spezialsysteme
OHO2000
Kap2-3
Anforderungen
• Interoperabilität
• zwischen heterogenen Plattformen, zugekaufte und
eigenen Lösungen, …
• sanfte Daten-Migration
• von bestehenden Lösungen auf neue Systeme
• flexible Erweiterung / Anpassung
• bestehender Systeme um neue Bedürfnisse
OHO2000
Kap2-4
2
Kommunikationsmiddleware
...Implementiert Kommunikation zwischen kooperierenden Prozessen
•
•
•
RPC
• hauptsächlich synchrone Ausführung von Prozeduren auf einem
entfernten Prozess
• oft implementiert als Teil des Betriebssystems
• verwendet in Client-Server-Datenbanksystemen, EchtzeitKommunikation, …
Message Oriented Middleware (MOM)
• asynchrone Kommunikation zwischen Prozessen über (persistente)
Warteschlangen
• üblicherweise implementiert als separates Software Paket, z.B. IBM
MQSeries, BEA MessageQ
• verwendet in Transaktionsmonitoren, Mobile Computing, …
Object Request Brokers
• objektorientierte Kommunikationsmiddleware
• Ausführung von Methoden auf Objekten entfernter Prozesse
• vgl. später, CORBA-Standard
OHO2000
Kap2-5
TP Monitor als Middleware
•
•
•
Client
TPM
Library
Server
Betriebsystem
Client
Client: Ausführung mit entfernten
Aufrufen “tpcall(....)
Server: Führt SQL-Aufrufe aus
Middleware: TP-Monitor als Server und
als DB-Client: Doppelrolle!
Middleware
Betriebsystem
TPM
Library
TP-Monitor
DB Client
Library
DB Server
Library
Betriebsystem
Client
OHO2000
DB
Server
Betriebsystem
Server
Kap2-6
3
Hauptmerkmale und Vorteile der Drei-StufenArchitektur
•
Mittlere Schicht ist
• (künstlicher) Server dem (eigentlichen) Client gegenüber und
• (künstlicher) Client dem (eigentlichen) Server gegenüber.
•
Die folgenden Hauptvorteile resultieren daraus:
• Anwendungen unabhängig vom DBMS-Hersteller entwickeln
• Flexibilität in der Verwendung von DBMSen verschiedener
Hersteller
• Verfügbarkeit und Lastbalancierung durch Replikation von
Servern
• Flexible (technische) Fehlerbehandlung durch Neustart von
Teilaktivitäten
OHO2000
Kap2-7
2.2 Funktionalität und Aufbau eines TP-Monitors
•
•
Definition: (eng): Betriebssystem für Transaktionsverarbeitung
(“managing client/server transactions”). Weiter gefasst: Infrastruktur
für die Entwicklung und Ausführung von Anwendungen, Diensten und
Komponenten der mittleren Stufe einer drei-stufigen Architektur.
Hauptaufgaben:
• Prozessmanagement: Starten von Serverprozessen,
Durchschleusen/Trichtern (“Funneling”) von Arbeit, Überwachen
der Ausführung und Lastbalanzierung.
• Transaktionsverwaltung: Garantie von ACID-Eigenschaften für
globale Transaktionen, unabhängig davon, ob Stored Procedures
und DBMSs verschiedener Hersteller involviert sind. Durchführung,
Überwachung eines Zwei-Phasen-Commit.
• Client/Server-und Server/Server-Kommunikation:
Ausführungsgarantien durch TRPC (“transactional remote
procedure call”), Transactional Queues und MOMs, Zuordnung
eines Transaktions-ID für alle Teilaufträge, die zu einer ClientTransaktion gehören, für 2PC.
OHO2000
Kap2-8
4
TP-Monitor-Transaktion
Server
Transaction Program
Receive
SQL
Call
SQL
Store
Send
Context
DB X
DB Y
Sphere of control established
by the TP monitor
aus GRAY, S. 251
OHO2000
Kap2-9
TP-Monitor als Betriebssystem - warum?
A) Without a TP Monitor
1000
Clients
1000 Connections
+
1000 Processes
+
500 Mbytes of RAM
+
10.000 Open Files
B) With a TP Monitor
1000
Clients
TP
Monitor 50
OS Dies
I Can Handle This!
50 Shared Connections
+
50 Processes
+
25 Mbytes of RAM
+
500 Open Files
OS is Fine
(aus OHE99)
OHO2000
Kap2-10
5
Betriebssystemlösung
Aus GRAY, S. 254
OHO2000
Kap2-11
TP-Monitor-Lösung
Coordinator
l
aus GRAY, S. 257
OHO2000
Kap2-12
6
Flexible TP-Monitor-Lösung
Coordinator
aus GR, S. 258
OHO2000
Kap2-13
TP-Monitor: Bindemittel (“Glue”) für Komponenten
und Schicht (=Fournier, “Veneer”) für Anwendungen
TP application programs
TP monitor API veneer
Request
routing
User
interface
services
Transactional
communications
Operating
system
services
Two-phase
commit
Communications
services
…
Database
system
services
(aus PTP, S. 39)
OHO2000
Kap2-14
7
Transactional Remote Procedure Calls
•
Transactional Remote Procedure Call:
• üblicher RPC + Aufruf wird (Sub-)Transaktion der globalen
verteilten Client-Transaktion.
• Dabei wesentlich: Jeder Aufruf, bzw. jede Message enthält neben den eigentlichen Parametern - eine automatisch
vergebene Transaktionskennung TXID
• Mittels TXID koordiniert der TP-Monitor alle Teilaktivitäten,
garantiert, dass Nachrichten empfangen werden, Services genau
einmal gestartet werden (“exactly-once” Semantik) und
entscheidet über Commit oder Rollback.
OHO2000
Kap2-15
Transactional xxx (nach OHE99)
Feature
Ordinary Queues, RPCs, ORBs,
Publish-and-Subscribe, and
Conversational Communications
Transactional Queues, RPCs, ORBs,
Publish-and-Subscribe, and
Conversational Communications
Participants
L o o s e l y - c o u p l e d c l i e n t/ s e r v e r
p rogram s
Commit synchronization
Only-once semantics
Server management on the recipient
node
No
T r a n s a c t i o n a ll y b o u n d
c l i e n t/ s e r v e r a n d s e r v e r / s e r v e r
p ro g ram s . T h e m ess a g e
in v o c a t i o n c a u s e s th e r e c i p i e n t
p r o g r a m t o jo i n t r a n sa c t i on
Y es
No
Y es
N o . I t ’ s ju s t a d e l i v e r y
m ech an is m . (O R B s p r o v id e
m in i m a l s e r v e r m a n a g e m e n t . )
Load balancing
U s i n g th e d ir e c t o r y s e r v i c e s . T h e
fir st s er v e r to r e g iste r b e c o m e s a
h o ts p o t. N o d yn am ic lo a d
b a lan cin g is p ro v id ed .
Supervised exchanges
N o . E x c h a n g e s a r e s im p l y
b e t w e e n th e c li e n t a n d th e s e r v e r .
T h e e x c h a n g e s a r e tr a n s i e n t. N o
c r a sh r e c o v e r y o r e r r o r
m a n a g e m en t is p r o v i d e d. Yo u ’ r e
on your ow n.
Y es . T h e p ro ces s th a t r eceiv es th e
m e s s a g e i s s ta r t e d , l o a d
b a la n c e d , m o n ito r e d , a n d tra c k e d
a s p a r t o f t h e t r a n sa c t i o n .
U s e s th e T P M o n ito r ’s
s o p h i s t i c a t e d l o a d - b a l a n c in g
a l g o r i th m s . C a n s p r e a d w o r k
a c r o s s m u l ti p l e S M P m a c h in e s
an d d yn am icall y a d d m o re
p ro ces se s to co v er h o ts p o t o f
a c tiv ity. S e v e ra l se r ve r s ca n r e a d
fr o m s a m e q u e u e .
T h e T P M o n ito r su p er v ise s th e
e n tir e e x c h a n g e , r e s t a r t s
c o m m u n i c a ti o n l in k s , r e d i r e c t s
m e ss a g e s to a n a ltern a te se rv e r
p r o c e s s i f t h e f ir s t o n e g e t s h u n g ,
p e r f o r m s r e tr i e s , a n d p r o v i d e s
p e rs iste n t q u e u e s a n d cra sh
r ecover y.
OHO2000
Kap2-16
8
Standard für Resource Managers in TP MonitorUmgebung
X/Open DTP (=Distributed Transaction Processing)
• RM = Resource Manager, z.B. DBMS
• RM API = RM Application Program Interface, z.B. ESQL, CLI
• TX API = API zum Transaction Manager (TM), im wesentlichen
BeginTX, CommitTX, AbortTX
• XA API Interface zwischen RM und TM, im wesentlichen für
PrepareCommit, Commit, Rollback
• Transactional Communications durch die Standards
• XATMI, basierend auf Tuxedo’s Application to Transaction
Monitor Interface (ATMI)
• TxRPC, Transactional Remote Procedure Calls, basierend auf
DCE (Distributed Computing Environment)
• CPI-C, basierend auf IBM “peer-to-peer”
OHO2000
Kap2-17
X/Open DTP Gesamtarchitektur
Application
(AP)
RM API
Resource
Manager
(RM)
XA
TX API
Transaction
Manager
(TM)
XATMI
TxRPC
CPI-C
XA+
Communication
Resource
Managers
(CRM)
XAP-TP Interface
OSI-TP
TCP/IP
OHO2000
APPC
OSI
Kap2-18
9