Get documents about "WS-AtomicTransaction
Shared by: HC120809162320
-
Stats
- views:
- 0
- posted:
- 8/9/2012
- language:
- pages:
- 22
Document Sample
WS-AtomicTransaction
Mark Little, Chief Architect
Arjuna Technologies Ltd
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
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
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
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 coordinator’s commit decision
7
WS-C and WS-AT
Application level
UDDI/WSDL
Service
Service Provider
Requestor
XML Messages
Request Application
Initiator
SOAP SOAP Service
Response
[application context]
Infrastructure level
WS-AT Participant
WS-Coordination
WS-BA WS-AT
Security Security
SOAP Coordination Messages SOAP
[execution context]
8
Completion
Protocol
Commit
Rollback
I C
Committed
Aborted
9
2PC Protocol
Prepare
Rollback
C P
Commit
Prepared
ReadOnly
Aborted
Committed
Replay
10
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
WS-Addressing
• Specification uses WS-Addressing
– Important for interoperability
• Different message classifications
– Request messages
– Reply messages
– Notification messages
– Fault messages
12
Commit message
<soapenv:Header>
<wsa:To>http://localhost:8080/ws-t/Durable2PCParticipant</wsa:To>
<wsa:ReplyTo>
<wsa:Address>http://localhost:8080/ws-t/Durable2PCCoordinator</wsa:Address>
<wsa:ReferenceProperties>
<wsarjaddr:InstanceIdentifier>7f000001:8018:4369ea05:e</wsarjaddr:InstanceIdentifier>
</wsa:ReferenceProperties>
</wsa:ReplyTo>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/10/wsat/Commit</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
Committed
message
<soapenv:Header>
<wsa:To>http://localhost:8080/ws-t/Durable2PCCoordinator</wsa:To>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/10/wsat/Committed</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
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
Resources
• WS-AtomicTransaction
– http://schemas.xmlsoap.org/ws/2004/10/wsat/d
efault.htm
• Web services whitepapers, specs,
workshops
– http://msdn.microsoft.com/webservices/
– http://www-
128.ibm.com/developerworks/webservices/libra
ry/specification/ws-tx/
– http://www.arjuna.com/library/
16
State tables (per
participant)
Atomic Transaction 2PC protocol
(Coordinator View)
States
Inbound
Events
None Active Preparing Prepared PreparedSuccess Committing Aborting
Durable: Invalid State
Aborting
Invalid State Send RegisterResponse Invalid State Invalid State Invalid State
Register Volatile: Send Register N/A
None Active PreparedSuccess Committing Aborting
Response
Active
Durable: Send
Rollback Resend Rollback,
Invalid State Record Vote Ignore Resend Commit
Prepared Volatile: Invalid N/A and forget
Aborting Preparing PreparedSuccess Committing
State Aborting
None
Ignore Forget Forget Invalid State Invalid State Forget
ReadOnly N/A
None Active Preparing PreparedSuccess Committing Aborting
Ignore Forget Forget Invalid State Invalid State Forget
Aborted N/A
None Aborting Aborting PreparedSuccess Committing Aborting
Ignore Invalid State Invalid State Invalid State Forget Invalid State
Committed N/A
None Aborting Aborting PreparedSuccess Committing Aborting
Durable: Send
Rollback
Send Rollback Send Rollback Ignore Send Commit Send Rollback
Replay Volatile: Invalid N/A
Aborting Aborting PreparedSuccess Committing Aborting
State
None
17
State tables
Atomic Transaction 2PC protocol
(Participant View)
States
Inbound
Events
None Active Preparing Prepared PreparedSuccess Committing Aborting
Register
Register Invalid State Invalid State Invalid State Invalid State Invalid State Invalid State
Subordinate
Response Active Aborting Prepared PreparedSuccess Committing Aborting
Active
Gather Vote
Send Aborted Ignore Ignore Resend Prepared Ignore Resend Aborted, and forget
Prepare Decision
None Preparing Prepared PreparedSuccess Committing Aborting
Preparing
Send Committed Invalid State Invalid State Invalid State Initiate commit decision Ignore InconsistentInternalState
Commit
None Aborting Aborting Aborting Committing Committing Aborting
Initiate Rollback, Initiate Rollback, Initiate Rollback,
Initiate Rollback,
Send Aborted Send Aborted, Send Aborted, and Send Aborted, and InconsistentInternalState Send Aborted, and Forget
Rollback Send Aborted, and Forget
None and Forget Forget Forget Committing Aborting
Aborting
Aborting Aborting Aborting
18
Workshops
• March 2004 for feedback workshop
• January 2005 for interoperability workshop
– http://msdn.microsoft.com/webservices/comm
unity/workshops/transactionsinterop1204.asp
x
• Several public endpoints, including …
– http://wsi.alphaworks.ibm.com:8080/wstx/servi
ces/InteropService
– http://mssoapinterop.org/ws/
19
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
General flow
Implementation A Implementation B
CoordinatorProtocolService ParticipantProtocolService
InitiatorApp (IA) ParticipantApp (PA)
(CS) (PS)
tns:Request()
wscoor:RegisterRequest()
wscoor:RegisterResponse()
tns:Response()
wsat:Protocol()
21
Interoperability results
22
