4 ms·

My commiserations on the train journey, I don't miss the Brighton <> London commute one bit (assuming it's the same Clapham, of course). Guaranteed delivery is

My commiserations on the train journey, I don't miss the Brighton <> London commute one bit (assuming it's the same Clapham, of course). Guaranteed delivery is indeed easy if your messages are idempotent, but if they're not then life is significantly more difficult. Most messaging systems have an "at least once" guarantee, but building in an "exactly once" guarantee, especially with a system with any significant distribution doesn't seem easy at all (tell me if I've missed something though, but event ordering in distributed systems has a reasonably interesting history). The same obviously applies to message ordering. These (presumably incrementing/timestamped?) ordering identifiers are fine if they don't have to cross a sender/batch boundary, but plenty of situations are more complex than that. How do you "simply" avoid the problem of either centralised synchronisation or time slip in ordering, as well as out of order delivery with major partition events? Just curious as to whether you're saying that these are all easy problems, or that the domain is easy if you have enough constraints!

Spearchucker 14y ago
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?
- kolektiv 14y ago
  I'll go for qualified agreement to some extent :) You're right in saying that, for example, exactly once delivery is a symptom of a business requirement. I do agree, but even something like message de-duplication has issues with scaling in a genuinely distributed system. Admittedly, whether you choose to look at that as part of messaging (a term which I admit to possibly over-broadening sometimes, as I tend to look on it as more of an approach than a technology) is open to debate, but I do get where you're coming from much better now. On the second point, I wouldn't describe my scenario as a distributed transaction - there's also very possibly no single server on which to do a classic database transaction - as soon as you do there's a scalability barrier. Anyway - it's more a difference of scenarios I think, and I'd agree that in the ones you've described the solutions sit outside of a messaging layer/domain. Always interesting to hear, thanks for clarifying!

Spearchucker 14y ago

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?

kolektiv 14y ago
I'll go for qualified agreement to some extent :) You're right in saying that, for example, exactly once delivery is a symptom of a business requirement. I do agree, but even something like message de-duplication has issues with scaling in a genuinely distributed system. Admittedly, whether you choose to look at that as part of messaging (a term which I admit to possibly over-broadening sometimes, as I tend to look on it as more of an approach than a technology) is open to debate, but I do get where you're coming from much better now. On the second point, I wouldn't describe my scenario as a distributed transaction - there's also very possibly no single server on which to do a classic database transaction - as soon as you do there's a scalability barrier. Anyway - it's more a difference of scenarios I think, and I'd agree that in the ones you've described the solutions sit outside of a messaging layer/domain. Always interesting to hear, thanks for clarifying!