Everything as an Atom
The Atom Publishing Protocol (or AtomPub as it's often called) defines a simple protocol for performing CRUD (Create, Read, Update, and Delete) operations on data over HTTP. Over the coming months, most of the Windows Live Services will provide offerings that conform to the AtomPub standards. This is a fantastic move toward standardization of the Windows Live Services APIs. In the last few years the APIs emerging from the various Windows Live Services have been varied and numerous. Each product group within Microsoft created their own API set: some were REST based, some were SOAP, and others used WebDav. Standardizing on a single technology to access the Windows Live Services will make developers' lives easier.
|In an ASP.NET server-side development world, much of the code needed to access these AtomPub services can be in a template and reused.|
The new AtomPub services will be available for access through the delegated authentication mechanism described in the previous section. Combining these two technologies to create a well-defined mechanism for accessing, authenticating, and working with the Windows Live Services has the following implications:
ADO.NET Data Services (aka Astoria)
- Applications can reuse the authentication code across multiple services.
- Well-defined architectural patterns can be created to guide application development.
- Tools will emerge to automate some of the code generation (see the next section).
At the MIX07 conference in Las Vegas, Microsoft announced a new technology codenamed "Astoria." Astoria has since been named "ADO.NET Data Services" and is currently available for download as a pre-release (CTP) for Visual Studio 2008 users in the ASP.NET 3.5 Extensions pack.
The ADO.NET Data Services consists of libraries for creating and consuming data services over HTTP. These services can expose CRUD operations invoked through the use of the HTTP verbs (GET
, and DELETE
). Does this sound familiar yet?
ADO.NET Data Services are designed to work with standard formats such as JSON and AtomPub. This is really lucky
for developers who want to use the new Windows Live AtomPub services!
However, there is more goodness to be harvested from the ADO.NET Data Services, as they provide a mechanism for modeling the data into objects. These objects are instances of entities; you can use the ADO.NET Data Service to represent the data as entities, and also the relationships between the entities, as defined in the service schemas.
|If the service offered requires that you identify your application with an application identifier, you will need to obtain an application ID from the Windows Live Microsoft Service Manager.|
This means that developers consuming services can interact with Windows Live AtomPub services in terms of .NET objects that they can query, modify, and send back to the service—in other words, they provide a natural way for .NET code to interact with services. Because it is all AtomPub under the covers, openness and interoperability are not compromised.
As a related note, developers wanting to create
services that follow the same HTTP interface pattern as Windows Live AtomPub services can use ADO.NET Data Services on the server to easily do that.
Microsoft, Do It for Me
By providing the Windows Live Service offerings in the AtomPub open standard, Microsoft has enabled all developers to access the same services in a uniform way. As an ASP.NET developer, you might not care about those other programmers—but having a well defined and open standard way of accessing the data benefits you as well. In an ASP.NET server-side development world, much of the code needed to access these AtomPub services can be placed in a template and reused.
The ADO.NET Data Services provides this templating technology. An ASP.NET AJAX library abstracts all the nasty details of how to make the HTTP calls, leaving you to focus on how you want to manipulate the data in your application. All you need to do in your ASP.NET AJAX code is create an instance of a Sys.Data.DataService class, passing the URI of the service into the constructor:
var liveService =
After you obtain a DataService instance, you can perform various operations on the data using the following methods:
- Query: Retrieve data from the service
- Insert: Create new data records on the service
- Update: Change data that already exists
- Remove: Delete data
Remember that not all services will support all these actions. When an operation fails, it might be because your application doesn't have the correct authorization, or it could be because the service doesn't support the attempted operation.
|Standardizing on a single technology to access the Windows Live Services will simplify developers' lives.|
Each of these methods creates an instant request over the wire to carry out the operation. You can batch operations together using the createActionSequence
method of the DataService object. An ActionSequence is a class that contains a collection of operations to perform on the service. After creating the ActionSequence and adding the operations you want to perform, you call the executeActions
method to submit the batched operation requests.
The Windows Live Photos API allows a third party site to request delegated authentication from a user. After the user has granted authentication privileges to a site, the code on that site can make requests to read and write photos associated with that user's Live ID—the same photos that are displayed on Windows Live Spaces.
The code in Listing 1
provides an example of how to use ADO.NET Data Services to call the Windows Live Photos API. You can see that—by encapsulating the hard work of accessing the service—the code addresses the Windows Live Photos API just as if it were a set of local .NET objects.
The code in Listing 2
shows the details of how to create the supporting classes to provide this extra layer of encapsulation. The LivePhotos class does the heavy listing—and most of that is done by simply deriving from the WebDataContext class.
Writing an article like this before the technology is released presents some challenges, but it can also help you gain insight into how new technologies will impact your work in the near future. As more Windows Live Services start to support the AtomPUB format you (with the help of the ADO.NET Data Services) will be able to access a huge quantity of resources, personal data and relationships between people. All this adds up to a far deeper level of connection between the online applications we build. And still, only the data a user actually wants to expose will be available to web applications. Access will become a new and important consideration for you to handle in your code. How will your application behave if a user denies access to a set of data? Will you provide a downgraded experience? Will you block that user form your site? Will you provide an equally rich experience? As always, a new set of solutions creates its own new set of challenges.
Whatever strategies you decide to adopt in your applications, you can be sure the technologies discussed in this article are starting to open the doors of accessibility to a large number of web developers that have previously found the Windows Live APIs too diverse and complex.