I think I'm understanding now why others below have such doubts about the simplicity of what I describe ;-) You're describing two problems - the first is aroun

I think I'm understanding now why others below have such doubts about the simplicity of what I describe ;-) You're describing two problems - the first is around message delivery (in-order, exactly once) and the second is a distributed transaction. Both of these problems are solved by separating message transmission from message processing. First, in-order and exactly once. Lets assume we have two systems. One we'll call the messaging client (MC) and server (MS), which sends and receives messages. The other we'll call a system of record, also client (SoRC) and server (SoRS), which is the system that has, say, an exactly once requirement: SoRC -> MC -> MS -> SoRS Lets say that I'm ordering a pair of shoes from Amazon. I don't want to receive two pairs, and I also don't want to receive no pair. Receiving a single pair of shoes exactly once is a business function. The fact that the message containing my order has been received exactly once provides no assurance. What if the ordering system on the other side rejects my order because I entered an invalid product code? Even a semantically correct and valid product code doesn't help me if the shoes are out of stock. I want those shoes, not the certainty that the message was delivered. The assurance that my order was delivered once and only once is therefore a business rule, and completely immaterial at the messaging level. Therefore I can send a once, and exactly once message to the server a 1000 times over. The server-side messaging component (MS) will submit the first valid incoming message to the sever system of record (SoRS). If the client re-sends the same message because an acknowledgement failed, then the MS simply discards that resent message. Given the above, the use case for reliable messaging evaporates. Joe Gregorio (http://bitworking.org/news/201/RESTify-DayTrader http://bitworking.org/news/201/RESTify-DayTrader) explains it well (search for "Orders should be reliable"). Second, distributed transactions: This one is solved using the same philosophy - that a transactional requirement has nothing to do with a messaging requirement. Assume we need to debit one account, and credit another. On the client I'd wrap that in a local database transaction, because databases happen to do transactions really well. Then I'd send the message as described in my first post above. When received on the server I'd use another database transaction to persist it in the business application. Again, the use case for reliable messaging evaporates, because this is a business logic problem, and not a message delivery problem. More info using REST is available from http://www.infoq.com/articles/tilkov-rest-doubts http://www.infoq.com/articles/tilkov-rest-doubts Hope that clears it up?