Getting started

Remember that SSDS is a service provided by Microsoft. So, the first step is creating an account. You can register here: http://www.microsoft.com/sql/dataservices/default.mspx

After receiving the confirmation you’ll be able to access the services.

Adding the service reference

In order to use the SSDS instance, we need to add a reference to the SOAP service. The URL is http://data.beta.mssds.com/soap/v1?wsdl. Remember that this is a beta instance, so the URL can be changed in any moment.

Creating entities

SSDS has a defined structure: authorities, containers and entities. Then, we need to create those entities in order to use the service.

Creating the proxy

When creating the proxy, you should only submit the client credentials.

Note: Sitka is SSDS’ codename.

public static SitkaSoapServiceClient GetProxy()
{
    SitkaSoapServiceClient proxy = new SitkaSoapServiceClient("SitkaSoapEndpoint");
    proxy.ClientCredentials.UserName.UserName = "---"; //TODO: Add username
    proxy.ClientCredentials.UserName.Password = "----"; //TODO: Add password
    return proxy;
}

Creating authorities

Creating an authority is just a simple call to the service. In this case the Scope will be empty, because we’re creating a new one.

public static Authority CreateAuthority(string id)
{
    Scope scope = new Scope();
    Authority authority = new Authority();
    authority.Id = id;
    GetProxy().Create(scope, authority);

    return authority;
}

Creating containers

Creating a container is very similar to creating an authority. The only difference is that now the container is going to be scoped to an authority, so we need to specify that in the Scope.

public static Container CreateContainer(string id, Authority authority)
{
    Scope scope = new Scope();
    scope.AuthorityId = authority.Id;
    Container container = new Container();
    container.Id = id;
    GetProxy().Create(scope, container);

    return container;
}

Creating entities

Now we’re all set to add entities to our container. Given that the model is very flexible, in order to create entities we only need to provide the id and the values.

Note that the entity will be scoped to an authority and a container.

public static Entity CreateEntity(string id, Dictionary<string, object> values,
        Authority authority, Container container)
{
    Entity entity = new Entity();
    entity.Kind = "default"; //Optional metadata
    entity.Id = id;
    entity.Properties = new Dictionary<string, object>(values);
    SitkaSoapServiceClient proxy = GetProxy();
    Scope scope = new Scope();
    scope.AuthorityId = authority.Id;
    scope.ContainerId = container.Id;
    proxy.Create(scope, entity);

    return entity;
}

Querying entities

Taking into account that the queries are text-based, querying over entities is just a call to the service.

public static Entity[] Query(string query, Authority authority, Container container)
{
    SitkaSoapServiceClient proxy = GetProxy();
    Scope scope = new Scope();
    scope.AuthorityId = authority.Id;
    scope.ContainerId = container.Id;

    return proxy.Query(scope, query);
}

Putting all together

That’s it. We have our data layer implemented without having an SQL server. We’re just using an on-the-cloud service and we don’t have to worry about deploying, maintenance, etc.

Putting all together, we can use the methods defined in this post like this:

static void SSDSSample()
{
    // Creating authority
    Authority authority = CreateAuthority("testauthority");
    // Creating container
    Container container = CreateContainer("testauthority_container", authority);

    // Adding entities
    for (int i = 0; i < 10; i++)
    {
        Dictionary<string, object> props = new Dictionary<string, object>(3) {
                {"name", "name" + i}, {"address", "address" + i}, {"tel", "tel" + i}};
        CreateEntity("person" + i, props, authority, container);
    }

    // Querying entities
    Entity[] retrievedEntities = Query("from e in entities select e", authority, container);
    foreach (Entity entity in retrievedEntities)
    {
        Console.WriteLine(entity.Id);
        foreach (KeyValuePair<string, object> val in entity.Properties)
        {
            Console.WriteLine(val.Key + ": " + val.Value.ToString());
        }
        Console.WriteLine();
    }
    Console.ReadKey();
}

Motivation

The motivation of this service is to provide a scalable data storage and query processor utility "on the cloud". Using this approach, the costs of infrastructure and support decreases, since that responsibility relies on Microsoft and not in the software provider.

Besides, more and more new Web applications need to save less complex data, with a high service level agreement (SLA).

Implementation

SSDS is built on the SQL Server technology, using the SOAP and REST communication protocols. Some of the features are:

• No schema. Since the data model is flexible, we now can have heterogeneous entities (serialization becomes more complex).
• Pay-as-you-grow model. The space used can grow as you need it.
• SLA covering high availability, performance and redundancy.
• Easy to develop. In order to use the data we only need to call the appropriate Web Service.
• The queries are text-based with a C# LINQ pattern.

The organization model is really simple:

• Customers are the organizations that are using the SSDS. Customers have many Accounts.
• Accounts are the billing entities. An account has authorities assigned.
• Authorities are the ones that organize the data containers. It defines the location and security policies of its containers.
• Containers are the scope for the entity storage and query. For example, each employee may have a container with its personal data.
• Entities are the storage unit of SSDS, for example the employee’s education information.

Conclusion

I think that this service has a lot of potential. With the growth of Web2.0 and social applications, we need a way of deploying small applications with a reliable data access. Obviously is very expensive to deploy and maintain a data base server, so having that service on-the-cloud is a very interesting alternative.

From the technical point of view, the no-schema structure is very interesting. Still, I guess that it can have a negative impact in the serialization process.

On the other hand, this service is still in working process, so we’ll be awaiting for new features to come.