Tentative Hold Protocol Part 1: White Paper

Abstract

The objective of Tentative Hold Protocol is to facilitate automated coordination of multi-business transactions. Tentative Hold Protocol is an open, loosely coupled, messaging-based framework for the exchange of information between businesses prior to the actual transaction itself. Tentative Hold Protocol defines an architecture that allows tentative, non-blocking holds or reservations to be requested for a business' resource (e.g., the items for sale from an online retailer).

Status of this document

This document is a submission to the World Wide Web Consortium (see Submission Request, W3C Staff Comment). For a full list of all acknowledged Submissions, please see Acknowledged Submissions to W3C.

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. No W3C resources were or are allocated to the issues addressed by the NOTE. W3C has had no editorial control over the preparation of this NOTE.

A list of current W3C technical documents can be found at the Technical Reports page.

Table of Contents

• Executive Summary
• Introduction
• Tentative Hold Protocol
  • Overview
  • Tentative Hold Protocol and Custom Coordination
  • Tentative Hold Protocol and Compensating Transactions
  • Tentative Hold Protocol and Two Phase Commit
• Sample Scenarios
  • Travel Related Activities
  • Automated Iterative Searches
  • Shipping
• Conclusion

Executive Summary

In just a few years, the first wave of the Web revolution has changed the way companies do business. Diverse businesses such as Amazon.com, Dell Computer, Federal Express, Intel, and Wal-Mart are just a few examples of companies that have won customers and reduced costs by shifting commerce online. However, the greatest opportunities are now emerging as businesses strive to bring the benefits of automation to interaction between businesses. 

Automation of not just one-to-one interactions between businesses, but the entire complex web of many-to-many interactions, best described as a supply lattice, will lead to an economy that is more dynamic and agile by many orders of magnitude. It will enable vendors to more rapidly adjust prices based on changes to inventory and world markets. Automation will enable customers to link to a wide variety of suppliers and effectively arbitrage orders to garner best pricing and delivery. 

While the potential benefits of multi-business interaction automation are truly phenomenal, it poses some hard challenges: 

· Integrating information across heterogeneous Internet environments can be very difficult. 
· Vendors should still have the flexibility to provide differentiated service levels to different classes of customers. 
· Customers should be able to apply business rules to their purchase decisions that vary depending on the situation. 
· Transactions tend to be long-running, potentially tying up resources for long periods of time before a given transaction is completed or cancelled.. 
· It is important to ensure that the businesses involved in the interaction do not have stale or out-of-date information about each other.

Any single technology cannot provide a solution that successfully helps all businesses to overcome all the challenges. Tentative Hold Protocol can work with other technologies to increase their effectiveness in automating inter-business transactions by addressing the above-mentioned challenges. Also, Tentative Hold Protocol can be beneficial by itself. 

In essence, Tentative Hold Protocol is an open, loosely coupled messaging-based protocol for the exchange of information across businesses prior to an actual transaction, recognizing the extremely dynamic nature of business conditions. This framework includes a standard way for businesses to exchange tentative commitments to the terms of an interaction (e.g., price, quantity, lead time, and so on) and update each other when the situation changes. These exchanges increase the chances of successful completion of the interaction regardless of whether the interaction is coordinated using custom applications or standard middleware services such as compensating transactions. Tentative Hold Protocol defines an architecture that allows tentative, non-blocking holds or reservations to be requested for a business' resource (e.g., the items for sale from an online retailer).

In addition to facilitating the coordination of complex multi-business interactions, Tentative Hold Protocol creates new opportunities to exploit the Internet to improve efficiencies. For example, a human might be limited to considering a handful of scenarios that combine two or three suppliers to fill a need, while a computer can assemble, disassemble and rearrange requirements into various aggregations and come up with a combination of, for example, 50 suppliers, that fulfills the need at the best price and availability. 

This paper discusses the exciting new opportunity of automation of complex multi-business interactions and the role of Tentative Hold Protocol as a key facilitator. It also provides business scenarios where Tentative Hold Protocol could be applied from various industries such as manufacturing and logistics. 

Introduction

