When I think of say e-mail or IM or web pages or personalized home pages or single sign on or address books, I realize that there is really no good excuse, certainly not in the long run, for these services to be delivered in a centralized fashion. Why can't I just have a little box off in a corner of my house hooked up to my Internet connection that provides these services for me? Why can't I have my own little e-mail, IM and web server that hosts all of my content? At the very least I would maintain my privacy, something I have no hope of maintaining when a 3rd party hosts my content for me (even if the hosting service doesn't peak, doesn't leak and isn't hacked, I can safely assume the government is looking). But in addition to privacy I would also get better functionality since my little box would 'over provisioned' compared to the processing power allocated to users in a typical centralized service.
As soon as an Internet scale service expects to allow clients to both read and write data it's a sure bet that optimistic concurrency will come up. After all, how else do you solve the lost update problem without drowning in a sea of performance crippling locks? Better yet, implementing optimistic concurrency in a service is pretty trivial. You just need some kind of change indication system (dates, e-tags, updategrams, etc.) and a 1/2 decent transactioning system (available off the shelf) and you're pretty much done. But unfortunately all optimistic concurrency does is move the 'lost update' lump under the carpet and make it the client's problem. Moving the lump isn't bad but it does mean that before declaring victory you absolutely must be sure that your clients have a workable solution for the merge issue.
[Ed. Note: I updated the article in response to a number of comments on the web.]
As part of creating a service platform, e.g. a platform focused on the creation and consumption of services by other services, we realized that we needed a consistent way to model messages within our system. This isn't about creating some universal message model for everyone, everywhere. This is strictly about creating a message model for our use. But I think the issues we are dealing with are fairly universal so I thought it would be interesting to share our current thinking. Please keep in mind that this is all very preliminary and subject to change without notice.
[Note: Updated to add a section on extensibility]
As part of my job I am thinking deep thoughts about what protocols Windows Live should expose and right now I'm pushing hard for JSON to be a premier protocol data format. I like JSON because it makes it extremely easy to persist hierarchical data structures which account for the bulk of the messages that Windows Live needs to move around. But JSON does have a number of issues that I think need to be addressed, specifically: namespaces, extensibility, schema/type support and relative linking. In this article I make a proposal for how to address namespaces. I will address the other issues in future articles.