infm2 :: AW1 :: SOA (2) Transaktionsmanagement mit Services und Geschäftsprozessen Martin Gerlach

infm2 :: AW1 :: SOA (2) :: Martin Gerlach2 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen  Long Running Distributed Transactions  Geschäftsprozesse  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach3 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen  Long Running Distributed Transactions  Geschäftsprozesse  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach4 Motivation :: Verteilte Services im Ferienclub Ferienclub Autovermietung B Restaurant [Ort, Preiskl., …] Reservierungs- Service Hotel [Ort, Preiskl., …] Reservierungs- Service Kino [Ort, Genre, …] Reservierungs- Service Autovermietung A [Attribute…] Reservierungs- Service Kalender- Service Reservierungs- Broker-Service Payment- Service Anwendung

infm2 :: AW1 :: SOA (2) :: Martin Gerlach5 Motivation :: Club-Anwendungen sollen funktionieren  Kombinierte Buchung von Leistungen Mietwagen + Restaurant + Auswärtiges Hotel + Bezahlung Getränkebestellung + Bezahlung Buchen von Sportgerät/-plätzen …  Geht nur mit zuverlässigem "Transaktionskonzept"  "(Geschäfts)Prozesse" definieren die Abfolge der Service- Aufrufe

infm2 :: AW1 :: SOA (2) :: Martin Gerlach6 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen  Long Running Distributed Transactions  Geschäftsprozesse  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach7 Klassischer Transaktionsbegriff  Transaktion [10, 11] Handel: Geschäftsvorfall (Business Transaction) Datenbanken: Allgemein zugängliche Daten bei Zugriff durch mehrere Clients konsistent halten Ausgeweitet von Datenbanken auf andere Ressourcen  Atomicity, Consistency, Isolation, Durability  Verteilte Transaktionen Gesamtsystem nach der Transaktion konsistent  Erweiterte Konzepte [nach [2]] Nested TX + Open Nested TX Saga SplitJoin ConTracts Long Running Activity

infm2 :: AW1 :: SOA (2) :: Martin Gerlach8 Klassische verteilte TX :: Zuverlässigkeit  2 Phase Commit (2PC) Koordinator (C) steuert Knoten A und B aus [1]  … und andere (3PC etc.), die auch den Ausfall des Koordinators berücksichtigen

infm2 :: AW1 :: SOA (2) :: Martin Gerlach9 Klassische verteilte TX :: Zeit  Üblicherweise vollautomatisch  Daher "schnell" Typischer Abstand zwischen 2PC "PREPARE" und "COMMIT" im Millisekunden/Sekunden-Bereich [1]  Bei Timeout ROLLBACK

infm2 :: AW1 :: SOA (2) :: Martin Gerlach10 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen Nutzung klassicher TX Zeitbetrachtung  Long Running Distributed Transactions  Geschäftsprozesse  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach11 … und zwar hier Services :: Nutzung klassischer TX  Jeder Service kann für die Erfüllung seiner Aufgabe, klassische – auch verteilte – Transaktionen nutzen  Der gesamte Prozess muss aber auch gesichert sein …

infm2 :: AW1 :: SOA (2) :: Martin Gerlach12 Services :: Verteilte Services im Ferienclub Ferienclub Autovermietung B Restaurant [Ort, Preiskl., …] Reservierungs- Service Hotel [Ort, Preiskl., …] Reservierungs- Service Kino [Ort, Genre, …] Reservierungs- Service Autovermietung A [Attribute…] Reservierungs- Service Kalender- Service Reservierungs- Broker-Service Payment- Service Anwendung

infm2 :: AW1 :: SOA (2) :: Martin Gerlach13 Services :: Verteilung und Zeit  Hochgradige Verteilung Über unterschiedliche Organisationen  Abarbeitung eines Requests Ist u. U. nicht vollautomatisch Kann u. U. "lange dauern" Besonders dann, wenn andere Services (entfernt) aufgerufen werden  Mit ACID TX und 2PC würden Ressourcen für zu lange Zeit gesperrt bleiben  Folge: Man benötigt ein Konzept für "Long Running Distributed Transactions"

