In March of this year I published a blog entry called “MDM -> Entity Framework -> ADO.Net Data Services. Better together?” where I theorised about implementing ADO.Net Data Services (aka Astoria) as a means for exposing entities out of Microsoft’s forthcoming Master Data Management (MDM) product that is slated for release with Office 14. As I investigated I discovered an impedance mismatch between the two that meant doing this was going to be unworkable unless usage of MDM was severely hamstrung; in that blog entry I said:
ostensibly it looks as though the inherent features of Microsoft MDM and the Entity Framework will play well together but unfortunately that's not the case. Let me explain by pointing two very important facets of these technologies:
- In Microsoft MDM the entities are defined and modified AFTER the system has been deployed. i.e. At run-time
- In Entity Framework the entities are defined BEFORE the Entity Data Model has been deployed i.e. At design-time
Microsoft MDM is a lot more dynamic in nature than Entity Framework hence any time I make a change to my entities in Microsoft MDM (which could happen often) I would have to redesign and redeploy my Entity Data Model
With that in mind I was interested to read a blog post from Pablo Castro (Pablo is the head of the ADO.Net Data Services team) entitled ADO.NET Data Services in Windows Azure: pushing scalability to the next level. He was talking about enhancements made that will benefit Windows Azure users and what caught my eye was the following paragraphs:
In the current version of Data Services types are "closed" in the sense that they have a structure that's final. You list a set of properties for each type and instances of that type cannot have properties added dynamically.
It turns out that the data services we have online have a more flexible model, where each entity has a fixed portion but also a dynamic portion. Typically the fixed portion includes a key or some sort and a version property. The dynamic portion is a property bag where you can add any name/typed-value pair.
We call these types that can be extended on a per-instance basis at runtime "open types". We introduced support for open types in the Data Services runtime such that you can mark a given entity type as "open" in metadata and that would cause the system to allow unknown properties to be set, as well as the use of unknown properties in queries (e.g. in filter predicates).
Pablo doesn’t use the same vocabulary as I did in March, and indeed he doesn’t name the same collection of technologies, but nonetheless he has described the same problem; an impedance mismatch between a data abstraction layer that expects a static data model and a data model that can change often.
That last paragraph quoted from Pablo’s post doesn’t mention the ability to retrieve unknown properties but I will assume (big assumption) that that scenario is supported. With that assumption in mind it seems that by solving an impedance mismatch between ADO.Net Data Services team and Windows Azure Pablo’s team have also solved the problem that I outlined in March in regard to MDM. I hope so.
-Jamie