• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Sanjay Dalal and Sazi Temel
BEA Systems
Mark Little
HP Arjuna Labs
Mark Potts
Talking Blocks
 Jim Webber
 Arjuna Technologies
CoordinatingBusiness Transactionson the Web
The business transaction protocol addresses limitations of data-centric (ACID) transactions for multiparty interactions in Web service-based business interactions.
T
he shortcomings of traditionaltransaction semantics and proto-cols have become apparent as Webservices have evolved for integratinginter-enterprise processes and applica-tions. To guarantee consistent outcomesand correct execution, most business-to-business (B2B) collaborative applicationsrequire transactional support. Theseapplications often involve long-runningcomputations, loosely coupled systems,and components that do not share data,location, or administration. It is thus dif-ficult to incorporate transactions withproperties such as atomicity, consistency,isolation, and durability (ACID
1
) withinsuch architectures because such an infra-structure requires fine-grained control of locking and close trust that is not neces-sarily present in arbitrary B2B situations.Most collaborative business processmanagement systems support complex,long-running processes in which admin-istrators sometimes need to undo com-pleted tasks for recovery or to chooseanother acceptable execution path. Fur-thermore, to assume that transactions inthe back-end systems that underpin busi-ness processes exhibit ACID propertiescan lead to problems when exposingresources to third parties, because it couldultimately prevent other concurrent tran-sactions from progressing while third-party users have resources locked. Although several other extended-trans-action models support complex transac-tion structures and the relaxation of ACIDproperties, most such models are database-centric — primarily aimed at preserving theconsistency of shared data. (See the side-bar, “Related Work in Transaction Specifi-cations.”) Thus, they are generally notapplicable for applications comprisingloosely coupled, Web-based business ser- vices in which business process recoveryis as important as data recovery.To meet these shortcomings, the Orga-nization for the Advancement of Struc-tured Information Standards (OASIS) hasdeveloped the business transaction pro-
30JANUARY • FEBRUARY 2003 Published by the IEEE Computer Society1089-7801/03/$17.00©2003 IEEEIEEEINTERNETCOMPUTING
   M   i   d   d   l  e  w  a  r  e   f  o  r   W  e   b   S  e  r  v   i  c  e  s
 
tocol (BTP) to meet the requirements of Web-basedlong-running collaborative business applications.
2
(See www.oasis-open.org/committees/business-transactions/ for more.) BTP is designed to supportinteractions that cross application and adminis-trative boundaries, thus requiring extended trans-actional support beyond classical ACID. In thisarticle, we examine the drivers behind BTP and theway it might be applied in a potential use case.
Transaction PropertyRequirements
To support B2B interactions, a transaction modelshould possess certain key properties. We can illus-trate these requirements with a simple scenario inwhich a user wants to reserve a flight, a hotelroom, and perhaps a rental car for the duration of a conference. While maintaining autonomy and control of theresources they manage, enterprises exposing Webservices (service providers) must make assurancesthat the user can reserve desired options. The trip’scomponents are clearly interrelated as it makes nosense to book the hotel or car without a flight, but itmight be desirable to book the flight and hotelwithout the car. In addition, the attendee might alsowant to try several options concurrently by reserv-ing multiple flights while looking for convenienthotels, which further increases the transactionrequirements; they must be able to handle multiplesuccessful outcomes, as we demonstrate later. Giventhat business relationships imply a level of value tothe parties involved, achieving some consensusamong them is important. Moreover, because notall participants in a particular transaction need thesame outcome, each transaction might include sev-eral different
consensus groups
.In addition to understanding the outcomes, aparticipant within a business transaction mightneed to support provisional or tentative statechanges — indicating, for example, that a tickethas been reserved but will be released if not con-firmed within a specific time period. All parties must also support the transaction’scompletion, whether through confirmation (finaleffect) or cancellation (countereffect), but each par-
IEEEINTERNETCOMPUTINGhttp://computer.org/internet/JANUARY • FEBRUARY 200331
Coordinating Business Transactions
Related Work in Transaction Specifications
T
here are other emerging specificationsthat seek to address the problem of coordination multiparty business interac-tions on the Web.While these models donot necessarily follow in the same vein asBTP,their goals are close enough to warrantsome additional examination.Perhaps the most noteworthy (in termsof its sponsors) is the Web services coor-dination (WS-C) specification supportedby IBM,Microsoft,and BEA,which aims todefine a generic framework for coordinat-ing abstract entities.
1
WS-C essentially pro-vides an abstract notion of coordinationthat is extended to specific coordinationprotocols by the addition of third partyagents.There is no equivalent of WS-C inBTP,which has been designed specificallyfor transactional coordination and interac-tions.While this means than WS-C ispotentially more flexible that BTP becauseit can support a variety of coordinationprotocols,only one such protocol has beenproposed to date:WS-Transaction,
2
whichIBM,Microsoft,and BEA are also develop-ing based on the WS-C work.WS-T has two transaction models:
•
 Atomic transactions
