OakLeaf Systems: Microsoft Patent Application for the Entity Framework and EDM

Tuesday, April 03, 2007

Microsoft Patent Application for the Entity Framework and EDM

The U.S. Patent and Trademark Office (PTO) published on March 8, 2007, U.S. Patent Application 20070055692, "Incremental Approach to an Object-Relational Solution." The inventors are the usual data programmability team suspects: Michael Pizzo, Pablo Castro, Jose Blakeley, Andrew Conrad, Alyssa Henry, et al. The application was filed on February 28, 2006, about four months before the first post on the Data blog and the once-missing ADO.NET 3.0 Entity Frameworks documentation reappeared.

The three principal claims are:

1. A system that facilitates object-relational mapping comprising the following computer-executable components: a storage-specific provider component that exposes a common schema over a store schema of a data store according to a common data model; a mapping provider component that exposes a rich schema over the storage-specific provider component in accordance with a rich data model; a services component that operates in terms of the rich data model; and an object mapping component that provides object services over the rich schema. ...
18. A computer implemented method for incrementally extending a data provider, comprising the following computer executable acts: exposing a common schema over a store schema of a data store in accordance with a common data model; mapping the common schema to a rich schema in accordance with a rich data model that operates at a value layer; providing entity services that function in terms of the rich data model; and providing object services that operate on top of the rich schema. ...
20. A computer executable system that provides object-relational mapping and incrementally extends a data provider, comprising: computer implemented means for extending a storage-specific data provider to support a common command representation; computer implemented means for mapping a storage-specific data model to a rich data model that is defined at the value layer; computer implemented means for providing entity services that conform to the rich data model; and computer implemented means for providing object services built over the rich data model.

(The term rich appears about 80 times in the application's text and several times in the drawings.)

You can learn quite a bit about what the developers had in mind by reading the Summary and Detailed Description sections. I'm not a patent attorney, but the descriptions use the same terminology and describe much of the EF and EDM technology that was discussed in the June 2006 documentation and implemented in the Orcas March 2007 CTP.

The Summary starts by describing an "incremental" approach to O/R mapping:

The subject matter disclosed and claimed herein, in one aspect thereof, comprises an architecture that can facilitate an incremental approach to an Object-Relational mapping solution. We refer to this solution as "incremental" in that it provides layers of abstraction that expose incrementally richer views of the data starting from the flat relational model (exposed by a store-specific provider interface), a nested relational model (exposed by a mapping provider interface), and a full object model (exposed by object services built on top of the mapping or store-specific providers).

It goes on to define the Entity Framework:

In accordance therewith, an Entity Framework can employ a mapping provider, which can expose a common data provider application programming interface (API) over extended storage-specific data providers. The Entity Framework can leverage services that work in terms of a common data model, including the mapping provider, to incrementally build functionality typically found in an Object-Relational layer on top of an existing API (e.g., a relational API or value layer API), rather than providing an entirely new set of components and APIs for working with objects. Services such as client side mapping to rich nested relational schemas, state management, update processing and the like can be added in terms of existing relational API classes. As well, object services can be built on top of these rich services, which can follow a common programming pattern. [Emphasis added].

And finally defines the Entity Data Model (EDM) as a "rich conceptual model" here:

Developers of new data-aware applications can work with a common set of familiar data provider classes such as a class provided by the store-specific data provider and/or the mapping provider. These classes can connect to, query, or retrieve results in terms of a rich conceptual data model. This rich conceptual data model (e.g., the EDM) can include concepts such as nesting, inheritance, complex types and relationships such as containment and association. The EDM can be mapped to various existing flat relational schemas, without requiring changes or additions to the store schema. The store schema, application schema, and even the type of store can all evolve independently, with the mapping to the store and store schema controlled through application configuration. The developer can have the choice of working entirely in terms of textual queries that return standard data records, entirely in terms of object queries that return strongly typed object results, or in any combination of the two.

A reference follows to "Entity Data Model (EDM)," apparently to explain the preceding abbreviation.

The Detailed Description section includes numerous code snippets, which are difficult to read in the full-text version because they aren't <pre> formatted.

Page Images and Drawings

The PTO uses a uncommon TIFF format (ITU T.6 or CCITT Group 4 (G4) compression) for page images and drawings, which require a specialized, proprietary viewer. So here are a few representative drawings from the application.