Typical Scenarios

To see how these key features of SDS can benefit organizations, let's consider some common business application scenarios.

Data Hub

In a data hub scenario, you typically want to enable different mobile and remote users to collaborate using the same set of data. Consider an insurance company that has a large mobile sales force consisting of more than five thousand people spread out across North America. Keeping customer and pricing data synchronized across the entire sales force is a constant problem. The first part of the problem is getting new customer contact information from the sales force into the internal finance systems. The second part is getting new pricelist information out to the sales force. The insurance company needs a solution that will:

• Keep each salesperson's laptop up to date with the latest pricing information.
• Keep the corporate system up to date with new customer information from the laptop of each salesperson, without the risk of exposing critical corporate data.

Currently, product and customer data is stored in a central SQL Server database in the data center. In addition, employees in the sales team use an application that runs on their laptops and stores data in SQL Server Express. The IT department does not want to open the firewall to the on-premise data center to provide possibly insecure access from each salesperson's laptop. The development team can provide a safe and fully synchronized solution that uses SDS, by completing the following three tasks:

1. Create a data structure in SDS to store product data and customer data.
2. Create a Microsoft Sync Provider for the data center. This Sync Provider will keep product and customer data synchronized between the data center and the SDS data hub.
3. Create a second Microsoft Sync Provider for the sales team's laptops. This Sync Provider will keep product and customer data synchronized between the field sales people and the SDS data hub.

The following diagram illustrates this solution.

Figure 2. Conceptual overview of a data hub scenario.

Product pricing data flows from the enterprise database, through SDS, to more than five thousand sales people. Customer contact data flows from more than five thousand sales people, through SDS, to the enterprise database. When a sales person's laptop is offline, changes made to local data are tracked. When the laptop's Internet connection is restored, the Sync Provider enumerates these changes and sends them to SDS. The safety of the corporate data center is ensured.

Archival and Compliance

Many organizations need to store historical data, such as financial records, business transactions, or correspondence, either for future reference or for compliance with record-keeping regulations. Consider a software-as-a-service (SaaS) vendor that provides compliance support to businesses, including financial, government, healthcare, real estate, and franchising companies. They employ a document management system for archived data that provides full text search, together with workflow functionality and check processing. They must also track and report access to resources as required for audit purposes. To lower data storage costs and help ensure rapid and secure access to records, the company would like to migrate their customers' archive data to the cloud.

Towards this aim, the company can create an account with SDS, together with .NET Services accounts within the company space for each of its customers. Once a customer has an account, they can upload any form of document, such as e-mail, scanned checks, and escrow documents. Some of the documents are stored as binary large objects (BLOBs), while other documents are stored as structured data with standardized data fields.

The uploaded content is fully indexed and enables the company to execute queries against BLOB content, entity metadata, and user-defined flexible properties. Going forward, the company could implement new services and capabilities, such as Optical Character Recognition (OCR) scanning or workflow processes built using .NET services integrated with SDS.

Architectural Overview

Technology Stack

SDS is implemented as a mid-tier application. The service exposes SOAP and REST endpoints for communication with client applications. Behind the scenes, SDS uses ADO.NET to communicate with the underlying SQL Server-based platform. The following diagram shows a conceptual illustration of the technology stack.

Figure 3. The SDS technology stack.

To use SDS, you first provision an account. Within each account, SDS provides a simple, hierarchy-based data model that consists of three layers: authorities, containers, and entities. An authority is a collection of containers, and a container is a collection of entities. This is known as the ACE model.

The ACE Model

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

Business Logic 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
Entity	Scalar property bag	A unit of storage	An individual record

Table 1: The ACE model

An authority is the top-level organizational element in the SDS data model, and it's the first thing you create when you use SDS. Every authority is assigned a domain name system (DNS) name, which enables you to access your authority through the REST protocol and effectively makes the authority a unit of geo-location. You can think of an authority as being analogous to an individual SQL Server instance.

Each authority can contain any number of containers. You can think of a container as being analogous to an individual database. However, while a traditional database uses tables and schemas to organize data, containers impose no such restraints. You can use containers to store homogeneous data (entities of the same kind and shape) or heterogeneous data (entities of different kinds and shapes). Instead of tables and schemas, you use properties of the entities themselves to provide as much or as little structure as your solution requires.

A container can contain any number of entities. An entity includes two types of properties: flexible properties and metadata properties. Flexible properties are defined by the user and stored in a simple string object dictionary, and they enable you to define data fields in any supported data type. Currently, SDS supports String, Base64Binary, Boolean, Decimal, and DateTime types. These types are compatible with the types used by SQL Server.

Metadata properties are standard properties that every entity has. You can use them to structure your data and refine your queries. The following table describes the purpose of each metadata property.

Metadata Property	Purpose
ID	Provides a unique identifier for each entity.
Version	Maintains a version number for each entity. Predominantly used to synchronize cloud data from SDS with local data sources.
Kind	Allows applications to assign an arbitrary type to each entity. The interpretation of the type property is currently application specific. This property enables you to query specific kinds of entities from heterogeneous containers, or to divide the entities in a container into different kinds for special processing.

Table 2: Entity metadata properties

For example, suppose you create a container to store data on cars for sale. You might use the Kind metadata property to distinguish between new cars and used cars. You then could add flexible properties as required to identify body types, engine sizes, and so on.

Functional Overview

The SDS API

One of the key design goals for SDS was to support programming from any development environment. To enable this support, the service currently exposes SOAP and REST endpoints. The SOAP protocol is familiar to many developers who consume Web services, is language and platform independent, and is available in any development environment that provides access to a SOAP stack. SDS is also very well supported by the Microsoft Visual Studio® tools. Developers typically use SOAP when developing for a Microsoft-based environment, especially in enterprise applications where security and interoperability are important.

REST, on the other hand, is a lightweight, HTTP-based protocol that uses URIs and HTTP verbs to facilitate the exchange of data. As such, you can use the REST protocol from any development environment that provides access to an HTTP stack. Developers typically use REST when programming on a non-Microsoft platform, and when simple security and interoperability approaches are sufficient.

SDS has a natural REST implementation, because the principal HTTP methods map well to the key CRUD (Create, Retrieve, Update, and Delete) database operations. The following table illustrates this mapping.

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

Table 3: Mappings between HTTP verbs and SDS operations

When you create an authority, a DNS record is created to facilitate the use of the REST protocol. For example, if you created an authority named london, you would access your authority at the following URI.

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

You can scope operations at any level of your data structure by building on this root URI.

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

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

SDS will also support REST-based access using Atom Publishing Protocol (AtomPub) and JavaScript Object Notation (JSON) through the ADO.Net Data Services ("Astoria") conventions.

Manipulating Your Data

SDS exposes service methods at every level of the data model. Regardless of whether you use SOAP or REST, each operation follows the same pattern: you set the scope of the operation (service, authority, container, or entity) and call the appropriate method. The following table summarizes the service operations that are available at each scope.

Scope	Service Operations
Service	§         CreateAuthority
Authority	§         FetchAuthority §         QueryContainers §         CreateContainer
Container	§         FetchContainer §         QueryEntities §         DeleteContainer §         CreateEntity
Entity	§         FetchEntity §         UpdateEntity §         DeleteEntity

Table 4: SDS scopes and service operations

If you use the SOAP protocol, you create a Scope object and pass this object as a parameter when you call the appropriate method. If you use the REST protocol, the URI represents the scope of the operation. You create an HTTP request to the URI, call the appropriate HTTP method, and write your data to the request stream as an XML payload.

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