require ACIDsemantics and therefore assume thatresources are locked for the tran-saction’s duration.
•
Business activities
are designed for usein long-running transactions.Theyensure that any updates to state in asystem are made immediately,signi-ficantly reducing the period duringwhich locks must be held.WS-T has no notion of a two-phase com-mit for a business activity because commitsare made immediately on receipt of theassociated messages.If a failure occurs,abusiness activity runs compensating actionsto restore data to a consistent form.Taking a different approach to the prob-lem,Intel’s tentative-hold protocol (THP)introduces the tentative-hold phase,whichcan be used with both
atomic 
and
compen-sating 
transactions.
3
In this phase,business-es can exchange tentative commitments tothe terms of a contract or interaction (howlong to hold a flight reservation,for exam-ple) in a nonblocking manner.Clients cantentatively obtain resources for long timeperiods without requiring the resourceprovider (the travel agent,for instance) tolock such resources for the duration.If aclient subsequently commits a transactionand acquires the resource,THP will informthem that the holds they have are nolonger valid.Although these protocols aim to fulfillthe same goal as BTP — handling transac-tions in loosely coupled systems — theapproaches differ somewhat considerably.Over time,however,we expect that theproponents of these specifications willreach consensus.A single specification thatharvests the better points of each will like-ly prevail.
References
1.
Web Services Coordination (WS-C)
,joint specifica-tion by IBM,Microsoft,and BEA,Aug.2002;www.ibm.com/developerworks/library/ws-coor/.2.
Web Services Transaction (WS-T)
,joint specificationby IBM,Microsoft,and BEA,Aug.2002;www.ibm.com/developerworks/library/ws-transpec/.3.J.Roberts and K.Srinivasan,“The Tentative HoldProtocol,” W3C Note,Nov.2001;www.w3.org/TR/tenthold-1/.
 
ticipant can determine what it means to confirm or cancel completed work. In our example, the airlinemight choose to make changes (reserve the seats onthe requested flight, for example) as a provisionaleffect (an operation whose results are not madedurable or visible to other business processes untilthe current process has successfully completed) andmake them visible to other business transactions.Finally, in the Web services domain, applica-tions exchange messages as XML documents, butthe way different parties exchange these docu-ments (by email or HTTP, for instance) is a func-tion of environment, business relationship, andother business or logistical factors. Any messageexchanges involved with coordinating transactionsshould therefore be agnostic to carrier protocols.
Business Transaction Protocol
BTP is designed to handle long-running transac-tions, whether user- or initiator-defined, to permitflexible outcomes for the transactional activities,and to support a transaction concept that goesbeyond data-centric transactions. This latter pointis particularly important because business interac-tions over the Internet, such as Web service-basedbusiness transactions, must ensure process consis-tency as well as the standard requirement for dataconsistency, and it almost always involves long-running activities that cannot be comfortably han-dled by ACID transaction protocols. In this article,we describe how the protocol can be applied with-in a Web services environment. More details onspecific aspects appear elsewhere.
3–6
Consensus of Opinion
To ensure atomicity between multiple participants,a traditional transaction system uses a multiphase(typically two-phase) protocol. During the firstphase (preparation), individual participants mustmake durable any state changes that occurredwithin the transaction’s scope, such that thosechanges can be rolled back (undone) or madedurable (committed) once consensus is achieved. Assuming no failures occur during the first phase(in which case, all participants would have to undotheir changes), the second phase gives participantsthe chance to update the original state with thechanges made durable in the first phase.BTP uses a two-phase outcome protocol toguarantee atomicity of decisions, but it does notimply specific implementations. To enforce thisdistinction, rather than mirroring an ACID trans-action environment by calling the second phasesof the termination protocol “commit” and “roll-back,” BTP terms the phases “confirm” and “can-cel,” respectively. The intention is to decouple thephases from any preconceptions of specific back-ward compensation in the implementation.
Open-Top Coordination
In a traditional system, the application has very few verbs — typically,
begin
,
commit
, and
rollback
— with which to control transactions. When anapplication asks a transaction to commit, the coor-dinator executes the entire two-phase protocolbefore returning an outcome. BTP calls this a
closed-top
commit protocol. The time elapsedbetween executing the first and second phases istypically milliseconds to seconds, but it is entirelyunder the coordinator’s control. The two-phasealgorithm imposes no time restrictions on execut-ing the first and second phases, but the longer theperiod between them, the greater the chance for failures and the longer resources remain locked.BTP uses an
open-top
commit protocol that letsthe application set the time between phases byexpanding the range of available verbs —
prepare
,
confirm
,
cancel
, and so on — toinclude explicit control over both phases. Theapplication has complete control over when trans-actions prepare and can use whatever businesslogic is required to later determine which transac-tions to confirm or cancel.
Extended Transactions for Web Services
To address the specific needs of business transac-tions, BTP introduces two types of extended trans-actions:
atom
and
cohesion
. Both use the two-phase completion protocol in an open-top fashion,driven directly by the application.
Atom.
The atom transaction type uses a two-phaseoutcome protocol to ensure that the “logical unit of work” achieves a consistent result. In this context,a unit of work is considered to be a number of busi-ness actions that should either be completed togeth-er or reversed to a state as if not executed. An atomis similar in some respects to the traditional ACIDtransaction in that the outcome is guaranteed to beatomic; despite failures, all enlisted participants willeither accept (
confirm
) or reject (
cancel
) the work.Isolation is relaxed in atom transactions to supportlong-lived transactions.To illustrate, let’s take the travel agent scenarioand assume that the flight, hotel, and car reserva-tions are components of a single business transac-tion. Furthermore, we can assume that a bookingwith each of these parties is essential for a particu-
32JANUARY • FEBRUARY 2003 http://computer.org/internet/IEEEINTERNETCOMPUTING
 Middleware for Web Services
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...