The Business Transaction Protocol (BTP) is a multi-party coordination protocol for use where "autonomy and discontinuous networks reign." [BTP Overview for High Performance Trans System Workshop] , in other words, commercial collaborations over the Internet. The BTP specification effort began in January of 2001, initiated by a group of companies involved in e-commerce infrastructure, including BEA, Sun, and HP. The intent of BTP is to simplify applications programming for business collaborations, while making transactions flexible enough to be useful for complex transactions on an essentially unreliable medium, the Internet Version 1.0 of the BTP was released 1 May 2002 by the Organization for the Advancement of Structured Information (OASIS) BTP Committee, and HP has already incorporated it into its web services "stack".

This paper is intended to provide an overview of BT. It is divided into the following sections:

1. Problem Definition and Description

BTP was developed to increase the level of automation of Business to Business (B2B) transactions and the number of processes that are automated. Further, these tasks must be accomplished while operating over the Internet, tolerating both its unpredictable quality of service and latency. The following paragraphs describe the problem in more detail.

A business transaction can be informally defined as a consistent change in the state of the business as a result of a well-defined business function, such as paying a vendor. Business transactions usually consist of several activities that might each be characterized as a transaction in traditional database terms: paying a vendor might require the transfer of funds between capital and operating accounts, generation of a sales agreement, transfer of funds to the vendor, receipt of a bill of sale, deduction of money from the operating account, posting the acquisition of the asset to a program account, etc.

When compared to a traditional database transaction, the larger scope of a business transaction has the effects of

1. increasing the duration of the transaction beyond the time usually considered when budgeting for transaction security with respect to locks and time-outs, and
2. involve more and potentially unknown participants in the process.

In the vendor payment example, from the supplier's perspective, the transaction might not be complete until the vendor sent, possibly by non-electronic means, a bill of sale - a matter of days or weeks, and the participants might be two or more financial databases, an equipment database, a vendor sales terms database, a program asset database, etc.

Traditional database transactions usually take place either within an organization, or among a small number of trusted trading partners. In either case, the transactions take place on controllable infrastructure, involve well-known and pre-identified entities (such as specific databases), and unfold in accordance with a pre-defined script that enforces a 2-phase commit scheme - the transaction is all or nothing. However, in reality, much of the business process is either not automated, or is automated with other business partners, usually in a pair-wise fashion. In the vendor/supplier example, the vendor may query his vendors to get parts and prices, and they may query their vendors, etc - but each of these interactions is either manual or played out in accordance with a pre-defined script.

The purpose of BTP is to allow coordination and aggregation of traditional database transactions to more closely mimic actual business transactions with the result that business processes can be more accurately modeled for automation. The result of this is anticipated to be better throughput for existing processes as they are automated, and more effective business processes as the concessions and adaptations to traditional database technology are stripped away.

Other protocols are being developed with the purpose of better managing distributed business processes, for example, ebXML (Electronic Business XML), WSFL (Web Services Flow Language), and BPML (Business Process Modeling Language), but they are complemented by BTP, rather than competing with BTP. For example, WSFL, IBM's nominee for characterizing and propagating web services and web services interactions, doesn't mention anything about transactions, or how to choreograph them. Several of these describe how two business partners might collaborate, but not how multiple partners could. As a result, BTP may provide a simple extension route for some of the ambitious business process application implementers. In , the authors suggest that BTP be considered part of the stack that supports such models, as shown in Figure 1. This position is articulated by Alastair Green in one of the three original submissions that started the BTP effort: "Our principle guide is that a BT protocol should not be aware of application control flow, application message content, or operation algorithms and effect."

BTP was developed to allow transactions with these characteristics to occur, with the business decisions and data provided by the applications programs of the participants, and the choreography of the transaction accomplished by BTP, under guidance of the initiating application.

1. Use Cases and Constraints

The use cases that define BTP are described in Table 2 and the constraints applied to the use cases are listed in Table 3. The key requirements exposed by the use cases are