Business traditionally consisted of a set of automated business processes that reflected the internal workings of the company. There was one process to accept a customer's order, another process to fulfill the order, and yet another process billed the customer. The list goes on. A key point is that the processes seldom crossed business boundaries. A customer would place an order with a business using phone, fax, or other media - directly interacting with the internal business process. The first wave of Internet business provided browser-based user interfaces that allowed business partners access to a business' services. This however, did not change the boundaries of automated business processes. Customers still had to manually trigger the order fulfillment processes that were constrained to operate within the business' boundaries. The buisiness, in turn, had to manually communicate with its suppliers.

Figure 1. Processes expanding beyond enterprise boundaries

The advent of automated supply chains has modified this business ecology by extending processes beyond businesses as shown in Figure 1. Now, a customer's application can automatically place orders with a business without the need for any human intervention in either of the businesses. Standards for communication using XML-encoded messages, e.g., Simple Object Access Protocol or SOAP, and vertical industry standards for data and business processes (e.g., RosettaNet Dictionaries and Partner Interface Processes or PIPs) are playing a key role in enabling automated processes that span multiple businesses. 

While these recent developments that extend processes beyond enterprises are significant, they still impose a significant limitation - they automate only one-to-one linear interactions between businesses. However, most real world business scenarios involve complex many-to-many interactions that could be better described as supply lattices.

For example, imagine you decide to remodel your home. Usually, you will deal with a general contractor who needs to secure agreements with the following parties to complete your job:

• Materials suppliers that can meet your requirements;
• Shippers for the materials;
• Craftsmen in your area who are available when the materials will arrive.

Even if the contractor has automated his order placement with the above providers, the coordination of all the orders to ensure that everything is secured within the total cost and schedule constraints is predominantly manual. Today there are two ways to conduct such a business. One way is person-to-person by phone, which is how many construction projects are managed. Another way is to have all of the involved parties be departments within a single larger company such that common layers of management provide the infrastructure to coordinate the transaction. This is the common model for other kinds of projects besides home construction. Automating of this complex coordination would minimize human intervention, thus increasing the agility of the business and reducing the operating costs.

Automation of such complex coordination is becoming more valuable in the Internet economy and might soon be a necessity for the competitiveness of a business. Here are some of the factors that are driving the need for automation:

• The Internet has brought down the geographic and size barriers to potential business partners. Hence, instead of the handful of local businesses from among whom you had to choose, in some cases, you may have thousands of businesses to choose from. Intel, for example, now has many thousands of known suppliers of everything from chip wafers to hotel rooms. We want our computer applications to do the tedious work of running through all the possible combinations of all those suppliers to garner best pricing and delivery.
  
• The automation of individual 1:1 transactions has driven their cost considerably down. For example, manual invoice transaction processing used to cost Intel approximately $7.50. Automation of this transaction is driving that cost to less than a dollar. This reduction in the fixed overhead associated with business transactions is driving a trend towards a larger number of smaller transactions to satisfy a business need. Identifying the best combination of many small orders from a large number of businesses requires automation.
  
• Technologies for automated discovery and integration of on-line services (e.g., Universal Description, Discovery, and Integration or UDDI) provide a basis for automation of the coordination of complex multi-business interactions.

The urgent need for automating the coordination of multi-business interactions has received the attention of technology providers. The key approaches for automation include the following:

• Custom applications managing the coordination;
• Extensions to Two Phase Commit protocol (e.g., Transaction Internet Protocol); and
• Compensating transactions.

Each of these approaches has its own strengths and weaknesses; the suitability depends on the individual business' needs. In fact, there are some significant challenges to be addressed depending on the business scenario. For example: 

• Most businesses require that flexibility must be maintained while achieving greater levels of automation. Vendors should still have the flexibility to provide differentiated service levels to different classes of customers. Customers should be able to apply business rules that vary depending on the situation to their purchase decisions. 
• Automation requires accurate and current information. It is important to ensure that all the businesses involved in the interaction do not have stale or out-of-date information about each other.

Tentative Hold Protocol can work with the technologies mentioned above, increasing their effectiveness in automating inter-business transactions by addressing these challenges. Tentative Hold Protocol could also be beneficial by itself. This paper will provide an overview of Tentative Hold Protocol, explain how it could be used synergistically with other technologies and provide some scenarios from different industries where it could be applied.

