Out of time
February 16, 2007 |
co.mments
Messaging causality for a non-originating system:
- messages of origin must come into a system before leaving that system
- acknowledgements for messages of origin come into a system after the origin message has left the system.
- an origin message that has been sent or acknowledged cannot no longer be unsent.
Those truths are non-contingent, ie they are true in all possible messaging systems that accept and send messages of origin. However for an observer who is reacting latently to the system's events:
- events about acknowledgements for origin messages can appear before events about origin messages.
This is the kind of thing SOA proponents need to be thinking about and writing down if they want to build useful large-scale systems.
February 16, 2007 06:42 PM
Comments
If I understand you correctly, an example problem (that I run into frequently) would be an HTTP conversation where an initial POST/PUT returns a redirect, and the client follows the redirect (accessing the same resource) before the server is done cleaning up after the initial request. Right?
Think of it as radio astronomy. Everyone is a long way from everyone else, and their view of the universe is different. Your database could have gone in a supernova, but you are still pumping out requests until the shockwave comes to wipe out your very existence.
The other way the metaphor holds up is there is no one true "now"; everyone's clock is different. Even though NTP can fix things, it is never consistent across the world.
@Steve: That is a brilliant metaphor.
Hi Robert,
practically speaking it means the loading logic for any monitoring system that is tracking events about the state of messages, requires constraints (eg don't move a message state from 'sent' to 'unsent') and a background job 'repairing' associations (eg, at time t+2 link this acknowledgement event I got at time t with the origin event I got at time t+1). Without those, the system watching the messages can't be eventually consistent.
In turn meaningful constraints require you to identify basic axioms and truths for the system you want to build. I understand clock logic is covered in a roundabout way in distributed computing theory and some people might see talk about "neccessary truth" as architecture astronautics (to push Steve's analogy). The point is that I never ever see this kind of thinking from SOA practitioners, even thought there are direct consequences of not understanding the system characteristics. I just see woolly stuff about "future business value".
Here's another one to think about - a system to manage and distribute events related to messages, must scale at a rate an order of magnitude greater than the messaging system itself.
"That is a brilliant metaphor."
What Pete said. Nice one Steve.
"In a distributed system, it is sometimes impossible to
say that one of two events occurred first. The relation
"happened before" is therefore only a partial ordering
of the events in the system. We have found that problems
often arise because people are not fully aware of this fact
and its implications. "
- Leslie Lamport
Time, Clocks, and the Ordering of Events in a Distributed System
1978
http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf
Special relativity holds true for computational systems, as well as the real world. There is no way that all observers can agree that they all perceive events happening in the same order.
back to asychronous message queues?
Exactly, SteveD. The phrasing of the first three "truths" implies the existence of a global clock.
Post a comment
Trackback Pings
TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/2039