infm2 :: AW1 :: SOA (2) :: Martin Gerlach14 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen  Long Running Distributed Transactions Überblick, Konzepte Lösungen: BTP, THP, WS-*  Geschäftsprozesse  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach15 Long Running Distributed Transactions  "Long-running activities can be structured as many independent, short-duration transactions, to form a 'logical' long-running transaction." [1]  Anforderungen Verteilung Lange Laufzeit Ressourcen sollen nicht zu lange gesperrt bleiben  ACID zu restriktiv  Einzelsysteme sollen schnell "committen"  Aber der Mietwagen soll nicht gebucht bleiben, wenn das Restaurant ausgebucht ist…  Optimistische Nebenläufigkeitskontrolle

infm2 :: AW1 :: SOA (2) :: Martin Gerlach16 Long Running Distributed TX :: Kompensation  Wenn ACID nicht erwünscht ist, benötigt man kompensierende Aktionen Typischerweise auch über Service Call  Beispiel (aus [1]) t1: Mietwagen/Taxi t2: Restaurant t3: Theater t4: Hotel (ausgebucht) tc1: Storno t2/t3 t5': Kino t6': More fun stuff

infm2 :: AW1 :: SOA (2) :: Martin Gerlach17 Long Running Distributed TX :: Systementwurf  Hochgradige Verteilung von Anfang an berücksichtigen Nicht erstmal alles als lokal, schnell, verfügbar, zuverlässig betrachten. Unzuverlässigkeiten, Verzögerungen etc. müssen u. U. zunächst simuliert werden (z.B. beim Prototyping)  Architektur muss für verteilte Services gebaut werden (nicht andersherum)  Service Oriented Architecture

infm2 :: AW1 :: SOA (2) :: Martin Gerlach18 Long Running Distributed TX :: Lösungen :: BTP  Business Transaction Protocol (OASIS) [2, 17]  Koordinator-basiert (ähnl. 2PC)  Applikation hat Kontrolle über beide Commit-Phasen durch Business-Logik  "Open Top" Commit Protocol  Normale Kontroll-Verben BEGIN, COMMIT, ROLLBACK  Neue Kontroll-Verben PREPARE, CONFIRM, CANCEL

infm2 :: AW1 :: SOA (2) :: Martin Gerlach19 Long Running Distributed TX :: Lösungen :: BTP  Zwei Arten von Transaktionen  Atoms Garantiert konsistent, alle Teilnehmer sehen gleiches Ergebnis (confirm oder cancel)  Cohesions Teilnehmer können unterschiedliche Ergebnisse haben 2-Phasen-Protokoll erlaubt genaue Parametrisierung welche Teilnehmer "confirmed"/"canceled" werden Nur "confirmed" Teilnehmer sehen das gleiche Ergebnis Dadurch teilweise Aufhebung von "Atomicity" und "Isolation"

infm2 :: AW1 :: SOA (2) :: Martin Gerlach20 Long Running Distributed TX :: Lösungen :: BTP  Gedacht für QoS-Layer aus [1]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach21 Long Running Distributed TX :: Lösungen :: BTP Optimierungen und weitere Details in [1], [2], [17] <SOAP:Envelope SOAP:encodingStyle=" xmlns:SOAP=" <btp:begin transaction-type="atom" xmlns:btp="urn:oasis:names:tc:BTP:1.0:core"/>  Für Web Services über SOAP 1.1:

infm2 :: AW1 :: SOA (2) :: Martin Gerlach22 Long Running Distributed TX :: Lösungen :: THP  Tentative Hold Protocol [2, 18]  Nicht-blockierende Sperren vor der TX  "Reservierung"  Paradigma "Online-Ordering"  Nachrichten-basiert  Wenn ein reservierender Prozess "committed", werden andere benachrichtigt  Framework: THP-Koordinatoren auf Requestor- und Provider-Seite Sollten durch Firewall kommunizieren können Requestor/Provider-spezifische APIs Verwaltung der Sperren

infm2 :: AW1 :: SOA (2) :: Martin Gerlach23 Long Running Distributed TX :: Lösungen :: THP aus [2]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach24 Long Running Distributed TX :: Lösungen :: THP  Erweiterung: Web Service Tentative Hold and Compensation Composition Transaction Model  Dynamische Service- Choreography Reihenfolge Parallel/Sequentiell Constraints  Kompensierung  Kompliziert…  [2] / AW2 / Projekt … aus [2]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach25 Long Running Distributed TX :: Lösungen :: WS-*  WS-* Spezifikationen WS-Addressing WS-Coordination WS-Policy WS-Security …  Nur Web Services  BEA, IBM, Microsoft, VeriSign u.a.  Praktisch für alles rund um Web Serivces