Tentative Hold Protocol

Overview

Current supply chain automation technologies provide automation of one-to-one business interactions. In the emerging supply lattice ecology, businesses interact with numerous other businesses in a highly automated fashion, acquiring and transferring resources in complex coordinated transactions. These transactions involve multiple businesses and require careful orchestration due to their strong interdependence. This section will describe Tentative Hold Protocol, showing how it can facilitate such orchestration.

Tentative Hold Protocol is an open, loosely coupled, messaging-based framework for the exchange of information between businesses prior to the actual transaction itself. Tentative Hold Protocol defines an architecture that allows tentative, non-blocking holds or reservations to be requested for a business' resource (e.g., the items for sale from an online retailer). In the paradigm of online purchasing, these lightweight reservations are placed prior to the sale, allowing multiple clients to place these holds on the same item (thus non-blocking). Whenever one client completes the purchase of the item the other clients receive notifications that their holds are no longer valid.

This provides flexibility for both ends of the transaction. The clients have the ability to request tentative reservations on the resources that they want to acquire as a single coordinated purchase, verifying price and availability before completing the transactions. If one item becomes unavailable (purchased by some other client), this client has the ability to replace it with another item without losing any holds on other items already reserved. The vendors grant non-blocking reservations on their products, retaining control of their resources, while allowing many potential customers greater flexibility in coordinating their purchases. 

There will be a Tentative Hold Protocol coordinator on both the client and resource owner side, responsible for communicating hold requests, cancellations, etc. Also, the resource owner will provide a rules engine entity with which the resource side Tentative Hold Protocol coordinator will communicate; it shall be responsible for handling any business rule specific actions. This allows the resource owner great latitude in providing targeted customer service with the granting of holds, specifying greater or lesser hold expirations for a given hold request, as well as the potential for notifying valued clients when some resource is being reserved by another client - allowing the preferred client the opportunity to lock in their purchase first. (For further information, refer to the Tentative Hold Protocol Technical Specification document.)

In the following sections, we will describe the value provided by including Tentative Hold Protocol with some of the inter-business transaction coordination methods (e.g., custom applications/manual coordination, compensating transactions and two-phase commit transactions).

Tentative Hold Protocol and Custom Coordination

Today, the orchestration of multi-business interactions is commonly carried out through either human intervention or creation of custom applications that contain the logic about the interdependencies between the transactions that constitute the interaction. In this scenario, rolling back a previously completed transaction is dependent upon either an application or manual intervention. Obviously this has the drawback of requiring potentially expensive development time or human intervention. 

Adding a Tentative Hold Protocol phase would provide the following significant benefits:

• Minimizes the need for cancellations. Both the requesting clients and vendors would benefit from Tentative Hold Protocol. For instance, the requesting clients would be less likely to cancel an order after they have placed it. Hence, the vendor is less likely to have a need to process a cancellation.
• Provides customers with up-to-date data to base their decisions upon. A client would place a tentative hold on an item and be aware of its current availability and price. Should that item become unavailable, the client would be notified by a Tentative Hold Protocol message. Without Tentative Hold Protocol, the client would have no knowledge of the change of state, and might make significant decisions based on data that is no longer valid.

Tentative Hold Protocol and Compensating Transactions

Another method of managing inter-business transactions involves the use of compensating transactions. Individual steps in a transaction are completed immediately. If one of the steps fails, the other steps in the transaction are undone using a compensating transaction. A new transaction must occur to compensate for the prior transaction (e.g., an order cancellation transaction would compensate for the order placement transaction).

Compensating transactions are not susceptible to the problem of potentially long resource locks that are problematic for Two Phase Commit (2PC, described in the following section). Compensating transaction technology allows for eventual consistency (rather than immediate consistency, as provided by 2PC) between parties involved in the transaction. Consistency will be ensured after any needed compensations have completed.

All transactions may not be cleanly and completely compensatable. Consider, for example, a situation where an item was purchased across international lines. Such a purchase could conceivably involve fluctuating currency exchange rates. A compensating transaction for a cancelled sale may not result in transferring the same amount of money should the exchange rate fluctuate between the original transaction and the compensating transaction. 

