4. TA-Modelle für heterogene Systeme, Workflows und Web Entwurfsautonomie

Transkript

1 4. TA-Modelle für heterogene Systeme, Workflows und Web Entwurfsautonomie Autonomie in heterogenen Systemen Ziel - Einführung in Daten-, Funktions-, Anwendungs- und Prozeßintegration - hier: Unterstützung durch TA-Konzepte Heterogene TA-Systeme - Autonomie vs. Transparenz - Probleme: Serialisierbarkeit, Atomarität, Deadlocks TA-Verwaltung in heterogenen Systemen - Korrektheitsbedingungen bei Mehrebenen-TA - Globale Serialisierbarkeit und globale Atomarität Daten- und Funktionsintegration - Ausführung von föderierten Funktionen als Sammlung lokaler Funktionen - Komponente zur Funktionsintegration (KIF) der föderierten Funktionen - Anwendungsintegration - einzelne DBs sind unabhängig voneinander entworfen - variierender Grad an Autonomie bei Eintritt in Verbund sind DB-Schema-Anpassungen möglich lokale DB-Schemata bleiben unverändert erhalten lokale DB-Schemata dürfen jederzeit beliebig geändert werden Web Services 1 zielen auf diese extremste Form der Autonomie ab und verlangen deshalb eine sehr lose Form der Kopplung! Kommunikationsautonomie - einzelne Komponentensysteme können selbst entscheiden, mit welchen anderen Systemen sie kommunizieren - autonomes kann selbst bestimmen, wann es in den Verbund eintritt oder ihn verläßt - freie Entscheidung über die Art der Kommunikation (Verhandlung über Zugriff auf Datenbestände, Rolle von Import-/Export-Schemata) Workflow-Management - Ausführung von Workflows - Stratifizierte Transaktionen - ConTracts Geschäftstransaktionen und Web Services - Elektronischer Handel, Geschäftsmodelle - Einsatz von Web Services: BPEL4WS - Atomarität bei Geschäftstransaktionen 4-1 Ausführungsautonomie - freie Entscheidung, welche Anwendungsprogramme, Anfragen und Änderungsoperationen ein System ausführt und - zu welchem Zeitpunkt es diese Operationen ausführt - gewisse Einschränkungen erforderlich, um sinnvolle Kooperation zu ermöglichen (Reihenfolge von Ops, 2PC,...) 1. The term Web Services refers to an architecture that allows applications to talk to each other (Adam Bosworth). Schlüsseleigenschaften ihrer Realisierung sind Kommunikationseffizienz (bei zustandslosen Protokollen), lose Kopplung (bei fein-granularem Zugriff auf gekapselte Objekte, die ihr Schema ändern dürfen), und Asynchronität aller Anforderungen. 4-2

2 Heterogene TA-Systeme Heterogene TA-Systeme (2) Autonomie vs. Transparenz 2 Grobarchitektur von F und M verteilte Transaktionssysteme föderierte globale Anwendungen globale Anwendungen isolierte programmierte Verteilung lose gekoppelt (Multi-) verteilte Föderierungsdienst / globale TA-Verwaltung Transaction Routing Verteilung von DB- Operationen eng gekoppelt (F) parallele lokale Anwendungen DBMS 1... DBMS n lokale Anwendungen Verteilungstransparenz / Kooperationsumfang Knotenautonomie / Heterogenität / Verteilungsgranulat DB 1 L 1 DB n L n Verknüpfung von heterogenen Komponentensystemen durch - Föderierte (F) engere Kopplung oft homogenisierte Datensicht (externe Schemata) für globale Anwendungen teilweise Aufgabe der Autonomie Vor- und Nachteile von föderierten Systemen im Allgemeinen - Multi-Datenbanksysteme (M) losere Kopplung Wahrung der vollen Autonomie keinerlei komponentenübergreifende Integritätsbedingungen Zusammenschluß existierender zu einem losen -Verbund 2. Rahm, E.: Mehrrechner-Datenbanksysteme Grundlagen der verteilten und parallelen Datenbankverarbeitung, Addison-Wesley, Bonn, Autonomie sehr wichtig, da Systeme zum Zeitpunkt der Integration bereits bestehen - Föderierungsdienst / globale TA-Verwaltung erlauben eine Integration und Nutzung einer Menge von isolierten und heterogenen 3 globale Anwendungen können auf alle Daten der beteiligten zugreifen lokale Anwendungen greifen, wie bisher auch, auf die Daten eines lokalen zu 3. Eine mögliche Unterteilung liefern die folgenden Formen: - Heterogenität auf Systemebene, z. B. in Form unterschiedlicher Anfrage- und Zugriffsschnittstellen der beteiligten Systeme, - auf Datenmodellebene durch die Nutzung verschiedener Datenmodelle in den einzelnen Quellen - auf Schemaebene durch unterschiedliche Modellierungen eines Weltausschnitts, - auf Datenebene mit Konflikten aufgrund verschiedener Repräsentationen ein und desselben Real-Welt-Sachverhalts. 4-4

3 Heterogene TA-Systeme (3) Heterogene TA-Systeme (4) Struktur der Transaktionen - systemübergreifende Transaktionen Zerlegung in globale Sub-TA (GST) durch GTM Ausführung der GST durch lokale - lokale Transaktionen (LT) Modell für TA-Abläufe GT 1 GT 2 GT 3 GTM kann nur GTs kontrollieren - Annahme: alle Objekte, auf die durch GTs zugegriffen wird, können durch GTM identifiziert werden - Erkennung nur von direkten Konflikten zwischen GST ij möglich Beispiel GT 1 GT 2 GTM GST 11 GST 21 GST 12 GST 22 GTM T 1 T 2 w(a) r(a) L 1 LT 1 LT 2 LT 3 LT 1 GST 11 GST 12 GST 21 GST31 GST 32 T1 T2 T3 L 1 L 2 L n w(c) r(c) w(d) r(d) t L 2 - GST werden durch L wie LT behandelt - erkannte Abhängigkeiten durch GTM GT 1 GT 2 Jedes beteiligte (L) ist autonom - kann im Prinzip eigenes Datenmodell besitzen - tatsächlicher Abhängigkeitsgraph - kann eigene Algorithmen für Synchronisation und Recovery einsetzen F / MBDS sind, nicht nur auf Datenmodellebene, heterogene Systeme a GT 2 GT 1 c d LT

