OakLeaf Systems: SQL Data Services to Gain New ADO.NET Data Services Client Model

Saturday, January 03, 2009

SQL Data Services to Gain New ADO.NET Data Services Client Model

Note: I wrote this post on 11/2/2008, but it got lost in the post-PDC shuffle.

Pablo Castro describes the forthcoming Astoria client model for SQL Data Services (SDS) in his ADO.NET Data Services in Windows Azure: pushing scalability to the next level post of 11/1/2008. The rationale for the new model is:

.NET types are a great solution for the scenarios where the schema is known and more or less bounded, and will continue to be the primary way of creating services in that context. However, we needed something else to handle the high-end side of the spectrum.

And here’s an introduction to the something else:

To address this need we introduced a new interface that data services can optionally implement. We already had the internals of the system organized more or less like this, but didn't expose it in the first release. The idea is that there is main split between the "upper half" of the runtime that deals with URL translation, LINQ expression tree generation, interceptors, policies and all aspects that make a Data Service look like a Data Service.

The "bottom half" is the "data service provider", and is responsible for describing the shape of the service among other things. There are two built-in "data service providers", the Entity Framework provider which is what you use when you create a data service over an Entity Framework model, and the reflection-based provider which is what you use when creating a service on top of an arbitrary object graph. With the new change you can now create new implementations of these data service provider thingies that can obtain and manage metadata any way they want.

However, Pablo adds a caveat about the high-end side:

At the same time, addressing the needs for the highest-end services out there is important, so many (if not all) of these changes will eventually make it into the shipping product so that other folks out there can use them if they chose to. Beware that these interfaces are not designed to be "nice", but rather optimized for control and efficiency, so it may not be exactly a fun experience, but you'll get all the scalability you'll need out of them.

Taking advantage of “highest-end services” involves a substantial amount of manually written code to provide an Astoria front end to even the trivial Azure TableServices that Pablo and Niranjan Nilakantan described in their Windows Azure: Modeling Data for Efficient Access at Scale PDC 2008 session.

I believe most developers will stick with the original front-end for SQL Server Data Services (SSDS), as described in my SQL Data Services (SDS) Test Harness Updated to the Windows Azure Services Platform post of 11/1/2008 until the Astoria team provides a graphical model designer and code generator that’s at least a sophisticated as LINQ to SQL’s O/RM designer or the SDS Team implements promised schemas for SDS entities.