Why ADO.NET Data Services Framework (aka Astoria)?
I've responded to a few posts on our online forums asking what the motivations were for building Astoria. After one of our recent posts to the forums a comment was left that the replies would be a good blog post. So, what follows is a few of my responses to those forums questions appended together and touched up a bit so they can be read together as a single post.
In general, the goal of the ADO.NET Data Services Framework is to create a simple REST-based framework for exposing data centric services. We built the framework in part from analysis of traditional websites and then looked at how architectures were changing with the move to AJAX and RIA based applications. One key observation the team had was that in traditional approaches to web development the information exchanged between a client (ex. a web browser) and the mid tier was a combination of presentation + behavior + data (ex. HTML file with JavaScript and inline HTML tables of data) and that the core interactions to retrieve raw data was between the mid-tier and backend store (ex. SQL server or other). When we looked at RIA, AJAX, smart client, etc applications it became apparent that these architectures pushed much more "smarts" to the client tier where the client first retrieves the presentation + behavior information (as a DLL in the case of a Silverlight application) and then, as the user interacts with the client application, the app turns back (ex. background async call) to the mid-tier to retrieve the data needed to drive the user experience. This is nothing new (separation of presentation + behavior from data), but it’s interesting to note it now is not only a best practice but mandated in the architectures of today’s web and RIA apps. From this we looked at how such clients could consume data from the mid-tier today and how could we help improve the experience for the developer. A few areas came up:
1)Creating and maintaining rich data oriented services with current approaches requires a significant developer investment
2) Building generation purpose client libs/tools with current approaches to data centric services is hard
For #1, imagine you wanted to expose the data in your CRM database to you client tier application. Further assume you want to enable typical application scenarios like retrieving sorted views of the data, paging over the data, filtering, etc. To expose this data as a set of callable remote methods (using current approaches to developing web services) you would need to write a large number of methods to expose each of the entities in your CRM DB (customers, orders, etc) and then add additional methods for each to retrieve entities by key, sort them, page over them, etc etc. ADO.NET Data Services, addresses this issue by allowing you to declaratively state the contract of such a data centric service, by telling us the schema of the data and having the data services technology automatically create the required remote endpoints, enabling paging, sorting, etc with no code from the developer. Then as you change your data model, your service endpoints also change.
For #2 above, an interesting artifact of a REST-based approach to web services is that it promotes creating a uniform interface. That is, how you address items in an ADO.NET Data Service (i.e. how to construct URIs), how to interact with data (using HTTP verbs), etc is the same across any ADO.NET Data Service, regardless of the data it exposes. This uniform interface enables code reuse against your web services such that one can create reusable client libraries and UI widgets for all their services. For example, the ADO.NET Data Service team is doing this by shipping .NET , Silver light, AJAX, etc libraries which can talk to any data service. In addition, this feature (uniform interface) enables us to add features such as LINQ to ADO.NET Data Services since the translation of LINQ query statements to URIs is stable and well known.
So far I’ve talked mainly about how Astoria fits into the mid-tier and makes aspects of app development easier for AJAX/RIA/etc developers. Another key trend that drove us to build the ADO.NET Data Services Framework was the observation that an ever increasing amount of data is being stored in the cloud and web-based APIs to access that data seem to be growing by the minute. A goal ADO.NET Data Services Framework is to fit into this use case by providing a way of easily creating a service that has a RESTful API and a uniform interface that plays well with libraries and tools just like in the app (AJAX, Silverlight, etc) use case described above.
This post is already getting a bit long, but in addition to the items noted above, additional advantages of REST-based approaches also apply such as rich integration with HTTP such that you can leverage existing HTTP infrastructure (ex. HTTP Proxies) deployed at large .
After writing this, I couldn't help but wonder how this aligns with the general view the developer community has of Astoria now that we have released a few CTPs and everyone can try out the bits first hand. After reading this post, did this describe your overall view of Astoria and its target use cases?
- Mike Flasko
Program Manager, ADO.NET Data Services Framework
Comments
- Anonymous
February 03, 2008
PingBack from http://www.travel-hilarity.com/airline_travel/?p=1174 - Anonymous
February 04, 2008
Mike,This was useful and kinda reiterated my own conceptions.I am however interested in what you guys are planning around hosted data services. I long for the day when I can submit a conceptual model, built-in my data modelling tool of choice, and then you guys generate and host a data service for me. This is, i admit, data-service-nirvana but I hope that you guys are thinking of things along these lines.I'd especially like to see Microsoft provide hosted data services that are instantly scalable! Something like this would hugely decrease the time it takes to build our web-based ventures. Its a very compelling thought.cheersJamie - Anonymous
February 04, 2008
>After writing this, I couldn't help but wonder how this aligns with the general view the developer community has of Astoria now that we have released a few CTPs and everyone can try out the bits first hand. After reading this post, did this describe your overall view of Astoria and its target use cases?<<Hi Mike;I think it's a fair question you ask, especially after all the hard work you and your team have been putting together and I think deserves an answer from different individuals.In my personal case, I had already learned what Astoria will do for me prior to you answering Michael's questions, but I'm glad you did. But as far as usage goes, in my situation, I have not been able to use it much, not because I do find any faults or short coming in Astoria, but mainly, I'm waiting for SL 2.0 beta to show up to get started. Just knowing that we have Astoria that supports SL is a great news, but I think if you are not getting a lot of feedback, is because the other part of the puzzle is missing. I'm sure by summer you'll be getting tons of feedback.I thought I share this with you, because any PM wants to know what people think of their product.I hope by release of SL 2.0, Astoria will be solid and will have a good docs to back it up.Thank you for the great product!..Ben - Anonymous
February 04, 2008
Mike has posted Why ADO.NET Data Services Framework (aka Astoria)? over on our team blog. While I generally - Anonymous
February 04, 2008
Mike has posted Why ADO.NET Data Services Framework (aka Astoria)? over on our team blog. While I generally - Anonymous
February 05, 2008
And how does it integrate with WSDL-like web services?Am I able to automatically discover and get the contract of the Astoria service? Or I have to know the name of the entities and their attributes by antecipation?What about integration with WCF? - Anonymous
February 11, 2008
You've been kicked (a good thing) - Trackback from DotNetKicks.com - Anonymous
February 21, 2008
Mike FLasko is program manager for ADO.NET Data Servcies. Becasue people have asked frequently on the