4 Heterogene TA-Systeme (5) Probleme heterogener TA-Systeme Lokale Autonomie impliziert - Kontrollinformation eines L (für Synchronisation und Recovery) wird nicht nach außen verfügbar gemacht Globale Graphen für Serialisierbarkeitsprüfung oder Deadlock-Erkennung können nicht genutzt werden - Alle Zugriffe zu lokalen Daten (DB i ) werden durch das entsprechende L i ausgeführt Globale TA erzeugen lokale Sub-TA für jedes L i, auf die sie zugreifen wollen Globale Serialisierbarkeit - F besteht aus L 1 und L 2. Objekte a und b werden von L 1, c und d von L 2 verwaltet. Es werden zwei globale TA ausgeführt: GT 1 : r 1 (a) r 1 (c) GT 2 : r 2 (b) r 2 (d) - Gleichzeitig werden zwei lokale TA ausgeführt: LT 3 : w 3 (a) w 3 (b) LT 4 : w 4 (c) w 4 (d) - Zwei mögliche lokale Schedules: S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 - Ein L kann nicht zwischen lokalen und globalen TA unterscheiden S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c 4 r 1 (c) c 1 Sub-TA sind innerhalb eines L nicht identifizierbar und werden nicht speziell behandelt - Nicht automatisch zu erzielen! Graphische Veranschaulichung: GT 1 r 1 (a) r 1 (c) - L entscheiden unabhängig über das Commit lokal ausgeführter TA GT 2 r 2 (b) r 2 (d) Selbst wenn das Abort einer Sub-TA einen nicht-serialisierbaren globalen ergibt, kann GTM das Commit dieser Sub-TA nicht erzwingen - Bereits existierende lokale Programme werden nach der Integration weiterbenutzt Schedule LT 3 LT 4 L 1 w 4 (c) r 1 (a) w 3 (a) w 3 (b) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 w 4 (d) Es ist keine Anpassung der SW (Schnittstellen) erforderlich L 2 w 4 (c) r 2 (d) c 2 w 4 (d) c 4 r 1 (c) c 1 Heterogenität und Autonomie erschweren die Erhaltung der globalen Konsistenz - lokale Serialisierungsreihenfolgen L 1 : L 2 : 4-7 nicht auflösbarer Widerspruch auf globaler Ebene 4-8

5 Globale Atomarität Probleme heterogener TA-Systeme (2) - Sub-TA einer GT müssen entweder alle mit Commit oder alle mit Abort abschließen setzt Prepared -Zustand voraus! - lokale Ausführungsautonomie erlaubt beliebigen TA-Abbruch Beispiel: L 1 verwaltet das Objekt a und L 2 das Objekt c. - Erfolgreiche Ausführung von GT 1 : r 1 (a) w 1 (a) w 1 (c) - Commit der GT 1 in L 2 erfolgreich, in L 1 jedoch gescheitert - Ausführung von LT 2 in L 1 : r 2 (a) w 2 (a) - Abbruch von GT 1 nicht mehr möglich, Wiederholung von r 1 (a) w 1 (a)? - Erfolgreiche Sub-TA (r 1 (a) -> w 1 (c)) basiert auf altem Wert von a und kann nicht mehr verändert werden - Deshalb Versuch der Wiederholung von w 1 (a) (als LT 3 mit w 3 (a) in L 1 ) - Globale Atomarität verletzt! Siehe Ablauf: Probleme heterogener TA-Systeme (3) Globale Deadlock-Erkennung und -Vermeidung - 2PL-Protokoll erlaubt Erkennung bzw. Vermeidung von Deadlocks in einem - Jedoch keine Wait-for -Graphen für gesamtes Komponentensystem - Annahme: 2PL in L 1 (mit Objekten a und b) und in L 2 (mit Objekten c und d) - Globale und lokale TA mit GT 1 : r 1 (a) r 1 (d) GT 2 : r 2 (c) r 2 (b) LT 3 : w 3 (b) w 3 (a) LT 4 : w 4 (d) w 4 (c) - Kein lokal erkannter Deadlock! Siehe Ablauf: GT 1 r 1 (a) w 1 (a) w 1 (c) (c 1 ) w 1 (a) c 1 GT 1 GT 2 r 1 (a) r 2 (c) r 1 (d) r 2 (b) LT 3 w 3 (b) w 3 (a) LT 2 r 2 (a) w 2 (a) c 2 LT 4 w 4 (d) w 4 (c) L 1 r 1 (a) w 1 (a) a 1 w 1 (a) -1 r 2 (a) w 2 (a) c 2 w 3 (a) c 3 L 1 r 1 (a) w 3 (b) % % L 2 w 1 (c) c 1 L 2 r 2 (c) w 4 (d) % % aus Sicht von L 1 : r 2 (a) w 2 (a) c 2 w 3 (a) c 3 (commit-abgeschlossen) für GTM Ablauf in L 1 : r 1 (a) r 2 (a) w 2 (a) c 2 w 1 (a) c 1 - Abhängigkeitsfolge: - Lösung? Aus jeweils lokaler Sicht von L 1 und L 2 und aus Sicht von GTM gibt es keine Verklemmung! - Blinde Deadlock-Auflösung mit Timeout? - Jede Lösung erfordert Beschränkung der Autonomie und globale Verfügbarkeit von lokaler Information! 4-10