infm2 :: AW1 :: SOA (2) :: Martin Gerlach26 Long Running Distributed TX :: Lösungen :: WS-* [5]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach27 Long Running Distributed TX :: Lösungen :: WS-Coordination  Coordination Framework 1.Coordination Services (WS-Coordination Spec) Activation Service Registration Service Coordination Service 2.Coordination Protocols (WS-Transaction Specs) Protocol for Atomic Transactions Protocol for Business Transactions (Long Running TX)

infm2 :: AW1 :: SOA (2) :: Martin Gerlach28 Long Running Distributed TX :: Lösungen :: WS-Coordination aus [8]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach29 Long Running Distributed TX :: Lösungen :: WS-Coordination  Transaktionsprotokolle kombinierbar aus [8]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach30 Long Running Distributed TX :: Lösungen :: WS-Coordination  Coordination Context... <wscoor:CoordinationContext xmlns:wsme=" xmlns:wscoor=" xmlns:myApp=" T13:20: : RepeatableRead...

infm2 :: AW1 :: SOA (2) :: Martin Gerlach31 Long Running Distributed TX :: Lösungen :: WS-AtomicTransaction aus [8]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach32 Long Running Distributed TX :: Lösungen :: WS-BusinessActivity aus [8]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach33 Long Running Distributed TX :: Lösungen :: WS-*  Spezifikationen teilweise noch nicht vollständig  Implementierungen?  Security (  Thies) WS-Policy WS-Security

infm2 :: AW1 :: SOA (2) :: Martin Gerlach34 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen  Long Running Distributed Transactions  Geschäftsprozesse SOA Einordnung BPEL4WS  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach35 Geschäftsprozesse  Geschäftsprozess  Technischer Prozess  Technischer Prozess  Services  Analyse, Modellierung für Technische Prozesse: "Service- based processes: design for business and technology" [13]  Technischer Prozess ist auch ein Service  Geschäftsprozessmodellierung

infm2 :: AW1 :: SOA (2) :: Martin Gerlach36 Geschäftsprozesse :: SOA Einordnung  SOA Schicht: "Process Layer" (  Sven)  Service Orchestration + Choreography [3, 4]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach37 Geschäftsprozesse :: Integration  Organisation der Aktivitäten eines Prozesses  Verschiedene existierende Services werden aufgerufen  Patterns (  Sven) zur Prozess-Integration [5, 6]  Seriell und/oder parallel neinja Serieller ProzessParalleler Prozess Work Flow Eine NachrichtBroker Router parallel seriell nein ja

infm2 :: AW1 :: SOA (2) :: Martin Gerlach38 Geschäftsprozesse :: BPEL4WS [5]

infm2 :: AW1 :: SOA (2) :: Martin Gerlach39 Geschäftsprozesse :: BPEL4WS  XML-basierte Modellierungssprache für Service-basierte Prozesse [9]  Kontrollsemantik auf Mengen von Interaktionen mit Services, die Bestandteil des Prozesses sind  Runtime Engine benötigt, z. B. BPWS4J [19]  Rekursiv: BPEL Prozesse sind Web Services  Grober Ablauf Aufruf ("Receive") Logik + Service-Aufrufe Antwort ("Reply")

infm2 :: AW1 :: SOA (2) :: Martin Gerlach40 Geschäftsprozesse :: BPEL4WS Tooling <process expressionLanguage="Java" name="Process" xmlns:wsdl=" xmlns:wsdl0=" xmlns:wsdl1=" > <![CDATA[ return getInputVariable().getContents().startsWith("A"); ]]> <invoke inputVariable="InputVariable" operation="OperationA" outputVariable="VariableB" partnerLink="PartnerLinkA" portType="wsdl0:PortTypeA"/>... <reply operation="InputOperation" partnerLink="PartnerLink" variable="InputVariable"/>

