Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
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.
Learning to be a Good Product Owner: Foundation Skills
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
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:
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
9 comments
Watch Thread Reply