SQL Azure Team Blog : Data Access

Accessing the New Relational SDS with REST

davidrob — Fri, 20 Mar 2009 19:16:45 GMT

Hi Everyone! This is Lev Novik, one of the architects on the SQL Data Services Team.

We get a number of questions about whether or not we have abandoned or downgraded REST access to SDS, and if so, why. To summarize: not at all --- rather than abandoning REST, we intend to support it in precisely the ways and places where we believe most people want it. Allow me to explain.

Consider an average (web) application today. Most often, it consists of a:

client (often running in a browser),
mid-tier business logic (often running in a web server), and
back-end storage (often a relational database).

What are the protocols that are typically used? Well, the protocol between the client and the mid-tier is usually HTTP and often REST; the protocol between the mid-tier and the back-end storage is typically the native protocol of the back-end database.

Well, with SQL Data Services, the situation is quite similar. In these scenarios:

SDS takes the place of the back-end database,
mid-tier business logic is running maybe in Windows Azure, or maybe outside,
and the client, well, the client is unchanged

In this world, we believe that you will continue to want to use the most powerful mechanism to talk from your mid-tier to SDS, together with the nicest database tools; and you will continue to want to be able to easily expose your web application to its clients in the most simple, elegant, and web-friendly way. This is why we concentrate on:

Exposing TDS (SQL Server native protocol) as the full-featured way to talk to SDS
Making it very easy for you to expose REST access to your SDS-based application.

To achieve the latter, we rely on ADO.NET Data Services (aka “Astoria”). Its very purpose in life is to make building data-driven REST services as easy as possible. For those who haven’t played with ADO.NET DS, I highly recommend it --- grab a favorite beverage, watch a quick introductory movie, get hold of a database of your own, and see what it takes to make a REST web service out of it (you might just have some of the beverage still remaining at this point).

But of course, your application is unlikely to be just a one-to-one mapping of a database --- you will want to build your own business logic, your own security policies, your own views, etc. ADO.NET Data Services allows you to implement these, and to make your creation into a real non-toy service (though this will certainly involve a few more trips into the kitchen!)

But that was SQL Server on your own dev box --- how does that work with SDS and Windows Azure? Well, we intend to make it work in much the same way:

Get set-up to develop Windows Azure services.
Create an SDS Database in the cloud, and load it up with your schema.
Create a Windows Azure Web Cloud Service Project in Visual Studio.
Add ADO.NET Data Service project item, and point it at the SDS Database (or at a local database with the same schema).
Develop your ADO.NET Data Service (security, biz logic, templates, etc)
Change the connection string to point to the real SDS Database in the cloud (if you used a local database for development)
Publish your service to Windows Azure.

And at the end, you have an SDS-based REST Service, configured just the way you like it!

Hope this made some sense!

--Lev

Jon Udell cURL's with SQL Server Data Services

Soumitra Sengupta — Thu, 28 Aug 2008 03:31:00 GMT

Just read Jon Udell's post on SQL Server Data Services (SSDS) here. Happy to hear that Jon was able to explore SSDS with cURL "within minutes of cracking open the SSDS documentation". Readers who are wondering what Jon is talking about, should read Jeff Currier, one of the guys writing real code that we ship in SSDS, talking about using cURL to explore SSDS here.

When few of us crazies started thinking of SSDS, a non-negotiable requirement was that developers should be able to start exploring and using the service quickly. There is so much going on in the cloud services space that if it took too long to experiment with a new service, we were afraid that developers will put it on the shelve and may never give it a spin. I know I do not like to spend months on something to see if I would use it. It was hard for us to "cover up" the SQL Server heritage of SSDS, but we argued that simplicity is a virtue that we should aspire to.

Jon hits on an interesting point when he says 'while the novelty of “just coding to a URL” on a Microsoft platform will undoubtedly attract some tirekickers who otherwise wouldn’t show up, the real draw will be the ability to exercise choice along the whole continuum'. Internally we use the words "reach" and "rich". We believe that to be a platform with large adoption, one needs to provide both "reach" (so that people from all other platforms can use you) as well as "richness" (so that people who use your platform exlusively have a rich set of tools to leverage). Today it is easy to see that SSDS is aiming to "reach" as many developers as possible. To do this we have to address "the continuum of access styles". Jon seems to be saying that we are meeting that goal. What do you think? Are we close? Are we way off base? Or we should not worry about the "continuum of access styles".

It will be interesting to hear from you all.

Eugenio Pace continues with his Litware HR app

kellyalt — Fri, 28 Mar 2008 10:22:00 GMT

Eugenio has published the 3rd installment of his article on building the Litware HR application that Nigel demonstrated at MIX08. Here he discusses enhancement to his data access layer by caching data locally. It is a good read.