The Business Transactions Protocol, Page 3
Time to Choose
In a traditional transaction system, the application or user has very few verbs with which to control transactions. Typically these are "begin", "commit" and "rollback". When an application asks for a transaction to commit, the coordinator will execute the two-phase protocol before returning an outcome. The elapse time between the execution of the first phase and the second phase is typically milliseconds to seconds.
However, the actual two-phase protocol does not impose any restrictions on the time between executing the first and second phases. Obviously the longer this period takes the more chance there is for a failure to occur and the longer resources remain locked. BTP on the other hand, took the approach of allowing the time between these phases to be set by the application simply by expanding the verbs available to include explicit control over both phases, i.e., "prepare", "confirm" and "cancel". The application has complete control over when it can tell a transaction(s) to prepare and using whatever business logic is required, later determine which transaction(s) to confirm or cancel. This ability to explicitly control the termination protocol is a powerful tool.
Architecture of the Business Transaction Protocol
The BTP architecture can best be described with reference to Figure 3. Web Services do work within the scope of atoms (similar to atomic transactions), which are created by the initiator of the business transaction; multiple atoms are composed into a business transaction (e.g., arranging a holiday) by a cohesion composer such that different atoms may possess different outcomes, as directed by the business logic, e.g., cancel one insurance quote and confirm another.
Figure 3: BTP actors.
The actors involved in a BTP business transaction are:
- Coordinator (atom): used to scope work performed on Web Services. As with an atomic transaction, the coordinator is responsible for informing enlisted participants about whether they should accept (confirm) or reject (cancel) the work done within the scope of that atom.
- Initiator of the atom: communicates with an atom manager (factory) and asks it to start a new atom. Once created, information about the atom (the context) can be propagated to Web Services in order for the work to be conducted within the scope of an atom.
- Terminator of the atom: This will typically be the same entity as the initiator, but need not be. Although an atom can be instructed to confirm all participants immediately, as mentioned in Section 3.2, it is more typically instructed to prepare them first, and later (hours, days, etc.) to either confirm or cancel them.
- Web service, e.g., the taxi booking service: Whenever the initiator contacts a service whose work it wishes to be under the control of an atom, it flows the context to that service. The service can then use this information to enlist a participant with the atom. The service is responsible for ensuring that concurrent accesses by different applications are managed in a way that guarantees some internal consistency criteria for that service.
- Each participant supports a two phase termination protocol via the prepare, confirm and cancel operations. What the participant does when asked to prepare is implementation dependant (e.g., reserve the theatre ticket); it then returns an indication of whether or not it succeeded. However, unlike in an atomic transaction, the participant does not have to guarantee that it can remain in this prepared state; it may indicate that it can only do so for a specified period of time, and also indicate what action it will take (confirm or cancel) if it has not been told how to finish before this period elapses. In addition, no indication of how prepare is implemented is implied in the protocol, such that resource reservation need not occur.
- Cohesion composer: the business logic for gluing together the flow of the application into one or more atoms. Although Web Services do work within the scope of atoms, it is the cohesion composer (cohesion) that ultimately determines which atoms to confirm, and which to cancel. The composer may prepare and cancel atoms at arbitrary points during the lifetime of the business transaction. The main difference between an atom and a cohesion is that whereas all participants enrolled with an atom will either confirm or cancel, the participants enrolled with a cohesion (atoms) may have different outcomes. However, once the composer has arrived at its confirm-set (the participants that will confirm) it essentially collapses down to become an atom and guarantees an all-or-nothing effect.
Through the cohesion composer, BTP gives the business logic the flexibility to structure interactions with services into multiple consensus groups. The fact that atoms may be prepared at any point in the normal flow of business and later confirmed or cancelled, gives greater flexibility to the application.