• selective acceptance of sub-components of a transaction and
• the ability to coordinate transactions that may include entities that do not meet the ACID isolation requirement.

Table 3 - Constraints on the Design of BTP

In addition, "micro-transactions" are described, in which very small amounts of money are charged to users who use very small amounts of service - such as a dictionary web service with thesaurus and spell checkers, where a user might be charged fractions of a cent per use. This is not feasible with current technology since it costs more to process the charge than the charge itself, but in a web services world, where the whole process can be automated and take place electronically, it becomes a financial possibility.

In addition to the concrete requirements, it is required that BTP operate in an environment where relationships among business entities are defined by contract, not by design.

1. Functional Description

"BTP is designed to allow coordination of application work between multiple participants owned or controlled by autonomous organizations. BTP uses a two-phase outcome coordination protocol to ensure the overall applications achieves a consistent result. BTP permits the consistent outcome to be defined a priori - all the work is confirmed or none is - (an atomic business transaction or atom) - or for application intervention into the selections of the work to be confirmed (a cohesive business transaction or cohesion)"

At a very high level, "BTP-enabled" web services will have both a commerce application (application) and a BTP application (BTP) running. When the application either initiates an action with another web service, or is contacted by another BTP-enabled web service, the application will (1) provisionally perform the directed operations and (2) inform its own BTP layer of the BTP address of its initiating application. At some point, the initiating application will direct its BTP layer to poll the subordinate applications as to their readiness to confirm or cancel the provisional effects of the operation.

BTP transactions can either be atomic, where they behave like an ordinary two-phase commit, or be part of a cohesion, in which some subset of the actions can be cancelled at the direction of the initiating application. If the transaction is atomic, all the subordinate actions are committed if they are all ready, or all are cancelled if even one of them is not properly prepared. Alternately, if the relationship is a cohesion, the BTP layer of the initiating application can select one or more of the atoms to fail, although the atom was ready to commit its activity. In addition, the atoms can withdraw from the cohesion autonomously - for example, because a quote exercise date expired. To cope with this, BTP allows for multiple polls of subordinate services.

All BTP-coordinated transactions are trees made up of either atomic transactions or cohesions. The type of the transaction at any level of the tree is hidden from layers above and below, so no single node knows of all the participants in the transaction.

 

2. Technical Description of BTP

BTP was developed to support the use cases described in Table 2, assuming that application software would be exposed to potential partners as BTP-enabled web services (as stated in the use cases).

A BTP Enabled Service is a software agent that accepts and acts on application messages from the initiator of a business transaction. It must be able to support tentative state changes (provisional effects), confirmation (a final effect), or a cancellation (counter-effect). The meaning of each of these depends on the application, but each service must be able to initiate provisional effects, then either confirm them or cancel them.

When a service is BTP-enabled, it has both an application element and a BTP element, as shown in Figure 3. The application element embodies all the business rules and performs, or directs its subordinates applications to perform all the necessary operations such as placing an order, verifying that the item is in stock, calculating price, etc. The BTP elements of the applications are only involved in the decision to commit or cancel the effects of the work performed by the application elements.

Note: All figures in this section are modifications of figures appearing in .

 

 

 

 

 

 

Figure 3- Basic BTP Relationship

The building block of a BTP transaction is a bilateral relationship among nodes, as shown in Figure 3. Transactions are built up of multiple such relationships; an BTP-enabled application can have this relationship with several subordinate BTP-enabled applications reporting to it. This results in a tree with the node of each tree being a Superior, and the leaves each inferior to the node above, as shown in Figure 4. The simplest relationship is between two services, but the trees can grow wide, with many inferiors reporting to a single superior, and deep, with many layers of superior/inferiors. The shape of the tree is limited only by the interactions of the applications.

1. Atomic Transactions and Cohesions

As described in the previous section, BTP is capable of managing two types of transactions: atomic and cohesions. Atoms are traditional 2 phase commit transactions, which fully commit or fully rollback and they have all the ACID properties. The operations of one web service are usually considered to be an atom.

