Enterprise Integration PatternsConversation Patterns
HOME    PATTERNS    RAMBLINGS    ARTICLES    TALKS    DOWNLOAD    BOOKS    CONTACT

Tentative Operation

Conversation Patterns

Previous Previous   Next Next

A participant is interacting with multiple, independent services, which change their state based on the interaction. Some of the interactions may fail.

How can a requestor ensure a consistent outcome across multiple, independent providers?

  • The communication channels used by loosely coupled, distributed systems usually do not provide transactional semantics at the transport level. Instead, participants can send and receive message, often reliably.
  • While some operations are inherently reversible, e.g. debiting a bank account after a credit, other operations, such as shipping a package or scrapping a car cannot easily be undone. As a result, the requestor might not be able to do much to rectify the situation.
  • Distributed conversations typically involve uncertainty: a participant cannot be certain that a conversation partner continues in the conversation or even exist after the last interaction. Participants should therefore allocate resources cautiously.

The consumer performs a Tentative Operation, and confirms it later, possibly after it interacted with other services.

The Tentative Operation conversation involves the following participants:

  • The Requestor executes a tentative operation on a service providers. It later confirms or cancels the operation.
  • The Provider receives operation requests from the Requestor. It waits for a Confirm message from the Requestor before completing the operation. It cancels the operation upon receiving a Cancel message or after it's own rule for cancellation triggers, usually a time-out.

Tentative Operation comes in two variants:

  • explicit cancellation cancels the Tentative Operation upon the Provider receiving an explicit Cancel message
  • implicit cancellation cancels the Tentative Operation after the Provider reaches a defined condition, usually a time-out.

Tentative Operation is also known as "Try-Confirm-Cancel" based on the operations involved [Atomikos]. Pat helland described a similar concept [Helland].

Tentative Operation with implicit cancellation is similar to Lease, except that it is a one-time confirmation, not a periodic renewal.

Expressed as a state transition diagram, Tentative Operation consists of 3 states: initial, reserved, and confirmed [REST].

One major aspect of this conversation is whether the Confirm operation can fail. If success is guaranteed, the provider's implementation of Tentative Operation resembles that of Compensating Action as the Tentative Operation has to allocate all required resources. The only difference is then in the conversational aspect: Tentative Operation require explicit confirmation and implicit cancellation while Compensating Action has implicit confirmation but explicit cancellation.

Not all service providers support Tentative Operations. Tentative Operations complicate the conversation. If Tentative Operation is not available, a service consumer should attempt to PERFORM MOST LIKELY TO FAIL ACTION FIRST and/or PERFORM HARDEST TO REVERT ACTION LAST to minimize the risk of ending up in an inconsistent, not not reconcilable state.

Tentative Operation can cause yield management issues for the resource provider because many customers may cancel tentative resource allocations they previously made. If there is not penalty for cancellation, requestors are incentivized to perform the Tentative Operation first in a services of operations, following the PERFORM HARDEST TO REVERT ACTION LAST pattern. This can lead to a large volume of Tentative Operation and subsequent cancellations. Many real-life providers have hence setup cancellation charges or incentivize requestors to perform firm operations with reduced pricing.

Example: Travel Booking

A traveler needs to book a hotel and a flight for a trip. Both resources are provided independently by different providers. If a hotel is not available for the flight dates, the customer needs to change the flight reservation, which may incur penalties. Therefore, the customer may ask the airline to “hold” a reservation without submitting payment, so he can confirm the availability of a hotel. Once the hotel is guaranteed, the customer will complete the purchase of the airline ticket and submit payment. If the customer does not confirm the reservation within the agreed-upon time window, the airline with cancel the "hold".

Holding reservations incurs a cost to the airline, partially compensated by yield management, i.e. confirming more seats than are actually available. Airlines therefore encourage customers to use Compensating Action by offering lower prices on early firm bookings. Canceling such bookings usually carries a heavy penalty.

Related patterns: Compensating Action, Lease



Introduction
Overview
Preface
Table of Contents
Introduction
Describing Conversations
Choreography
Orchestration
Hypermedia State
Conversation Vocabulary
Discovery
Dynamic Discovery
Advertise Availability
Consult Directory
Referral
Leader Election
Starting a Conversation
Three-Way Hand Shake
Acquire Token First
Rotate Tokens
Verify Identity
User Grants Access
Basic Conversations
Fire-and-Forget
Asynchronous Request-Response
Request-Response with Retry
Polling
Subscribe-Notify
Quick Acknowledgment
Intermediaries
Proxy
Relay
Load Balancer
Scatter-Gather
Managing Distributed Systems
Heartbeat
Resource Management
Incremental State Build-up
Lease
Renewal Reminder
Ensuring Consistency
Ignore Error
Compensating Action
Tentative Operation
Coordinated Agreement
Appendices
Bibliography