OASIS BTP, the Transaction Protocol for XML Services

Copyright © 2001, Choreology Ltd, 13 Austin Friars, London EC2N 2JX.

When two companies trade they align their business processes: a work item in one company's internal systems must be coordinated with an item in the other's. An offer is made, a bid is returned, and a deal is done. However complex the commercial transaction, the same need occurs: to link process steps into a single related group across the organizational or departmental boundary. Typically this group of related operations must either succeed as a whole, or be wholly reversed or counter-effected.

This fall the OASIS Business Transactions technical committee will adopt the Business Transaction Protocol (BTP) as an OASIS Committee Specification. BTP extends the well-known principle of two-phase commit transaction management into a new dimension. BTP addresses the needs of autonomous trading partners exchanging XML data as part of system-to-system electronic commerce.

Backed by leading companies in the field such as BEA Systems, Bowstreet, Hewlett Packard, Interwoven and Sun Microsystems, the OASIS committee has worked since March 2001 to define novel features which make BTP uniquely flexible. This protocol brings transactions to the world of web services, while preserving the ability to incorporate traditional distributed transaction managers and to coordinate standard resource managers such as relational DBMS, transactional queuing/messaging products and transactional connectors.

Industry sectors where BTP is likely to prove relevant include electronic financial trading, e-procurement, content publication and replication, network management and wireless trading environments.

The key requirements that motivate the creation of a new approach to transactions are

• Autonomous participants, united by contract

• Discontinuous service

• Interoperation by XML over multiple communications protocols

Participant Autonomy

Collaborative electronic commerce relies on mirroring business contracts in software contracts. A collaborative, inter-organizational system has no central controller or authority: no company will allow its processes to be held up, or its data to be locked out, at the whim of a customer. Instead, the customer and supplier must come together in well-defined, temporary relationships that reflect their reciprocal business interests. The parties' systems are synchronized by agreement.

Unique technical features that flow from this autonomous style of computing (and which are not present in old-school transaction protocols) are:

• compensation-based reversals (as well as the conventional before-image restoration model for achieving counter-effect on cancellation)

• participant-defined timeouts, where a participant can place itself under a central transaction authority for a self-chosen interval, and can determine whether it will automatically cancel or confirm after that time has elapsed

• application data on protocol messages, which allows trading communities or bilateral partnerships to enrich the basic coordination contract of the two-phase commit protocol

• cohesions, or "cohesive business transactions": structures created by customers or commissioners over a population of potential suppliers or offerers, which allow complex business logic to dictate which of the many candidates become the final selections which are tied together in a single, atomic outcome.

Discontinous service

Interorganizational transactions may be of almost any duration. Real-time trading partners in a financial community or exchange may offer quotes with lifetimes measured in tens of seconds. Software or content releases in a controlled multi-version publication environment may take days or weeks.

The possibility of long-running transactions introduces a high likelihood of service interruptions which are non-fatal (perhaps from routine maintenance, for example). Conventional transactional protocols do not cater for recovery during the active work phase of a transaction: BTP does.

Interoperation via XML across a choice of communications protocols

Autonomous operation contributes to a strong need for interoperation, which is vastly more likely to be needed in a cross-company trading system than inside the firewall. Suppliers and their customers will buy software from different vendors, and yet must interact to achieve electronic trading.

The emergence of XML as the lingua franca of data exchange simplifies the job of creating interoperable encodings for a coordination protocol's messages. Building on this baseline, BTP messages can be sent over any communications protocol, and can be combined with any type of application message. This generic capability is matched by a specific binding of BTP messages to SOAP, allowing cohesion-aware web services to be exported as SOAP-invokable operations.