Ingo criticizes the use of airline reservation systems as an example in distributed concurrent systems: "The last time I checked, a ticket was no guarantee for a seat and the only real transactional guarantee for a seat is during check in. Reservation doesn't count too much here."
Since I've spent most of this millennium programming airline reservation systems, I can comment. The reason that such a system may not be a good example for distributed objects is not ticketing, but the fact that all Global Distribution Systems (Sabre, Apollo, etc.) reflect 40 years of cruft. Sabre, once the "Semi-Automatic Business Research Environment," was the first large commercial distributed system; a true pioneer in the history of computing. Here's an example: a fundamental assumption of GDS's is that seats between any two city-pairs are rare on any given day, even say, between New York and Washington. And availability is not an accurate empty-seat count, but a series of fare classes and a number between 0 and 7! (Why 7? Because 3 bits rather than 4 saved real money in 1962. [Apparently Galileo goes to 9 -- ed.]) And lots of crucial data, like fare-change rules, are never implemented according to whatever standard was cooked up in the 70s, they're almost always implemented in "comments" fields in an organization-specific way that's evolved for decades.
But the real lesson to be learned from programming reservation systems is how you must place the client above your textbook learning. If you went to an airline or a travel agency and said "No, a Flight should be this, a TravelParty should be that, and an Itinerary should be this other thing," you'd never be asked to even bid. Instead, you have to appreciate that the greatest concern of such clients, far more than improving efficiency, is losing efficiency for any amount of time. If you said "There's a 90% chance of a 20% permanent improvement in efficiency, but it'll cost you 10% efficiency loss for 1 month," they'd show you the door every time, because such organizations are so attrited (especially from the past two years), they have no margin of error.
So what you do when you're programming an airline reservation system is make everything subservient to the customer's existing processes, both automated and manual. Your job is not to enlighten these people about the world of objects; your job is to create a system that is as invisible as it can be.
Having said all that, it's really cool when, having implemented an Open Travel Alliance-compliant XML front-end to a system, you can prototype all kinds of smart clients and smart searches.