Personal Web Services – The Unnecessary Business

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.

Continue reading Personal Web Services – The Unnecessary Business

Optimistic Concurrency – A False Panacea

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.]

Continue reading Optimistic Concurrency – A False Panacea

Thoughts On Creating An Infoset For Windows Live Services Platform

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]

Continue reading Thoughts On Creating An Infoset For Windows Live Services
Platform

Adding Extensibility to JSON Data Formats

How does one version a JSON message? How does one make it backwards or forward compatible? This may not be an issue when one's own Javascript is talking to one's own server via JSON but once you throw in creative use of script tags with src attributes or environments other than the browser these issues become relevant.

Continue reading Adding Extensibility to JSON Data Formats

Adding Namespaces to JSON

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.

Continue reading Adding Namespaces to JSON

Building A Services Platform – An Ode To Redundancy

Microsoft is a platform company which means that we like to take re-usable bits of functionality, wrap them up and make them widely available. The problem is that when a bit of functionality is not well understood trying to create a platform feature to address it will almost certainly result in something that either functions badly or not at all. The trick to good platform design is to know what to leave out and anything that deserves the title "Research" must be in the 'leave out' category.

In the services world there are numerous problems that richly deserve the title "Research". Almost anything having to do with latency optimization for read/write or real time data, most interesting security problems, almost all interesting privacy problems, just about all worthy service development language/IDE problems, etc. These are all areas that everyone is grappling with but which aren't well understood and where the industry needs to experiment.

But as this experimentation goes on the end result is what looks like a lot of redundancy. As each service deals with its own variant of the previously listed issues they tend to re-invent what looks like the same functionality. This sort of thing drives management batty because redundancy == waste in their minds. But it a'int necessarily so. Redundancy can be incredibly useful when it is stimulating learning. It is exactly this sort of redundancy, both within Microsoft and across the industry, that gives us the experience we need to move a problem from 'Research' to 'Development' and then into the platform.

Nevertheless I get more than a few odd looks from my fellow Microsofties when I explicitly say "Yes, I know your feature Y looks like something Group X is doing but Group X hasn't shipped their feature and anyway feature Y isn't well understood. So please, ship! Ship! SHIP!"

But really, my fellow Microsofties shouldn't be at all confused. A true platform maven doesn't believe in 'do it once', a true platform maven believes in 'do it right'. Until we know what 'right' is we need to experiment.

AJAX is great, except for the J and the X

AJAX has been great for the services community. By adding asynchrony it's possible to build services that can retrieve data in the background and remain interactive with the user. This is not only great for building more powerful service interfaces but it also provides us with a critical tool in defeating latency by allowing for services to be built out of other services down on the client instead of having to mash things up on the server. I suppose life would be good then if it weren't for one tiny problem – writing code in AJAX sucks. It is, I believe, time to move beyond Javascript to a byte code environment and beyond XML to a data language that can be reasonably versioned and is truly performant.

Continue reading AJAX is great, except for the J and the X

Windows Live – It's About Services (or maybe ads)

Sigh…. I know… I know… Microsoft… evil… proprietary… no cross platform… Windows über alles… etc. Whatever. Look folks, this is really easy. I work for Windows Live and my mission as handed to me by my boss, his boss and his boss's boss is simple – Make money on services.

Continue reading Windows Live – It's About Services (or maybe ads)

What My Group Does For Microsoft

My daughter just went to bed and I need to go to sleep too since I have the night feeding so I'll keep this relatively brief (for me). My group at MS (which is led by Bill Zissimopoulos (Dev Lead) and myself (Group Program Manager)) has the following responsibilities:

  1. Provide guidance to Windows Live groups on how to design their external interfaces

  2. Provide a software as a service platform for Windows Live properties

  3. Provide a software as a service platform for external properties

  4. Hire "A" Players

Continue reading What My Group Does For Microsoft

SOA Lifecycle (SOAL) – How to Make SOA Work In the Enterprise

The Enterprise SOA vision is all about composite applications. These are applications formed out of numerous independent web services all working together to provide some greater functionality. Except, how exactly do you define how 20 or 30 loosely coupled services interact to form a composite application? How do you deploy 20 or 30 services written in 20 or 30 languages for 20 or 30 different platforms in a sane way? And if you do manage to actually design and deploy the beast, how do you monitor it? The tools needed to make SOA work in the real world mostly don't exist yet. That's o.k. though because most Enterprises are just taking their first baby steps down the road to SOA. So we have a little time to get our act together. This article lays out a vision for how an architecture that will allow enterprises to maximize SOA's benefits.

Continue reading SOA Lifecycle (SOAL) – How to Make SOA Work In the
Enterprise