Incidentally, I explained this exact concept to a few friends who I talk to about my project, except I used Pat & Oscar's! You order and they give you a number, and you go sit down. Then when your order is ready, they come to you by finding the table with your number on it. A benefit to this analogy is that you can have multiple outstanding "orders", simply by having multiple numbers on your table.
I've been meaning to write a post about how I plan on using this, I just haven't felt motivated. Maybe I will now!
Still, it's not really what I was asking for. I'm looking more for a job messaging architecture, where the client makes a request and the server asynchronously works on it, and sends it down whenever it's finished. Ideally you have one connection that stays constantly open (or you re-open it whenever it closes) that receives the results, and you use the other connection (since the bare minimum for Ajax connections is 2) to make your requests. That requires cooperation on both sides of the gap.
Maybe I should have said "managers with a decent technical background" instead.
http://www.joelonsoftware.com/articles/BestSoftwareWriting.h...
http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf (warning: PDF)
Amongst the points discussed, it talks about how real life transactions from getting a coffee at Starbucks to buying a home aren't atomic but are rather based on "workflows" with promises and budgetting for worst cases.
