ADO.NET Data Services == Project "Astoria"

  • Article

A new name, but goals stay the same

As per our last blog post, we just finished a round of presentations on Astoria at Tech Ed EMEA, Tech Ed Africa, Dev Connections and finally Dev Teach. Thanks to everyone that attended our sessions and who stopped by our product booths for a chat. We much appreciate your feedback and learning how you see the technology fitting into your solutions. One item we announced at each of these conferences is that Project Codename "Astoria" will be officially known as ADO.NET Data Services. We landed on this name as the technology expands on the existing ADO.NET stack for accessing relational data as well as the upcoming ADO.NET Entity Framework (a technology to enable working with a conceptual domain model instead of the schema used by the data store) as follows: 

ADO.NET Data Services consume a conceptual model representing the entities that your application wishes to expose, along with the associations between those entities, and exposes them as HTTP resources, each identified by a URI. The conceptual model exposed by ADO.NET Data Services is defined using the Entity Data Model (EDM), which is the same schema definition language used by the Entity Framework. While ADO.NET Data Services and the Entity Framework share a mechanism to model data in terms of resources (entites) and links (associations) it is important to note that when creating data services, two key scenarios exist:

1. you are exposing a conceptual view of the data stored within a relational database.  For this ADO.NET Data Services integrates very easily with the Entity Framework to enable exposing such a model on the web over a DB

2. you are exposing a conceptual view of the data in an arbitrary data source (file, custom data store, web service, application business logic, etc).  For this, ADO.NET Data services make heavy use of LINQ constructs such that any data accessible via an IQueryable provider + extensions for update can be used as the source of a data service. 

 

CTP1 is almost here...

In addition to the official name of the product, we discussed that we plan to release the first CTP of the production version of Astoria early this month (Dec 2007). We call this the first CTP because all the releases of Astoria prior to this point were based on a prototype code base which we used to iterate very quickly and explore the requirements of data services on the web. As we discussed in previous blog posts and in our online forums, we have since started from scratch, engineering the product from the ground up using the lessons and requirements learned from our proof of concept releases. We look forward to sharing the bits with you soon and hearing your feedback. We look forward to hearing what looks good and what you think needs improvement or needs to be added/removed from the product. Since initial prototype CTPs, a number of changes and additions have been made such as:

  • Industry standard ATOM/APP (AtomPub) serialization is now supported
  • JSON serialization is still supported, but specifics of the wire format have changed to address functional and security requirements
  • The start of an access control framework has been added to the system, enabling a service developer to create access control policy for a data service
  • A newly created service is locked down by default (ie. each entity must be explicitly exposed by the developer). Prior CTPs exposed everything by default as a way to quickly explore the prototype versions
  • As per a previous blog post, data services can easily be created over any data source (relational databases, files, custom stores, web services, etc)
  • Enhanced query support in the URI
  • LINQ to Astoria (use LINQ queries to access data in an ADO.NET Data Service)
  • Client libraries for ASP.NET AJAX and .NET Framework based applications
  • etc

In the coming weeks we will post more detailed discussion of the features in this first CTP so everyone can give them a spin.  We look forward to hearing your thoughts...

 

Mike Flasko

Program Manager, ADO.NET Data Services (aka "Project Astoria")