6 Daten- und Funktionsintegration durch heterogene TA-Systeme Daten- und Funktionsintegration durch heterogene TA-Systeme (2) Ziel - homogenisierter Zugriff auf eine Vielzahl verschiedenartiger Datenquellen - generische Anfrage- und Manipulationssprache (SQL) - aber: Anwendungssysteme kapseln ihre Daten und bieten nur einen funktionsbasierten Zugriff (API) homogenisierter Zugriff Klassifikation der lokalen Systeme - Nicht wiederherstellbare Systeme (non-recoverable systems): Anwendungen auf Dateisystemen - Wiederherstellbare Systeme (recoverable systems) sind nach innen transaktional - Transaktionale Systeme bieten einen sichtbaren Prepare-to-Commit-Zustand an - Offene transaktionale Systeme geben Informationen über TA-Zustände (Sperren, Deadlocks) nach außen Einsatz von nicht-wiederherstellbaren Systemen verbietet sich für unternehmenskritische Daten und Anwendungen! F Integration durch SQL-System (F) Minimale Qualität der lokalen Systeme Datenquellen und Anwendungssysteme - wiederherstellbar - Forderungen Datenbanksysteme Applikationssysteme Dateien an den Systemen keine Änderungen (Schnittstelle) keine Rekompilation der Anwendungen höchstens Erweiterungen (neue Tabellen) bestehender DB-Schemata Wie lassen sich TA-Eigenschaften bereitstellen? trotzdem: umschließendes (globales) TA-Modell sollte Lösungen für globale Serialisierbarkeit, globale Atomarität und globale Deadlock- Erkennung und -Vermeidung besitzen

7 Modell für mehrschichtige TA-Verwaltung Korrektheitsbedingungen bei Mehrebenen-TA Dreischichtige F-Architektur mit en Globale Serialisierbarkeit - kann durch Schicht-zu-Schicht-Serialisierbarkeit garantiert werden (level-to-level serializability (L2L)) F - läßt sich überprüfen durch Umwandlung eines serialisierbaren Mehrebenen- Schedule in einen seriellen Schedule... Methode - TA wird als Baum von geschachtelten Operationsaufrufen betrachtet - Isolierung von Teilbäumen Ein Teilbaum ist isoliert, wenn keine Überlappung mit anderen Teilbäumen auftritt, d.h., wenn im Schedule eine serielle Ausführung aller von der Wurzel des Teilbaums abhängigen Operationen stattfindet. - Reduktion von isolierten Teilbäumen - F kontrolliert Ausführung globaler TA - lokale führen lokale TA und Sub-TA globaler TA (globale Sub-TA oder kurz Sub-TA) aus - en erlauben Kontrolle der Konflikte zwischen lokalen und globalen TA TA-Verwaltung bei Mehrebenen-TA - läßt sich flexibel an Gegebenheiten von F anpassen - unterschiedliche TA-Verwaltungen in verschiedenen Schichten und sogar in der gleichen Schicht in verschiedenen Systemen möglich - Prinzip der strengen Schichtung kann teilweise aufgegeben werden: Sub-TA in den verschiedenen Systemen können sich über unterschiedlich viele Schichten aufteilen Könnte anstelle eines lokalen wieder ein F auftreten? 3 wichtige Regeln - Regel 1: Kommutativität von Operationen Die Reihenfolge von zwei im zu überprüfenden Schedule benachbarten, geordneten Operationsaufrufen verschiedener TA kann vertauscht werden, wenn die Operationen kommutieren. Zwei Operationen o und o kommutieren, wenn beide möglichen Ausführungsreihenfolgen o < o und o < o für sie selbst und für alle anderen nachfolgenden Operationen dasselbe Ergebnis liefern - Regel 2: Reduktion von isolierten Teilbäumen Ein isolierter Teilbaum von Operationsaufrufen kann bis auf die Wurzel reduziert werden - Regel 3: Kompensation von Operationen Wenn in einem Schedule eine Kompensationsoperation o -1 unmittelbar auf die Operation o selber folgt und beide Operationen isoliert sind, dann heben sich beide Operationen in ihrer nach außen sichtbaren Wirkung auf und sie können aus dem Schedule entfernt werden

8 Beispiel Korrektheitsbedingungen bei Mehrebenen-TA (2) T 1 T 2 L2 Beispiel Korrektheitsbedingungen bei Mehrebenen-TA (3) - Regel 3: Kompensation von Operationen Auszahlung(k1) Auszahlung(k1) Einzahlung(k2) Einzahlung(k2) L1 T 1 T 2 L2 Upd(s1) Upd(i) Upd(s1) Upd(i) Upd(s2) Upd(s2) Upd(i) Upd(i) L0 Auszahlung(k1) Auszahlung(k1) Stornierung(k1) L1 Regel 1 kommutierbar Upd(s1) Upd(i) Upd(s1) Upd(i) Upd(s1) Upd(i) L0 T 1 T 2 L2 Regel 2 Auszahlung(k1) Auszahlung(k1) Einzahlung(k2) Einzahlung(k2) L1 T 1 T 2 L2 Upd(s1) Upd(i) Upd(s1) Upd(i) Upd(s2) Upd(i) Upd(s2) Upd(i) L0 Auszahlung(k1) Auszahlung(k1) Stornierung(k1) L1 Regel 2 invers T 1 T 2 L2 Regel 3 Auszahlung(k1) Auszahlung(k1) Einzahlung(k2) Einzahlung(k2) L1 T 1 T 2 L2 kommutierbar Auszahlung(k1) L1 Regel 1 T 1 T 2 L2 Regel 1 T 1 T 2 L2 Auszahlung(k1) Einzahlung(k2) Auszahlung(k1) Einzahlung(k2) L1 Auszahlung(k1) L1 Regel 2 Regel 2 T 1 T 2 L2 T 1 L2 Schrittweise Konvertierung in einen seriellen Schedule 4-15 Behandlung einer abgebrochenen Mehrebenen-TA 4-16