Adding a tentative hold phase for businesses using this paradigm would provide the following significant benefits:

• Minimizes compensations. Consider, for example a client who is interested in coordinating the purchase of item X from company A and item Y from company B. Without Tentative Hold Protocol, the client would likely decide to place an order for item X from company A, and then try to purchase item Y. If unable to purchase item Y, the customer would compensate for his earlier action by canceling the order with A. With tentative holds, the client would place tentative holds on both the items thus ensuing their availability, and then complete both purchases. In this case, the customer is far less likely to cancel, having determined that both X and Y are available at an acceptable price before placing any orders. 
• Reduces lag between original transaction and compensation. From the previous example, it is clear that the lag time between a purchase and a compensating transaction would be reduced, due to the fact that the client acquires tentative commitments from all the participating businesses before it starts executing the actual transactions with any one of them.
• As in the benefits for custom coordination, Tentative Hold Protocol provides customers with completely up-to-date data to base their decisions upon. 

Tentative Hold Protocol and Two Phase Commit

The 2PC technology is stable and mature, and has been implemented by many ISV's for intra-enterprise transaction support. This architecture breaks a transaction into two steps, a prepare phase and a commit phase. In the Prepare phase, all resource managers (e.g., database managers) associated with the pending transaction can vote Yes or No on the requested transaction after locking the resources involved in their part of the transaction. A transaction manager will either commit the transaction if everyone voted Yes or abort it if any one voted No. The effect of the commit is that all resource managers will be notified to complete their part of the transaction; conversely, the abort tells all parties to release any resources tied to their portion of the transaction.

The 2PC protocol provides ACID properties (Atomicity, Consistency, Isolation and Durability) ensuring that all involved parties' transaction states are always immediately consistent. However, long first phase durations can be a problem for 2PC since the vendor's resources are locked until the transaction manager either Commits or Aborts the transaction. 2PC can be used instead of Compensating Transactions in situations where immediate consistency is an absolute must and resource locks can be tolerated.

Adding a tentative hold phase prior to the 2PC would provide the following significant benefits:

• Would shorten the required 2PC lock duration by minimizing the time spent in the prepare phase since it allows you to obtain tentative commits and make all decisions before you enter the prepare phase of a 2PC commit transaction. This is analogous to how it minimizes the time lag between the original and the compensating transactions as described in the previous section.
• Would minimize the likelihood of rollbacks since it allows the customers and vendors to exchange information on the terms they could commit to (e.g., price and quantity) and keep each other up-to-date about any change in status through proactive notifications.
• As in the benefits for Custom Coordination and Compensating Transactions, Tentative Hold Protocol provides customers with completely up-to-date data to base their decisions upon. 

It is important to note that without the additional benefits provided by Tentative Hold Protocol, vendors might be unwilling to use 2PC technology beyond their enterprise boundaries.

Sample Scenarios

The following sample business scenarios are included to show some typical business interactions and how Tentative Hold Protocol could increase their level of automation. 

Travel Related Activities

