The current set of Web service specifications [WSDL][SOAP11][SOAP12]
defines protocols for Web service interoperability. Web services increasingly
tie together a number of participants forming large distributed applications.
The resulting activities may have complex structure and relationships.
WS-Coordination [WSCOOR] defines an
extensible framework for defining coordination types. This specification
provides the definition of an Atomic Transaction coordination type used to
coordinate activities having an "all or nothing" property. Atomic
transactions commonly require a high level of trust between participants and
are short in duration. WS-AtomicTransaction defines protocols that enable
existing transaction processing systems to wrap their proprietary protocols and
interoperate across different hardware and software vendors.
To understand the protocol described in this specification,
the following assumptions are made:
The reader is familiar with existing standards for two-phase
commit protocols and with commercially available implementations of such
protocols. Therefore this section includes only those details that are
essential to understanding the protocols described.
The reader is familiar with WS-Coordination [WSCOOR] which defines the framework for the Atomic Transaction
coordination protocols.
The reader is familiar with WS-Addressing [WSADDR]
and WS-Policy [WSPOLICY].
Atomic transactions have an all-or-nothing property. The
actions taken by a transaction participant prior to commit are only tentative;
typically they are neither persistent nor made visible outside the transaction.
When an application finishes working on a transaction, it requests the
coordinator to determine the outcome for the transaction. The coordinator
determines if there were any processing failures by asking the participants to
vote. If the participants all vote that they were able to execute successfully,
the coordinator commits all actions taken. If a participant votes that it needs
to abort or a participant does not respond at all, the coordinator aborts all
actions taken. Commit directs the participants to make the tentative actions
final so they may, for example, be made persistent and be made visible outside
the transaction. Abort directs the participants to make the tentative actions
appear as if they never happened. Atomic transactions have proven to be
extremely valuable for many applications. They provide consistent failure and
recovery semantics, so the applications no longer need to deal with the
mechanics of determining a mutually agreed outcome decision or to figure out
how to recover from a large number of possible inconsistent states.
This specification defines protocols that govern the outcome
of Atomic Transactions. It is expected that existing transaction processing
systems will use WS-AtomicTransaction to wrap their proprietary mechanisms and
interoperate across different vendor implementations.
By using the XML [XML], SOAP [SOAP11] [SOAP12] and WSDL [WSDL] extensibility model, SOAP-based and WSDL-based
specifications are designed to work together to define a rich Web services
environment. As such, WS-AtomicTransaction by itself does not define all
features required for a complete solution. WS-AtomicTransaction is a building
block used with other specifications of Web services (e.g., WS-Coordination [WSCOOR], WS-Security [WSSec]) and
application-specific protocols that are able to accommodate a wide variety of
coordination protocols related to the coordination actions of distributed
applications.
The uppercase key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
this document are to be interpreted as described in RFC2119 [RFC2119].
This specification
uses an informal syntax to describe the XML grammar of the XML fragments below:
·
The syntax appears
as an XML instance, but the values indicate the data types instead of values.
·
Element names
ending in "..." (such as <element.../> or <element...>)
indicate that elements/attributes irrelevant to the context are being omitted.
·
Attributed names
ending in "..." (such as name=...) indicate that the values are
specified below.
·
Grammar in bold
has not been introduced earlier in the document, or is of particular interest
in an example.
·
<!--
description --> is a placeholder for elements from some "other"
namespace (like ##other in XSD).
·
Characters are
appended to elements, attributes, and <!-- descriptions --> as follows:
"?" (0 or 1), "*" (0 or more), "+" (1 or more).
The characters "[" and "]" are used to indicate that
contained items are to be treated as a group with respect to the "?",
"*", or "+" characters.
·
The XML namespace
prefixes (defined below) are used to indicate the namespace of the element
being defined.
·
Examples starting
with <?xml contain enough information to conform to this specification;
others examples are fragments and require additional information to be
specified in order to conform.
1.3 Namespace
The XML namespace [XML-ns] URI that MUST
be used by implementations of this specification is:
http://docs.oasis-open.org/ws-tx/wsat/2006/06
This MUST also be used as the CoordinationContext type for Atomic
Transactions.
The following namespaces are used in this document:
Dereferencing the XML namespace
defined in section 1.3 will produce the Resource Directory Description
Language (RDDL) [RDDL] document that describes this
namespace, including the XML schema [XML-Schema1] [XML-Schema2] and WSDL [WSDL]
declarations associated with this specification.
SOAP bindings for the WSDL [WSDL],
referenced in the RDDL [RDDL] document, MUST use
"document" for the style attribute.
There should be no inconsistencies found between any of the
normative text within this specification, the normative outlines, the XML
Schema definitions, and the WSDL descriptions, and so no general precedence
rule is defined. If an inconsistency is observed then it should be reported as
a comment on the specification as described in the "Status" section
above.
The protocol elements define various extensibility points
that allow other child or attribute content. Additional children and/or
attributes MAY be added at the indicated extension points but MUST NOT
contradict the semantics of the parent and/or owner, respectively. If a
receiver does not recognize an extension, the receiver SHOULD ignore the
extension.
An
implementation is not conformant with this specification if it fails to satisfy
one or more of the MUST or REQUIRED level requirements defined herein. A SOAP
Node MUST NOT use elements and attributes of the declared XML Namespace (listed
on the title page) for this specification within SOAP Envelopes unless it is
conformant with this specification.
[RDDL] Jonathan
Borden, Tim Bray, eds. “Resource Directory Description Language (RDDL) 2.0”, http://www.openhealth.org/RDDL/20040118/rddl-20040118.html,
January 2004
[RFC2119] S. Bradner, "Key words for use in
RFCs to Indicate Requirement Levels", http://www.ietf.org/rfc/rfc2119.txt,
IETF RFC2119, March 1997
[SOAP11] W3C Note, "SOAP: Simple Object Access Protocol 1.1", http://www.w3.org/TR/2000/NOTE-SOAP-20000508, 08 May 2000
[SOAP12] W3C Recommendation, "SOAP Version
1.2 Part 1: Messaging Framework (Second Edition)", http://www.w3.org/TR/2007/REC-soap12-part1-20070427/,
April 2007.
[WSADDR] Web Services Addressing
(WS-Addressing) 1.0, http://www.w3.org/2005/08/addressing,
W3C Recommendation, May 2006
[WSCOOR] OASIS
Public Review Draft, Web
Services Coordination (WS-Coordination) 1.2, http://docs.oasis-open.org/ws-tx/wscoor/2006/06,
August 2008
[WSDL] Web Services Description Language
(WSDL) 1.1, http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[WSPOLICY] W3C Recommendation, Web Services
Policy 1.5 – Framework (WS-Policy), http://www.w3.org/TR/2007/REC-ws-policy-20070904/,
September 2007.
[WSPOLICYATTACH] W3C Recommendation, Web Services
Policy 1.5 – Attachment (WS-PolicyAttachment), http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/,
September 2007.
[WSSec] OASIS Standard, March 2004, Web Services
Security: SOAP Message Security 1.0 (WS-Security 2004) , http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.
OASIS Standard, February 2006, Web Services Security: SOAP Message Security 1.1
(WS-Security 2004), http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf.
[WSSecConv] OASIS Committee Draft
01, WS-SecureConversation
1.4, http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512,
July 2008.
[WSSecPolicy] OASIS
Committee Draft 01, WS-SecurityPolicy 1.3, http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802,
July 2008.
[WSTrust]
OASIS Committee Draft 01, WS-Trust 1.4, http://docs.oasis-open.org/ws-sx/ws-trust/200802,
June 2008.
[XML] W3C Recommendation, “Extensible Markup Language
(XML) 1.0 (Fourth Edition)”, http://www.w3.org/TR/2006/REC-xml-20060816,
16 August 2006
[XML-ns] W3C Recommendation, "Namespaces
in XML (Second Edition)", http://www.w3.org/TR/2006/REC-xml-names-20060816,
16 August 2006
[XML-Schema1]
W3C
Recommendation, " XML Schema Part 1: Structures Second Edition", http://www.w3.org/TR/2004/REC-xmlschema-1-20041028,
28 October 2004
[XML-Schema2]
W3C
Recommendation, " XML Schema Part 2: Datatypes Second Edition", http://www.w3.org/TR/2004/REC-xmlschema-2-20041028,
28 October 2004
WS-AtomicTransaction builds on WS-Coordination [WSCOOR], which defines an Activation service, a Registration
service, and a CoordinationContext type. Example message flows and a complete
description of creating and registering for coordinated activities is found in
WS-Coordination [WSCOOR].
The Atomic Transaction coordination context is a
CoordinationContext type with the coordination type defined in this section.
Atomic Transaction application messages that propagate a coordination context
MUST use an Atomic Transaction coordination context. If these application
messages use a SOAP binding, the Atomic Transaction coordination context MUST
flow as a SOAP header in the message.
WS-AtomicTransaction adds the following semantics to the
CreateCoordinationContext operation on the Activation service:
If the request includes the CurrentContext element, the target
coordinator is interposed as a subordinate to the coordinator stipulated inside
the CurrentContext element.
If the request does not include a CurrentContext element,
the target coordinator creates a new transaction and acts as the root.
A coordination context MAY have an Expires element. This
element specifies the period, measured from the point in time at which the
context was first created or received, after which a transaction MAY be
terminated solely due to its length of operation. From that point forward, the
coordinator MAY elect to unilaterally roll back the transaction, so long as it
has not made a commit decision. Similarly a 2PC participant MAY elect to abort
its work in the transaction so long as it has not already decided to prepare.
The Atomic Transaction protocol is identified by the
following coordination type:
http://docs.oasis-open.org/ws-tx/wsat/2006/06
This specification defines the following protocols for Atomic
Transactions:
Completion:
The completion protocol initiates commit processing. Based on each protocol's
registered participants, the coordinator begins with Volatile 2PC and then
proceeds through Durable 2PC. The final result is signaled to the initiator.
Two-Phase Commit (2PC): The
2PC protocol coordinates registered participants to reach a commit or abort
decision, and ensures that all participants are informed of the final result. The
2PC protocol has two variants:
Volatile 2PC: Participants
managing volatile resources such as a cache register for this protocol.
Durable 2PC: Participants
managing durable resources such as a database register for this protocol.
A participant MAY register for more than one of these
protocols.
The correct operation of the protocols requires that a
number of preconditions must be established prior to the processing:
The source SHOULD have knowledge of the destination's
policies, if any, and the source SHOULD be capable of formulating messages that
adhere to this policy.
If a secure exchange of messages is required, then the
source and destination MUST have appropriate security credentials (such as
transport-level security credentials or security tokens) in order to protect
the messages.
The Completion protocol is used by an application to tell
the coordinator to either try to commit or abort an Atomic Transaction. After
the transaction has completed, a status is returned to the application.
An initiator that registers for this protocol MUST use the
following protocol identifier:
http://docs.oasis-open.org/ws-tx/wsat/2006/06/Completion
A Completion
protocol coordinator MUST be the root coordinator of an Atomic Transaction. The
Registration service for a subordinate coordinator MUST respond to an attempt
to register for this coordination protocol with the WS-Coordination fault
Cannot Register Participant.
The diagram below illustrates the protocol abstractly. Refer
to section 9 State Tables for a detailed description of this protocol.
The coordinator accepts:
Commit
Upon receipt of this notification, the coordinator knows
that the initiator has completed application processing. A coordinator that is
Active SHOULD attempt to commit the transaction.
Rollback
Upon receipt of this notification, the coordinator knows
that the initiator has terminated application processing. A coordinator that is
Active MUST abort the transaction.
The initiator accepts:
Committed
Upon receipt of this notification, the initiator knows that
the coordinator reached a decision to commit.
Aborted
Upon receipt of this notification, the initiator knows that
the coordinator reached a decision to abort.
A coordination service that supports an Activation service
MUST support the Completion protocol.
The Two-Phase Commit (2PC) protocol is a Coordination
protocol that defines how multiple participants reach agreement on the outcome
of an Atomic Transaction. The 2PC protocol has two variants: Volatile 2PC and Durable
2PC.
Upon receiving a Commit notification in the Completion
protocol, the root coordinator begins the prepare phase of all participants
registered for the Volatile 2PC protocol. All participants registered for this
protocol MUST respond before a Prepare is issued to a participant registered
for Durable 2PC. Further participants MAY register with the coordinator until
the coordinator issues a Prepare to any durable participant. Once this has
happened the Registration Service for the coordinator MUST respond to any
further Register requests with a Cannot Register Participant fault message. A
volatile recipient is not guaranteed to receive a notification of the
transaction's outcome.
Participants that register for this protocol MUST use the
following protocol identifier:
http://docs.oasis-open.org/ws-tx/wsat/2006/06/Volatile2PC
Upon successfully completing the prepare phase for Volatile
2PC participants, the root coordinator begins the prepare phase for Durable 2PC
participants. All participants registered for this protocol MUST respond
Prepared or ReadOnly before a Commit notification is issued to a participant
registered for either protocol.
Participants that register for this protocol MUST use the
following protocol identifier:
http://docs.oasis-open.org/ws-tx/wsat/2006/06/Durable2PC
The diagram below
illustrates the protocol abstractly. Refer to section 9 State Tables for a
detailed description of this protocol.
The participant accepts:
Prepare
Upon receipt of this notification, the participant knows to
enter phase one and vote on the outcome of the transaction. A participant that
is Active MUST respond by sending Aborted, Prepared, or ReadOnly notification
as its vote. If the participant does not know of the transaction, it MUST send
an Aborted notification. If the participant knows that it has already voted, it
MUST resend the same vote.
Rollback
Upon receipt of this notification, the participant knows to
abort and forget the transaction. A participant that is not Committing MUST
respond by sending an Aborted notification and SHOULD then forget all knowledge
of this transaction. If the participant does not know of the transaction, it
MUST send an Aborted notification to the coordinator.
Commit
Upon receipt of this notification, the participant knows to
commit the transaction. This notification MUST only be sent after phase one and
if the participant voted to commit. If the participant does not know of the
transaction, it MUST send a Committed notification to the coordinator.
The coordinator accepts:
Prepared
Upon receipt of this notification, the coordinator knows
the participant is Prepared and votes to commit the transaction.
ReadOnly
Upon receipt of this notification, the coordinator knows
the participant votes to commit the transaction, and has forgotten the
transaction. The participant does not wish to participate in phase two.
Aborted
Upon receipt of this notification, the coordinator knows
the participant has aborted and forgotten the transaction.
Committed
Upon receipt of this notification, the coordinator knows
the participant has committed and forgotten the transaction.
Conforming implementations MUST implement the 2PC protocol.
WS-Policy Framework [WSPOLICY] and
WS-Policy Attachment [WSPOLICYATTACH]
collectively define a framework, model and grammar for expressing the
capabilities, requirements, and general characteristics of entities in an XML
Web services-based system. To enable a Web service to describe transactional
capabilities and requirements of a service and its operations, this
specification defines an Atomic Transaction policy assertion that leverages the
WS-Policy [WSPOLICY] framework.
The Atomic Transaction policy assertion is provided by a Web
service to qualify the transactional processing of messages associated with the
particular operation to which the assertion is scoped. It indicates whether a
requester MAY or MUST include an Atomic Transaction coordination context flowed
with the message.
The normative outline for the Atomic Transaction policy
assertion is:
<wsat:ATAssertion
[wsp:Optional="true"]? ... >
...
</wsat:ATAssertion>
The following describes additional, normative constraints on
the outline listed above:
/wsat:ATAssertion
A policy assertion that specifies that an Atomic Transaction
coordination context MUST be flowed inside a requester’s message. From the
perspective of the requester, the target service that processes the transaction
MUST behave as if it had participated in the transaction. For application
messages that use a SOAP binding, the Atomic Transaction coordination context MUST
flow as a SOAP header in the message.
/wsat:ATAssertion/@wsp:Optional="true"
Per WS-Policy [WSPOLICY], this is
compact notation for two policy alternatives, one with and one without the
assertion.
The Atomic Transaction policy assertion MUST NOT include a
wsp:Ignorable attribute with a value of “true”.
Because the Atomic Transaction policy assertion indicates Atomic
Transaction behavior for a single operation, the assertion has an Operation
Policy Subject [WSPOLICYATTACH].
WS-PolicyAttachment defines two WSDL [WSDL]
policy attachment points with an Operation Policy Subject:
wsdl:portType/wsdl:operation – A policy expression
containing the Atomic Transaction policy assertion MUST NOT be attached to a
wsdl:portType; the Atomic Transaction policy assertion specifies a concrete
behavior whereas the wsdl:portType is an abstract construct.
wsdl:binding/wsdl:operation – A policy expression containing
the Atomic Transaction policy assertion SHOULD be attached to a wsdl:binding.
An example use of the Atomic Transaction policy assertion
follows:
(01) <wsdl:definitions
(02) targetNamespace="bank.example.com"
(03) xmlns:tns="bank.example.com"
(04) xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
(05) xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
(06) xmlns:wsat="http://docs.oasis-open.org/ws-tx/wsat/2006/06"
(07) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>
(08) <wsp:Policy
wsu:Id="TransactedPolicy" >
(09) <wsat:ATAssertion
wsp:optional="true" />
(10) <!--
omitted assertions -->
(11) </wsp:Policy>
(12) <!--
omitted elements -->
(13) <wsdl:binding
name="BankBinding" type="tns:BankPortType" >
(14) <!--
omitted elements -->
(15) <wsdl:operation
name="TransferFunds" >
(16) <wsp:PolicyReference
URI="#TransactedPolicy" wsdl:required="true" />
(17) <!--
omitted elements -->
(18) </wsdl:operation>
(19) </wsdl:binding>
(20) </wsdl:definitions>
Lines 8-11 are a policy expression that includes an Atomic Transaction
policy assertion (line 9) to indicate that an Atomic Transaction in
WS-Coordination [WSCOOR] format MAY be used.
Lines 13-19 are a WSDL [WSDL] binding.
Line 16 indicates that the policy in lines 8-11 applies to this binding,
specifically indicating that an Atomic Transaction MAY flow inside messages.
Atomic Transaction faults MUST include, as the [action]
property, the following fault action URI:
http://docs.oasis-open.org/ws-tx/wsat/2006/06/fault
The protocol faults defined in this section are generated if
the condition stated in the preamble is met. These faults are targeted at a
destination endpoint according to the protocol fault handling rules defined for
that protocol.
The definitions of faults in this section use the following
properties:
[Code] The fault code.
[Subcode] The fault subcode.
[Reason] A human readable explanation of the fault.
[Detail] The detail element. If absent, no detail element is
defined for the fault.
For SOAP 1.2, the [Code] property MUST be either
"Sender" or "Receiver". These properties are serialized
into text XML as follows:
|
SOAP Version
|
Sender
|
Receiver
|
|
SOAP 1.2
|
S12:Sender
|
S12:Receiver
|
The properties above bind to a SOAP 1.2 fault as follows:
<S12:Envelope>
<S12:Header>
<wsa:Action>
http://docs.oasis-open.org/ws-tx/wsat/2006/06/fault
</wsa:Action>
<!-- Headers elided for clarity. -->
</S12:Header>
<S12:Body>
<S12:Fault>
<S12:Code>
<S12:Value>[Code]</S12:Value>
<S12:Subcode>
<S12:Value>[Subcode]</S12:Value>
</S12:Subcode>
</S12:Code>
<S12:Reason>
<S12:Text xml:lang="en">[Reason]</S12:Text>
</S12:Reason>
<S12:Detail>
[Detail]
...
</S12:Detail>
</S12:Fault>
</S12:Body>
</S12:Envelope>
The properties bind to a SOAP 1.1 fault as follows:
<S11:Envelope>
<S11:Body>
<S11:Fault>
<faultcode>[Subcode]</faultcode>
<faultstring xml:lang="en">[Reason]</faultstring>
</S11:Fault>
</S11:Body>
</S11:Envelope>
This fault is sent by a participant or coordinator to
indicate that a protocol violation has been detected after it is no longer
possible to change the outcome of the transaction. This is indicative of a
global consistency failure and is an unrecoverable condition.
Properties:
[Code] Sender
[Subcode] wsat:InconsistentInternalState
[Reason] A global consistency failure has occurred. This is
an unrecoverable condition.
[Detail] Unspecified
This fault is sent by a coordinator to indicate that it has
no knowledge of the transaction and consequently cannot convey the outcome.
Properties:
[Code] Sender
[Subcode] wsat:UnknownTransaction
[Reason] The coordinator has no knowledge of the
transaction. This is an unrecoverable condition.
[Detail] Unspecified
The security model for Atomic Transactions builds on the
model defined in WS-Coordination [WSCOOR]. That is,
services have policies specifying their requirements and requestors provide
claims (either implicit or explicit) and the requisite proof of those claims. Coordination
context creation establishes a base secret which can be delegated by the
creator as appropriate.
Because Atomic Transactions represent a specific use case
rather than the general nature of coordination contexts, additional aspects of
the security model can be specified.
All access to Atomic Transaction protocol instances is on
the basis of identity. The nature of transactions, specifically the uncertainty
of systems means that the security context established to register for the
protocol instance may not be available for the entire duration of the protocol.
Consider, for example, the scenarios where a participant has
committed its part of the transaction, but for some reason the coordinator
never receives acknowledgement of the commit. The result is that when
communication is re-established in the future, the coordinator will attempt to
confirm the commit status of the participant, but the participant, having
committed the transaction and forgotten all information associated with it, no
longer has access to the special keys associated with the token.
The participant can only prove its identity to the
coordinator when it indicates that the specified transaction is not in its log
and assumed committed. This is illustrated in the figure below:
There are, of course, techniques to mitigate this situation
but such options will not always be successful. Consequently, when dealing with
Atomic Transactions, it is critical that identity claims always be proven to
ensure that correct access control is maintained by coordinators.
There is still value in coordination context-specific tokens
because they offer a bootstrap mechanism so that all participants need not be
pre-authorized. As well, it provides additional security because only those
instances of an identity with access to the token will be able to securely
interact with the coordinator (limiting privileges strategy). This is
illustrated in the figure below:
The "list" of authorized participants ensures that
application messages having a coordination context are properly authorized
since altering the coordination context ID will not provide additional access
unless (1) the bootstrap key is provided, or (2) the requestor is on the
authorized participant "list" of identities.
It is strongly RECOMMENDED that the communication between
services be secured using the mechanisms described in WS-Security [WSSec]. In order to properly secure messages, the body and
all relevant headers need to be included in the signature. Specifically, the <wscoor:CoordinationContext> header needs to be
signed with the body and other key message headers in order to "bind"
the two together.
In the event that a participant communicates frequently with
a coordinator, it is RECOMMENDED that a security context be established using
the mechanisms described in WS-Trust [WSTrust] and
WS-SecureConversation [WSSecConv] allowing for
potentially more efficient means of authentication.
It is common for communication with coordinators to exchange
multiple messages. As a result, the usage profile is such that it is
susceptible to key attacks. For this reason it is strongly RECOMMENDED that the
keys be changed frequently. This "re-keying" can be effected a number
of ways. The following list outlines four common techniques:
Attaching a nonce to each message and using it in a derived
key function with the shared secret
Using a derived key sequence and switch
"generations"
Closing and re-establishing a security context (not possible
for delegated keys)
Exchanging new secrets between the parties (not possible for
delegated keys)
It should be noted that the mechanisms listed above are
independent of the Security Context Token (SCT) and secret returned when the
coordination context is created. That is, the keys used to secure the channel
may be independent of the key used to prove the right to register with the
activity.
The security context MAY be re-established using the
mechanisms described in WS-Trust [WSTrust] and
WS-SecureConversation [WSSecConv]. Similarly, secrets MAY
be exchanged using the mechanisms described in WS-Trust [WSTrust].
Note, however, that the current shared secret SHOULD NOT be used to encrypt the
new shared secret. Derived keys, the preferred solution from this list, MAY be
specified using the mechanisms described in WS-SecureConversation [WSSecConv].
The following list summarizes common classes of attacks that
apply to this protocol and identifies the mechanism to prevent/mitigate the
attacks:
Message alteration – Alteration is
prevented by including signatures of the message information using WS-Security
[WSSec].
Message disclosure – Confidentiality
is preserved by encrypting sensitive data using WS-Security [WSSec].
Key integrity – Key integrity is
maintained by using the strongest algorithms possible (by comparing secured
policies – see WS-Policy [WSPOLICY] and
WS-SecurityPolicy [WSSecPolicy]).
Authentication – Authentication is
established using the mechanisms described in WS-Security and WS-Trust [WSTrust]. Each message is authenticated using the
mechanisms described in WS-Security [WSSec].
Accountability – Accountability is a
function of the type of and string of the key and algorithms being used. In
many cases, a strong symmetric key provides sufficient accountability. However,
in some environments, strong PKI signatures are required.
Availability – Many services are
subject to a variety of availability attacks. Replay is a common attack and it
is RECOMMENDED that this be addressed as described in the next bullet. Other
attacks, such as network-level denial of service attacks are harder to avoid
and are outside the scope of this specification. That said, care should be
taken to ensure that minimal processing be performed prior to any
authenticating sequences.
Replay – Messages may be replayed
for a variety of reasons. To detect and eliminate this attack, mechanisms
should be used to identify replayed messages such as the timestamp/nonce
outlined in WS-Security [WSSec]. Alternatively, and
optionally, other technologies, such as sequencing, can also be used to prevent
replay of application messages.
The protocols defined in WS-AtomicTransaction use a
"one way" message exchange pattern consisting of a sequence of
notification messages between a Coordinator and a Participant. There are
two types of notification messages used in these protocols:
A
notification message is a terminal message when it indicates the end of a
coordinator/participant relationship. Committed, Aborted and ReadOnly
are terminal messages, as are the protocol faults defined in this specification
and in WS-Coordination [WSCOOR].
A
notification message is a non-terminal message when it does not indicate the
end of a coordinator/participant relationship. Commit, Rollback,
Prepare and Prepared are
non-terminal messages.
The following statements define addressing interoperability
requirements for the Atomic Transaction message types:
Non-terminal notification messages:
·
MUST
include a [source endpoint] property whose [address] property is not set to
‘http://www.w3.org/2005/08/addressing/anonymous’ or 'http://www.w3.org/2005/08/addressing/none’.
Both terminal and non-terminal notification messages:
·
MUST include a
[reply endpoint] property whose [address] property is set to
'http://www.w3.org/2005/08/addressing/none’.
Notification messages used in WS-AtomicTransaction protocols
MUST include as the [action] property an action URI that consists of the wsat
namespace URI concatenated with the "/" character and the element
name of the message. For example:
http://docs.oasis-open.org/ws-tx/wsat/2006/06/Commit
Notification messages are normally addressed according to
section 3.3 of WS-Addressing 1.0 – Core [WSADDR] by both coordinators
and participants using the Endpoint References initially obtained during the
Register-RegisterResponse exchange. If a [source endpoint] property is present in a notification message,
it MAY be used by the recipient. Cases exist where a Coordinator or Participant
has forgotten a transaction that is completed and needs to respond to a resent
protocol message. In such cases, the [source endpoint] property SHOULD be used
as described in section 3.3 of WS-Addressing 1.0 – Core [WSADDR].
Permanent loss of connectivity between a coordinator and a participant in an
in-doubt state can result in data corruption.
Protocol
faults raised by a Coordinator or Participant during the processing of a
notification message are terminal notifications and MUST be composed using the
same mechanisms as other terminal notification messages.
All messages are delivered using connections initiated by
the sender.
The following state tables specify the behavior of
coordinators and participants when presented with protocol messages or internal
events.
Each cell in the tables uses the following convention:
|
Legend
|
|
Action to take
Next state
|
Each state supports a number
of possible events. Expected events are processed by taking the prescribed
action and transitioning to the next state. Unexpected protocol messages MUST
result in a fault message as defined in the state tables. These faults use
standard fault codes as defined in either WS-Coordination [WSCOOR]
or in section 5 Transaction Faults. Events that may not occur in a given state
are labeled as N/A.
Notes:
Transitions with a “N/A” as their action are inexpressible. A
TM should view these transitions as serious internal consistency issues that
are likely fatal conditions.
The "Internal events" shown are those events,
created either within a TM itself or on its local system, that cause state
changes and/or trigger the sending of a protocol message.
|
Completion Protocol
(Coordinator View)
|
|
Inbound Events
|
States
|
|
None
|
Active
|
Completing
|
|
Commit
|
Unknown Transaction
None
|
Initiate user commit
Completing
|
Ignore
Completing
|
|
Rollback
|
Unknown Transaction
None
|
Initiate user rollback, send aborted
None
|
Invalid State
Completing
|
|
Internal Events
|
|
|
Commit Decision
|
N/A
|
N/A
|
Send committed
None
|
|
Abort Decision
|
N/A
|
Send aborted
None
|
Send aborted
None
|
These tables present the view of a coordinator or
participant with respect to a single partner. A coordinator with multiple
participants can be understood as a collection of independent coordinator state
machines, each with its own state.
|
Atomic Transaction 2PC Protocol
(Coordinator View)
|
|
Inbound Events
|
States
|
|
None
|
Active
|
Preparing
|
Prepared
|
PreparedSuccess
|
Committing
|
Aborting
|
|
Prepared
|
Durable: Send Rollback
Volatile: Unknown Transaction
None
|
Invalid State
Aborting
|
Record Vote
Prepared
|
Ignore
Prepared
|
Ignore
PreparedSuccess
|
Resend Commit
Committing
|
Resend Rollback
Aborting
|
|
ReadOnly
|
Ignore
None
|
Forget
None
|
Forget
None
|
Inconsistent Internal State
Prepared
|
Inconsistent Internal State
PreparedSuccess
|
Inconsistent Internal State
Committing
|
Forget
None
|
|
Aborted
|
Ignore
None
|
Forget
None
|
Forget
None
|
Inconsistent Internal State
Prepared
|
Inconsistent Internal State
PreparedSuccess
|
Inconsistent Internal State
Committing
|
Forget
None
|
|
Committed
|
Ignore
None
|
Invalid State
Aborting
|
Invalid State
Aborting
|
Inconsistent Internal State
Prepared
|
Inconsistent Internal State
PreparedSuccess
|
Forget
None
|
Inconsistent Internal State
Aborting
|
|
Internal Events
|
|
|
User Commit
|
N/A
|
Send Prepare
Preparing
|
N/A
|
N/A
|
N/A
|
N/A
|
N/A
|
|
User Rollback
|
N/A
|
Send Rollback
Aborting
|
N/A
|
N/A
|
N/A
|
N/A
|
N/A
|
|
Expires Times Out
|
N/A
|
Send Rollback
Aborting
|
Send Rollback
Aborting
|
Send Rollback
Aborting
|
Ignore
PreparedSuccess
|
Ignore
Committing
|
Ignore
Aborting
|
|
Comms Times Out
|
N/A
|
N/A
|
Resend Prepare
Preparing
|
N/A
|
N/A
|
Resend Commit
Committing
|
N/A
|
|
Commit Decision
|
N/A
|
N/A
|
N/A
|
Record Outcome
PreparedSuccess
|
N/A
|
N/A
|
N/A
|
|
Rollback Decision
|
N/A
|
Send Rollback
Aborting
|
Send Rollback
Aborting
|
Send Rollback
Aborting
|
N/A
|
N/A
|
N/A
|
|
Write Done
|
N/A
|
N/A
|
N/A
|
N/A
|
Send Commit
Committing
|
N/A
|
N/A
|
|
Write Failed
|
N/A
|
N/A
|
N/A
|
N/A
|
Send Rollback
Aborting
|
N/A
|
N/A
|
|
Participant Abandoned
|
N/A
|
N/A
|
N/A
|
N/A
|
N/A
|
Durable: N/A
Volatile: None
|
None
|
“Forget” implies that the subordinate’s participation is
removed from the coordinator (if necessary), and otherwise the message is
ignored
|
Atomic Transaction 2PC Protocol
(Participant View)
|
|
Inbound Events
|
States
|
|
None
|
Active
|
Preparing
|
Prepared
|
PreparedSuccess
|
Committing
|
|
Prepare
|
Send Aborted
None
|
Gather Vote Decision
Preparing
|
Ignore
Preparing
|
Ignore
Prepared
|
Resend Prepared
PreparedSuccess
|
Ignore
Committing
|
|
Commit
|
Send Committed
None
|
Invalid State
None
|
Invalid State
None
|
Invalid State
None
|
Initiate Commit Decision
Committing
|
Ignore
Committing
|
|
Rollback
|
Send Aborted
None
|
Initiate Rollback and Send Aborted
None
|
Initiate Rollback and Send Aborted
None
|
Initiate Rollback and Send Aborted
None
|
Initiate Rollback and Send Aborted
None
|
Inconsistent Internal State
Committing
|
|
Internal Events
|
|
|
Expires Times Out
|
N/A
|
Initiate Rollback and Send Aborted
None
|
Initiate Rollback and Send Aborted
None
|
Ignore
Prepared
|
Ignore
PreparedSuccess
|
Ignore
Committing
|
|
Comms Times Out
|
N/A
|
N/A
|
N/A
|
N/A
|
Resend Prepared
PreparedSuccess
|
N/A
|
|
Commit Decision
|
N/A
|
N/A
|
Record Commit
Prepared
|
N/A
|
N/A
|
Send Committed
None
|
|
Rollback Decision
|
N/A
|
Send Aborted
None
|
Send Aborted
None
|
N/A
|
N/A
|
N/A
|
|
Write Done
|
N/A
|
N/A
|
N/A
|
Send Prepared
PreparedSuccess
|
N/A
|
N/A
|
|
Write Failed
|
N/A
|
N/A
|
N/A
|
Initiate Rollback and Send Aborted
None
|
N/A
|
N/A
|
|
ReadOnly Decision
|
N/A
|
Send ReadOnly
None
|
Send ReadOnly
None
|
N/A
|
N/A
|
N/A
|
This document is based on initial contributions to the OASIS
WS-TX Technical Committee by the following authors: Luis Felipe Cabrera (Microsoft),
George Copeland (Microsoft), Max Feingold (Microsoft), Robert W Freund (Hitachi),
Tom Freund (IBM), Jim Johnson (Microsoft), Sean Joyce (IONA), Chris Kaler
(Microsoft), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark
Little (Arjuna Technologies), Frank Leymann (IBM), Eric Newcomer (IONA), David
Orchard (BEA Systems), Ian Robinson (IBM), Tony Storey (IBM), Satish Thatte (Microsoft).
The following individuals have provided invaluable input
into the initial contribution: Francisco Curbera (IBM), Doug Davis (IBM), Gert
Drapers (Microsoft), Don Ferguson (IBM), Kirill Gavrylyuk (Microsoft), Dan
House (IBM), Oisin Hurley (IONA), Thomas Mikalsen (IBM), Jagan Peri (Microsoft),
John Shewchuk (Microsoft), Stefan Tai (IBM).
The following individuals were members of the committee
during the development of this specification:
Participants:
Charlton Barreto, Adobe Systems, Inc.
Martin Chapman, Oracle
Kevin Conner, JBoss Inc.
Paul Cotton, Microsoft Corporation
Doug Davis, IBM
Colleen Evans, Microsoft Corporation
Max Feingold, Microsoft Corporation
Thomas Freund, IBM
Robert Freund, Hitachi, Ltd.
Peter Furniss, Choreology Ltd.
Marc Goodner, Microsoft Corporation
Alastair Green, Choreology Ltd.
Daniel House, IBM
Ram Jeyaraman, Microsoft Corporation
Paul Knight, Nortel Networks Limited
Mark Little, JBoss Inc.
Jonathan Marsh, Microsoft Corporation
Monica Martin, Sun Microsystems
Joseph Fialli, Sun Microsystems
Eric Newcomer, IONA Technologies
Eisaku Nishiyama, Hitachi, Ltd.
Alain Regnier, Ricoh Company, Ltd.
Ian Robinson, IBM
Tom Rutt, Fujitsu Limited
Andrew Wilkinson, IBM