9 TA-Verwaltung Globale Serialisierbarkeit TA-Verwaltung Globale Serialisierbarkeit (2) Umsetzung der Korrektheitsbedingungen bei heterogenen Systemen erforderlich Globale Serialisierbarkeit - überprüfbar für globale TA (ohne unsichtbare Konfliktsituationen) Früheres Beispiel: GT 1 : r 1 (a) r 1 (c) GT 2 : r 2 (b) r 2 (d) LT 3 : w 3 (a) w 3 (b) LT 4 : w 4 (c) w 4 (d) GT 1 GT 2 GST 11 GST 21 GST 12 GST 22 GTM - Zwei mögliche lokale Schedules (ohne Einsatz von RL): S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c 4 r 1 (c) c 1 T 1 T 2 w(a) r(a) LT 1 L 1 Einsatz von zurückgehaltenen Sperren (RL) A1: rl 1 (a) <-- w 3 (a) (LT 3 ist blockiert) T1 T2 T3 w(c) r(c) w(d) r(d) L 2 S 1 : r 1 (a) c 1 - aber: was macht man bei lokalen TA und indirekten Konflikten? 4 S 2 : w 4 (c) r 2 (d) c 2 Erkennung und Vermeidung von indirekten Konflikten erfordert - Konflikttests zwischen lokalen TA und globalen Sub-TA - spezielle Sperrmechanismen auf der Basis von zurückgehaltenen Sperren (retained locks) Modifikation des Modells offener geschachtelter TA - am Ende einer Sub-TA werden ihre Sperren nicht freigegeben, sondern zurückgehalten A2: rl 2 (d) <-- w 4 (d) (LT 4 ist blockiert) hl 4 (c) <-- r 1 (c) (GT 1 ist blockiert) - Fortsetzung der lokalen Schedules (1): A1: rl 1 (a) <-- w 3 (a) (LT 3 ist blockiert) S 1 : r 1 (a) c 1 r 2 (b) c 2 - normale Sperren gelten für alle TA - zurückgehaltene Sperren werden nur bei lokalen TA angewendet 4. Es gelten weiterhin die Annahmen: Lokale Systeme liefern keine Informationen über ihre TA-Verwaltung, und sie können auch nicht modifiziert werden 4-17 S 2 : w 4 (c) r 2 (d) c 2 A2: rl 2 (d) <-- w 4 (d) (LT 4 ist blockiert) hl 4 (c) <-- r 1 (c) (GT 1 ist blockiert) 4-18

10 TA-Verwaltung Globale Serialisierbarkeit (3) TA-Verwaltung Globale Serialisierbarkeit (4) - Zwei mögliche lokale Schedules (ohne Einsatz von RL): S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c 4 r 1 (c) c 1 Einsatz von zurückgehaltenen Sperren (Forts.) - Fortsetzung der lokalen Schedules (2): A1: rl 1 (a) <-- w 3 (a) (LT 3 ist blockiert) S 1 : r 1 (a) c 1 r 2 (b) c 2 GT 1 : r 1 (a) r 1 (c) GT 2 : r 2 (b) r 2 (d) LT 3 : w 3 (a) w 3 (b) LT 4 : w 4 (c) w 4 (d) - Zwei mögliche lokale Schedules (ohne Einsatz von RL): S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c 4 r 1 (c) c 1 Einsatz von zurückgehaltenen Sperren (Forts.) - Fortsetzung der lokalen Schedules (4): A1: S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c4 A2: hl 4 (c) <-- r 1 (c) (GT 1 ist blockiert) S 1 : r 1 (a) c 1 r 2 (b) c 2 w 3 (a) w 3 (b) c 3 ) - Fortsetzung der lokalen Schedules (3): A1: rl 1 (a) <-- w 3 (a) (LT 3 ist blockiert) S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c4 r 1 (c) c 1 A2: - lokale Serialisierungsreihenfolgen S 1 : r 1 (a) c 1 r 2 (b) c 2 S 2 : w 4 (c) r 2 (d) c 2 w 4 (d) c4 r 1 (c) c 1 L 1 : L 2 : A2: Erweiterungen erforderlich für Konflikterkennung, da nicht zwischen lokalen TA und globalen Sub-TA unterscheiden kann

11 TA-Verwaltung Globale Serialisierbarkeit (5) TA-Verwaltung Globale Atomarität Anforderungen - Globale Sub-TA müssen identifizierbar sein (z.b. durch zusätzliche Anweisungen BEGIN SUBTRANSACTION und END SUBTRANSACTION) - Sub-TA müssen Sperren bis zum Ende ihrer globalen TA zurückhalten - Ende der globalen TA muß erkennbar sein Alle TA laufen über die en Mehrebenen-TA sind offen geschachtelte TA - Sub-TA führen Commit vor globaler TA aus - kein Rollback, sondern Kompensation (der SQL-Operationen) - aber nur möglich, wenn keine Konflikt-TA dazwischen verarbeitet wurde Rolle der zurückgehaltenen Sperren GA GT F Was passiert bei Crash eines lokalen? LA GST LT T1 - Tn... GST T1 - Tn LT LA - zurückgehaltene Sperren im en persistent, damit Sub-TA (aus der Sicht des lokalen bereits im Commit-Zustand) Crash überleben kann - nach Wiederanlauf des lokalen erneute Anforderung der zurückgehaltenen Sperren, bevor neue TA gestartet werden F realisiert 2PC-Protokoll - muß zwischen lokaler Anwendung und lokalem plaziert werden - bietet -Schnittstelle, so daß lokale Anwendungen nicht modifiziert werden müssen - Erweiterungen der Schnittstelle durch zusätzliche Operationen möglich en bilden zusätzliche Ebene im Mehrebenen-TA-Modell - Vorschlag: Jeder Operationsaufruf einer -TA wird eigene -TA 5 - Konsequenzen? - erste Phase für jede Sub-TA separat Prepared-Zustand der Sub-TA Umwandlung der Sperren in zurückgehaltene Sperren - zweite Phase am Ende aller Sub-TA globale TA erreicht Commit alle zurückgehaltenen Sperren werden freigegeben 5. Schaad, W.: Transaktionsverwaltung in heterogenen, föderierten Datenbanksystemen, infix, DISDBIS 12,