A very common use of the Internet involves making travel arrangements. Customers can use a travel coordinating service (e.g., Travelocity^TM or MSN's Expedia^TM) that provides a wide range of travel-related services. This is displayed in the following figure - the customer is dealing with a travel coordinator type of service that is itself tied into service providers. In this scenario, a client who needs airline, car and hotel reservations must do quite a bit of legwork. For instance, first checking the airline rate, then searching for a hotel room, then resubmitting the airline rate search if too much time has passed and the quote is stale, then looking for a car, and so on. Currently, the client's only other option is to go ahead and make the reservations and then cancel them if a subsequent item is not available (e.g., cancel the airline seat if all the hotels are booked) - a problem for the travel vendor since their item is temporarily unavailable to other customers.

Figure 2. Travel Coordination

A Tentative Hold Protocol enabled travel coordinator would allow the customer to gather a set of non-binding reservations for each item, effectively gathering all three requests into a single virtual operation - the customer would request tentative holds on the three items (providing a non-binding, non-exclusive hold on the availability and price of each entry) then make the purchase only when satisfied with the entire package. Should a tentatively held item become unavailable, the vendor would notify the customer. Tentative Hold Protocol also allows vendors to be always aware of the level of interest in the market for their products and also reduces the number of cancellations that need to be handled.

Automated Iterative Searches

Company XYZ Bicycles is in the business of building and selling bicycles, using various commodity component suppliers to provide parts. Since these parts are commodity products, it is possible for XYZ to leverage dynamic business situations allowing more flexibility in ordering parts (e.g., satisfying a large order by placing multiple small orders to get better prices, ship times, and so on). Organizing multiple orders with numerous vendors and coordinating them into a single transaction is very complex and is limited by the amount of time a person can sit at a terminal or phone, building up various potential options. This problem is also aggravated by the potential of working based on stale data. For example, a supplier may no longer be able to meet the request since someone else has purchased their stock and the customer will realize this only when the order is being placed.

For example, to satisfy next month's production run of XYZ's mountain bikes, it needs to procure 15,000 sprockets - a commodity component that potentially could be provided by any of 20 suppliers. These 20 suppliers may offer different prices, lead time and quantity. Someone must determine which vendors to combine to optimally satisfy an order. These decisions need to be made quickly since the market conditions could be changing fast!

Figure 3. Automated Iterative Searches

Tentative Hold Protocol provides the potential for automating a great deal of this activity. Using tentative holds, it would be possible to build an automated iterative search of the suppliers, check price and availability, and then build a series of best-fit options for coordinating the overall order. Each option would contain tentative reservations with the various suppliers for some number of items, and if any one supplier aborted their tentative reservation, a notification would be sent and the system could regroup and try again with another combination. This automated iterative search could be done very quickly and without direct human intervention, as well as avoiding the necessity for rolling back any previous independent transactions.

Shipping

Tentative Hold Protocol could be very useful for an e-Marketplace, a virtual market where many suppliers and buyers interact. The example scenario here revolves around a freight handling e-Market jobs board where customers can post their shipping needs, which are then viewed by freight vendors. In this case the freight vendors are trying to gather sufficient shipment requests (gathering tentative holds on the customer postings) to justify creating a shipment. As in the prior scenario, an automated iterative search of the postings to construct shipment options would be very effective here.

Tentative Hold Protocol can play a key role by streamlining the process for both the clients and the freight companies. Shipping providers would attempt to establish tentative holds on a set of clients' shipping requests, attempting to gather enough non-binding reservations to justify creating a new truck shipment. These holds would be of benefit to the provider since a notification would be sent if any individual client request were removed (committed to some other provider), allowing the provider to react in a timely manner - a big benefit because without Tentative Hold Protocol, the change of status would only come to light when the provider tried to commit to the entire shipment request. The client would benefit both from the feedback on their request (i.e., hold request activity being a good indicator of interest in servicing the shipping request), as well as from being able to reject any hold requests from unwanted vendors (e.g., from a shipping provider that did a poor job in the past). Once a provider had sufficient holds to justify a new shipment, the transactions could be completed, using the automated or manual transaction methods discussed previously.

This scenario leverages Tentative Hold Protocol's capabilities to eliminate stale information through notifications in business interactions where transaction management capability is not used.

Conclusion

While no single technology can provide a solution that successfully helps all businesses overcome all the challenges facing automation of multi-business interactions, Tentative Hold Protocol can work with other technologies to increase their effectiveness in automating inter-business transactions by addressing these challenges. 

The addition of Tentative Hold Protocol to business interactions presents a very compelling and useful capability - improving the efficiency for both the vendor and client in the interaction. Clients will favor vendors that support this architecture due to ease-of-use, vendors can expose their products to a wider market of potential buyers using tentative holds - this also provides benefits for a range of transaction types from completely manual to highly automated. 

Tentative Hold Protocol facilitates the coordination of complex multi-business interactions as well as creation of new opportunities to exploit the Internet to improve individual business' efficiencies. Automating the exchange of critical information prior to a transaction decreases the impact of out-of-date data, reduces the potential for cancellations, and improves the odds of successfully completing transactions.

Tentative Hold Protocol presents a significant opportunity to improve the current state of inter-business process integration, providing an important value-add to a wide variety of businesses and transaction technologies employed by them.