Clemens Vasters has a fine article on Transactions, SOAP and the Web. I think he makes some wonderful points.
This prompted me to clarify some of the feelings I had on this topic, and the quote Clemens has on Mark Backer's words: "For many years, people have talked about normal ACID/2PC transaction semantics are unsuitable for use on the Internet. That is still the case. We need to rethink what a transaction is on the Web, and I can guarantee you that when we do, it will be implementable as an HTTP extension."
Ahh... I respectfully disagree, Mark. I think you pretty much got it backwards. There's a reason why transactions were defined as they were, and their essence is deeply embedded in that four letter acronym you mention: ACID. Redefine Transactions? And make them what? just A? just C? just AD? What? Either I'm plain dumb, or I've been working on the wrong kind of applications. At least those I'm currently working in, when you need transactions, you need ACID, period. There's no ifs or buts. Particularly not when someone's payment on the mortage on his home is at stake, for example.
What we need to rethink is the notion of doing transactions over HTTP. What we need is transactions over the internet (you said it yourself), not over the web, or HTTP. If the only reason is the old "get through the firewalls" argument, then it is just plain silly... if the need is there (and business transactions between partners requiring real ACID semantics is a very powerful need, imho), then, given the correct security measures (a strict requirement, in this context), an Sysadmin will be much more confident in opening a special port on his firewall. Trying to cram everything on HTTP is not only the wrong choice; it is also a very dangerous choice in the long run.