12 TA-Verwaltung Globale Atomarität (2) Rolle der en Zustände einer globalen TA (für eine Sub-TA gezeigt) TA-Abbruch einer globalen TA - Rollback der laufenden, Kompensation der erfolgreich beendeten Sub-TA - hat alle Operationen, die Kompensation erfordern, in einen Log geschrieben - Automatische Ableitung von inversen Operationen durch wünschenswert Kenntnis des DB-Schemas erforderlich! Aufgabe ist auf niederen Sprachebenen einfach (Read/Write) aber bei SQL? - IUD-Operationen - gespeicherte Prozeduren, Sichten, Regeln und Trigger? Automatisierung ist abhängig vom Datenmodell Globale Deadlock-Erkennung - wenn verfügbar, Nutzung von Wait-for-Information aus lokalen betrifft lokale TA und Sub-TA Kommunikation zwischen en und F - sonst: Timeout-Verfahren COS BOT BOS op BOS op -1 COS BOT BOS COT COS = Begin-Of-Transaction = Begin-Of-Subtransaction = Commit-Of-Transaction = Commit-Of-Subtransaction AOS AOT AOS op op -1 = Abort-Of-Transaction = Abort-Of-Subtranscation = Operation = inverse Operation COT AOT Aufgaben des en - vor allem: Konflikterkennung und -verhütung zwischen lokalen TA und globalen Sub-TA - F ist aus Sicht des en eine Anwendung spezialisierte Schnittstelle für Koordination zum Erreichen globaler Serialisierbarkeit, globaler Atomarität usw. Austausch von Informationen zur effizienteren globalen Deadlock- Erkennung Aufbau des en - Anfrageanalysator - Schemaverwaltung (Anpassung von Operationen an SQL-Dialekte, Ableitung von Inversen) - TA-Verwaltung mit Komponenten für Concurrency Control, Logging und Recovery - Komponenten und Schnittstellen Anwendung API Anwendungslogik SQL SQL Recovery SQL Anfragen TAV-API Schema Sperren F-Architektur mit en bietet bisher nur Datenintegration, ist aber schon komplex genug

13 Daten- und Funktionsintegration 6 Daten- und Funktionsintegration (2) Bisher manuelle Integration mehrerer AWS erforderlich - Scenario: Einkaufsabteilung eines Unternehmens Mitarbeiter wird durch Funktion Kaufentscheid unterstützt Parameter hängen vom Qualitäts- und Zuverlässigkeitsgrad und der Nummer der Komponente ab Einsatz von Funktionen verschiedener AWS erforderlich (GibQualität von Lagerhaltungssystem, GibZuverlässigkeit von Einkaufssystem, GibKompNr von PDMS) INT GibQualität (INT ZuliefererNr) Eingabe: ZuliefererNr, KompName INT GibZuverlässigkeit (INT ZuliefererNr) INT GibKompNr (STRING KompName) Automatisierung der Funktionsintegration - Abbildungsmodell: Immer wiederkehrende Sequenzen von (lokalen) Funktionsaufrufen sollen hinter einer föderierten Funktion verborgen werden - Ausgangslage föderierte Funktionen lokale Funktionen F 1 (e 1,... a 1,...) F i (e 1,... a 1,...) Abbildung f 1 (e 1,... a 1,...)... f 2 (e 1,... a 1,...)... f j (e 1,... a 1,...) horizontale Abbildung vertikale Abbildung Ausführungsreihenfolge INT GibGrad (INT Qualität, INT Zuverlässigkeit) - Beschreibung durch Abhängigkeiten F 1 (e 1, e 2, a 1, a 2, a 3, a 4 ) STRING Kaufentscheid (INT Grad, INT KompNr) f 1 (e 1,a 1 ) Ausgabe: Entscheidung f 2 (e 1, e 2, a 1, a 2 ) f 3 (e 1,a 1 ) Ablauf der einzelnen Schritte des Benutzers bei manueller Integration 6. Informationsintegration wird manchmal als die Verbindung von Daten- und Funktionsintegration angesehen. Funktionsintegration bezeichnet das Verfügbarmachen lokaler Funktionen bzw. Dienste aus den einzelnen Systemen in einer einheitlichen Form Parameterabhängigkeiten Ausführungsreihenfolge (implizit) gerichteter, azyklischer Graph: topologische Sortierung! 4-26

14 Prozeßmodell eines Workflows Daten- und Funktionsintegration (3) Daten- und Funktionsintegration (4) Wie läßt sich Funktions-/Anwendungsintegration erreichen? - Anwendungssysteme erlauben nur Funktionsaufrufe E E a 1 A Workflow-Prozeß - Mehrere lokale Funktionen können zu einer föderierten Funktion zusammengefaßt werden - Aufrufstruktur für Anwendungssysteme, die lokale Funktionen bereitstellen, läßt sich als Graph spezifizieren - Komponente zur Funktionsintegration (KIF) kann Graph abarbeiten und Ergebnis als abstrakte Tabelle zum F übermitteln - Zugriff auf föderierte Funktion (über F) E A Select Entscheidung a 2 From KaufeKomponente Where KompName = xyz And ZuliefererNr = 1234 E A - gleiche TA-Problematik wie bei F a 3 KIF TAV- Komp. Datenfluß A Kontrollfluß Anwendung Anwendung Anwendung - Übereinstimmungen gerichteter, azyklischer Graph Ausführungsreihenfolge Kontrollfluß Abhängigkeiten Datenfluß Funktionen Aktivitäten Kommunikation über Funktionsaufrufe zwischen KIF und Anwendungssystem Kommunikation über TAV-API zwischen TAV-Komponente und

15 Daten- und Funktionsintegration (5) Vollständige Architektur zur Daten- und Funktionsintegration Optionen zur Implementierung der KIF 7 - UDTFs (user-defined table functions): eingeschränkte Aufrufstrukturen (z.b. keine Iteration) - Flow-System (keine Einschränkungen) WfMS (schwerfällig, Benutzerinteraktion nicht erforderlich) Microflows (sogen. Production Workflows ohne Benutzerinteraktion) - J2EE, Web Services,... wird nicht vertieft Anbindung an F (hier: abstrakt durch ) - SQL/MED-Wrapper als künftiger Standard - UDTFs wird nicht vertieft F 7. Härder, T., Hergula, K.: Ankopplung heterogener Anwendungssysteme an Föderierte Datenbanksysteme durch Funktionsintegration, in: Informatik Forschung und Entwicklung 17:3, Sept. 2002, pp KIF Anwendung Anwendung Anwendung TAV- Komp. Workflows Neue Herausforderung Dauer der Ablaufkontrolle sec Workflows in tech. AW Data Mining Data Warehousing Prozeßausführung Stapelverarb. kurze TA Zeitskala Strukturierung der Abläufe: Abhängigkeiten auf gemeinsamen Daten DB flache Transaktionen besitzen keine Struktur Workflows müssen Struktur aufweisen transaktionsgestützte Workflows

