Following the previous post I had a chance to exchange a few email with
Mark Little (the
director of engineering in the JBoss division of Red Hat). Mark thinks
the topic of transactions and SOA has been beaten to death already and
wonder's why does it need to resurface (see his post
"Is anyone out there?")
- I don't see a problem with discussions resurfacing when new people
are faced with situations others already solved (but that's a matter
for another post)
Anyway, the reasons we're here is that I
think that during this conversation mark made a few interesting
observations and I think the end result is pretty interesting. I
decided (with his permission) to post it here ( It is only minimally
edited: no deletions, few additions (in []) and a few time shifting to
make it more coherent as a single conversation)
Mark :
From what I can see it's [the arguments on transaction and services -
are] the same old arguments that have gone round and round, ignoring
the important fundamental issues and not doing enough background
research.
Sagas are transactional - it's just an Extended
Transaction model and not an ACID transaction model. Don't get hung up
on the word "transaction", which is way to overloaded in our industry
to actually mean anything by itself. Plus, 2PC is a consensus protocol
too; it does not impose any other aspect of ACID than the A. Even the D
is optional until/unless you want to tolerate failures.
Arnon I know this is an old argument - but that doesn't mean it isn't worthwhile
Mark It
isn't worthwhile if people aren't going to listen

I've been
involved in these debates so many times over the past 7 years (for Web
Services transactions) and longer for extended transactions, that it
gets a bit old after a while. Maybe we should create a wiki page and
point people at that

?
Arnon I guess, but you should
keep in mind that people who are solely in the .NET camp only got WS-AT
recently with Windows Communications Foundation so you can expect the
issues to resurface. By the way a wiki might not be a bad idea
[regarding
2PC.] 2PC is a distributed consensus protocol and in principle doesn’t
have to be related to ACID transaction. But I think the common view and
use of it is for ensuring distributed ACID behavior. Looking back at my
experience with XA and COM+ transactions it seems it does a good job at
achieving this ACIDness
Mark This is an education
issue. The literature is clear on this. People who know and understand
transactional protocols don't make the mistake of equating 2PC to ACID
properties.
Arnon Yes it is an educational issue . But
I am not sure that it is that common knowledge. It is expected that
middleware vendors who build the tools to support these protocols to
understand it better - I don’t think it is that widely known outside
these circles. Most of the architects I’ve don’t (maybe It time to look
for new friends

)
By the way as 2PC is not resilient to
failures of the coordinator so in a highly distributed environment like
SOA it might have been a better idea to go with paxos commits if at all
you go down that path.
Mark The reason WS-AT and WS-ACID
chose 2PC is: interoperability. All TP monitors support it. Try getting
IBM, MSFT, Oracle, BEA etc. to change to Paxos, 3PC, flat-commit, or
anything else and you'll be waiting for the heat death of the universe.
Arnon Can’t argue with that
Mark [also]
2PC is resilient to failures if the coordinator eventually recovers.
Paxos has its own failure assumptions too: Jim never disputed this.
Same as 3PC and other consensus protocols. As with *any* fault
tolerance approach (transactions, recovery blocks, replication, etc)
it's always probabilistic. All we're doing is making it highly unlikely
that the system cannot complete, but we can never make it entirely
safe. Even in the airline industry they can "only" go to a probability
that failures happen .000000001
Arnon You are
probably right that in an SOA situations the chances of not getting an
ACID transaction are worse than in a controlled environment - which
actually make the situation even worse since people using WS-AT
perceive it as allowing them ACID interaction (e.g. Juvals podcast) .
Mark WS-AT
is *all* about ACID, in the same way WS-ACID is about ACID
transactions. It is *nothing* to do with SOA though. Web Services are
not purely the domain of SOA implementations!
Arnon I
totally agree that Web-services and SOA are not directly related and
can each exist independently of each other. Again this is an
educational issue but, SOA==Web-services is a very common
misconception (I guess the word “service” in web-service doesn’t help

)
[in any event] I think distributed transactions in general should be used carefully period.
Mark Absolutely. They are not a global panacea and people who push them as such do more harm than good.
Arnon WS-AT
is more problematic than regular distributed transactions as by
definition in an SOA you do not know who and how many other services
will participate in your transactions so you are much more likely to
run into problems.
Sagas which embrace the temporal shift don't
give an illusion of ACIDness and allow to focus on achieving
distributed consensus while keeping all parties involved consistent. I
think that it is a much better option if you need transaction-like
behavior
Mark For SOA, yes. Although Sagas are only good
for a certain type of use case. That's why we've always tried to
develop "live documents" that allow people to add new models when/if
needed. With a couple of exceptions during the BTP days, there has
always been consensus that one size does not fit all
(http://www.webservices.org/weblog/mark_little/blackadder_and_the_micro_kernel_approach_to_web_services_transactions).
Web
Services *anything*, whether it's WS-AT, WS-Sec, or WS-Addressing all
have their non-SOA aspects because Web Services aren't developed purely
with SOA in mind. If that were to happen then Web Services as a
technology would lose some of their important benefits immediately.
Arnon This
whole discussion is in the context of SOA (at least from my side ) –
naturally there’s a place for ACID transactions for other uses.
Regarding
Sagas - calling them "Extended transactions that are not ACID" is just
semantics - my point was that they are not ACID transaction. I think
most people equate transactions with ACID transactions as well (but I
may be wrong)
Mark Many people do and that again is an
education problem. The term Extended Transactions (don't need to say
"that are not ACID") has a well defined meaning in the R&D
community. There have been many good models and implementations around
Extended Transactions. They really took off in the vendor community
through the Additional Structuring Mechanisms for the OTS, back in the
1990's. If you check that out you'll see that it formed the basis of
WS-TX and WS-CAF. Even in Jim's original technical report he discussed
relaxing all of the ACID properties in a controller manner to get more
flexibility. That was the first extended transaction. In fact, ACID
transactions are just one type of extended transaction. There are many
many others, including nested transactions, coloured actions, epsilon
transactions, sagas etc.
Unless I qualify it beforehand, I try
to never use the term "transaction" in isolation because it has
different meanings to different people. For example, when talking to
developers working in trading infrastructures, a "transaction" isn't an
ACID transaction at all. In telecos it's different again.