SQL Server Data Services to Deliver Entities from the Cloud

Complementing its lowering the size barrier to the Office Live Workspace, SharePoint Online and Exchange Online services, Microsoft announced a SQL Server Data Services (SSDS) beta on March 5, 2008. Ray Ozzie mentioned SSDS in passing during his MIX08 keynote.

Updated 3/6/2008 and 3/7/2008

SSDS provides an on-demand, pay-per-use data model, including the following features:

• Flexible, schemaless entity model, which lets users add new attributes to the entity type when needed; the system indexes them automatically.
• Simplified data types for properties: string, numeric, datetime, boolean and binary
• REST-based and LINQ-like queries; SOAP is supported also
• Plain old XML (POX) is the only wire format currently available; AtomPub is promised
• No projections; the unit of storage is a complete entity
• Highly scalable by partitioning of sizes in the 10s of GB
• Secure data access with SSL, LiveID authentication, and authorization at the account (billing unit), authority (collection of containers), container (set of entity sets), type (entity type) levels.
• Data synchronization and bulk uploads with the Microsoft Sync Services.
• On-premises version (presumably ADO.NET Data Services, a.k.a. Astoria)

SSDS is scheduled for 2009H1 deployment with an invitation-only beta open for registration now; an open beta will start in July 2008. During the beta period, the SSDS team intends to update the services every eight weeks with features added or altered in response to user feedback.

The following additional documentation was available today: SQL Server Data Services FAQ and SQL Server Data Services overview. There's no mention of Entity Framework, ADO.NET Data Services or Entity Data Model in the Web-based documents currently available.

The strangely named SSDS blog (The Long Term Store cast) is now live with autobiographical posts by two SSDS architects. The Long Term Store moniker probably derives from Microsoft's belief that archiving will be a major SSDS use case. There's a placeholder for an SSDS blog on MSDN with a single Coming Soon post.

Update 3/7/2008: The following MIX 08 presentation on SSDS is available online:

BT05 - Introducing SQL Server Data Services (WMV)

Thursday, March 6 8:30 AM - 9:45 AM, Delfino 4005
Speaker(s): Nigel Ellis
Audience(s): Business, Technical
Session Type: Breakout

Come learn about our new cloud-based storage service and how it addresses a number of business scenarios. This session introduces the new Microsoft SQL Server Data Services, as well as outlines business models and terms.

The documentation uses http://mydomain.stratus.microsoft.com/ChildrensBooksContainer1 as a sample REST request for an EntitySet, so it's reasonable to assume that the service is named Stratus. (Cirrus was the codename for Microsoft Access and Cumulus was the codename for Windows NT's erstwhile Object File System (OFS)).

Update 3/6/2008: Microsoft's Eugenio Pace says the codename was Sitka (a city on the Alaskan Panhandle) in his SQL Server Data Services - SDSDS - New version of LitwareHR post of March 5, 2008.

Astoria Similarities and Differences

It's obvious that ADO.NET Data Services and SQL Server Data Sources are related but they don't appear to share a common API. The current Astoria CTP supports Atom/AtomPub and JSON but not POX; SSDS only supports POX. SSDS promises AtomPub for the future and the Astoria team promises POX.

Update 3/6/2008: Francois Ajenstadt, director of project management for SQL Server, said the following in reply to my "SSDS's API appears to have diverged from Astoria's, which is surprising" comment to the Data Platform Insider blog's Announcing SQL Server Data Services post:

The goal is to bring the API's between SSDS and Astoria closer together closer to Release. Stay tuned.

There's no indication that SSDS support associations or relationships, which is surprising.

Information Week's J. Nicholas Hoover's Microsoft Extends SQL Server To The Web With Data Services article of March 5, 2008 states on page 2:

Microsoft's wrapping the "entity data model" into SQL Server Data Services, meaning that in addition to the traditional data model, developers will be able to easily create containers for a set of data and define data entities like "Customer" or "Order" that contain all the data types relevant to a customer or an order and can be altered at will, using technology Microsoft developed in a project code-named Astoria.

However, the preceding paragraph has no attribution. As I read the tea leaves, SSDS doesn't support SQL Server's "traditional data model."

Hoover compares ADO.NET data sources with Amazon S3's unstructured storage instead of their SimpleDB. My Amazon Announces Beta of SimpleDB Web Services in the Cloud post of December 14, 2007 and Dare Obasanjo's Amazon SimpleDB: The Good, the Bad and the Ugly post of December 21, 2007 analyze SimpleDB's feature set.

Update 3/7/2008: Microsoft's party line appears to be: "SSDS is not a SimpleDB compete," which was Nigel Ellis's answer to a question after his presentation. I doubt if anyone buys that line. The primary differences at present between the two services are SSDS's use of an industrial-strength database engine instead of a Erlang application, LINQ-like queries, data synchronization, and simple data types: string, numeric, date/time, and binary (base64-encoded).

(Queries use LINQ syntax but appear from Nigel Ellis's demo to be late-bound and thus untyped.)

It's now obvious why the Astoria team didn't rejuvenate the free Live Labs ADO.NET Data Services Online Service demonstration. Its schema wizard made designing entities relatively easy, but SSDS automatically builds its schema under the covers (and keeps it there).

Entity Data Platform Backstory from the Microsoft Business Intelligence Conference

The SQL Server "Katmai" to Deliver Entity Data Platform and Support LINQ post of May 25, 2007 covers references to the Entity Data Platform, which Data Architect Michael Pizzo described as follows:

Microsoft envisions an Entity Data Platform that enables customers to define a common Entity Data Model across data services and applications. The Entity Data Platform is a multi-release vision, with future versions of reporting tools, replication, data definition, security, etc. all being built around a common Entity Data Model. [Emphasis added.]

The Katmai CTP Scheduled for June post of May 23, 2007, includes a link to the video of Ted Kummert's keynote to the Microsoft Business Intelligence Conference. Comments about LINQ and the Entity Data Platform start at 46:00 into the presentation.

Register for the Beta

SSDS received brief coverage in today's Microsoft Unlocks the Power of the Web for Connected Customer Experiences press release.

Register for the SSDS beta at http://www.microsoft.com/sql/dataservices/default.mspx.

You must enter 5000 or more as the number of employees to register. This restriction formerly applied to Microsoft's SharePoint Online and Exchange Online services but was removed on March 2, 2008, according to the Microsoft to Expand Microsoft Online Services for Businesses of All Sizes press release. I was surprised to see the restriction for this beta.

Update 3/5/2008 1630 PST: An anonymous commenter says:

There is no restriction to the size of your company... big or small can sign up.

Please make this correction...

which I've done. I've verified that the number of employees and other company details no longer are marked as required fields.

Update 3/6/2008: The commentator turned out to be the Microsoft person in charge of the signup form who said it was a bug, which they fixed.

Technorati tags: SQL Server Data Services, SSDS, Stratus, Entity Framework, Entity Data Model, LINQ to Entities, LINQ to SSDS, LINQ, REST, Entity Data Platform, Sync Services