1. 95-843 Service Oriented Architecture Master of Information System Management Service Oriented Architecture 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. 2 Today’s Topics WS-Coordination WS-Atomic Transaction Two Phase Commit Protocol WS-BusinessActivity

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

4. 4 Coordination Every activity introduces a level of context into an application runtime environment. Context Information must be managed, preserved and/or updated and distributed to activity participants. WS-Coordination establishes such a framework.

5. 5 From IBM

6. 6 From Apache’s Kandula Project

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

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

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

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

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

12. 12 activation Service registration service participant coordinator participant 1 2 1.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. Call createCoordinationContext

13. 13 Coordination Context <wscoor:CoordinationContext...

14. 14 activation Service registration service participant coordinator 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. 3 4 Call register

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

16. 16 Players Invited To Play <wscoor:CoordinationContext http://myCoordinationService/ts/activity1 2002-06-30T13:20:00.000-05:00 http://xml-soap.org/2002/06/AtomicTransaction http://myRegistrationService

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

18. 18 From Microsoft article

19. 19 1.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. 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. 21 From Microsoft article

22. 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. 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. 24 activation Service registration service participant coordinator participant Suppose everyone is registered for an atomic transaction using 2PC participant

25. 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. 26 activation Service registration service Book Trip WS coordinator Book Plane WS Suppose everyone is registered for an atomic transaction using 2PC Book Car WS Book Hotel WS

27. 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. 28 Participant talks to coordinator Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client openTrans Unique Transaction ID TID Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. TID = openTransaction() Recoverable objects needed to rent a car. Any server

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

30. 30 Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Plane joins the transaction 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. The participant only calls join if it has not already done so. join(TID,ref to participant)

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

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

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

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

35. 35 Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client ROLLBACK CHANGES This time no cars available (3) OK returned NO CARS AVAIL abortTransaction(TID) abortTransaction Each participant Gets a GLOBAL_ABORT ROLLBACK CHANGES

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

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

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

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

40. 40 Two-Phase Commit Protocol (Gray Coordinator BookPlane BookHotel 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. Global Commit ACK Global Commit ACK Global Commit ACK

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

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

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

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

45. 45 2PC Blocks in three places Init wait Abort Commit ---------- Vote-request Vote-commit ---------------- Global-commit Vote-abort -------------- Global-abort Init Ready Abort Commit Vote-request ----------------- Vote-commit Vote-request ----------------- Vote-abort Global-commit ------------------- ACK Global-abort ---------------- ACK 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.

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

47. 47 2PC Blocks in three places Init wait Abort Commit ---------- Vote-request Vote-commit ---------------- Global-commit Vote-abort -------------- Global-abort Init Ready Abort Commit Vote-request ----------------- Vote-commit Vote-request ----------------- Vote-abort Global-commit ------------------- ACK Global-abort ---------------- ACK 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.

48. 48 2PC Blocks in three places Init wait Abort Commit ---------- Vote-request Vote-commit ---------------- Global-commit Vote-abort -------------- Global-abort Init Ready Abort Commit Vote-request ----------------- Vote-commit Vote-request ----------------- Vote-abort Global-commit ------------------- ACK Global-abort ---------------- ACK 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.

49. 49 Strong Division of Function With atomic transactions there is a strong division of function between application and function. 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. 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.

51. 51 Business Activity Differs from Atomic Transactions Has a longer duration (minutes, days,weeks) Locks are released between steps. Changes become visible. Application logic is involved in coordination.

52. 52

53. 53 1.The Buyer service sends each Seller a PurchaseOrder message with a CoordinationContext header. These messages can all be sent at the same time. 2. All three Sellers register for the BusinessAgreementWithParticipantCompletion protocol. 3. From this point on, each of the 3 Sellers have different flows: a. Seller A cannot make a quote. It notifies the Buyer using the coordination protocol Fault message with message's ExceptionIdentifier parameter to indicate this. b. Sellers B and C can make a quote. They each notify the Buyer using the coordination protocol Completed message with price information included in the message using the extensibility elements of the protocol messages.

54. 54 4. After looking at the quotes from Sellers B and C, the Buyer chooses B. a. It notifies B with the coordination protocol Close message. b. It notifies C with the coordination protocol Compensate message. This compensation may require the Buyer to pay a handling fee.