SQL for Cloud Computing: Microsoft SQL Data Services

More Resources SQL Data Services Portal SQL Data Services Dev Center SQL Data Services Documentation SQL Data Services Team Blog

In most organizations, Web applications rely on an accompanying database infrastructure to store data and service queries. This infrastructure requires constant management by IT Professionals. Before you deploy an application, you must consider whether you have sufficient capacity for your data, whether the infrastructure has enough redundancy to provide the level of availability you need, and how variable usage and load might affect performance.

The onsite, server-side data platform also has a number of limitations for evolving development patterns. For example, Web applications that rely on Microsoft Silverlight™ or Flash to drive presentation and interactivity don't work well with the traditional post-back model for data population, and are better suited to a service-oriented architecture. Similarly, mashup applications must be able to consume data as a service, rather than through a tightly-coupled connection to a back-end database server.

Cloud-based data platforms such as SDS have evolved to provide answers to these constraints and limitations, thereby giving you more time and freedom to innovate with data-driven solutions. Over the course of this paper we'll take a closer look at how SDS works and how you can use it in your own applications.

What Is SDS?

SDS is an Internet-facing database that provides a robust, secure, and flexible alternative to traditional onsite database infrastructures. SDS encapsulates a set of services you can use to store, retrieve, and manipulate any amount of data, from a few kilobytes to several terabytes.

These services are exposed through standards-based interfaces such as Simple Object Access Protocol (SOAP) and Representation State Transfer (REST), making them accessible from virtually any programming language and development environment. SDS also provides a flexible entity-based data model, so you can map any data source to the cloud regardless of schematization or structure.

Why Use SDS?

SDS is a truly enterprise-class database service that you can use to extend your on-premise applications or to develop new and innovative cloud-based solutions. Let's start by looking at some of the features that SDS can offer you as a developer. There are three key areas in which SDS provides advantages:

Flexibility and scale

When you use SDS, your applications can scale to any size without hitting infrastructure limits. Support for data partitioning means you can perform parallel operations against SDS and achieve extremely high throughput rates. You can also access your data at any time and from any device that has an Internet connection and support for HTTP. From a business perspective, the "pay as you grow" service model helps to keep your start-up costs low and ensures that you only pay for the storage you use, which results in a lower total cost of ownership (TCO).

Business-ready reliability and security

SDS is built on tried and tested Microsoft Windows Server® and SQL Server® technologies, which together with published service level agreements (SLAs) can help ensure enterprise-class performance and reliability. SDS stores and manages multiple, geo-redundant copies of your data to protect against loss, and ensures that transactional consistency is maintained across these copies. You can also define the geographic locations in which your data is stored to help reduce latency and increase response times.

The confidentiality and privacy of your data is of paramount importance. SDS provides secure login access with support for Secure Sockets Layer (SSL), and you can implement further authentication and authorization at each level of the data model.

Developer agility

SDS currently exposes Web services over the SOAP and REST protocols, with support for other protocols such as JavaScript Object Notation (JSON) and Atom Publishing Protocol (AtomPub) expected soon. As such, you can program for SDS from virtually any language or environment--all you need is access to either a SOAP stack or an HTTP stack. You can query your data by using a simple text-based query syntax, based on the C# Language Integrated Query (LINQ) pattern.

The flexible data model does not require schemas, which means you can rapidly provision your data without first creating tables, columns, and relationships. SDS supports familiar String, Decimal, Boolean, DateTime, and Binary property data types, and you can also store virtually any type of content as a binary large object (BLOB).

Getting Started

Registering for the Service

You can try out the private beta version of SDS for free. To register, visit the SDS home page and follow the instructions there.

Before you start programming with SDS, it's important to get an understanding of the basic architecture. The SDS data model consists of just three hierarchical levels of containment: authorities, containers, and entities, known collectively as the ACE model.

The ACE Model

In SDS, an authority is the top-level object. An authority can contain any number of containers, and a container can contain any number of entities.

Figure 1. ACE model

The following table shows the definition and purpose of authorities, containers, and entities.

Containment Layer	Definition	Purpose	SQL Server Analogy
Authority	Set of containers	Groups containers for accounting, security, and co-location	A SQL Server instance
Container	Set of entities	Groups entities for content and queries	An individual database (heterogeneous storage) or a database table (homogeneous storage)
Entity	Scalar property bag	A unit of storage	An individual record

Table 1: Definition and purpose of authorities, containers, and entities

In fact, authorities and containers are also types of entity. You'll see why as we move through the paper--you can use the same programming patterns to interact with SDS at any level of the data model.

A traditional relational database table has a schema that describes the row structure. In contrast, containers in SDS are not schematized. There are no columns, and you can add different types of entity, each with a different set of properties, to the same container. We'll discuss authorities, containers, and entities in more detail as we move through the paper.

The Programming Model

As mentioned earlier, you can use either SOAP or REST to perform CRUD (Create, Retrieve, Update, and Delete) operations against your data in SDS. The programming model is broadly similar in each case:

1. Set the scope of your operation (service, authority, container, or entity).
2. Perform the operation (create, retrieve, update, or delete).

If you use the SOAP protocol, you create a Scope object and then set properties on this object to target specific authorities, containers, or entities. For example, you can use the following C# code to create an authority:

using (SitkaSoapServiceClient proxy = new SitkaSoapServiceClient())
{	
        proxy.ClientCredentials.UserName.UserName = "myUserName";
        proxy.ClientCredentials.UserName.Password = "myPassword";

        //Use the empty scope to target the service level	
        Scope myScope = new Scope();

        //Create the authority
        Authority myAuthority = new Authority();
        myAuthority.Id = "exampleID";

        //Pass the scope and authority objects to the Create method
        proxy.Create(myScope, myAuthority);
}

Note: The next release of SDS will include multiple SOAP endpoints for different authentication methods. In this case, you will need to modify the using statement to specify which endpoint the proxy object should use.

REST, on the other hand, is a very simple, HTTP-based protocol that relies on URIs and basic HTTP verbs to set scopes and define operations. The scope of an operation is determined by the URI to which you address the HTTP request. Every time you create an authority, SDS creates an associated DNS record. For example, suppose you create an authority named miami. To scope an operation to the miami authority, you would address an HTTP request to the following URI:

https://miami.data.beta.mssds.com/v1/

 You can build on this root URI to scope operations to containers or entities within your authority, as in the following examples:

https://miami.data.beta.mssds.com/v1/<container-id>

https://miami.data.beta.mssds.com/v1/<container-id>/<entity-id>

Having established the scope of your request, you simply call the HTTP method that corresponds to the database operation you want to perform. The following table illustrates how the principal HTTP verbs map to the core CRUD operations in SDS:

HTTP Verb	SDS Operation
POST	Create
GET	Fetch, Query
PUT	Update
DELETE	Delete

Table 2: Mappings between HTTP verbs and SDS operations

In the remainder of this paper, we'll focus on how to use SDS with the REST protocol, because REST offers broader platform support. However, the key concepts are the same regardless of your choice of protocol.

Note: For the public beta version, the service URI is expected to change from https://data.beta.mssds.com to https://data.database.windows.net. Furthermore, the service will only be available over https.

Email Article Print Article Download PDF Digg del.icio.us Newvine furl StumbleUpon BlinkList Newsvine Magnolia Facebook Tailrank Slashdot Technorati Google Bookmarks Yahoo Favorites Windows Live Ask