16 Ausführung von Workflows Ausführung von Workflows (2) Definitionsversuche: - Ein Geschäftsprozess ist eine Menge von manuellen, (teil)automatisierten betrieblichen Aktivitäten, die nach bestimmten Regeln auf ein bestimmtes (unternehmerisches) Ziel hin ausgeführt werden - Workflow is a collection of activities performed by information systems and/or humans to carry out a business process. - Workflow-Management supports integrated definition, validation, analysis, enactment, and monitoring of processes in a heterogeneous environment. Eigenschaften von Workflows - verteilt, parallel - langlebig 8 - heterogen, hierarchisch organisiert - Aktionen auf getrennten und gemeinsamen Datenbereichen (Wf- und AW-spezifisch) - TA-geschützte und ungeschützte Aktivitäten (Ai) - Kooperation zwischen unabhängigen Komponenten (z. B. RM) Essentielle Aspekte von Workflows eingeführt in MOBILE 9 : Forschungsprototyp eines WfMS - orthogonale Aspekte Funktionaler Aspekt: Was soll ausgeführt werden? Datenbezogener Aspekt: Welche Daten werden von Workflows/Workflow-Applikationen konsumiert und produziert? Verhaltensbezogener Aspekt: Wann sind Workflows/Workflow-Applikationen auszuführen? Operationaler Aspekt: Wie ist eine Workflow-Operation/-Applikation implementiert? Organisatorischer Aspekt: Wer hat eine(n) Workflow/-Applikation auszuführen? Sicherheitsaspekt: Wer ist zur Wf-Ausführung berechtigt? (Authentifikation und Autorisierung) - weitere technische Aspekte Steuerungsschicht Anwendungsschicht A1 A2 A3 A4 A5 A6 A7 A8 transaktionaler Aspekt: Wie wird erreicht, daß Aktivitäten und logisch zusammengehörige Folgen von Aktivitäten atomar und persistent ausgeführt werden? historischer Aspekt: Welche Information existiert zu bereits abgeschlossenen Workflow-Ausführungen? (Nachweis, Optimierung) 8. Bei Workflows und Geschäftsprozessen (insbes. im Web) ist das meist synomym zu people-driven. Wfs für Entwurfsvorgänge heißen auch Designflows Jablonski, S.; Bussler, C.: Workflow-Management Modeling Concepts, Architecture and Implementation, Thomson International,

