How ADO.NET Data Services came to be (formerly known as Project Astoria)

alexbarnett — Thu, 21 Aug 2008 02:16:00 GMT

Pablo Castro has recounted some of his timelined memories about how "Project Astoria" evolved from a lunch time conversation to bits in .NET 3.5 SP1 and Visual Studio 2008 SP1 now known as ADO.NET Data Services Framework). Nice write up.

Three memories of my own to add to the story:

1. I was reading up on the whole REST thing in the summer of 2006 - its origins, philosophy and design patterns. I knew there was something interesting going on and some potential dots to join, but I wasn't sure which dots...So I collated and circulated a bunch of research / links to the team, then blogged the links (I liked How I explained REST to my wife. More recently see Explaining REST to Damien Katz). I got a few proverbial (and some literal) blank stares as I shared my enthusiasm for REST, asking how we could apply the ideas to the various projects we were working on. It was Pablo, and (as Pablo attests) Britt Johnston (now a PUM for SQL Business) who were able to develop the initial conceptual leaps into something more concrete like a Think Week Paper and a prototype demo.

2. When it came to brainstorming the code name, the team agreed on a "cloud" theme. A number of proposals were floated around along with their rationales, including "cumulus" and "cirrus". We were then advised that city and town code names were legal-safe. So there we were, struggling to agree on some city or town name we all liked (or at least not hate nor be confused by..."how about Nameless?"...), and then Mike Pizzo's proposal came in: "Astoria - hey, it's the cloudiest city in the USA!" (at least it was in 2006). Sold.

3. I think my favorite memory of all is the reaction Gary Flake provided (of Microsoft's Live Labs) to the prototype Pablo demo'd at one of the pitch meetings: "As God himself would have designed it!" Dr Flake exclaimed..."Cool", I thought to myself - "but does that mean no REST for the wicked?"

Hyperdata, interoperable data web and other loosely related concepts

alexbarnett — Wed, 24 Jan 2007 02:12:00 GMT

Apologies in advance. I'm attempting to couple loosely related threads here...I have no conclusion.

Leigh Dobbs originally published Connecting Social Content Services using FOAF, RDF and REST for XTech 2005, where he analysed a sample of eight APIs (including the usual suspects - del.icio.us, Last.fm and Upcoming).

Dobbs speculated as to why those services lacked 'hypermedia' support.

Hypermedia: links and pointers to other resouces that are included in a service response to allow further discovery and interaction of those other resources. Or, to paraphrase Danny Ayers, 'Hypermedia should be hyperdata and Hyperdata is 'the Semanitc Web'.

Back to Dobbs (my bold):

"Lack of linking can be attributed to three factors. Firstly, discussion of the REST style have, to date, been largely centred on correct use of HTTP rather than the additional benefits that acrue from use of hypermedia. Secondly, the RPC style that the majority of the services follow, promotes a view of the API as a series of method calls, rather than endpoints within an hypertext of data. Thirdly, the use of API keys prohibits free publishing of links, as given URL is only suitable for use by a single application, the one to which the key was assigned."

Mike Dierken (a 'Senior Troublemaker') last week provided another reason why the desired 'hypermedia' (or 'hyperdata') support might be missing from those services analysed by Dobbs...again, my bold:

"This review notes that nearly all services do not use hypermedia which I think is unfortunate but understandable. I've always had a problem resolving the desire to be flexible in allowing the internal data identifiers to be used in many situations and the desire to be trivally easy for clients to access other resources by simply using links - the mashup problem. One issue I have is that the server-side software that generates the representation might not know all the possible resources made available by sibling services. Think of a US postal zip-code - if you have a service that provides weather based on zip code, should that representation also be responsible for linking to all other services - either provided by your system or some other server - that could potentially take in a zip-code? My approach is to return both direct links to known resources (tagged appropriately) as well as the short-form of the identifier, the plain zip-code for example. Microformats sort of do this, but it's a style that isn't well applied by data services."

I'll give Danny the final word (for this post at least ;-) on Hyperdata:

"I'm still convinced that working at the syntax/grammar level without any common data model/language (i.e. semantics) is fundamentally flawed when it comes to global interop. On the web interop starts with URIs for ~~concepts &~~ resources and their relations, not angle brackets. [PS. reworded - amounts to the same, but sounds less abstract]"

More <loosely> related reading:

Semantic Web & Data Integration by Kingsley Idehen
Network-Oriented Architecture and Perfect Programming by Jason Kolb
Every webservice is an island and Understanding the Future of Data: Data 2.0 by Alex James (also see Data 2.0, a response by Danny Ayers to Alex James' post)

Alex Barnett blog : Data, Web, ROA

How ADO.NET Data Services came to be (formerly known as Project Astoria)

Hyperdata, interoperable data web and other loosely related concepts