A real world example of context over object key

While writing this entry I got to thinking about what was a good real world example of the benefits of a context-based approach to sessions and state management. The one I came up with is fairly obvious (particularly with 20-20 hindsight): snail mail.

So how is this a good example of referencing via context? Well let's look at how we might model this architecture using two different approaches. In both cases, obviously the goal is to get some information (the content of the letter) to an entity that can deal with it (the person/organisation on the front of the envelope).

In the first approach (WS-RF) the address on the envelope is a hard reference to the ultimate receiver and therefore I would be required to deliver the message directly to that house. If the individual moved, then I'd need to figure out where he'd gone (maybe he would stick a redirect message on the front-door, but there are obvious limits to how much effort I'm going to go to there).

Now let's go back to the way the snail-mail post really works. I'm fairly sure mail delivery works pretty much the same throughout the world, but here in the UK when you've addressed and stamped a letter you stick it into a postbox - you never deliver it by hand. Now that letter doesn't go directly to the individual on the address; it is routed via a sorting office, which may then pass it to other offices in this country or even abroad. Ultimately it'll end up in a sorting office that is local to the final destination and a postman will be given the job of delivering the letter (probably at 1pm in the afternoon if my post is anything to go by!)

So, implicit with every address I put on a letter is the address of the local sorting office. They know where the ultimate receiver is and I don't need to (which is good because I'd hate to have to run something like MultiMap each time I wanted to find out where someone lived). If he's moved, he can arrange to have mail diverted to a new location simply by telling them. Obviously this can't go on forever and eventually becomes a matter of diminishing returns, but that's up to the householder.

In this case, the initial destination (service) for my letter is the post office (as I said, implicitly addressed in the physical world) and the context associated with the message is what I stick on the front of the envelope: it's my session information and is the same for all letters I write to that individual. How the post office "service" gets the content of my letter to the recipient is a backend implementation choice. They can (and have) changed that implementation many times over the years, but the way I write my envelopes (the context) never changes.

If the ultimate receiver does eventually move, I may get a new context from them (setting up a new session) or the equivalent of a 404 (Not Found) message.

Trying to be even handed, I suppose another way of approaching this would be to say that the binding of SOAP-to-PostOffice implicitly does all of this routing/redirecting for me, but that then relies on a specific medium. I'd like this to work no matter what carrier medium I use.

You could also argue that the post office (or actually the sorting office) that is implicitly addressed in the physical world suffers from the same static address problem. But it doesn't - as far as my letter is concerned it is stateless; the letter could just as easily be dealt with by any sorting office in the country (hey, the model allows me to post my letter anywhere after all). So this is an example of where any "service" that offers the same functionality (dealing with post in this case) can be used: I'm not tied to a specific instance.

Of course another way of looking at this is that it's all just
hierarchical naming again. However, I think it just shows that abstracting the *what* (my ultimate receiver) out of the *how* (the post office in this case), makes for a scalable system. (Except at Christmas, where they almost never guarantee delivery dates for postcards!)