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