Cohesions are sets of atoms that are affected by the business transaction's initiator. A cohesion is constructed and run by an enrollment and voting process, but the a process external to the atom has the final say as to whether each individual atom in the cohesion succeeds or fails, not the atom; that is, the atom could be capable of succeeding in its operation, and the "judging" process can unilaterally tag it as failed. The purpose of this is to allow the enrollment of many atoms, then winnow them down to a single outcome, based on business rules. An example of this is the Financial Trading use case, in which many brokerages were capable of providing the service, but all except the least expensive were rejected, that is, the "judge" decided that they failed based on application of a business rule: Buy low. Also, in that case, the transactions that occurred when the stock and options were actually purchased were atoms.

Finally, a critical difference between cohesions and traditional 2 phase commits is that, because of the duration of the transaction, some atoms optimistically commit their part of the transaction before the transaction as a whole is completed, as in the Manufacturer-Supplier-Shipper use case. In this case, the transaction as a whole has lost its ACID property of isolation. That is, if an order got canceled after a supplier had optimistically updated its database to reflect the order, operations that occurred between the time that the order was committed and canceled were operating on dirty data. In this case, a rollback of all those transactions is probably not appropriate. Even a undo of the offending order may not be the correct action, since the business rule might be to charge the defaulting manufacturer a fee for the cancellation. However, determining the correct action to take is not within the scope of the BTP - that is the responsbility of the application software.

For the purposes of definition, B2B transactions are considered to take place among Trading Partners, which is some business entity represented by applications hosted on a server, which can send messages to other trading partners. Each trading partner's server has an application element and a BTP element. In order to support the "judgement" activity and to provide the ability for enrolled services to extend the transaction as described in Section 2, several roles have been defined in BTP.

2. BTP Roles

The roles that can be played in BTP are shown graphically Figure 5. All BTP elements are either Superiors or Inferiors. A Superior is the BTP-element associated with the application that initiated the business transaction, while an Inferior is associated with the responding application. Superiors manage transactions, while Inferiors report whether the provisional outcome of the application's activities can be confirmed or cancelled, called becoming prepared.

Superiors can either manage atomic transactions or cohesions. If the Superior is at the top level of the tree, that is, their invoking application initiated the entire transaction, they may either be an Atom Coordinator or a Cohesion Composer. An Atom Coordinator is a Superior whose application requires that all its inferiors either confirm or cancel. A Cohesion Composer is a Superior whose initiating application doesn't require that all inferiors confirm or cancel; it allows the application to select some subset of the inferiors to confirm and others to cancel. In either case, it is called the Decider. The Decider has the final vote on whether or not all the subordinate transactions will take place. The application associated with the Decider is called the Terminator because it requests the Decider to make a final vote and terminate the transaction.

Superiors that are not at the top level of the tree, that is, their initiating application was not the initiator of the entire transaction, are known as Sub-coordinators and Sub-composers; a Sub-coordinator presides over atomic transactions, while a Sub-composer manages cohesions.

Inferiors are those elements with a Superior. As shown in Figures 1 and 2, both Superiors and Inferiors can be Sub-coordinators or Sub-composers. This is possible because an Inferior can initiate subordinate services itself, thus making itself superior to its invoked applications - a Sub-coordinator or Sub-composer. If an Inferior is not superior to any other inferiors, it is called a Participant. Figure 4 puts many of these ideas together.

3. Business Transaction Activities

A business transaction is started by an application, which directs the creation of either a Composer or a Coordinator. The BTP object creation is the responsibility of the application. After creation, a messages are sent to the application indicating that the object was created and stating its address and identification necessary for the application to contact the BTP element. The context information is made available at the BTP-element. It identifies the Coordinator or Composer as a Superior, gives its address and identification, and whether it is a Coordinator or Composer.

