Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
SOA Transactions Using the Reservations Pattern
Posted by Boris Lublinsky on Sep 16, 2009
For several years now there has been a discussion on transactional processing in SOA. Despite the fact that several standards, including BTP, WS-BusinessActivity, WS-AtomicTransaction, WS-Coordination have been proposed to solve this problem, there is still no widely accepted solution. In his new post, Arnon Rotem-Gal-Oz presents an excerpt from his upcoming book - Practical SOA - Reservations pattern.
Arnon describes the problem with SOA transactions as following:
... in a distributed world, SOA or otherwise, it is rarely a good idea to use atomic short lived transactions... the fact that cross service transactions are discourages is one of the main reasons we would to consider using the Saga pattern... One of the obvious shortcomings of Sagas is that you cannot perform rollbacks... Still, since interactions, and especially long running ones, can fail or be canceled Sagas offer the notion of Compensations. Compensations are cool; we can’t have rollbacks so instead we will reverse the interaction’s operation and have a pseudo rollback... Unfortunately, there are a number of problems with compensations. These problems come from the fact that, unlike ACID transactions, the changes made by the Saga activities are not isolated. The lack of isolation means that other interactions with the service may operate on the data that was modified by an activity of other sagas, and render the compensation impossible.
Arnon also mentions another limitation of compensations and the Saga pattern itself - a requirement for an external coordinator which might introduce unwanted coupling of services to the external coordinator.
In his post Arnon proposes the pattern, which tries to answer the question:
How can we efficiently provide a level of guarantee in a loosely coupled manner while maintaining services’ autonomy and consistency ?
The solution, the Reservation pattern, requires the introduction of an internal service component handling reservations. The responsibilities of the component include:
- Reservation - making the reservation when a message that is deemed "reserving" arrives. For instance when an order arrives, in addition to updating some durable storage (e.g. database) on the order it needs to set a timer or an expiration time for the order confirmation alternatively it can set some marker that the order is not final.
- Validation - making sure that a reservation is still valid before finalizing the process. In the ordering scenario mentioned before that would be making sure the items designated for the order were not given to someone else.
- Expiration - marking invalid reservation when the conditions changed. E.g. if a VIP customer wants the item I reserved, the system can provision it for her. It should also invalidate my reservation so when I finally try to claim it the system will know it’s gone. Expiration can also be timed, as in, |we’re keeping the book for you until noon tomorrow.
This pattern enables managing the resource allocation process in an orderly manner by implementing a two pass protocol (somewhat similar to a two phase commit). During the first pass, the initiator asks each participant to reserve itself. If the initiator gets an OK from all the involved services (within a timeout) it will start the second pass, confirming reservation to all the participants.
Unlike many other SOA patterns, the Reservation is more a business pattern than a technological one. This means there isn’t a straight one-to-one technology mapping to make it happen. Arnon also describes a possible pattern’s implementation based on EJB 3.0.
Considering that transaction processing is the cornerstone of today’s software technology that makes distributed computing reliable and manageable and it is used by large enterprises in transportation, finance, insurance, telecommunications, manufacturing, etc. depending on transactional processing for funds transfer, payments processing, electronic communications, inventory control and other processing, it is extremely important to implement some form of transactions in SOA. The Reservation pattern, as defined in Arnon’s post, is an important tool in SOA architect’s toolbox.
But then there is the question: should services invoke each other, or there should be a process orchestrating service invocation? In the latter case such process is effectively a coordinator and if services interfaces support both actions and compensations then the Saga pattern might be a simpler solution.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
can you prove more details on a specific case / scenario?
by
Fernando Felman
Posted
Re: can you prove more details on a specific case / scenario?
by
Boris Lublinsky
Posted
Re: can you prove more details on a specific case / scenario?
by
Fernando Felman
Posted
Re: can you prove more details on a specific case / scenario?
by
Guy Pardon
Posted
BTP Cohesions
by
Mark Little
Posted
Re: BTP Cohesions
by
Boris Lublinsky
Posted
Re: BTP Cohesions
by
Mark Little
Posted
Easy to do with Atomikos Try-Confirm/Cancel
by
Guy Pardon
Posted
TCC = the best of both worlds
by
Guy Pardon
Posted
-
Hmm, seems like a pragmatic approach to the problem. i mean, we already have 2 phase commit protocols to solve a somewhat similar problem, and this suggestion seems like a further continuation on the existing solution.
saying that, there's one case i'm not sure i understand how this suggestion would handle: how will the reservation pattern react when on the 2nd run, a reserved resource becomes invalid?
example:
you've to manage 3 resources in the transaction.
on 1st run, you get OK for reservation from the 3.
on 2nd run, the first resource is committed, but the second resource is invalid.
obviously, the third resource would become invalid when it reaches timeomt (so no concerns there), but how would you mange the first resource which by now is already committed?
or am i missing something here?
thanks,
Fernando -
How is this different to BTP Cohesions, especially when you recall the ability to add Qualifiers to the mix?
-
saying that, there's one case i'm not sure i understand how this suggestion would handle: how will the reservation pattern react when on the 2nd run, a reserved resource becomes invalid?
example:
you've to manage 3 resources in the transaction.
on 1st run, you get OK for reservation from the 3.
on 2nd run, the first resource is committed, but the second resource is invalid.
obviously, the third resource would become invalid when it reaches timeomt (so no concerns there), but how would you mange the first resource which by now is already committed?
or am i missing something here?
thanks,
Fernando
Unless all resources confirm reservation, commit (confirmation) does not happen. -
I would say, reservations is one of the ways to implement BTP. There is no surprise, that reservations was suggested as one of the implementation approaches to BTP. This is one of the wonders of our field. We keep forgetting what was done before and then re invent it. Good for you - you still remember.
-
Unless all resources confirm reservation, commit (confirmation) does not happen.
doesn't this contradict what you say in the article regarding Expiration?
from the article: "Expiration - marking invalid reservation when the conditions changed. E.g. if a VIP customer wants the item I reserved, the system can provision it for her."
if i understand correctly, in the Expiration example you have a normal user reserving the item, but then a VIP is reserved with the same item hence making the first reservation invalid. in such scenario, my original question is still valid as a resource may be reserved in the 1st run, nut then become invalid after the 2nd run initiated (that is, after some resources have been fully committed). -
I should remember: I helped write it ;-)
-
Hi,
Reservation-style interactions _do_ have a one-to-one technology mapping as described in this article.
Reservations (and the try-confirm/cancel programming model) are supported out-of-the-box by Atomikos ExtremeTransactions.
Best
Guy -
Relating to:
Arnon also mentions another limitation of compensations and the Saga pattern itself - a requirement for an external coordinator which might introduce unwanted coupling of services to the external coordinator.
and also:
But then there is the question: should services invoke each other, or there should be a process orchestrating service invocation? In the latter case such process is effectively a coordinator and if services interfaces support both actions and compensations then the Saga pattern might be a simpler solution.
This is precisely what TCC is all about.
To challenge the situation a bit more: suppose you have composite applications and so you need composite transactions... You want maximum node independence, minimum interference with ongoing requests and the like. This is what TCC was designed for. It gives you the best of both worlds: the consistency of transactions, and the kind of loose coupling typical of SOA.
Guy
Disclaimer: I work for Atomikos, but still I think what I am disclosing here is highly relevant to the thread. -
Hi,
Feel free to download ExtremeTransactions with TCC support and check the manual for details on this scenario. Basically we recommend the following:- The try-phase (reservation) should make sure all resources are reserved for success of phase 2 (confirm or cancel) - this is a design guideline to minimize problems.
- As long as the workflow on top does not request "confirm", each individual service can timeout independently and the result will still be cancel everywhere (like two-phase commit timeouts).
- The second phase (confirm) is started with a prepare round (also like in two-phase commit) to end the freedom to timeout in each service. However, this prepare is done only when ALL services have succeeded the business logic already. Hence, it is relatively short-lived in duration.
- Should the second phase not succeed for some exotic reason, then we resort to heuristic outcomes (inherently possible in any distributed agreement protocol, also those that claim to avoid 2-phase commit or transactions) - in that (extreme) case, the error is logged and the details of the anomaly are available in the logs for human reconciliation.
9 comments
Watch Thread Reply