Yesterday, Part 1 in this series introduced you to the basic fundamentals behind SQL Data Services (SDS).
The official definition of SQL Data Services is below.
“Microsoft SQL Data Services (SDS) offers highly scalable and Internet-facing distributed database services in the cloud for storing and processing relational queries. SDS can help you develop and provision new applications quickly with REST and SOAP based web protocols.”
In review, we covered the design principal (ACE) which included a brief summary of the roles played by the Authority, Container and Entity concepts.
Today’s entry will cover authentication, data interfaces and the SQL Data Services SDK.
The SQL Data Services SDK
To begin working with SDS, it is highly recommended that you download and install the SDS Software Development Kit (SDK).
The kit is rather lightweight (ironically) but contains some tools we will refer to shortly.
The SDK (CTP) can be downloaded from this location.
SDS Explorer
SDS Explorer, which comes as part of the SDS SDK, is a handy tool which uses the REST interface. It can be used as a light querying utility and an especially good debugging tool and helper for writing queries.
SDS Explorer in action
ST Utility
The st.exe application is a shell/console application which is designed for batching/bulk operations.
It is predominantly designed to be used via the “SSDS Command Prompt” which launches the shell with environment variables set.
This utility should be viewed as an administrative utility, it’s designed to perform all the tough grunt work, like bulk uploading of entity data, and various administrative tasks.
ST Utility Help Screen
Authentication
SQL Data Services has been designed with a federated security model in mind. As such, SDS supports two authentication methods in the initial release.
The first (and easiest to use up front) is Basic Authentication (username + password).
The second method is token based authentication.
From the official documentation: “SQL Data Services (SDS) supports authentication and authorization via tokens issued by the .NET Access Control Service.”
To use token based authentication, you must live with the following restrictions:
For more information, see .NET Services [http://www.microsoft.com/azure/netservices.mspx] which at this time is in private CTP (Community Technology Preview).
The majority of samples provided will use Basic Authentication, until such time that I can review the token based approach in more detail.
For more on token based authentication refer to this MSDN page [http://msdn.microsoft.com/en-us/library/cc984294.aspx]
SDS Data Interface Support
Now that we have covered authentication, let us take a look at the ways we can access and manipulate data.
SDS supports browser based queries, Simple Object Access Protocol (SOAP) and Representational State Transfer (REST).
The majority of sample I’m using are based on using the both the browser and the SOAP interface, however I will endeavour to cover REST where applicable.
Putting It All Together
In the next article, we’ll start really getting stuck into SDS. You’ll need a copy of Visual Studio (preferably 2008) and have successfully registered for the SDS CTP (as covered in the previous entry).
Summary
In today’s entry we have briefly covered the available authentication and interface options for the initial SDS release.
We’ve also reviewed the helper utilities which are available in the Software Development Kit.
In the next article, we will look at bringing all of these interfaces, tools and authentication techniques together and create some data in the cloud!
