Late Delivery

Round my way, there’s one thing you can guarantee every Christmas. I’m not talking about snow here by the way; I live in England after all, and the best we can hope for is a cold drizzle. No, the most regular feature here — more regular than door-to-door carol singers, arguments with relatives and plum pudding — is the story in the local newspaper about the Christmas card posted fifty years ago that has only just arrived. These stories are always good copy, because there are a lot of amusing angles to them. For instance, is there a whole pile of undelivered Paleolithic mail lying around in the corner of every sorting office, just waiting to be let out one item at a time? How many families have been torn apart by the apparent non-delivery of that one card? And do they charge extra for delivery because the postage rates have gone up in the meantime?

To me, however, the interesting question is this: should you be astounded at the incompetence of the postal authorities in failing to deliver the mail for so long, or should you be impressed with them for delivering it in the end, no matter how late? Obviously, the answer depends on the relative time-dependence of the item being posted. In the case of a Christmas card, if it’s a month late, it might as well be thrown away, but if it’s an important legal document, it doesn’t matter so much if it’s a bit late, as long as delivery is guaranteed.

Everything we’ve looked at so far in this book is to do with relatively closely-coupled systems, where, setting aside considerations of bandwidth, you can develop the software as if it was going to run on a single central server. Remember that phrase “location transparency”? Even when we talked about serializing our data for efficiency in Chapter 3, we made the assumption that the client and the server would both be running simultaneously, and would maintain good, if slow, communications with each other. But what if one of them wasn’t running at all? Could we still write a system that made any sense?

The answer to this last question is, inevitably, yes. In the last chapter, we looked at how Microsoft is making transactions mainstream by absorbing them into the Windows operating system. In this chapter, we look at how they are making guaranteed messaging mainstream by absorbing that into the operating system too. The code name for Microsoft Transaction Server was Viper — a name that has all but disappeared from the lips of all but Redmond die-hards. The code for Microsoft Message Queue was Falcon, a name that you still see on documents. Well, would you rather be promoting a snake or a bird of prey?

© 1998 by Wrox Press. All rights reserved.