WS-AtomicTransaction. Mark Little, Chief Architect Arjuna Technologies Ltd

Size: px

Start display at page:

Download "WS-AtomicTransaction. Mark Little, Chief Architect Arjuna Technologies Ltd"

Valentine Harmon
6 years ago
Views:

1 WS-AtomicTransaction Mark Little, Chief Architect Arjuna Technologies Ltd

2 Introduction Coordinate agreement with ACID semantics Atomic, Consistent, Isolated, Durable Tried and trusted model Simple application model Synchronized state changes Correctness in the face of failures Widespread adoption Proven protocols 2

3 Model Assumptions Transactions are short lived Resources isolated (locked) for duration Coordinator availability Connected and responsive Timely failure recovery Participants trust that the above are true 3

4 But why? Web services are for the internet B2B communication Separate trust domains Why WS-AT? Two reasons Interoperability Heterogeneous systems Ubiquity Vision of WS-* scale down 4

5 Core Scenarios Some services require ACID properties - Tight coordination of mission critical state Use with service-based resource managers Example: Queue service Use within datacenter Controlled environment Use with virtual datacenter Between close partners Contractual QOS 5

6 Protocol Defines WS-Coordination Coordination Type Activities are transactions CreateCoordinationContext Create transaction Join transaction as subordinate Register Create subordinate enlistment Three coordination protocols Completion Durable 2PC Volatile 2PC Simple message patterns One-way messages Correlation using WS-Addressing Full state machines for 2PC 6

7 The Actors Completion Initiator (I) Signals coordinator to complete a transaction Can request commit or rollback Coordinator (C) Responsible for coordinating a single outcome Drives 2PC with participants Phase 1: Ensure all participants are prepared Phase 2: Notify participants of outcome Participants (P) Can vote to abort Can vote prepared to commit Must honor coordinator s commit decision 7

8 WS-C and WS-AT Application level Service Requestor UDDI/WSDL XML Messages Service Provider Initiator SOAP Request Response SOAP Application Service [application context] Infrastructure level WS-AT WS-BA Security WS-Coordination Participant WS-AT Security SOAP Coordination Messages [execution context] SOAP 8

9 Completion Protocol I Committed Aborted Commit Rollback C 9

10 2PC Protocol C Prepared ReadOnly Aborted Committed Replay P Prepare Rollback Commit 10

11 Volatile versus Durable 2PC Two variants of 2PC protocol One for volatile resources (e.g., cache) One for durable resources (e.g., database) Phase 1 has sub-phases A) Prepare all volatile participants This can cause more durable participant registrations B) Prepare all durable participants 11

12 WS-Addressing Specification uses WS-Addressing Important for interoperability Different message classifications Request messages Reply messages Notification messages Fault messages 12

13 Commit message <soapenv:header> <wsa:to> <wsa:replyto> <wsa:address> <wsa:referenceproperties> <wsarjaddr:instanceidentifier>7f000001:8018:4369ea05:e</wsarjaddr:instanceidentifier> </wsa:referenceproperties> </wsa:replyto> <wsa:action> <wsarjaddr:instanceidentifier>7f000001:8018:4369ea05:c</wsarjaddr:instanceidentifier> <wsa:messageid>auid:ef3bda4cf07c9add</wsa:messageid> </soapenv:header> <soapenv:body> <wsat:commit/> </soapenv:body> 13

14 Committed message <soapenv:header> <wsa:to> <wsa:action> <wsarjaddr:instanceidentifier>7f000001:8018:4369ea05:e</wsarjaddr:instanceidentifier> <wsa:messageid>auid:ca2178bb6e56949c</wsa:messageid> </soapenv:header> <soapenv:body> <wsat:committed/> </soapenv:body> 14

15 Policy assertions Transaction flow assertion <wsat:atassertion wsp:optional= true /> Operation Policy Subject Used by applications to indicate willingness to accept incoming transactions Wire format of serialized transaction is <wscoor:coordinationcontext> header Atomic service assertion <wsat:atalwayscapability /> Operation Policy Subject Used by applications to indicate that a requester s message will be processed transactionally 15

16 Resources WS-AtomicTransaction Web services whitepapers, specs, workshops ibm.com/developerworks/webservices/libra ry/specification/ws-tx/ 16

17 State tables (per participant) Atomic Transaction 2PC protocol (Coordinator View) Inbound Events None Active Preparing States Prepared PreparedSuccess Register None Send RegisterResponse Active Durable: Volatile: Send Register Response Active N/A PreparedSuccess Prepared Durable: Send Rollback Volatile: Invalid State None Record Vote Preparing N/A Ignore PreparedSuccess Resend Commit Resend Rollback, and forget ReadOnly Ignore None Forget Active Forget Preparing N/A PreparedSuccess Forget Aborted Ignore None Forget Forget N/A PreparedSuccess Forget Committed Ignore None N/A PreparedSuccess Forget Replay Durable: Send Rollback Volatile: Invalid State None Send Rollback Send Rollback N/A Ignore PreparedSuccess Send Commit Send Rollback 17

18 State tables Atomic Transaction 2PC protocol (Participant View) Inbound Events None Active Preparing Prepared States PreparedSuccess Register Response Register Subordinate Active Active Prepared PreparedSuccess Prepare Send Aborted None Gather Vote Decision Preparing Ignore Preparing Ignore Prepared Resend Prepared PreparedSuccess Ignore Resend Aborted, and forget Commit Send Committed None Initiate commit decision Ignore InconsistentInternalState Rollback Send Aborted None Initiate Rollback, Send Aborted, and Forget Initiate Rollback, Send Aborted, and Forget Initiate Rollback, Send Aborted, and Forget Initiate Rollback, Send Aborted, and Forget InconsistentInternalState Send Aborted, and Forget 18

19 Workshops March 2004 for feedback workshop January 2005 for interoperability workshop Several public endpoints, including

20 Testing scenarios Explicitly tested WS-AT and WS-BA Implicitly tested WS-C Many different test cases Both for coordinator and participants Included failures 20

21 General flow Implementation A Implementation B InitiatorApp (IA) CoordinatorProtocolService (CS) ParticipantProtocolService (PS) ParticipantApp (PA) tns:request() wscoor:registerrequest() wscoor:registerresponse() tns:response() wsat:protocol() 21

22 Interoperability results 22

Web Services Coordination and Transactions

Web Services Coordination and Transactions Kapitel 11 1 Motivation Need to coordinate (sets of) activities or applications Distributed Running on different platforms using local coordinators Example Reach