Share your data across data sources (Sharepoint, SQL Server, Azure, Reporting Services, etc) & applications (.NET, Silverlight, Excel, etc) using Data Services

This week at the SharePoint conference, Pablo Castro will be announcing that the next version of SharePoint natively integrates with data services such that all SharePoint lists will be exposed as an ADO.NET Data Service.  This means you can now program against SharePoint list data using all the VS tools and runtime client libraries (.NET, Silverlight, AJAX, Java, PHP, etc…) which support ADO.NET Data Services.  Also, since the Data Service interface is just plain HTTP and XML/Atom or JSON, pretty much any environment with an HTTP stack can now browse, update and interact with list and document data in SharePoint. We are very excited to be able to talk about SharePoint’s data service integration (more code-centric blogs to come on this topic) as this has been an ask we hear a lot each time we present data services.

This integration is also a good example of a step towards our larger vision for data services and, more generally, open data access on the web.  The remainder of this post outlines our roadmap around data services and what parts of that roadmap we are announcing this week.

First, a bit of context…

Successful applications collect lots of valuable data. Often it is relatively easy to get data into applications but hard to get it out or to have multiple applications to use one another’s data. Part of the problem is lack of a simple, uniform way of exchanging data across systems. Server side applications such as SharePoint server are examples where it would be extremely valuable to have a general purpose data service interface. Another example is SQL Server Reporting Services, as reports frequently become the official entry point for application data. Excel and the analysis services clients in SQL Server are examples of client side applications that would greatly benefit from having readily access to data managed by applications of all kinds, from SharePoint sites to Reporting Services reports in existing applications to custom applications that expose data as services. Client mash-ups also consolidate data from multiple sources to provide valuable cross-application perspective, provided that they can actually access data from all systems.

Background on the approach

Services, instead of APIs, is what is becoming common ground for interaction across tiers or across applications, both on the web and inside organizations. Microsoft has been working on data-centric service interfaces that enable simple, effective data sharing within and across applications. The first materialization of this effort is the ADO.NET Data Services framework that shipped last year as part of .NET 3.5 SP1. The approach taken is to use a RESTful data service interface built on top of standard, broadly available concepts and technologies such as HTTP and AtomPub. Conventions are defined on top such that things such as metadata discovery is possible

What we are announcing

A number of products and developer tools are all now aligned around this single RESTful data service interface. More specifically:

Developer tools:

We updated the protocol itself as well as our frameworks and developer tools in Visual Studio 2010, .NET 4.0 (starting with Beta 2) and Silverlight 4.  We’ll also release an update to .NET 3.5 SP1.

SharePoint:

Starting with SharePoint 2010 (beta release to come in November) all SharePoint sites are automatically exposed as RESTful data services that follow the ADO.NET Data Services convention. Now any client with an HTTP stack can read and write to SharePoint by just using simple HTTP methods and Atom (XML) or JSON formatted data. All the rich clients that work with Data Services will work with SharePoint out of the box.

Reporting Services:

Starting with SQL Server 2008 R2, all reports created with SQL Server Reporting Services will expose an option to render as an Atom feed that follows the Data Services convention as well. This makes it possible for developers and information workers to see the data “underneath” a report (whether it displays as tables, charts, etc.) and use it in their own applications.

Excel and Microsoft SQL Server PowerPivot for Excel 2010 (aka “Project Gemini”):

Also starting with SQL Server 2008 R2, the PowerPivot plug-in for Excel allows information workers to bring data from all sources for analysis will natively understand and load data from any Data Service. Now information workers can obtain data from reports, SharePoint sites, public sites that expose reference data and even custom applications and load it directly into the data analysis environments.

Cross-platform clients:

in addition to the .NET, Silverlight and AJAX clients that were already available, Microsoft sponsored open-source projects to create a PHP and a Java client for Data Services. Both are already publicly available.

All these products introduce first class support for producing or consuming the Data Services protocol, enabling data sharing scenarios for both developers and information workers. They join other already-existing services using the Data Services protocol such as the Windows Azure Table Store.

Stay tuned, more to come at the PDC & TechEd conferences later this year.

Mike Flasko

ADO.NET Data Services, Lead Program Manager

Comments

• Anonymous
  October 21, 2009
  Hi Mike,thanks for sharing this information. I'm looking forward to the Services of the next Sharepoint Version.One question I have: Silverlight 3 still contains the Client-Library for ADO.NET-Data Services 1.0. So Silverlight 4.0 will contain a new Client-Library for the new 1.5 Features, right? If so, will this 1.5 Client Library be downwards compatibel?Thomas
• Anonymous
  October 21, 2009
  @Thomas -- Yes SL4 will have an updated Astoria client library. The client in SL4 will be able to talk to existing (built with .NET Fx 3.5 SP1) and new (i.e. Sharepoint, built with .NET FX 4.0) data services.  
• Anonymous
  December 04, 2009
  I have an EntityModel that I created in Visual Studio 2008.  I created a WebService using the ADO.NET Data Services.   Everything works fine.I added a second WebService using ADO.NET Data Services and I started getting the following errors:  DataService is ambiguous in the namespace 'System.Data.Services'  IDataServiceConfiguration is ambiguous in the namespace 'System.Data.Services'  EntitySetRights is ambiguous in the namespace 'System.Data.Services'I then deleted the 2nd webservice and the errors remain.Can I add a 2nd WebService in the same solution?Why did I starting getting the ambiguous errors once I added the 2nd webservice?If the 2nd webservice created the errors, why when I removed them the errors remained?Thank you,William Apken