During a business transaction, the Initiator application will send messages to other applications directing or requesting that certain work be done. When appropriate, the messages will include the context information for the Composer/Coordinator - this will indicate to the receiving application that the requested operations will be confirmed or cancelled by the initiating application. This causes the receiving application to create a new inferior and enroll it with the Composer/Coordinator, based on the context information. If the new element is a Sub-Composer or Sub-Coordinator, propagation of the transaction takes place in essentially the same fashion. The major difference between Sub-Composer and the Composer is that the interface messages between the Composer and the Terminating application are defined in BTP, so the entire transaction can terminate, and the top-level Superior cannot initiate communications with the Terminator application. For Sub-composers, the messages between the application and the BTP-element, such as the one to tell the Sub-composer which Inferiors to keep or cancel, are application specific, and Sub-composers can send messages to their Superiors.

When a Composer is in the active state with its inferiors enrolled, the Terminator may send a Prepare_Inferiors message to the Composer. The subset of the inferiors that the Terminator identified as interesting are directed to Prepare - this subset is known as the confirm set, this allows the Terminator to gradually whittle down the subset of interest of the inferiors. After all the members of the confirm set have replied, the Composer sends their status to the Terminator. The Terminator will respond with a Cancel or Confirm message. The Confirm message includes a list of the confirm set, so the Composer, in its role as Decider, sends Confirm to all the members of the set and a Cancel to all its enrolled members not in the set. If a Cancel message is received, Cancel is sent to all inferiors of the Composer. The logic is the same for a Coordinator, except that the Terminator does not send a list of interesting inferiors, so it is assumed that they are all interesting. Note that even if all the Inferiors send Prepared messages, nothing will be committed without an explicit instruction from, first, the Terminator application and second the Decider.

Intermediate Superiors build up their confirm sets in essentially the same way, although the relationship between an intermediate Superior and its initiating application is not fully defined by the BTP. Since this is the case, Intermediate Superiors may send their Superior a message, if they should happen to know, through application insight that a significant event has occurred.

At any time, the Terminator can send a Cancel message to any inferior. Receipt of a Cancel message will cause application specific compensatory activities to occur.

Correspondingly, an inferior can autonomously Cancel or Resign. An autonomous Cancel is the same as if a Superior had canceled the Inferior. This is useful for situations in which there are different length stale dates on various quotes or information - the inferiors know when they are no longer valid and remove themselves. On the other hand, this can cause inconsistencies in the transaction, since other decisions might be based on an assumed Confirm. Inferiors have the capability to append a time-out to their Prepared message so the Superior knows how long the offer is good for. If the Inferior Cancels after Prepared has been sent, the Superior will recognize the conflict take whatever action is dictated by its application, and a Contradiction message will be sent to the Inferior. Failures that look like Contradictions are treated as Contradictions. An inferior can Resign at any time if it recognizes that further operations, either forward or compensatory actions, will have no effect on its state, in which case it is treated as if it never had belonged to the subset.

4. Issues

BTP and other B2B protocols - can run on any of them, should be viewed as an "infrastructure protocol", supporting, but not affecting the structure of the communications protocols.

One-shot optimizations. Typical operations take 8 messages (application request/response; Enroll, Enrolled; Prepare/Prepared; Confirm/Confirmed), but the minimum needed for a two phase commit is one message before the confirm/cancel decision is made by the Superior and one after the decision is made. Therefore, to cut down on message traffic, the first three messages can be merged into one message, allowing the entire operation to take place in two messages. This is called "one-shot" because the operation is ready to confirm or cancel with only one message.

One-phase confirmation - if a Coordinator or Composer has only one remaining inferior in the confirm set, the inferior can be requested to send a Confirm message, rather than performing the two phase exchange.

Autonomous cancel - a participant has the right to cancel a transaction at any time, autonomously. This capability is provided to model the ability of a business entity to set limits on the extent of its participation; for example, a bid that times out after 7 days, or a

Failure recovery. BTP can recover from a communications failure or node failure. A communications failure can be detected as a timeout and is addressed by enabling each of the actors to send messages to each other to complete the transaction.

