1 / 51

WS-Coordination and Transaction Management in Service-Oriented Architecture

Learn about WS-Coordination and the implementation of transaction management in Service-Oriented Architecture. Topics include WS-Atomic.Transaction, Two Phase Commit Protocol, WS-BusinessActivity, and more.

wmckinley
Download Presentation

WS-Coordination and Transaction Management in Service-Oriented Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service Oriented ArchitectureLecture 9 Notes from: Web Services & Contemporary SOA Ch 6, Erl XML Transactions for Web Services, Faheem Khan Distributed Systems Text, Tanenbaum Microsoft Article at http://msdn2.microsoft.com/en-gb/library/ms996526.aspx

  2. Today’s Topics • WS-Coordination • WS-Atomic Transaction • Two Phase Commit Protocol • WS-BusinessActivity

  3. WS-Coordination • An OASIS standard • Developed by IBM, Microsoft & BEA • Implemented in WebSpehere V6 • Implemented in JBOSS • Part of MS Vista and the Windows Communication Foundation (Indigo project) • Apache Foundation Kandula Project

  4. Coordination • WS-Coordination includes two lower level standards: • WS-AT Web Service Atomic Transaction • WS-BA Web Service Business Activity

  5. From IBM

  6. From Apache’s Kandula Project

  7. activation Service registration service Three services defined by WS-Coordination participant participant coordinator Potential participants

  8. activation Service CreateCoordinationContext registration service participant participant coordinator Potential participants

  9. activation Service registration service register participant participant coordinator Potential participants participant

  10. activation Service registration service A set of coordination protocol services for each supported coordination type. participant participant coordinator Potential participants participant

  11. activation Service registration service Each coordinator has a type: currently either WS-AtomicTransaction or WS-BusinessActivity participant participant coordinator This participant wants to engage others in an atomic transaction. participant

  12. Call createCoordinationContext registration service activation Service 1 2 coordinator participant participant 2. Request coordination context. A Coordination Context is an XML document containing: an activity identifier, the type of coordination, a registration endpoint, expiration time and application specific extensibility elements.

  13. Coordination Context <soapenv> <soapbody> <wscoor:CoordinationContext <Identifier> ... </Identifier> <Expires> ... </Expires> <wscoor:CoordinationType> ... </wscoor:CoordinationType> <wscord:RegistrationService> <Address/> </wscoord:RegistrationService> <!--extensibility element -> </wscoor:CoordinationContext> </soapbody> </soapenv>

  14. Call register registration service activation Service 3 coordinator 4 participant participant 3. 4. Register to play a role in a coordinated activity. The role depends upon what type of activity is going to take place and how the participating application is involved in that activity. The registration service will register the role of the participant application in the activity.

  15. registration service activation Service coordinator participant participant participant Other players get a copy of the context.

  16. Players Invited To Play <soapenv> <soapheader> <wscoor:CoordinationContext <wsme:Identifier> http://myCoordinationService/ts/activity1 </wsme:Identifier> <wsme:Expires> 2002-06-30T13:20:00.000-05:00 </wsme:Expires> <wscoor:CoordinationType> http://xml-soap.org/2002/06/AtomicTransaction </wscoor:CoordinationType> <wscoor:RegistrationService> <Address> http://myRegistrationService </Address> </wscoor:RegistrationService> </soapheader> <soapbody> <debitAccount ... /> </soapbody> </soapenv>

  17. registration service activation Service coordinator participant participant participant With a copy of the context, other players register.

  18. From Microsoft article

  19. Sending a CreateCoordinationContext message to the Activation • service creates an activity. The optional CurrentContext parameter is absent, so a • new activity is created and the returned CoordinationContext has a new activity • identifier and Registration service A. • 2. The CoordinationContext is propagated from application services A to B as a • SOAP header in an application message. This acts as an invitation to application • service B to participate in the activity using one of the coordination protocols for • that coordination type. The service that receives this invitation can either register • to participate or not. • 3. Service B registers using the Registration service A from the propagated context. • 4. The coordination protocol instance can then begin between the participants. This • Coordination protocol enables coordination. For example, this may be either the WS- • AtomicTransaction 2PC or WS-BusinessActivity protocol.

  20. WS-Coordination • The participant application has gained possession of an instance of the coordination context. • The participant application then propagates the coordination context instance to other applications that it would like to take part in the same activity. • Those applications also register themselves with the coordinator for the same activity. • The different participating applications may use the same coordinator or they may want to use their own trusted coordinators. In case different participating applications use their respective coordinators, the coordinators will talk to each other in order to provide coordination services.

  21. From Microsoft article

  22. In the above, after the import of the activity or the interposition of the trusted coordinator service B, Application B can deal with its own coordination services, which in turn deals with A's coordination services. 1. Create the activity and receive a CoordinationContext. 2. Propagate A's CoordinationContext to B in an application message. 3. B has a choice of whether to deal directly with A's coordination services, as in our first example, or use another set of coordination services as its representative. It decides to import the activity to B's coordination services by sending its Activation service the CreateCoordinationContext message with the context from A as the optional CurrentContext parameter. The returned CoordinationContext has the same activity identifier, but has B's Registration service. 4. Register B with its own Registration service obtained from its CoordinationContext identifier. 5. B's coordination services delegate the registration to A's Registration service, which it obtained from the CurrentContext parameter during import. This creates a new coordination protocol instance between A and B. 6. The coordination protocol instance can then begin between the participants A and B.

  23. WS-Coordination • But what is the coordinated activity (the actual sequence of operations) that will take place? • WS-Coordination says nothing about the actual activity. It leaves it up to the participating applications to decide what they want to do with the coordination context.

  24. registration service activation Service coordinator participant participant participant Suppose everyone is registered for an atomic transaction using 2PC

  25. Hypothetical Web Service Transaction Begin transaction BookTrip book plane book hotel book rental car End transaction BookTrip Notes adapted from Tanenbaum’s “Distributed Systems Principles and Paradigms”

  26. registration service activation Service coordinator Book Trip WS Book Car WS Book Plane WS Book Hotel WS Suppose everyone is registered for an atomic transaction using 2PC

  27. Transactions (ACID) • Atomic: All or nothing. No intermediate states are visible. • Consistent: system invariants preserved, e.g., if there were n dollars in a bank before a transfer transaction then there will be n dollars in the bank after the transfer. • Isolated: Two transactions do not interfere with each other. They appear as serial executions. • Durable: The commit causes a permanent change.

  28. Participant Talks to Coordinator Different servers Any server BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Recoverable objects needed to book a hotel. Unique Transaction ID TID openTrans BookRentalCar Participant Recoverable objects needed to rent a car. BookTrip Client TID = openTransaction()

  29. Client Calls Methods Different servers Any server BookPlane Participant BookTrip Coordinator Recoverable objects needed to book a plane BookHotel Participant Recoverable objects needed to book a hotel. Call + TID BookRentalCar Participant Recoverable objects needed to rent a car. BookTrip Client plane.bookFlight(111,”Seat32A”,TID)

  30. The participant only calls join if it has not already done so. Plane Joins the Transaction Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane join(TID,ref to participant) BookHotel Participant Recoverable objects needed to book a hotel. BookRentalCar Participant BookTrip Client The participant knows where the coordinator is because that information can be included in the TID (eg. an IP address.) The coordinator now has a pointer to the participant.

  31. Suppose All Goes Well (1) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Recoverable objects needed to book a hotel. BookRentalCar Participant BookTrip Client Recoverable objects needed to rent a car. OK returned OK returned OK returned

  32. Suppose All Goes Well (2) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Coordinator begins 2PC and this results in a GLOBAL COMMIT sent to each participant. Recoverable objects needed to book a hotel. BookRentalCar Participant Recoverable objects needed to rent a car. BookTrip Client OK returned OK returned OK returned CloseTransaction(TID) Called

  33. This Time No Cars Available (1) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Recoverable objects needed to book a hotel. BookRentalCar Participant Recoverable objects needed to rent a car. BookTrip Client OK returned OK returned NO CARS AVAIL abortTransaction(TID) called

  34. This Time No Cars Available (2) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Coordinator sends a GLOBAL_ABORT to all particpants Recoverable objects needed to book a hotel. BookRentalCar Participant Recoverable objects needed to rent a car. BookTrip Client OK returned OK returned NO CARS AVAIL abortTransaction(TID) called

  35. This Time No Cars Available (3) Different servers BookPlane Participant Coordinator ROLLBACK CHANGES BookHotel Participant abortTransaction ROLLBACK CHANGES Each participant Gets a GLOBAL_ABORT BookRentalCar Participant ROLLBACK CHANGES BookTrip Client OK returned OK returned NO CARS AVAIL abortTransaction(TID)

  36. BookPlane Server Crashes After Returning ‘OK’ (1) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Recoverable objects needed to book a hotel. BookRentalCar Participant BookTrip Client Recoverable objects needed to rent a car. OK returned OK returned OK returned

  37. BookPlane Server Crashes After Returning ‘OK’ (2) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant Coordinator excutes 2PC: Ask everyone to vote. No news from the BookPlane Participant so multicast a GLOBAL ABORT Recoverable objects needed to book a hotel. BookRentalCar Participant Recoverable objects needed to rent a car. BookTrip Client OK returned OK returned OK returned CloseTransaction(TID) Called

  38. BookPlane Server Crashes After Returning ‘OK’ (3) Different servers BookPlane Participant Coordinator Recoverable objects needed to book a plane BookHotel Participant GLOBAl ABORT ROLLBACK BookRentalCar Participant ROLLBACK BookTrip Client OK returned OK returned ROLLBACK OK returned CloseTransaction(TID) Called

  39. Two-Phase Commit Protocol - Phase 1 BookPlane Vote_Request Coordinator Vote_Commit Vote Request BookHotel Vote Commit Vote Request BookRentalCar Phase 1 Coordinator sends a Vote_Request to each process. Each process returns a Vote_Commit or Vote_Abort. Vote Commit

  40. Two-Phase Commit Protocol - Phase 2 BookPlane Global Commit Coordinator ACK BookHotel Global Commit ACK Global Commit BookRentalCar Phase 2 Coordinator checks the votes. If every process votes to commit then so will the coordinator. In that case, it will send a Global_Commit to each process. If any process votes to abort the coordinator sends a GLOBAL_ABORT. Each process waits for a Global_Commit message before committing its part of the transaction. ACK

  41. 2PC Finite State Machine From Tanenbaum Coordinator Participant State has already been saved to permanent storage. Init Init Vote-request ----------------- Vote-commit Vote-request ----------------- Vote-abort Commit ---------- Vote-request Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  42. 2PC Blocks in Three Places If waiting too long for a Vote-Request send a Vote-Abort Init Init Vote-request ----------------- Vote-commit Vote-request ----------------- Vote-abort Commit ---------- Vote-request Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  43. 2PC Blocks in Three Places Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request If waiting too long After Vote-request Send a Global-Abort Ready Vote-request ----------------- Vote-abort wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  44. 2PC Blocks in Three Places If waiting too long we can’t simply abort! We must wait until the coordinator recovers. We might also make queries on other participants. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  45. 2PC Blocks in Three Places If this process learns that another has committed then this process is free to commit. The coordinator must have sent out a Global-commit that did not get to this process. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  46. 2PC Blocks in Three Places If this process learns that another has aborted then it too is free to abort. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  47. 2PC Blocks in Three Places Suppose this process learns that another process is still in its init state. The coordinator must have crashed while multicasting the Vote-request. It’s safe for this process (and the queried process) to abort. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  48. 2PC Blocks in Three Places Tricky case: If the queried processes are all still in their ready state what do we know? We have to block and wait until the Coordinator recovers. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort

  49. Strong Division of Function • With atomic transactions there is a strong division of function between the business activity and coordination of the transaction. • The applications decides who to involve in the transaction and whether to commit or abort. • After this, coordination takes over and decides the outcome.

  50. Mutual Trust Is Required • Any system can abort the entire transaction. Systems must be trusted to have cooperative intentions. • Systems must trust each other to be responsive.

More Related