infm2 :: AW1 :: SOA (2) :: Martin Gerlach41 Geschäftsprozesse :: BPEL4WS & WS-*  Interessantes Paper [3] zur Kombination von BPEL4WS und WS- Coordination mittels WS-Policy [7]  Beispiel 1 "Coordinated BPEL-PartnerLinks": <wsce:CoordinatedService CoordinationType= " ws/2003/09/wsat"> <wsce:Protocol ProtocolIdentifier= " ws/2003/09/wsat#Durable2PC"/>

infm2 :: AW1 :: SOA (2) :: Martin Gerlach42 Geschäftsprozesse :: BPEL4WS & WS-*  Beispiel 2 "Coordinated BPEL-Scope": <service name="ABCBankService" <port name="creditAccount" binding="tns:CreditBinding" wsp:PolicyRefs="tns:WSATPolicy" >

infm2 :: AW1 :: SOA (2) :: Martin Gerlach43 Agenda  Motivation: Ferienclub  Klassische Transaktionen  Services und Transaktionen  Long Running Distributed Transactions  Geschäftsprozesse  Ausblick: AW2+Projekt

infm2 :: AW1 :: SOA (2) :: Martin Gerlach44 Ausblick: AW2 + Projekt (infm3)  Vorschlag für Gesamt-Architektur mit Tobias Kraue, Thies Rubarth, Sven Stegelmeier  Web Services  Transaktionen: Konzept, Architektur WS-* BTP/THP Features evtl. einfließen lassen Bereitstellung von Framework und Templates  Geschäftsprozesse: Service Orchestration + Choreography Konzeptionell Hands-on: Implementierungen testen, z.B. IBM/Rational Transaktionen BPEL4WS + WS-* ausprobieren(?) Hier könnte sich herausstellen, dass das in unserem Fall mit Kanonen auf Spatzen geschossen ist.

infm2 :: AW1 :: SOA (2) :: Martin Gerlach45 Referenzen :: Haupt 1.Mark Little, "Service-oriented Computing: Transactions and Web Services", Communications of the ACM, Volume 46 Issue 10, Oktober Benchaphon Limthanmaphon, Yanchun Zhang, "Web Service Composition Transaction Management", Proceedings of the fifteenth conference on Australasian database - Volume 27, Januar Stefan Tai, Rania Khalaf, Thomas Mikalsen, "Composition of Coordinated Web Services", Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, Oktober Girish B. Chafle, Sunil Chandra, Vijay Mann, Mangala Gowri Nanda, "Decentralized Orchestration of Composite Web Services", Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters, Mai Mark Endrei et. al., "Patterns: Service Oriented Architecture and Web Services", IBM ITSO Redbook SG246303, April Martin Keen et. al., "Patterns: Serial and Parallel Processes for Process Choreography and Workflow", IBM ITSO Redbook SG246306, April WS-* Spezifikationen, Überblick: (WS- Addressing, WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity, …) 8.Tom Freund, Tony Storey, "Transactions in the world of Web services", und August BPEL4WS: 10.Tanenbaum, van Steen, "Distributed Systems", Prentice Hall, Couloris, Dolimore, Kindberg, "Distributed Systems", Pearson Education, 2001

infm2 :: AW1 :: SOA (2) :: Martin Gerlach46 Referenzen :: Interessant 12.Martin Gudgin, "Web Services: Secure, reliable, transacted: innovation in Web Services architecture", Proceedings of the 2004 ACM SIGMOD international conference on Management of data, Juni Martin Henkel, Jelena Zdravkovic, Paul Johannesson, "Service-based Processes: Design for Business and Technology", Proceedings of the 2nd international conference on Service oriented computing, November Anis Charfi, Mira Mezini, "Service composition: Hybrid Web Service Composition: Business Processes Meet Business Rules", Proceedings of the 2nd international conference on Service oriented computing, November Fabien Baligand, Valérie Monfort, "Service security: A Concrete Solution for Web Services Adaptability Using Policies and Aspects", Proceedings of the 2nd international conference on Service oriented computing, November (Sehr viele Ressourcen zu SOA und Web Services) 17.Business Transaction Protocol (BTP) bei OASIS: open.org/committees/tc_home.php?wg_abbrev=business-transactionhttp:// open.org/committees/tc_home.php?wg_abbrev=business-transaction 18.Jerry Roberts, Krishnamurthy Srinivasan et al., "Tentative Hold Protocol (THP)": und BPWS4J (BPEL4WS Java Runtime):