A node failure is distinguished from a communications failure by the possibility of loss of data. Provision for saving required data is a responsibility of the application software, as well as the decision as to what application specific information to save. Recovery consists of providing another node with access to the saved data. At that point, the failure is treated as a communications failure.

In all cases, BTP requires that some information be saved: an inferior's decision to be Prepared and a Superior's decision to confirm are saved in order to guarantee a consistent decision and that the necessary information is available to all nodes. In addition, an Inferior's autonomous decision is also saved so that if it is conflict with the Superior's decision, the conflict will be reported to the Superior.

A Business Transaction is begun when an application program causes a composer or coordinator to be created, the role is specified in the creation message. The new role responds to the initiator with a context message, stating its address and identification so the Terminator can contact the Decider. The context information is made public, so that the Decider's address, identification and whether it is a coordinator or composer is known.

After creation of the Decider, other roles are created at the instigation of the initializing application. That application contacts another BTP-enabled application with the context information. This message is application specific, but it informs the receiving application that the work requested will be subject to a confirm or cancel decision. The receiving application causes an inferior to be created and enrolls with the Decider specified in the context information.

1. Failures

BTP recognizes Communications failures, in which messages between actors are lost, and Node failures, in which data may be lost. When messages can again be sent between actors, communications failures are defined as cured and the progress of the transaction continues, if it is still active. (One method of recognizing communications failures is through consistent time-outs, so it is possible that the transaction would have completed.) Node failure implies that some data is lost, so BTP requires that some data be persistent:

1. For an inferior, if it has decided to be prepared.
2. For a superior, if it has decided to confirm, that data must be saved and enough information to re-establish communications with inferiors
3. Any autonomous decision by the actor, so that Contradiction information will not be lost.

Recovery consists of re-establishing the node communications at some place with access to the saved information, either at the original address or a new one. If the node is re-established on a different site, a redirection message can be sent with the new address information. Activity on restart is application specific; it is not required to rollback transactions.

1. Assessment of the probability of success of the spec and/or approaches

The main strengths of the protocol are

• the momentum behind web services,
• the proponents of BTP,
• simplicity,
• orthogonality to other protocols.

BEA, HP, IBM and Microsoft have all invested significant resources in developing and marketing web services platforms. In order to make web services an attractive alternative to trusty, proprietary solutions, there needs to be a method of ensuring the consistency of the transaction across all its players. If web services can be used with confidence, the return in efficiency and speed will contribute even more to the speed of take-up. Since BTP addresses this issue, it is almost guaranteed at least a short-term vogue. BEA and HP have already announced product suites that include BTP, and the buzz is spreading, IdeaByte, an online technical magazine, says " . . . When externalizing existing business transactions using Web Services, features like BTP support or compensation transaction definition will most likely be required . . . "

BTP is also attractive because of its relative simplicity. Since it operates as a layer on top of applications, with a severely limited scope, it can be simple to implement and straightforward to use from an application viewpoint. Middleware vendors (such as HP and BEA) should be able to provide standardized BTP interfaces as commodities on servers.

Since BTP is orthogonal to other protocols, it is not tied to a specific carrier, such as SOAP. If IBM's HTTP-R is successful, BTP can be implemented on it with no effect on BTP's effectiveness. Further, different BTP implementations should be able to interact with each other transparently. By distancing itself from specific carrier protocols, BTP can operate on top of proprietary communication protocols, as well as standards, thus making itself capable of co-opting the legacy market.

The weaknesses of the protocol are that it is tied to a web services model of business transactions and it relies on XML schema to describe the protocol. If web services are not taken up, or evolve quickly enough, BTP will be left behind, and there are serious concerns that web services can provide the security and performance to entice large corporations from behind their firewalls. And, although XML is presently the most flexible method of characterizing messages, it may lose cachet, too, due to its lack of performance over http - and, if it does, BTP will die with it.

Based on these factors, it can be concluded that BTP will be implemented successfully for the short term at least. It may never be the household acronym that www is because it will always be a tool for B2B, not people to people - but it might be the first step on the way to the wide open web.