Alternate transaction models
For a long time, I thought that extended transactions would be very important. Actually, I thought they would be in wide use by now. In 2001, I was very interested to see what would become of BTP; the answer, at this point, is some very interesting additions to the literature and a few failed attempts at commercialization. The devil was in the details: with BTP, the application may subsume the role of the coordinator at which point it becomes less and less clear why the protocol is needed at all above and beyond the business logic itself. This led us to focus more on choreographies, with the notion of defining the business protocols through some formal structure that may or may not be automated by "transactional" infrastructure. The experience in recent years has led me to believe that transactions may be the wrong paradigm altogether for broadly distributed systems. The trouble is, we don't know what the right paradigm is yet.
Mark notes a recent paper by Pat Helland as an important read. I agree, but my conclusion is also increasingly heterodox with respect to the transactions community: that is, Pat's paper should be taken at face value to be about writing application logic. There are patterns here that need to be understood by application developers. Perhaps supported by frameworks. But it may simply be that transaction management won't play a broad role in that context.