Welcome to MSDN Blogs Sign in | Join | Help

Mike Amundsen is putting out lot of samples in his blog

I just noticed that Mike has put out interesting code in his "life in lowercase" blog.  It is good to see him add caching support to his provisioning client.  Just put it on my "to play with during my vacation" list for the summer.  Thanks Mike.

By the way, I responded to Mike's comments on SSDS and Astoria alignment.  I do not disagree with Mike that one of the core values of SSDS is its simplicity.  It is a tribute to the team that they have been able to keep it simple for developers to approach and use right away.  I appreciate Mike's concern that aligning SSDS with Astoria could make SSDS lot more complicated.  As I said in my response, the alignment does not mean that we are ditching the flex entity model.  Once we release the aligned service, as a developer you will have a choice of staying with the flex entity model or add schemas where it makes sense to add schemas.  We hope to provide this capability at the container level so you can choose to:

a. Keep all entities as flex entities
b. Keep all entities as typed entities
c. Have both typed and untyped entities and type entities with open or flex properties

The side effect is that the Astoria client library then becomes the default client library for developers to build their applications in Visual Studio.  Still does not solve the problem of client libraries for Java, Ruby and PHP.  I still got those on my plate to address.

If you look at the model above, you will notice that Amazon SimpleDB and SSDS only allows you to do a. today.  GAE lets you do a. and b.  We think c. is really very powerful and see all sorts of scenarios can be modeled using c. quite effectively.

At the time of writing this blog, I have not seen a plan for supporting EDM associations post alignment.  I also want to point out that this alignment is actually good for EDM as it extends the current EDM model to cover untyped or flex entities.  It is also important to point out that it is possible to bet on EDM without using EF.  Astoria itself is an example of that.

Published Wednesday, July 16, 2008 7:05 PM by Soumitra Sengupta
Filed under: ,

Comments

# re: Mike Amundsen is putting out lot of samples in his blog

It is good to see SSDS is going to allow us to use both flex and/or typed entities.

I haven't explore much about Astoria, but I have one doubt here, isn't it Astoria exposes service through REST / ATOM only? If that is the case, what will happen to SOAP interface?

Thursday, July 17, 2008 1:22 AM by ccchai

# re: Mike Amundsen is putting out lot of samples in his blog

Thanks for your comment.

It is a great question you ask.  SSDS will continue to have both REST and SOAP interfaces.  

This creates 2 challenges for alignment:

a. Query language - Astoria today do not have a query language per se

b. Symmetry of REST and SOAP interfaces.  I would like to hear readers' thoughts on how important is it to keep the REST and SOAP interfaces symmetric along multiple dimensions (query language, security etc.)

Thursday, July 17, 2008 1:39 AM by Soumitra Sengupta

# re: Mike Amundsen is putting out lot of samples in his blog

My comments on the SOAP/REST interfaces:

While I think it is important to offer the same features for both SOAP and REST interfaces, I don't expect these features to be implmented in the same ways for both SOAP and REST.

For example, the REST model should be implemented to support a wide range of content types including the POX you have today, Atom, JSON, even plain-text and HTML.  This approach would not make sense for SOAP.

As for security, SOAP may offer some functionality from the WS-* stack that is not appropriate for REST. However, both should support more than HTTP Basic Authentication. For example, REST should support Digest, OAuth, and the Identity/Claims model (via Zermatt project?).

The meta data for REST calls should appear in HTTP Headers instead of forcing this into the body of a POST message while SOAP uses the payload to hold both data and meta-data.

The query details may also be different. REST queries should continue to be designed to work via the URL using the GET method. This provides the most opportunity for caching and support for intermediaries in the future. The SOAP interface will probably need to continue to use the payload to hold queries and can take an entirely different approach to modeling the query statement.

Forcing SOAP to use HTTP-style implementations (HTTP Headers, sub-optimal query style) would be a mistake. Steering the REST implementation to rely on meta-data in a POST body when requesting data would also diminish the value of SSDS.

Again, staying true to the standards and practices of each architecture makes the most sense.

Thursday, July 17, 2008 2:19 AM by mamund

# re: Mike Amundsen is putting out lot of samples in his blog

did anything change in the service reference?

http://data.sitka.microsoft.com/soap/v1?wsdl  --> this doesn't work?

Wednesday, August 13, 2008 12:12 AM by vontlin
Anonymous comments are disabled
 
Page view tracker