Tomas, Brad and Sam point to my bit about the unsuitability of HTTP for transaction negotiation or even reliable messaging.
Brad said that this would explain why SOAP doesn't do transactions. Stop! I didn't say that. I said that HTTP, without resorting to things like tunneling or callbacks, doesn't support any flavor of transactional behavior and therefore any SOAP conversation layered exclusively on top of plain HTTP can't do transactions.
SOAP over a bidirectional transport suitable for reliable messaging and even SOAP wrappers for things like TIP for inter-TPM negotiation (<soap:body/> not <soap:header/> !) are definitely possible, although, on the latter, I don't really see a point in wrapping the every protocol ever invented with <soap:envelope/>. What I said should also not imply that I agree that there are no use cases for 2PC in an Internet environment; indeed there are quite a few, because there are classes of problems where compensation is infinitely hard to implement or just flatly impossible. In the vast majority of cases, 2PC can be avoided, though.
Considering this, the question really is whether I should use HTTP for all data exchanges that don't require reliability and/or transactions and use something else whenever reliability and/or transactions are required, or just use something else altogether. Which serious, business-critical application actually doesn't need reliability and/or transactions for any communication across business-process or use-case boundaries (the exact place where Web services do play a huge role in EAI/B2B)?
I happily repeat: The "I love HTTP" discussion (aka REST) is solely academic and of very little relevance for complex real-world designs now and even less moving forward -- methinks.
For additional cases where HTTP doesn't really work (P2P in general and even non-transactional, long running operations), consider reading this article by Larry Seltzer and this interview with Don.
7:51:25 AM 
|
