WSAtomicTransaction

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

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

4
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
Protocol

• Defines WS-Coordination Coordination Type
• http//schemas.xmlsoap.org/ws/2004/10/wsat
• 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
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 coordinators commit decision

7
WS-C and WS-AT
8
CompletionProtocol
Commit Rollback
I
C
Committed Aborted
9
2PC Protocol
Prepare Rollback Commit
C
P
Prepared ReadOnly Aborted Committed Replay
10
Volatile versusDurable 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
Prepare message
ltsoapenvHeadergt ltwsaTogthttp//localhost8080/w
s-t/Durable2PCParticipantlt/wsaTogt
ltwsaReplyTogt ltwsaAddressgthttp//localhost808
0/ws-t/Durable2PCCoordinatorlt/wsaAddressgt
ltwsaReferencePropertiesgt ltwsarjaddrInstanceI
dentifiergt7f00000180184369ea059lt/wsarjaddrInst
anceIdentifiergt lt/wsaReferencePropertiesgt
lt/wsaReplyTogt ltwsaActiongthttp//schemas.xmlsoa
p.org/ws/2004/10/wsat/Preparelt/wsaActiongt
ltwsarjaddrInstanceIdentifiergt7f00000180184369ea
057lt/wsarjaddrInstanceIdentifiergt
ltwsaMessageIDgtAUIDe0e1c2b07369e621lt/wsaMessageI
Dgt lt/soapenvHeadergt ltsoapenvBodygt
ltwsatPrepare/gt lt/soapenvBodygt
12
Prepared message
ltsoapenvHeadergt ltwsaTogthttp//localhost8080/w
s-t/Durable2PCCoordinatorlt/wsaTogt
ltwsaReplyTogt ltwsaAddressgthttp//localhost808
0/ws-t/Durable2PCParticipantlt/wsaAddressgt
ltwsaReferencePropertiesgt ltwsarjaddrInstanceI
dentifiergt7f00000180184369ea057lt/wsarjaddrInst
anceIdentifiergt lt/wsaReferencePropertiesgt
lt/wsaReplyTogt ltwsaActiongthttp//schemas.xmlsoa
p.org/ws/2004/10/wsat/Preparedlt/wsaActiongt
ltwsarjaddrInstanceIdentifiergt7f00000180184369ea
059lt/wsarjaddrInstanceIdentifiergt
ltwsaMessageIDgtAUIDe8022a77874bb1c9lt/wsaMessageI
Dgt lt/soapenvHeadergt ltsoapenvBodygt
ltwsatPrepared/gt lt/soapenvBodygt
13
Commit message
ltsoapenvHeadergt ltwsaTogthttp//localhost8080/w
s-t/Durable2PCParticipantlt/wsaTogt
ltwsaReplyTogt ltwsaAddressgthttp//localhost808
0/ws-t/Durable2PCCoordinatorlt/wsaAddressgt
ltwsaReferencePropertiesgt ltwsarjaddrInstanceI
dentifiergt7f00000180184369ea05elt/wsarjaddrInst
anceIdentifiergt lt/wsaReferencePropertiesgt
lt/wsaReplyTogt ltwsaActiongthttp//schemas.xmlsoa
p.org/ws/2004/10/wsat/Commitlt/wsaActiongt
ltwsarjaddrInstanceIdentifiergt7f00000180184369ea
05clt/wsarjaddrInstanceIdentifiergt
ltwsaMessageIDgtAUIDef3bda4cf07c9addlt/wsaMessageI
Dgt lt/soapenvHeadergt ltsoapenvBodygt
ltwsatCommit/gt lt/soapenvBodygt
14
Committedmessage
ltsoapenvHeadergt ltwsaTogthttp//localhost8080/w
s-t/Durable2PCCoordinatorlt/wsaTogt
ltwsaActiongthttp//schemas.xmlsoap.org/ws/2004/10/
wsat/Committedlt/wsaActiongt ltwsarjaddrInstanceId
entifiergt7f00000180184369ea05elt/wsarjaddrInsta
nceIdentifiergt ltwsaMessageIDgtAUIDca2178bb6e569
49clt/wsaMessageIDgt lt/soapenvHeadergt
ltsoapenvBodygt ltwsatCommitted/gt
lt/soapenvBodygt
15
Policy assertions

• Transaction flow assertion
• ltwsatATAssertion wspoptionaltrue/gt
• Operation Policy Subject
• Used by applications to indicate willingness to
  accept incoming transactions
• Wire format of serialized transaction is
  ltwscoorCoordinationContextgt header
• Atomic service assertion
• ltwsatATAlwaysCapability /gt
• Operation Policy Subject
• Used by applications to indicate that a
  requesters message will be processed
  transactionally

16
WS-Addressing

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

17
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

18
Resources

• WS-AtomicTransaction
• http//schemas.xmlsoap.org/ws/2004/10/wsat/default
  .htm
• Web services whitepapers, specs, workshops
• http//msdn.microsoft.com/webservices/

19
State tables (I)
20
State tables(II)
21
Workshops

• March 2004 for feedback workshop
• January 2005 for interoperability workshop
• http//msdn.microsoft.com/webservices/community/wo
  rkshops/transactionsinterop1204.aspx
• Several public endpoints, including
• http//wsi.alphaworks.ibm.com8080/wstx/services/I
  nteropService
• http//mssoapinterop.org/ws/
• http//213.162.124.1578080/
• http//62.190.208.1968080/WsTxTester/ep

22
Testing scenarios

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

23
General flow
24
Interoperability results