skip to content

Under WS-AtomicTransaction, a partner wants your SOAP order service enlisted in its transactions — what would agreeing commit you to, and would you agree?

level: principalimportance: nice to knowfreq 4%

answer

  1. a context that must be understood
  2. register first, vote when asked
  3. Prepared, ReadOnly or Aborted
  4. the spec assumes trust and short duration

basics

~20 s

Agreeing means accepting a WS-Coordination context header, registering for Durable2PC with the partner's coordinator, and holding tentative work until it sends Commit or Rollback. The specification assumes high trust and short transactions, so across organisations it rarely fits.

solid answer

~40 s

WS-AtomicTransaction is a coordination type built on WS-Coordination. The partner creates a `wscoor:CoordinationContext` — `Identifier`, `Expires`, `CoordinationType` and a `RegistrationService` endpoint reference — and flows it as a SOAP header that MUST carry `mustUnderstand` true. My service would `Register` for `Durable2PC`, do its work tentatively, answer `Prepare` with `Prepared`, `ReadOnly` or `Aborted`, then wait for `Commit` or `Rollback`; it would advertise this with `wsat:ATAssertion` on the binding operation. The cost is that my locks and my recovery now depend on another organisation's coordinator, and the specification itself says atomic transactions need a high level of trust and short duration. Inside one trust domain I would agree; across a company boundary I would offer a reservation with explicit confirm and cancel operations instead.

go deeper

for a junior

Recall that WS-AtomicTransaction runs two-phase commit across SOAP services, using a coordination context header created through WS-Coordination.

for a middle

Explain what the context carries, how Register names a protocol, and the Durable2PC messages: Prepare, Prepared, ReadOnly, Aborted, Commit and Rollback.

for a senior

Show what a Prepared vote costs in production: tentative work and locks held until another party's coordinator decides, and recovery that needs that coordinator reachable.

for a principal

Make the call explicitly: inside one trust domain WS-AT can fit; across organisations argue for a reservation-and-confirm contract, and say what consistency you give up and who now owns failure handling.

## Two specifications, two jobs **WS-Coordination 1.2** (OASIS) is a generic framework. A coordinator offers: - an **Activation service** with `CreateCoordinationContext`, which a coordinator MAY support, returning a new context; - a **Registration service** with `Register`, which it MUST support, where participants sign up for a protocol; - the protocol services of each **coordination type** it supports. **WS-AtomicTransaction 1.2** is one coordination type, identified by `http://docs.oasis-open.org/ws-tx/wsat/2006/06`, for activities with an all-or-nothing property. Its introduction says what it was for: letting **existing transaction processing systems wrap their proprietary protocols** and interoperate across vendors, and it states that atomic transactions "commonly require a high level of trust between participants and are short in duration". Its companion type, WS-BusinessActivity, targets long-lived business activities. ## What flows to your service The partner's application creates a `wscoor:CoordinationContext` and sends it inside its order messages. The context carries an `Identifier` for the activity, an optional `Expires` (milliseconds), the `CoordinationType`, and a `RegistrationService` endpoint reference. When the context travels as a SOAP header, `mustUnderstand` MUST be present and true, so a receiver that does not understand it must fault rather than quietly run the order outside the transaction. Your service then sends `Register` to that Registration service with a `ProtocolIdentifier` and a `ParticipantProtocolService` endpoint reference for its own protocol endpoint; the `RegisterResponse` returns the coordinator's `CoordinatorProtocolService` reference. Instead of registering directly, your side may **interpose** its own coordinator: it calls `CreateCoordinationContext` with the partner's context as `CurrentContext`, gets a context with the same activity identifier but its own Registration service, and links upstream itself. ## The protocols you would speak | Protocol | Who registers | Messages | |---|---|---| | `Completion` | the initiator, with the root coordinator | `Commit` or `Rollback`, answered by `Committed` or `Aborted` | | `Volatile2PC` | participants with volatile resources, such as a cache | prepared before any durable participant; not guaranteed to hear the outcome | | `Durable2PC` | participants with durable resources, such as a database | `Prepare`, answered by `Prepared`, `ReadOnly` or `Aborted`; then `Commit` or `Rollback` | An order service writing to a database registers for `Durable2PC`. Its work stays tentative until the decision; on `Prepare` it votes, and after voting `Prepared` it must keep that work ready to commit until the coordinator decides. A repeated `Prepare` MUST get the same vote again. The general mechanics of two-phase commit, and what a prepared participant suffers when the coordinator vanishes, belong to the distributed-transactions subject; WS-AT standardises the messages, not a remedy for that. To publish the requirement, a service attaches `wsat:ATAssertion` — with `wsp:Optional="true"` if the transaction is optional — and it SHOULD go on the `wsdl:binding` operation. It MUST NOT be attached to a portType and MUST NOT be marked ignorable. ## What agreeing commits you to 1. **Your locks wait on their coordinator.** The window between your vote and the decision is governed by another organisation's availability, timeouts and operations. 2. **Your recovery depends on theirs.** Work left in doubt after an outage is resolved by talking to their coordinator. 3. **Shared trust and security plumbing.** The specification assumes high trust between participants, and its security considerations point to WS-Security and WS-Trust for protecting coordination messages. 4. **Lockstep interoperability.** Both stacks must implement WS-Coordination, WS-AtomicTransaction, WS-Addressing and the policy assertion compatibly, through every upgrade on either side. ## Making the call - **Agree** inside one trust domain: systems you operate, short transactions, transaction managers that already speak the protocol. That is the case the specification describes. - **Decline and offer a business protocol** across a company boundary: a reservation that expires on its own, explicit confirm and cancel operations, idempotent retries. The all-or-nothing decision moves into the contract, and each side keeps its own data and its own failure handling. - If both kinds of client must be served, `wsp:Optional="true"` on the assertion advertises an alternative without the transaction. As an industry observation rather than anything the standard says, WS-AT rarely ran across organisational boundaries; its own stated assumptions of trust and short duration explain most of that.

  • In what order does a WS-AtomicTransaction root coordinator prepare Volatile2PC and Durable2PC participants?
    Volatile2PC first: every volatile participant MUST respond before any durable participant receives `Prepare`. New participants may still register until the first durable `Prepare`; after that the Registration service MUST refuse with a Cannot Register Participant fault. The specification gives no rationale beyond the split; the usual reading is that volatile state such as a cache settles before durable resources vote. Volatile participants are not guaranteed to hear the outcome.
  • What does a ReadOnly vote let a Durable2PC participant skip?
    `ReadOnly` votes to commit and tells the coordinator that the participant has already forgotten the transaction and does not want to take part in phase two, which suits a participant that changed nothing. The coordinator sends it neither `Commit` nor `Rollback`, so it holds nothing while the others finish.
  • How does interposing your own coordinator change the conversation with the partner?
    Your side calls `CreateCoordinationContext` on its own coordinator with the partner's context as `CurrentContext`; the result has the same activity identifier but your Registration service. Your services register locally, and your coordinator links to the partner's — when and how often is left to the coordination type and the implementation. Protocol traffic across the boundary then runs coordinator to coordinator, concentrating trust and recovery on each side.

saying these in an interview costs you the question

  • WS-AtomicTransaction adds compensation so committed work can be undone later.
  • A service that does not support transactions may simply ignore the CoordinationContext header.
  • WS-Coordination is itself the two-phase commit protocol.
  • A ReadOnly vote means the participant aborted because it had nothing to do.
  • WS-AtomicTransaction makes long-running cross-company workflows safe to coordinate.