17 Ausführung von Workflows (3) Ausführung von Workflows (4) Überblick über Aufgaben und Abhängigkeiten eines Workflow-Management-System nach WfMC 10 generates Definition Tool Software component System control data External (product) data Zwei Arten von Datenhaltung erforderlich - Kontrolldaten (durch WfMS (-DBMS) verwaltet) - Produktionsdaten (durch AW oder AW-DBMS verwaltet) - keine abgestimmten Kooperationskonzepte (Autonomie, Heterogenität) - Achtung: WfMS und AWs sind aus der Sicht ihrer DBMS Applikationen! Workflow Enactment Service may reference Organization/ Role Model Data may refer to Administration & Control (Supervisor) Process Definition WFM WFM WFM Engine(s) Engine(s) Engine(s) Work List Worklist Handler User Interface interpreted by maintain use interact via references Workflow Control Data invoke Workflow Relevant Data invokes interacts with update Application(s Application(s) Workflow Application Data manipulate Application(s Application(s) Kontrollfluß manuelle und automatische Aktivitäten Konsequenzen A1 A2 A3 A4 A5 A6 A7 A8 - ACID und damit einfache Fehlersemantik sind nicht zu gewährleisten - Atomarität von Workflows nicht erreichbar, aber auch nicht wünschenswert - bestimmte Aktivitäten (Steps) können nicht wiederholt werden - Transaktionsschutz (ACID) zumindest selektiv erforderlich - kritische Kooperationen erfordern TA-Schutz durch RM-Protokolle 10. Workflow Management Coalition:

18 Funktionale Architektur von WfMS Funktionale Architektur im Überblick Anwendung 1 Anwendung k WfMS-Schnittstelle WfMS-Schnittstelle Wf 1 Wf m WfMS- Engine WfMS- TA-Mgr AW- TA-Mgr T P - M o n i t o r WfMS... AWP 1 AWP 2 AWP n -Client Meßstation AW-System -Client Server Server... Server Server Ausführung von Workflows (5) Transaktionsgestütztes Workflow-Szenario allgemeine Problemstellung T 4 T S 3 S 2 7 T1 S 1 C 1 C 3 S 4 S 6 C 7 S 9 S 0 C 4 S C 0 S 2 S 5 S = Step C 2 C 5 T 3 C = Compensation Recovery-Aktionen bei - Rücksetzen von T 2 - Crash bei t 1, t 2, t 3 Was passiert mit den ungeschützten Aktionen? t 1 t 2 t 3

19 Ausführung von Workflows (6) Stratifizierte Transaktionen Crash in Workflows - offene Transaktionen werden bei Crash zurückgesetzt - abgeschlossene Transaktionen bleiben vom Crash unbeeinflußt; bei Rollback des Workflow müssen sie, wenn sie betroffen sind, vollständig kompensiert werden - Aktionen, die nicht dem Transaktionsschutz unterliegen, gehen verloren Voraussetzungen für Crash-Recovery - alle persistenten Statusinformationen aller aktiven Workflows können für Vorwärts-Recovery (Fortführung des Wf) benutzt werden Phoenix-Verhalten von Workflows - Recoverable Messaging erlaubt die Nutzung persistenter Warteschlangen (Queued Transaction Processing) Absicherung der Kommunikation zwischen WfMS-Komponenten - automatisierter Wiederanlauf ohne Verlust eines Arbeitsschritts - Gruppen von TAs mit 2PC-Abschluß: Konzept der stratifizierten TAs Anbindung von Anwendungs-TAs an systeminterne TAs des WfMS (Sicherung der Kontexte im WfMS-) Einschub Recoverable Messaging - persistente Kontexte können einer Anwendungsfunktion wiederholt zur Verfügung gestellt werden - persistente Ausführungshistorie gestattet ein Rollback mit zeitlich gestaffelten Aufsetzmöglichkeiten Semantisch reichere Fehlermodelle erforderlich - Es geht immer nach vorne! Ein Zurück ist eigentlich nicht vorgesehen - frühzeitige Freigabe von Änderungen auf gemeinsamen Daten Konto A Abbuchung X put (B,X) Commit T1 Q2 T2 (B,X) get Gutschrift X Commit Konto B - Verwaltung der Ausführungsgeschichte und der Kontextdaten erlauben Unterbrechbarkeit sowie eine gewisse Art von Vorwärts-Recovery - persistente Zwischenergebnisse und Nachrichten Kombination von TA, persistenten Warteschlangen und Kompensation bei Blokkierung, Wiederanlauf sowie Rücksetzen von TA-Ergebnissen Zerlegung der globalen Transaktion Buchung von Konto zu Konto - Wichtigstes Prinzip: Enqueue / Dequeue wird jeweils innerhalb der Kontrollsphäre der Schreib- / Lesetransaktion durchgeführt - erfordert entsprechende Protokolle zwischen Queue-Manager und TA-Manager (mindestens 2PC) - Grundlage asynchroner Transaktionsverarbeitung - MOM: Message-oriented Middleware

20 Stratifizierte Transaktionen (2) Stratifizierte Transaktionen (3) AW-orientierte Zerlegung der Transaktion T - Erweiterung des Konzepts der Verkettung von TA durch Recoverable Messaging - Zerlegung in (möglicherweise verteilte) T 1,... T n ; - Verkettung: jede T i erhält persistente Warteschlange Q i, aus der sie Anforderungen erhält, bestimmte Operationen auszuführen Verkettung der Strata innerhalb der stratifizierten Transaktion T durch Baumstruktur S 1 S 2 S 4 Q 2 Q 4 - lineare Reihenfolge nicht zwingend WICHTIG: - Alle von den Transaktionen T i manipulierten Ressourcen (also insbes. auch die Nachrichten) sind wiederherstellbar Q 3 Stratum - Dies bedeutet, daß sich die von den Transaktionen T i benutzten RM (DBMS, MOM) in atomares Commit einbinden lassen (XA, 2PC) Struktur stratifizierter Transaktionen S 3 Queue Transaktion - Einige T i sollen gemeinsam zum erfolgreichen Ende kommen - disjunkte Zerlegung von T in Transaktionsmengen S 1,..., S m - (S i T mit S i 0, und S i S j = 0 für i j, m und U S j = T) j = 1 - Transaktionen von S i werden durch 2PC-Protokoll synchronisiert Alle Strata führen schließlich Commit aus unter der Bedingung, daß die jeweiligen Vater-Strata zu irgendeinem Zeitpunkt vorher Commit ausgeführt haben Falls Stratum wiederholt scheitert (echte Ausnahme): stratifizierte Transaktion muß zurückgesetzt werden (Kompensation) - Menge S i von Transaktionen heißt Stratum

21 Stratifizierte Transaktionen (4) ConTracts (1) Vorteile stratifizierter Transaktionen - im Vergleich zu T: früheres Commit der einzelnen Strata S i impliziert frühere Freigabe der Sperren und damit höhere Nebenläufigkeit - Antwortzeit für Benutzer: Ausführungszeit des Wurzelstratums (weniger TA!) - 2PC-Protokolle für alle Strata können weniger Nachrichten umfassen als das 2PC-Protokoll einer globalen TA T ConTracts: 11 Erweiterung des Saga-Ansatzes um - reichere Kontrollstrukturen (Sequenz, Verzweigung, Parallelität, Schleife usw.) - getrennte Beschreibung von Sub-Transaktionen (Steps) und Ablaufkontrolle (Skript) - Verwaltung eines persistenten Kontextes für globale Variablen, Zwischenergebnisse, Bildschirmausgaben usw. - Synchronisation zwischen Steps über Invarianten - flexiblere Konflikt-/Fehlerbehandlung einer der ersten innovativen Forschungs-Prototypen - Kolokation als mögliches Kriterium für Stratifikation von T lokale 2PC-Nachrichten Wächter, H., Reuter, A.: The Contract Model, in Elmagarmid, A.K. (Hrsg.): Transaction Models for Advanced Applications, Morgan Kaufmann, San Mateo, CA, 1992, S

22 ConTracts (2) ConTracts (3) Beispiel (graphische Darstellung) S8 failure T2 S7 S6 S2 Begin of ConTract End of failure T1 ConTract S1 S2 S3 S4 S5 S9 print documents car rental flight reservation hotel reservation travel data output S2 check flight schedules Si Step Compensation Beispiel (Forts.) - zugehöriges Skript CONTRACT Business_Trip_Reservations CONTEXT_DECLARATION cost_limit, ticket_price: dollar; from, to: city; date: date_type; ok: boolean; CONTROL_FLOW_SCRIPT S1: Travel_Data_Input ( in_context: ; out_context: date, from, to, cost_limit ); PAR_FOREACH ( airline: EXECSQL select airline from... ENDSQL ) S2: Check_Flight_Schedule ( in_context: airline, data, from, to; out_context: flight_no, ticket_price ); END_PAR_FOREACH; S3: Flight_Reservation ( in_context: flight, ticket_price;... ); S4: Hotel_Reservation ( in_context: Cathedral Hill Hotel ; out_context: ok, hotel_reservation ); IF ok THEN S5: Car_Rental (... Avis... ); ELSE BEGIN S6: Hotel_Reservation (... Holiday Inn... ); IF ok THEN S7: Car_Rental (... Hertz... ); ELSE S8 : Cancel_Flight_Reservation_&_Try_Another_One (... ); END S9: Print_Documents (... ); END_CONTROL_FLOW_SCRIPT COMPENSATIONS C1: Do_Nothing_Step(); C2: Do_Nothing_Step();

23 ConTracts (4) ConTracts (5) Beispiel (Forts.) - zugehöriges Skript (Forts.) C3: Cancel_Flight_Reservation(... ); C4: Cancel_Hotel_Reservation(... ); C5: Cancel_Car_Reservation(... ); C6: Cancel_Hotel_Reservation(... ); C7: Cancel_Car_Reservation(... ); C8: Do_Nothing_Step(); C9: Invalidate_Tickets(... ); END_COMPENSATIONS TRANSACTIONS T1 (S4, S5), DEPENDENCY ( T1:abort begin:t2 ); T2 (S6, S7), DEPENDENCY( T2:abort begin:s8 ); END_TRANSACTIONS Programmiermodell - Programmierung von Steps ist unabhängig von der Erstellung von Skripten - Beispiel für einen Step (Fragment): STEP Flight_Reservation DESCRIPTION: Reserve n seats of a flight and pay for them... IN airline: STRING; flight_no: STRING; date: DATE; seats: INTEGER; ticket_price: DOLLAR; OUT status: INTEGER; flight_reservation () SYNCHRONIZATION_INVARIANTS_&_CONFLICT_RESOLUTIONS S1: EXIT_INVARIANT (budget > cost_limit); POLICY: check/revalidate; S3: ENTRY_INVARIANT (budget > cost_limit) AND (cost_limit > ticket_price)); CONFLICT_RESOLUTION: S8: Cancel_Reservation (...) ; EXIT_INVARIANT (budget > cost_limit - ticket_price); POLICY: check/revalidate; S4, S6: ENTRY_INVARIANT (hotel_price < budget); CONFLICT_RESOLUTION: S10: Call_Manager_To_Increase_Budget (... ); S5, S7: ENTRY_INVARIANT (car_price < budget); CONFLICT_RESOLUTION: S10: Call_Manager_To_Increase_Budget (... ); END_SYNCHRONIZATION_INVARIANTS_&_CONFLICT_RESOLUTIONS END_CONTRACT Business_Trip_Reservations { char* flight_no; long date; int seats;... EXEC SQL UPDATE SET WHERE END SQL... } Reservations seats_taken = seats_taken + :seats flight = :flight_no AND date = :date

24 ConTracts (6) ConTracts (7) Transaktionsmodell - Steps: ACID (lokal) - Atomare Einheiten TRANSACTIONS T1 (S4, S5), T2 (S6, S7), Forward Recovery und Kontext-Management - Forward Recovery: nach einem Fehler soll auf dem jüngsten Step-konsistenten Zustand wiederaufgesetzt werden und nach vorne weiterverfahren werden - Forward Recovery erfordert persistentes Kontext-Management END_TRANSACTIONS... Si Sk... - Schachtelung möglich T1 (T2, T3 ) - Abhängigkeiten Alternative zu obigem Beispiel T1 (S4, S5), DEPENDENCY( T1:abort[1] begin:t1 ); /* erster Abort von T1 */ DEPENDENCY(T1:abort[2] begin:s8 ); /* zweiter Abort von T1 */ Step: OUT city1 Script: city1 context element from (log.name) privater Kontext des ConTracts Business Trip Reservation Attribute von Kontextelementen: logischer Name, ConTract-Identifikator, Step-Identifikator, Zeitpunkt der Erzeugung, Versionsnummer (bei mehreren Aktivierungen desselben Steps), Zähler (für parallele Aktivierungen); Step: IN departure-airport Script: departure-airport from as produced by Si Kontext-Datenbank

25 ConTracts (8) ConTracts (9) Kompensation - Kompensation eines ConTracts ausschließlich auf explizite Benutzeranweisung nicht automatisch - Regeln: für jede(n) Step/Transaktion muß genau eine Kompensationstransaktion vorhanden sein mit dem Commit des Steps müssen alle Daten, die für die Kompensation gebraucht werden, berechnet und abgelegt sein lokale Daten, die für Kompensationsschritte benötigt werden, müssen bis End-Of_ConTract vor Löschen geschützt werden nach der Entscheidung, einen ConTract zu kompensieren, müssen alle laufenden Steps abgebrochen werden bzw. es muß verhindert werden, daß weitere Steps gestartet werden Kompensationen können auch mit Abort beendet werden, müssen aber dann wiederholt werden keine (automatische) Behandlung des Falles, daß Kompensation nach k Wiederholungen immer noch nicht erfolgreich beendet werden konnte Synchronisation mit Invarianten (Forts.) - Ziel Ermöglichen eines hohen Parallelitätsgrades und Ausschluß von Konsistenzverletzungen trotz frühzeitiger Sperrfreigabe (am Ende eines Si) Invarianten steuern die Überlappung parallel ablaufender ConTracts bzw. Steps über Prädikate - Möglichkeiten value a value a e locking escrow locking t Synchronisation mit Invarianten - Invarianten Skript-Programmierer charakterisiert in Ausgangsinvariante den am Ende des Steps erreichten Zustand der bearbeiteten Objekte Nachfolgender Step kann mit seiner Eingangsinvarianten überprüfen, ob die Bedingung für seine korrekte Synchronisation noch erfüllt ist Beispiel einer Eingangsinvarianten eines Montage-Step: Anzahl der Schrauben im Magazin > 100 implizite Invarianzbedingung einer ACID-TA: Werte aller berührten Objekte bleiben bis TA-Ende eingefroren Serialisierbarkeit ist zwar hinreichend, aber oft keinesfalls notwendig für korrekten Ablauf 4-49 value a e e Sperrkonzept friert a zum Zeitpunkt e ein Escrow erlaubt beliebige Änderungen im Unsicherheitsintervall Check/reinvalidate-Prinzip erlaubt beliebige Änderungen von a; P(a) wird zum Zeitpunkt r neu evaluiert 4-50 check/revalidate r t t