Welcome to MSDN Blogs Sign in | Join | Help

Why Astoria alignment is not that trivial

I have been meaning to write about this topic for quite some time.  But it took me quite a while to understand deeply the key issues in aligning Astoria and SSDS.  Thanks to Alan Bush, an architect in our team, I have a much better understanding of the key issues.  The tendency for most of us is to focus on the data model and query language differences between Astoria and SSDS.  Turns out, while they are important, they are not the most difficult ones to work in.  So here is what I have learnt from Alan:

a. Astoria protocol and interaction model deals with only a single consistency domain.  Each consistency domain sort of maps to a database.  Astoria consistency domain is akin to SSDS container.  SSDS data model actually spans multiple consistency domains.  It is possible to write a query across containers or even query for container properties.  Yes Astoria can be extended to address this and we are working on that with Pablo and the Astoria team.
b. Multi-tenancy is a fundamental concept in SSDS while Astoria has no such concept at this point in time.  We have to work through this as well.  This has huge implications in the security model for the service.
c. Entities in SSDS do not require schema while default for Astoria is EDM schemas.  While on the surface this is an easy problem to solve yet it requires you to think through all the options.  If you look at the data model for Google App Engine, you will see how they chose to solve this problem - typed entities and expando entities are 2 separate concepts.  It is one way to deal with it but think about updates on a graph where you have both typed and flexible entities, how would the user deal with the semantic differences between the two concepts in the same transaction?

There are host of issues but these are some of the top ones we are grappling with.  Rest assured minds lot sharper than mine are working this and if there is an elegant solution, they will find it.  I have full faith that by PDC we will have a compelling story to tell around SSDS and Astoria.  So stay tuned.

Published Tuesday, July 15, 2008 6:56 AM by Soumitra Sengupta

Comments

# re: Why Astoria alignment is not that trivial

SSDS-Astoria alignment is not only non-trivial, I'm not sure it's desirable.

My primary concern is that SSDS *not* become another participant in the Entity Framework system.  You can improve the query model - and the support for multiple content types (Atom, RSS, JSON) without adopting the EDM pattern.

Keep SSDS lightweight and flexible.

Tuesday, July 15, 2008 10:17 AM by mamund

# re: Why Astoria alignment is not that trivial

I don't see SSDS-Astoria alignment as important feature too. I wonder how many users require this feature....

Having said that, what is the future plan of SSDS-Astoria alignment? Existing interfaces will be obsolete? Everyone must move to Astoria interface? Data schema would become mandatory when using Astoria/SSDS? It seems to me the end results might reduce the flexibility of SSDS.....

Tuesday, July 15, 2008 10:41 AM by ccchai

# re: Why Astoria alignment is not that trivial

Thanks for the feedback.

First, Astoria alignment does not mean SSDS loses the flexible entity model.  The idea is to provide the choice from one end of the spectrum (flex entities) to the other end of the spectrum (fully typed entities).  As developers we want you to have the choice based on the application you are writing.  We think there are scenarios that work well at the extremes and there are scenarios that are somewhere in the middle and could use schematized entites with flexible properties.  So you are not losing the flexibility you are gaining a choice.

Second, we believe that there are scenarios where an application maybe built in the cloud and then migrated on-premise or vice versa.  Providing symmetry between Astoria and SSDS gives us this symmetry and increases deployment choice for our customers.  Aligning on the interaction model and the serialization formats gives us the ability to leverage the client side libraries and tools in .Net and VS.

Third, embracing EDM as a model and EF as a framework are 2 different things.  Astoria for example uses the EDM model but does not use either EF or E-SQL.

This in short is our thinking at this time and we would like to hear if you think it makes sense.

Wednesday, July 16, 2008 2:16 AM by Soumitra Sengupta

# re: Why Astoria alignment is not that trivial

SS:

Thanks for the reply here. It's good to hear that EDM and EF are not required together. That makes sense to me, too.  Also, the notion of supporting both strong- and flex-typed entities is a positive.

I understand the value of the Astoria(AnDS) library and how it can make things easy for VS folks.  I also want to encourage you to continue to think (as you indicate in your follow up post) about non-VS development (Ruby, Java, etc.). In that light, please also keep in mind C#/VB folks that will not be using Astoria.  

Thanks again.

Wednesday, July 16, 2008 5:42 PM by mamund

# re: Why Astoria alignment is not that trivial

I do think that SSDS / Astoria need to integrate.  That said, I think tha Astoria needs to grow up and allow for dynamic / flexible entities.  I cannot believe it RTMed with a requirement of static entities.

Monday, October 06, 2008 1:10 PM by shan_mcarthur@spamcop.net
Anonymous comments are disabled
 
Page view tracker