IEEE SOFTWARE Published by the IEEE Computer Society - PDF document

IEEE SOFTWARE design ThoughtWorks thecoffee shop gets you thinking aboutcoupled systems. This happened to meon a recent trip to Japan. One of themore familiar sights in Tokyo is the nu-merous Starbucks coffee shops, especially aroundÒHotto Cocoa,Ó I started thinking about how aorders. As a business, the coffeeshop is naturally interested inbecause more fulfilled ordersInterestingly, the optimiza-a concurrent and asynchronousplace your order, the cashiercoffee cups on top of the espresso machine.The queue decouples the cashier and barista,if the store gets busy, without impacting thecashier. If the real world writes the best stories, thenCorrelationFor example, the asynchronous processingmodel means that drink orders arenÕt necessarilywere placed. This can happen for two differentdrinks usually take longer to make than drip cof-As a result, Starbucks has a correlation prob-must be matched up with the correct customer.Starbucks solves the problem with the sameÒpatternÓ we use in messaging architecturesÑout when the drink is ready. In other countries,ing out the drinks. My approach was to orderis,Òcorrelatable.Ófrom the sender, whatÕs the receiver to do whenYour Coffee Shop DoesnÕtUse Two-Phase Commit ever, permission to reprint/repub-or redistribution to servers or lists, March/April 2005IEEE SOFTWARE canÕt pay? They either pull your cupfrom the queue or toss the drink if it hasdrink thatÕs incorrect or unsatis-factory, they remake it. If the machineand they canÕt make yourdrink, they refund your money. Each ofcommon error-handling strategy forloosely coupled systems (see Figure 1).ing, or discard what youÕve done (see Fig-ure1a). This might seem like a pooran error-correction solution mightbecasionally, they failed to bill a customerwas small enough that it didnÕt signifi-account!). Periodically, theyÕd run recon-Retrysible option if thereÕs a realistic chanceHowever, if a business rule was violated,itÕs unlikely a retry will succeed. This approach requires a little more co-plifies the error-handling strategy. The obvious alternative to retryingcompleted operations to return the sys-tem to a consistent state (see Figurebest with monetary systems, where wecan credit money already debited. Butactions. For example, we might callage that was sent in error.Transaction coordinatorfer from a traditional two-phase com-customer wait at the cashierÕs counterwith money and the receipt until thedrink is ready. Then, the money, receipt,swoop. Neither the cashier nor the cus-was complete. proach would certainly kill a coffeeshopÕs business because it would dra-matically decrease the number of cus-commit can make life a lot simpler, itcan also hurt the free flow of messagesaction resource across the flow of mul-follows an optimistic approach to opti-scenario, even though this results in asmall loss when errors occur.When amounts and stakes are larger,acts as a transaction coordinator, offer-is, the purchase of the property. Once theYet even this case employs some com-pensation strategies. Because your bankaccount doesnÕt support a traditionalmoney from your account first and thenrolled back. Essentially, the tion is legal because we assume we cancredit an accountÑthis action wonÕt fail.exemplifies how to integrate a compen-two-phase-commit transaction.How- ResourceBResourceA ResourceBResourceA BResourceACoordinatorPrepareFeedbackCommitAction Action Action (b)(c)(d) Figure 1. Error-handling strategieswrite-off; (b) retry; (c) compensatingaction; (d) transaction coordinator.