After you've registered an account for SDS, your first task
will be to provision your data source and start adding data. Suppose that you
are hired to create a data hub for Coho Winery, a prestigious wine merchant.
The hub will include listings for red wines, white wines, and Champagnes, and
will also include video clips of taste tests and reviews. The following diagram
illustrates how you might map this to the ACE model.
 | |
| Figure 2. Example data structure for Coho Winery |
As you can see, we will create a single authority with an ID
of Coho. We will add a container
named Wines, which we will use for
heterogeneous storage of RedWine, WhiteWine, and SparklingWine entities. We will add a second container named Media to store taste tests and reviews
as BLOBs.
Now that you've established your data structure, your first
development task will be to create the authority.
As discussed earlier, an authority is the top layer in the
SDS data model. Every authority has a DNS name assigned to it, which
effectively makes the authority a unit of geographical location. Because of this,
every authority ID must be globally unique.
To create an authority using the REST interface, you first
create an XML payload that describes your authority:
<s:Authority xmlns:s='http://schemas.microsoft.com/sitka/2008/03/'>
<s:Id>coho</s:Id>
</s:Authority>
The Id property is compulsory, and can only
contain lowercase letters, numbers, or dashes. In case you're wondering,
"Sitka" is the pre-release codename for SDS.
Remember that to
create an authority, you must scope your operation at the service level. As
such, your next step is to send an HTTP request to the service:
https://data.beta.mssds.com/v1/
Because you are
performing a create operation, you use the HTTP POST method to stream your XML
payload to the service as a byte array. Set the Content-Type header to application/x-SDS+xml,
and set the Content-Length header to
the length of your XML payload in bytes. The following C# code sample
illustrates this process. This assumes that you have defined a string named myPayload that contains your XML
payload, and a string named serviceUri
that contains the URI of the service as provided in the previous paragraph.
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(serviceUri);
//Set the request headers
request.Credentials = new NetworkCredential(myUserName, myPassword);
request.Method = "POST";
UTF8Encoding encoding = new UTF8Encoding();
request.ContentLength = encoding.GetByteCount(myPayload);
request.ContentType = "application/x-ssds+xml";
//Write the XML payload to the request stream
using (Stream myStream = request.GetRequestStream())
{
myStream.Write(encoding.GetBytes(myPayload),
encoding.GetByteCount(myPayload));
}
When the operation
has completed, SDS will send an HTTP response. The response includes an HTTP
status code that indicates whether or not your operation was successful (a
status code of 201 indicates that a resource was created).
Note: For full end-to-end
code examples in C#, Java, and Ruby, together with SOAP examples in C#, visit
the SDS Primer site on MSDN.
You can use containers to store homogeneous data (entities
of the same kind) or heterogeneous data (entities of different kinds). If you
use a container to store homogeneous data, the container is analogous to an
individual database table. If you use a container to store heterogeneous data,
the container is analogous to an entire database. Whereas a traditional
database uses tables and schemas to organize data, containers impose no such
restraints. Instead of tables and schemas, you use entity metadata to structure
your data storage and retrieval. We'll cover this in more detail when we
discuss entities.
Going back to the Coho Winery example, our next step is to
create containers to store wine listings and media files. Because containers do
not require schemas, the creation process is exactly the same for both
containers: you don't need to create columns or specify what type of entity the
container will hold.
You can create a container in a very similar way to how you
create an authority. First, you assemble an XML payload that describes your
container:
<s:Container xmlns:s='http://schemas.microsoft.com/sitka/2008/03/'>
<s:Id>Wines</s:Id>
</s:Container>
To create a container, you must
scope your operation at the authority level. To do this, you address your HTTP
request to the authority URI:https://coho.data.beta.mssds.com/v1/
As before, you use the HTTP POST method to
perform a create operation, and you send your XML payload to SDS over the
request stream as a byte array. When the operation has completed, check the
status code of the response to verify that your container was created
successfully.
When you work with flexible entities (in other words,
non-BLOB entities), you need to be aware of two different types of properties.
Flexible properties are defined by the user and stored in a simple string
object dictionary. You can add as many or as few flexible properties to each
entity as you want. Currently, you can define property values in String, Base64Binary, Boolean, Decimal, and DateTime data types.
Metadata properties are fixed properties that provide
information on the entity itself. Each entity (with the exception of BLOB
entities, which we'll cover later) has three metadata properties.
|
Metadata
Property
|
Purpose
|
|
ID
|
Provides a unique
string identifier for each entity.
|
|
Version
|
Maintains a
system-generated version number for each entity. Enables synchronization
between data sources and provides support for conditional updates. Be aware
that version numbers are not incremental and do not start at 1.
|
|
Kind
|
Assigns an arbitrary
type to each entity, such as RedWine
or WhiteWine. Enables you to query
specific kinds of entity from heterogeneous containers.
|
Table
3: Entity metadata properties
Generally speaking,
you will only create authorities and containers when you provision or
reorganize your data. By contrast, creating entities is a frequent operation in
most applications that use SDS as entities to represent your data. As with
authorities and containers, when you create an entity using the REST protocol
your first step is to create an XML payload that describes your data:
<RedWine xmlns:s='http://schemas.microsoft.com/sitka/2008/03/'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:x='http://www.w3.org/2001/XMLSchema' >
<s:Id>CohoSauvignon05</s:Id>
<vineyard xsi:type='x:string'>Coho Vineyard</vineyard>
<vintage xsi:type='x:string'>2005</vintage>
<grape xsi:type='x:string'>Cabernet Sauvignon</grape>
<region xsi:type='x:string'>New Zealand</region>
<description xsi:type='x:string'>Full-bodied and fruity</description>
<thumbnail xsi:type='x:base64Binary'>/9j/4AAQSkZJ… </thumbnail>
<price xsi:type='x:decimal'>16.95</price>
</RedWine>
The name of the
parent element defines the Kind
metadata property value of the entity, and the Id child element specifies the obligatory ID value. You can add as
many flexible properties as you want by adding further child elements, with an
appropriate type attribute in each
case. Note that in this example we store a thumbnail image as a base64Binary
encoded value.
To create an
entity, you must scope your operation to the parent container. To do this, you
address your HTTP request to the container URI:
https://coho.data.beta.mssds.com/v1/wines/
Again, as with authorities and containers,
you use the HTTP POST method to perform a create operation, and you send your
XML payload to SDS over the request stream as a byte array. When the operation
has completed, check the status code of the response to verify that your entity
was created successfully.
Creating BLOB
Entities
In SDS, BLOBs are stored as entities. You can add BLOB
entities to containers in much the same way that you would add any other
entity. However, the metadata properties of BLOB entities differ from those of
regular entities in two key ways. First, the value of the Kind property is always Entity
and cannot be changed at present. Second, BLOB entities have an additional
metadata property named Content that
includes the following attributes.
|
Content
attribute
|
Purpose
|
|
content-type
|
Specifies the MIME
type of the BLOB content.
|
|
content-length
|
Specifies the size
of the BLOB.
|
|
content-disposition
|
Optionally specifies
how the client should handle the BLOB. For example, Web browsers use the ContentDisposition header to suggest
a filename when you save the BLOB as a file.
|
Table 4:
Attributes of the Content metadata property
As with regular entities, to create a BLOB entity you must
scope your operation to the parent container. To do this, you address your HTTP
request to the container URI:
https://coho.data.beta.mssds.com/v1/media/
Next, you add the metadata properties to the request header.
You use the Slug header to define
the ID value you want to apply to the entity. As with all "create"
operations, you use the HTTP POST method. The following C# code sample
illustrates this process.
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(containerUri);
request.Method = "POST";
request.ContentLength = 1234567;
request.ContentType = "video/x-msvideo";
request.Headers["Content-Disposition"] =
"attachment; filename='Coho1.avi'";
request.AllowWriteStreamBuffering = false; //enable full streaming
request.Headers["Slug"] = "CohoSauvignon05TastingNotes";
Finally, you use an asynchronous operation to write your
data to the request stream. To do this, you typically open a stream to the
object you want to upload and copy your data across in small chunks, such as 64
kilobytes at a time.
Remember, for full end-to-end code examples you
can visit the SDS Primer site on MSDN at http://msdn.microsoft.com/en-us/library/cc512417.aspx.