Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
  • G06F16/273—Asynchronous replication or reconciliation

Definitions

• FIG. 7 is a block diagram illustrating the Base Schema including its two top- level class types, Item and PropertyBase, and the additional Base Schema types derived therefrom;
• Fig. 8A is a block diagram illustrating Items in the Core Schema;
• Fig. 8B is a block diagram illustrating the property types in the Core Schema;
• Fig. 9 is a block diagram illustrating an Item Folder, its member Items, and the interconnecting Relationships between the Item Folder and its member Items;
• Fig. 10 is a block diagram illustrating a Category (which, again, is an Item itself), its member Items, and the interconnecting Relationships between the Category and its member Items; [0038] Fig.
• Fig. 35B illustrates a JIT method of dynamically rewriting one or more interfaces may be applied to dynamically factor or otherwise alter said interface
• Fig. 36 illustrates a three instances of a common data store and the components for synchronizing them
• Fig. 37 illustrates one embodiment of the present invention that presumes a simple adapter that is unaware of how state is calculated or its associated metadata is exchanged.
• the hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively.
• the drives and their associated computer readable media provide non volatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20.
• the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs) and the like may also be used in the exemplary operating environment.
• the exemplary environment may also include many types of monitoring devices such as heat sensors and security or fire alarm systems, and other sources of information.
• a number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37 and program data 38.
• a user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42.
• Other input devices may include a microphone, joystick, game pad, satellite disk, scanner or the like.
• serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB).
• the remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in Fig. 1.
• the logical connections depicted in Fig. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52.
• LAN local area network
• WAN wide area network
• Such networking environments are commonplace in offices, enterprise wide computer networks, intranets and the Internet.
• the personal computer 20 When used in a LAN networking environment, the personal computer 20 is connected to the LAN 51 through a network interface or adapter 53.
• the hardware/software interface system component 204 may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system.
• VMM virtual machine manager
• CLR Common Language Runtime
• JVM Java Virtual Machine
• the purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.
• the goal of any hardware/software interface system is to make the computer system convenient to use, as well as utilize the computer hardware in an efficient manner.
• the hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system.
• the application programs interact with the hardware/software interface system by requesting services via an application program interface (API).
• API application program interface
• directory a tree-based hierarchical arrangement
• directory a tree-based hierarchical arrangement
• the terms "directory” and/or “folder” are interchangeable, and early Apple computer systems (e.g., the Apple He) used the term "catalog” instead of directory; however, as used herein, all of these terms are deemed to be synonymous and interchangeable and are intended to further include all other equivalent terms for and references to hierarchical mformation storage structures and their folder and file components.
• a directory of folders is a tree-based hierarchical structure wherein files are grouped into folders and folder, in turn, are arranged according to relative nodal locations that comprise the directory tree.
• a DOS-based file system base folder (or "root directory") 212 may comprise a plurality of folders 214, each of which may further comprise additional folders (as "subfolders" of that particular folder) 216, and each of these may also comprise additional folders 218 ad infinitum.
• Each of these folders may have one or more files 220 although, at the hardware/software interface system level, the individual files in a folder have nothing in common other than their location in the tree hierarchy.
• the storage platform 320 may also provide application programs with additional capabilities for enabling data to be acted upon and for enabling interaction with other systems. These capabilities may be embodied in the form of additional services 328, such as an Info Agent service 334 and a notification service 332, as well as in the form of other utilities 336.
• the storage platform is embodied in, or forms an integral part of, the hardware/software interface system of a computer system.
• the storage platform of the present invention may be embodied in, or form an integral part of, an operating system, a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, or a Java Virtual Machine (JVM) or its functional equivalent.
• VMM virtual machine manager
• CLR Common Language Runtime
• JVM Java Virtual Machine
• a USPostalAddress type might have the properties Street, City, Zip, State in which Street, City and State are of type String and Zip is of Type Int32. Street may be multi- valued (i.e. a set of values) allowing the address to have more than one value for the Street property.
• the system defines certain primitive types that can be used in the construction of other types - these include String, Binary, Boolean, Intl6, Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUTD.
• the Properties of a Type may be defined using any of the primitive types or (with some restrictions noted below) any of the constructed types.
• the LivesAt Relationship has a Source called Occupant of Type Person and a Target called Dwelling of Type Location and in addition has properties StartDate and EndDate indicating the period of time for which the occupant lived at the dwelling. Note that a Person may live at multiple dwellings over time and a dwelling may have multiple occupants so the most likely place to put the StartDate and EndDate information is on the relationship itself.
• Relationships define a mapping between instances that is constrained by the types given as the endpoint types. For example the LivesAt relationship cannot be a relationship in which an Automobile is the Occupant because an Automobile is not a Person.
• the data model does allow the definition of a subtype-supertype relationship between types.
• the subtype-supertype relationship also known as the BaseType relationship is defined in such a way that if Type A is a BaseType for Type B it must be the case that every instance of B is also an instance of A. Another way of expressing this is that every instance that conforms to B must also conform to A. If, for example A has a property Name of Type String while B has a property Age of Type fritl ⁇ , it follows that any instance of B must have both a Name and an Age.
• the type hierarchy may be envisaged as an tree with a single supertype at the root. The branches from the root provide the first level subtypes, the branches at this level provide the second level subtypes and so on to the leaf-most subtypes which themselves do not have any subtypes.
• the unqualified name of the Item is "Location”.
• the qualified name of the Item is "Core.Location" which indicates that this Item structure is defined as a specific type of Item in the Core Schema. (The Core Schema is discussed in more detail later herein.)
• the Location Item has a plurality of properties including EAddresses, MetropohtanRegion, Neighborhood, and PostalAddresses. The specific type of property for each is indicated immediately following the property name and is separated from the property name by a colon (":").
• FIG. 5B is a block diagram illustrating the complex property types PostalAddress and EAddress.
• the PostalAddress property type defines that an Item of property type PostalAddress can be expected to have zero or one City values, zero or one CountryCode values, zero or one MailStop values, and any number (zero to many) of Postal AddressTypes, and so on and so forth. In this way, the shape of the data for a particular property in an Item is hereby defined.
• the EAddress property type is similarly defined as shown.
• another way to represent the complex types in the Location Item is to draw the Item with the individual properties of each complex type listed therein.
• Fig. 5C is a block diagram illustrating the Location Item wherein its complex types are further described.
• every Item is a subtype of the "Item" Item type which is the first and foundational Item type found in the Base Schema. (The Base Schema will also be discussed in detail later herein.)
• Fig. 6A illustrates an Item, the Location Item in this Instance, as being a subtype of the Item Item type found in the Base Schema. In this drawing, the arrow indicates that the Location Item (like all other Items) is a subtype of the Item Item type.
• the Base.Item type defines a field ItemlD of type GUID that stores the identity for the Item.
• An Item must have exactly one identity in the data store 302.
• An item reference is a data structure that contains information to locate and identify an Item.
• an abstract type is defined named ItemReference from which all item reference types derive.
• the ItemReference type defines a virtual method named Resolve. The Resolve method resolves the ItemReference and returns an Item. This method is overridden by the concrete subtypes of ItemReference, which implement a function that retrieves an Item given a reference.
• the Resolve method is invoked as part of the storage platform API 322.
• an Item must belong to at least one Item Folder so that if the sole Item Folder for a particular Item is deleted then, for some embodiments, the Item is automatically deleted or, in alternative embodiments, the Item automatically becomes a member of a default Item Folder (e.g., a "Trash Can" Item Folder conceptually similar to similarly-named folders used in various file-and-folder- based systems).
• Items may also belong to Categories based on common described characteristic such as (a) an Item Type (or Types), (b) a specific immediate or inherited property (or properties), or (c) a specific value (or values) corresponding to an Item property.
• Categories are conceptually different form Item Folders in that, whereas Item Folders may comprise Items that are not interrelated (i.e., without a common described characteristic), each Item in a Category has a common type, property, or value (a "commonality") that is described for that Category, and it is this commonality that forms the basis for its relationship to and among the other Items in the Category.
• Fig. 4 illustrates the structural relationship between Items, Item Folders, and Categories.
• a plurality of Items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of various Item Folders 422, 424, 426, 428, and 430. Some Items may belong to more than one Item Folder, e.g., Item 402 belong to Item Folders 422 and 424.
• the Base Schema defines certain special types of Items and properties, and the features of these special foundational types from which subtypes can be further derived.
• the use of this Base Schema allows a programmer to conceptually distinguish Items (and their respective types) from properties (and their respective types).
• the Base Schema sets forth the foundational set of properties that all Items may possess as all Items (and their corresponding Item Types) are derived from this foundational Item in the Base Schema (and its corresponding Item Type).
• the Base Schema defines three top-level types: Item, Extension, and PropertyBase.
• the Item type is defined by the properties of this foundational "Item” Item type.
• the top level property type "PropertyBase” has no predefined properties and is merely the anchor from which all other property types are derived and through which all derived property types are interrelated (being commonly derived from the single property type).
• the Extension type properties define which Item the extension extends as well as identification to distinguish one extension from another as an Item may have multiple extensions.
• ItemFolder is a subtype of the Item Item type that, in addition to the properties inherited from Item, features a Relationship for establishing links to its members (if any), whereas both IdentityKey and Property are subtypes of PropertyBase.
• Fig. 8A is a block diagram illustrating Items in the Core Schema
• Fig. 8B is a block diagram illustrating the property types in the Core Schema.
• the Core Schema is not extendable —that is, no additional Item types can be subtyped directly from the Item type in the Base Schema except for the specific predefined derived Item types that are part of the Core Schema.
• the storage platform mandates the use of the Core Schema Item types since every subsequent Item type is necessarily a subtype of a Core Schema Item type. This structure enables a reasonable degree of flexibility in defining additional Item types while also preserving the benefits of having a predefined set of core Item types.
• the specific Item types supported by the Core Schema may include one or more of the following: • Categories: Items of this Item Type (and subtypes derived therefrom) represent valid Categories in the Item-based hardware/software interface system. • Commodities: Items that are identifiable things of value. • Devices: Items having a logical structure that supports information processing capabilities. • Documents: Items with content that is not interpreted by the Item-based hardware/software interface system but is instead interpreted by an application program corresponding to the document type. • Events: Items that record certain occurrences in the environment. • Locations: Items representing physical locations (e.g., geographical locations). • Messages: Items of communication between two or more principals (defined below).
• a holding relationship controls the life-time of the target through a reference counting mechanism.
• the embedding relationships enable modeling of compound Items and can be thought of as exclusive holding relationships.
• An Item can be a target of one or more holding relationships; but an Item can be target of exactly one embedding relationship.
• An Item that is a target of an embedding relationship can not be a target of any other holding or embedding relationships.
• Reference relationships do not control the lifetime of the target Item. They may be dangling - the target Item may not exist. Reference relationships can be used to model references to Items anywhere in the global Item name space (i.e. including remote data stores).
• Fetching an Item does not automatically fetch its relationships. Applications must explicitly request the relationships of an Item.
• Relationship Declaration [0133] The explicit relationship types are defined with the following elements: • A relationship name is specified in the Name attribute. • Relationship type, one of the following: Holding, Embedding, Reference. This is specified in the Type attribute. • Source and target endpoints. Each endpoint specifies a name and the type of the referenced Item. • The source endpoint field is generally of type ItemlD (not declared) and it must reference an Item in the same data store as the relationship instance.
• the target endpoint field must be of type ItemlDReference and it must reference an Item in the same store as the relationship instance.
• the target endpoint can be of any ItemReference type and can reference Items in other storage platform data stores.
• one or more fields of a scalar or PropertyBase type can be declared. These fields may contain data associated with the relationship.
• Relationship instances are stored in a global relationships table. • Every relationship instance is uniquely identified by the combination (source ItemlD, relationship ID). The relationship ID is unique within a given source ItemlD for all relationships sourced in a given Item regardless of their type. [0134] The source Item is the owner of the relationship.
• the target endpoint reference type must be ItemlDReference and it must reference an Item in the same store as the relationship instance.
• Holding relationships enforce lifetime management of the target endpoint.
• the creation of a holding relationship instance and the Item that it is targeting is an atomic operation. Additional holding relationship instances can be created that are targeting the same Item. When the last holding relationship instance with a given Item as target endpoint is deleted the target Item is also deleted.
• the types of the endpoint Items specified in the relationship declaration will generally be enforced when an instance of the relationship is created. The types of the endpoint Items can not be changed after the relationship is established.
• Holding relationships play a key role in forming the Item namespace.
• the target endpoint reference type must be ItemlDReference and it must reference an Item in the same data store as the relationship instance.
• the types of the endpoint Items specified in the relationship declaration will generally be enforced when an instance of the relationship is created.
• the types of the endpoint Items can not be changed after the relationship is established.
• Embedding relationships control the operational consistency of the target endpoint. For example the operation of serializing of an Item may include serialization of all the embedding relationships that source from that Item as well as all of their targets; copying an Item also copies all its embedded Items.
• an Item Folder is an Item that has (or is capable of having) a set of Relationships to other Items, these other Items comprising the membership of the Item Folder.
• Other actual implementations of Relationships are possible and anticipated by the present invention to achieve the functionality described herein.
• a Relationship is a selectable connection from one object to another. The ability for an Item to belong to more than one Item Folder, as well as to one or more Categories, and whether these Items, Folders, and Categories are public or private, is determined by the meanings given to the existence (or lack thereof) in an Item-based structure.
• the aforementioned Relationships which represent the relationship between an Item and it Item Folder(s) can logically extend from the Item to the Item Folder, from the Item Folder to the Item, or both.
• a Relationship that logically extends from an Item to an Item Folder denotes that the Item Folder is public to that Item and shares its membership information with that Item; conversely, the lack of a logical Relationship from an Item to an Item Folder denotes that the Item Folder is private to that Item and does not share its membership information with that Item.
• Item Folder 900 is a block diagram illustrating an Item Folder (which, again, is an Item itself), its member Items, and the interconnecting Relationships between the Item Folder and its member Items.
• the Item Folder 900 has as members a plurality of Items 902, 904, and 906.
• Item Folder 900 has a Relationship 912 from itself to Item 902 which denotes that the Item 902 is public and sharable to Item Folder 900, its members 904 and 906, and any other Item Folders, Categories, or Items (not shown) that might access Item Folder 900.
• Item 902 there is no Relationship from Item 902 to the Item Folder 900 which denotes that Item Folder 900 is private to Item 902 and does not share its membership information with Item 902.
• Item 904 does have a Relationship 924 from itself to Item Folder 900 which denotes that the Item Folder 900 is public and shares its membership information with Item 904.
• Item 904 there is no Relationship from the Item Folder 900 to Item 904 which denotes that Item 904 is private and not sharable to Item Folder 900, its other members 902 and 906, and any other Item Folders, Categories, or Items (not shown) that might access Item Folder 900.
• Item Folder 900 In contrast with its Relationships (or lack thereof) to Items 902 and 904, Item Folder 900 has a Relationship 916 from itself to the Item 906 and Item 906 has a Relationship 926 back to Item Folder 900, which together denote that Item 906 is public and sharable to Item Folder 900, its members 902 and 904, and any other Item Folders, Categories, or Items (not shown) that might access Item Folder 900, and that Item Folder 900 is public and shares its membership information with Item 906.
• a logical representation for a Category may be its membership to comprise Items have one of two properties or both. If these described properties for the Category are "A" and "B", then the Categories membership may comprise Items having property A but not B, Items having property B but not A, and Items having both properties A and B.
• This logical representation of properties is described by the logical operator "OR” where the set of members described by the Category are Items having property A OR B. Similar logical operands (including without limitation “AND”, “XOR”, and “NOT” alone or in combination) can also be used describe a category as will be appreciated by those of skill in the art.
• FIG. 10 is a block diagram illustrating a Category (which, again, is an Item itself), its member Items, and the interconnecting Relationships between the Category and its member Items.
• the Category 1000 has as members a plurality of Items 1002, 1004, and 1006, all of which share some combination of common properties, values, or types 1008 as described (commonality description 1008') by the Category 1000.
• Category 1000 has a Relationship 1012 from itself to Item 1002 which denotes that the Item 1002 is public and sharable to Category 1000, its members 1004 and 1006, and any other Categories, Item Folders, or Items (not shown) that might access Category 1000.
• Item 1002 does not have a Relationship 1024 from itself to Category 1000 which denotes that the Category 1000 is public and shares its membership information with Item 1004.
• Category 1000 has a Relationship 1016 from itself to Item 1006 and Item 1006 has a Relationship 1026 back to Category 1000, which altogether denotes that Item 1006 is public and sharable to Category 1000, its Item members 1002 and 1004, and any other Categories, Item Folders, or Items (not shown) that might access Category 1000, and that the Category 1000 is public and shares its membership information with Item 1006.
• Item Folder structures and/or Category structures are prohibited, at the hardware/software interface system level, from containing cycles.
• Item Folder and Category structures are akin to directed graphs
• the embodiments that prohibit cycles are akin to directed acyclic graphs (DAGs) which, by mathematical definition in the art of graph theory, are directed graphs wherein no path starts and ends at the same vertex. 6.
• DAGs directed acyclic graphs
• subtype Base.Item • an ISV is allowed to introduce new Nested Element types, i.e. subtype Base.NestedElement; • an ISV is allowed to introduce new extensions, i.e. subtype Base.NestedElement; but, • an ISV cannot subtype any types (Item, Nested Element, or Extension types) defined by the initial set of storage platform schemas 340.
• Extensions are strongly typed instances but (a) they cannot exist independently and (b) they must be attached to an Item or Nested Element.
• Extensions are also intended to address the "multi-typing" issue. Since, in some embodiments, the storage platform may not support multiple inheritance or overlapping subtypes, applications can use Extensions as a way to model overlapping type instances (e.g. Document is a legal document as well a secure document).
• the ItemlD field contains the ItemlD of the item that the extension is associated with. An Item with this ItemlD must exist. The extension can not be created if the item with the given ItemlD does not exist.
• Extension type instances can be directly accessed through the view associated with the extension type.
• the ItemlD of the extension indicates which item they belong to and can be used to retrieve the corresponding Item object from the global Item view.
• the extensions are considered part of the item for the purposes of operational consistency.
• the Copy/Move, Backup/Restore and other common operations that the storage platform defines may operate on the extensions as part of the item. [0184]
• a Contact type is defined in the Windows Type set.
• a CRM application developer would like to attach a CRM application extension to the contacts stored in the storage platform.
• the application developer would define a CRM extension that would contain the additional data structure that the application can manipulate.
• CRMExtension and HRExtension are two independent extensions that can be attached to Contact items. They are created and accessed independently of each other. [0188] In the above example, the fields and methods of the CRMExtension type cannot override fields or methods of the Contact hierarchy. It should be noted that instances of the CRMExtension type can be attached to Item types other than Contact.
• Nested element is part of the item Storage Item hierarchy is Item extension Stored with item stored in its own hierarchy is stored tables in its own tables Query/Search Can query item Can query item Can generally be tables extension tables queried only within the containing item context Query/Search Can search across Can search across Can generally only scope all instances of an all instances of an search within nested item type item extension type element type instances of a singe (containing) item Relationship Can have No Relationships to No Relationships to semantics Relationships to item extensions nested elements items Association to Can be related to Can generally only Related to item via items other items via be related via fields.
• the elements are part of and soft extension semantics the item Relationships is similar to embedded item b) Extending NestedElement types [0192] Nested Element types are not extended with the same mechanism as the Item types. Extensions of nested elements are stored and accessed with the same mechanisms as fields of nested element types.
• the NestedElement type inherits from this type.
• NestedElement extensions are different from item extensions in the following ways: • Nested element extensions are not extension types. They do not belong to the extension type hierarchy that is rooted in the Base.Extension type. • Nested element extensions are stored along with the other fields of the item and are not globally accessible - a query can not be composed that retrieves all instances of a given extension type. • These extensions are stored the same way as other nested elements (of the item) are stored. Like other nested sets, the NestedElement extensions are stored in a UDT. They are accessible through the Extensions field of the nested element type.
• An object-oriented (OO) database system provides persistence and transactions for programming language objects (e.g. C++, Java).
• the storage platform notion of an "item” maps well to an "Object” in object-oriented systems, though embedded collections would have to be added to Objects.
• Other storage platform type concepts like inheritance and nested element types, also map object-oriented type systems.
• Object-oriented systems typically already support object identity; hence, item identity can be mapped to object identity.
• the item behaviors (operations) map well to object methods.
• object-oriented systems typically lack organizational capabilities and are poor in searching. Also, object-oriented systems to do not provide support for unstructured and semi-structured data.
• XML databases Similar to object-oriented systems, XML databases, based on XSD (XML Schema Definition), support a single-inheritance based type system. The item type system of the present invention could be mapped to the XSD type model. XSDs also do not provide support for behaviors. The XSDs for items would have to be augmented with item behaviors. XML databases deal with single XSD documents and lack organization and broad search capabilities.
• Fig. 13 is a diagram illustrating a notification mechanism.
• Fig. 14 is a diagram illustrating an example in which two transactions are both inserting a new record into the same B-Tree.
• Fig. 15 illustrates a data change detection process.
• Fig. 16 illustrates an exemplary directory tree.
• Fig. 17 shows an example in which an existing folder of a directory-based file system is moved into the storage platform data store. 1.
• the relational database engine 314 which in one embodiment comprises the Microsoft SQL Server engine, supports built-in scalar types.
• Built-in scalar types are "native" and “simple”. They are native in the sense that the user cannot define their own types and they are simple in that they cannot encapsulate a complex structure.
• User- defined types hereinafter: UDTs provide a mechanism for type extensibility above and beyond the native scalar type system by enabling users to extend the type system by defining complex, structured types.
• a UDT can be used anywhere in the type system that a built-in scalar type might be used
• the storage platform schemas are mapped to UDT classes in the database engine store.
• Data store Items are mapped to UDT classes deriving from the Base.Item type.
• Like Items, Extensions are also mapped to UDT classes and make use of inheritance.
• the root Extension type is Base.Extension, from which all Extension types are derived.
• a UDT is a CLR class - it has state (i.e., data fields) and behavior (i.e., routines). UDTs are defined using any of the managed languages - C#, VB.NET, etc.
• UDT methods and operators can be invoked in T-SQL against an instance of that type.
• a UDT can be: the type of a column in a row, the type of a parameter of a routine in T-SQL, or the type of a variable in T-SQL [0204]
• the mapping of storage platform schemas to UDT classes is fairly straightforward at a high level. Generally, a storage platform Schema is mapped to a CLR namespace. A storage platform Type is mapped to a CLR class. The CLR class inheritance mirrors the storage platform Type inheritance, and a storage platform Property is mapped to a CLR class property. 2.
• Item Mapping Given the desirability for Items to be globally searchable, and the support in the relational database of the present embodiment for inheritance and type substitutability, one possible implementation for Item storage in the database store would be to store all Items in a single table with a column of type Base.Item. Using type substitutability, Items of all types could be stored, and searches could be filtered by Item type and sub-type using Yukon's "is of (Type)" operator. [0206] However, due to concerns about the overhead associated with such an approach, in the present embodiment, the Items are divided by top-level type, such that Items of each type "family" are stored in a separate table.
• a "shadow" table is used to store copies of globally searchable properties for all Items. This table may be maintained by the Update() method of the storage platform API, through which all data changes are made. Unlike the type family tables, this global Item table contains only the top-level scalar properties of the Item, not the full UDT Item object.
• the global Item table allows navigation to the Item object stored in a type family table by exposing an ItemlD and a TypelD.
• Extensions are very similar to Items and have some of the same requirements. As another root type supporting inheritance, Extensions are subject to many of the same considerations and trade-offs in storage. Because of this, a similar type family mapping is applied to Extensions, rather than a single table approach. Of course, in other embodiments, a single table approach could be used.
• an Extension is associated with exactly one Item by ItemlD, and contains an ExtensionID that is unique in the context of the Item.
• a function might be provided to retrieve an Extension given its identity, which consists of an ItemlD and ExtensionID pair.
• An Item is uniquely identified by its Itemld.
• An Extension is uniquely identified by a composite key of (Itemld, Extensionld).
• a Relationship is identified by a composite key (Itemld, Relationshipld).
• Itemld, Extensionld and Relationshipld are GUID values.
• SQL Object Naming All objects created in the data store can be stored in a SQL schema name derived from the storage platform schema name. For example, the storage platform Base schema (often called “Base”) may produce types in the "[System.Storage]” SQL schema such as "[System. Storage] .Item”. Generated names are prefixed by a qualifier to eliminate naming conflicts.
• exclamation character (!) is used as a separator for each logical part of the name.
• Table below outlines the naming convention used for objects in the data store. Each schema element (Item, Extension, Relationship and View), is listed along with the decorated naming convention used to access instances in the data store.
• views are provided to support Relationships and Views (as defined by the Data Model). All SQL views and underlying tables in the storage platform are read-only. Data may be stored or changed using the UpdateQ method of the storage platform API, as described more fully below.
• Each view explicitly defined in a storage platform schema (defined by the schema designer, and not automatically generated by the storage platform) is accessible by the named SQL view [ ⁇ schema-name>].[View! ⁇ view-name>]. For example, a view named "BookSales" in the schema "AcmePublisher.Books" would be accessible using the name "[AcmePublisher.Books].[View!BookSales]”.
• Fig. 28 is a diagram illustrating the concept of an Item search view.
• Item search view contains a row for each instance of an Item of the specific type or its subtypes.
• the view for Document could return instances of Document, LegalDocument and ReviewDocument.
• the Item views can be conceptualized as shown in Fig. 29.
• Master Item Search View Each instance of a storage platform data store defines a special Item view called the Master Item View. This view provides summary information on each Item in the data store. The view provides one column per Item type property, a column which described the type of the Item and several columns which are used to provide change tracking and synchronization information.
• the master item view is identified in a data store using the name "[System.Storage] . [Master ⁇ tem]”.
• Each Extension type also has a search view. While similar to the master extension view, this view also provides access to the Item object via the _Extension column.
• Each typed extension search view is identified in a data store using the name [schemaName].[Extension ⁇ extensionTypeName]. For example [AcmeCorp.Doc] . [Extension! OfficeDocExf] .
• Each declared Relationship also has a search view which returns all instances of the particular relationship. While similar to the master relationship view, this view also provides named columns for each property of the relationship data.
• Each relationship instance search view is identified in a data store using the name [schemaName].[R.elationship ⁇ relationshipName]. For example [ AcmeCorp .Doc] . [Relationship ⁇ DocumentAuthor] .
• Createltem (Creates a new item in the context of an embedding or holding relationship) b. Updateltem (updates an existing Item) 2.
• Relationship operations a. CreateRelationship (creates an instance of a reference or holding relationship) b. UpdateRelationship (updates a relationship instance) c. DeleteRelationship (removes a relationship instances) 3.
• Change tracking information in the master search views provides information on the creation and update versions of an element, information on which sync partner created the element, which sync partner last updated the element and the version numbers from each partner for creation and update. Partners in sync relationships (described below) are identified by partner key.
• a single UDT object named _ChangeTrackingInfo of type [System.Storage.Store].ChangeTrackingInfo contains all this information. The type is defined in the System.Storage schema. _ChangeTrackingInfo is available in all global search views for Item, Extension and Relationship. The type definition of ChangeTrackinglnfo is:
• each typed search view provides additional information recording the sync state of each element in the sync topology.
• Tombstones The data store provides tombstone information for Items, Extensions and Relationships.
• the tombstone views provide information about both live and tombstoned entities (items, extensions and relationships) in one place.
• the item and extension tombstone views do not provide access to the corresponding object, while the relationship tombstone view provides access to the relationship object (the relationship object is NULL in the case of a tombstoned relationship).
• Item Tombstones [0236] Item tombstones are retrieved from the system via the view [System.Storage]. [Tombstone.'Item].
• Extension Tombstones are retrieved from the system using the view [System.Storage]. [Tombstone!Extension]. Extension change tracking inforaiation is similar to that provided for Items with the addition of the Extensionld property.
• the data store provides a tombstone cleanup task. This task determines when tombstone information may be discarded. The task computes a bound on the local create / update version and then truncates the tombstone information by discarding all earlier tombstone versions.
• Helper APIs and Functions [0240] The Base mapping also provides a number of helper functions. These functions are supplied to aid common operations over the data model. a) Function [System.Storage].GetItem
• Metadata There are two types of metadata represented in the Store: instance metadata (the type of an Item, etc), and type metadata.
• instance metadata the type of an Item, etc
• type metadata the type metadata
• Schema metadata is stored in the data store as instances of Item types from the Meta schema.
• Instance Metadata is used by an application to query for the type of an Item and finds the extensions associated with an Item. Given the Itemld for an Item, an application can query the global item view to return the type of the Item and use this value to query the Meta. Type view to return information on the declared type of the Item. For example,
• E. SECURITY In general, all securable objects arrange their access rights using the access mask format shown in the Fig. 26. In this format, the low-order 16 bits are for object-specific access rights, the next 7 bits are for standard access rights, which apply to most types of objects, and the 4 high-order bits are used to specify generic access rights that each object type can map to a set of standard and object-specific rights.
• the ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the object's SACL.
• item specific rights are placed in the Object Specific Rights section (low order 16-bits).
• Fig. 27 depicts a new identically protected security region being carved out of an existing security region, in accordance with one embodiment of a security model.
• the storage platform provides a notifications capability that allows applications to track data changes. This feature is primarily intended for applications which maintain volatile state or execute business logic on data change events. Applications register for notifications on items, item extensions and item relationships. Notifications are delivered asynchronously after data changes have been committed. Applications may filter notifications by item, extension and relationship type as well as type of operation. [0248] According to one embodiment, the storage platform API 322 provides two kinds of interfaces for notifications. First, applications register for simple data change events triggered by changes to items, item extensions and item relationships. Second, applications create "watcher" objects to monitor sets of items, item extensions and relationships between items.
• the storage platform of the present mvention is, in at least some embodiments, intended to be embodied as an integral part of the hardware/software interface system of a computer system.
• the storage platform of the present invention may be embodied as an integral part of an operating system, such as the Microsoft Windows family of operating systems.
• the storage platform API becomes a part of the operating system APIs through which application programs interact with the operating system.
• the storage platform becomes the means through which application programs store information on the operating system, and the Item based data model of the storage platform therefore replaces the traditional files system of such an operating system.
• the storage platform might replace the NTFS file system implemented in that operating system.
• application programs access the services of the NTFS file system through the Win32 APIs exposed by the Windows family of operating systems.
• the storage platform enables application programs which rely on the Win32 programming model to access the contents of both the data store of the storage platform as well as the traditional NTFS file system.
• the storage platform uses a naming convention that is a superset of the Win32 naming conventions to facilitate easy interoperability.
• the storage platform supports accessing files and directories stored in a storage platform volume through the Win32 API.
• the storage platform comprises an API that enables application programs to access the features and capabilities of the storage platform discussed above and to access items stored in the data store.
• This section describes one embodiment of a storage platform API of the storage platform of the present invention. Details regarding this functionality can be found in the related applications incorporated by reference earlier herein, with some of this information summarized below for convenience.
• a Containment Folder is an item which contains holding Relationships to other Items and is the equivalent of the common concept of a file system folder. Each Item is "contained" within at least one containment folder.
• the storage platform API uses SQLClient 1900 to talk to the local data store 302 and may also use SQLClient 1900 to talk to remote data stores (e.g., data store 340).
• the local store 302 may also talk to the remote data store 340 using either DQP (Distributed Query Processor) or through the the storage platform synchronization service ("Sync") described below.
• the storage platform API 322 also acts as the bridge API for data store notifications, passing application's subscriptions to the notification engine 332 and routing notifications to the application (e.g., application 350a, 350b, or 350c), as also described above.
• a programming interface may be viewed as any mechanism, process, protocol for enabling one' or more segment(s) of code to communicate with or access the functionality provided by one or more other segment(s) of code.
• a programming interface may be viewed as one or more mechanism(s), method(s), function call(s), module(s), object(s), etc. of a component of a system capable of communicative coupling to one or more mechanism(s), method(s), function call(s), module(s), etc. of other component(s).
• aspects of such a programming interface may include the method whereby the first code segment transmits information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) to the second code segment; the method whereby the second code segment receives the information; and the structure, sequence, syntax, organization, schema, timing and content of the information.
• information is used in its broadest sense and includes data, commands, requests, etc.
• 30A includes a function call Square(input, precision, output), a call that includes three parameters, input, precision and output, and which is issued from the 1st Code Segment to the 2nd Code Segment. If the middle parameter precision is of no concern in a given scenario, as shown in Fig. 32A, it could just as well be ignored or even replaced with a meaningless (in this situation) parameter. One may also add an additional parameter of no concern. In either event, the functionality of square can be achieved, so long as output is returned after input is squared by the second code segment. Precision may very well be a meaningful parameter to some downstream or other portion of the computing system; however, once it is recognized that precision is not necessary for the narrow purpose of calculating the square, it may be replaced or ignored.
• FIG. 33A the previous 1st and 2nd Code Segments of Fig. 30A are merged into a module containing both of them.
• the code segments may still be communicating with each other but the interface may be adapted to a form which is more suitable to the single module.
• formal Call and Return statements may no longer be necessary, but similar processing or response(s) pursuant to interface Interfacel may still be in effect.
• part (or all) of interface 12 from Fig. 30B may be written inline into interface II to form interface II".
• one or more piece(s) of middleware (Divorce Interface(s), since they divorce functionality and / or interface functions from the original interface) are provided to convert the communications on the first interface, Interfacel, to conform them to a different interface, in this case interfaces Interface2A, Interface2B and Interface2C.
• middleware Divorce Interface(s)
• a third code segment can be introduced with divorce interface DI1 to receive the communications from interface II and with divorce interface DI2 to transmit the interface functionality to, for example, interfaces I2a and I2b, redesigned to work with DI2, but to provide the same functional result.
• DI1 and DI2 may work together to translate the functionality of interfaces II and 12 of Fig. 30B to a new operating system, while providing the same or similar functional result.
• the JIT compiler may be written so as to dynamically convert the communications from the 1st Code Segment to the 2nd Code Segment, i.e., to conform them to a different interface as may be required by the 2nd Code Segment (either the original or a different 2nd Code Segment).
• This is depicted in Figs. 35 A and 35B.
• Fig. 35A this approach is similar to the Divorce scenario described above. It might be done, e.g., where an installed base of applications are designed to communicate with an operating system in accordance with an Interface 1 protocol, but then the operating system is changed to use a different interface.
• the JIT Compiler could be used to conform the communications on the fly from the installed-base applications to the new interface of the operatmg system. As depicted in Fig. 35B, this approach of dynamically rewriting the interface(s) may be applied to dynamically factor, or otherwise alter the interface(s) as well.
• the above-described scenarios for achieving the same or similar result as an interface via alternative embodiments may also be combined in various ways, serially and/or in parallel, or with other intervening code.
• the alternative embodiments presented above are not mutually exclusive and may be mixed, matched and combined to produce the same or equivalent scenarios to the generic scenarios presented in Figs. 30A and 30B.
• Section A discloses several embodiments of the present invention, while Section B focuses on various embodiments of an API for synchronization.
• the storage platform provides a synchronization service 330 that (i) allows multiple instances of the storage platform (each with its own data store 302) to synchronize parts of their content according to a flexible set of rules, and (ii) provides an infrastructure for third parties to synchronize the data store of the storage platform of the present invention with with other data sources that implement proprietary protocols.
• Storage-platform-to-storage-platform synchronization occurs among a group of participating "replicas.” For example, with reference to Fig. 3, it may be desirable to provide synchronization between the data store 302 of the storage platform 300 with another remote data store 338 under the control of another instance of the storage platform, perhaps running on a different computer system. The total membership of this group is not necessarily known to any given replica at any given time.
• Different replicas can make the changes independently (i.e., concurrently). The process of synchronization is defined as making every replica aware of the changes made by other replicas. This synchronization capability is inherently multi-master.
• the synchronization capability of the present invention allows replicas to: determine which changes another replica is aware of; request information about changes that this replica is not aware of; convey information about changes that the other replica is not aware of; determine when two changes are in conflict with each other; apply changes locally; convey conflict resolutions to other replicas to ensure convergence; and resolve the conflicts based on specified policies for conflict resolutions.
• Storage-Platform-to-Storage-Platform Synchronization [0277] The primary application of the synchronization service 330 of the storage platform of the present invention is to synchronize multiple instances of the storage platform (each with its own data store). The synchronization service operates at the level of the storage platform schemas (rather than the underlying tables of the database engine 314).
• the synchronization service operates on the principle of "net changes". Rather than recording and sending individual operations (such as with transactional replication), the synchronization service sends the end-result of those operations, thus often consolidating the results of multiple operations into a single resulting change. [0279]
• the synchronization service does not in general respect transaction boundaries. In other words, if two changes are made to a storage platform data store in a single transaction, there is no guarantee that these changes are applied at all other replicas atomically — one may show up without the other.
• Synchronization (Sync) Controlling Applications Any application can connect to the synchronization service and initiate a sync operation. Such an application provides all of the parameters needed to perform synchronization (see sync profile below). Such applications are referred to herein as Sync Controlling Applications (SCAs).
• SCAs Sync Controlling Applications
• the synchronization service is awoken by the messages sent by the synchronization service from the originating machine. It responds based on the persistent configuration information (see mappings below) present on the destination machine.
• the synchronization service can be run on schedule or in response to events. In these cases, the synchronization service implementing the schedule becomes the SCA.
• the schema designer must annotate the storage platform schema with appropriate sync semantics (designating Change Units as described below).
• Second, synchronization must be properly configured on all of the machines having an instance of the storage platform that is to participate in the synchronization (as described below).
• a fundamental concept of the synchronization service is that of a Change Unit.
• a Change Unit is a smallest piece of schema that is individually tracked by the storage platform. For every Change Unit, the synchronization service may be able to determine whether it changed or did not change since the last sync.
• Designating Change Units in the schema serves several purposes. First, it determines how chatty the synchronization service is on the wire. When a change is made inside a Change Unit, the entire Change Unit is sent to the other replicas, since the synchronization service does not know which part of the Change Unit was changed. Second, it determines the granularity of conflict detection.
• the synchronization service raises a conflict; on the other hand, if concurrent changes are made to different Change Units, then no conflict is raised and the changes are automatically merged.
• Defining Change Units requires finding the right trade-offs. For that reason, the synchronization service allows schema designers to participate in the process.
• the synchronization service does not support Change Units that are larger than an element.
• sync community A group of storage platform partners that wish to keep certain parts of their data in sync are referred to as a sync community. While the members of the community want to stay in sync, they do not necessarily represent the data in exactly the same way; in other words, sync partners may transform the data they are synchronizing.
• sync partners may transform the data they are synchronizing.
• the synchronization service takes the approach of defining "Community Folders".
• a community folder is an abstraction that represents a hypothetical "shared folder" that all community members are synchronizing with. [0289] This notion is best illustrated by an example.
• Joe wants to keep My Documents folders of his several computers in sync
• Joe defines a community folder called, say, JoesDocuments.
• Joe configures a mapping between the hypothetical JoesDocuments folder and the local My Documents folder. From this point on, when Joe's computers synchronize with each other, they talk in terms of documents in JoesDocuments, rather than their local items. This way, all Joe's computers understand each other without having to know who the others are — the Community Folder becomes the lingua franca of the sync community.
• Configuring the synchronization service consists of three steps: (1) defining mappings between local folders and community folders; (2) defining sync profiles that determine what gets synchronized (e.g.
• Community Folder mappings are stored as XML configuration files on individual machines. Each mapping has the following schema: /mappings/ 'community! ' older This element names the community folder that this mapping is for. The name follows the syntax rules of Folders. /mappings/localFolder This element names the local folder that the mapping transforms into. The name follows the syntax rules of Folders. The folder must already exist for the mapping to be valid. The items within this folder are considered for synchronization per this mapping.
• /mappings/transformations This element defines how to transform items from the community folder to the local folder and back. If absent or empty, no transformations are performed. In particular, this means that no IDs are mapped. This configuration is primarily useful for creating a cache of a Folder.
• /mappings/transformations/mapIDs This element requests that newly generated local IDs be assigned to all of the items mapped from the community folder, rather than reusing community IDs. The Sync Runtime will maintain ID mappings to convert items back and forth.
• /mappings/transformations/localRoot This element requests that all root items in the community folder be made children of the specified root. /mappings/runAs This element controls under whose authority requests against this mapping are processed.
• a Sync Profile is a total set of parameters needed to kick off synchronization. It is supplied by an SCA to the Sync Runtime to initiate sync.
• Sync profiles for storage platform- to-storage platform synchronization contain the following information: • Local Folder, to serve as the source and destination for changes; • Remote Folder name to synchronize with - this Folder must be published from the remote partner by way of a mapping as defined above; • Direction - the synchronization service supports send-only, receive-only, and send-receive sync; • Local Filter — selects what local information to send to the remote partner.
• Profiles can also be serialized to and from XML files for easy storage (often alongside schedules). However, there is no standard place in the storage platform where all the profiles are stored; SCAs are welcome to construct a profile on the spot without ever persisting it. Note that there is no need to have a local mapping to initiate sync. All sync mformation can be specified in the profile. The mapping is, however, required in order to respond to sync requests initiated by the remote side. (3) Schedules [0294] In one embodiment, the synchronization service does not provide its own scheduling infrastructure, instead, it relies on another component to peform this task - the Windows Scheduler available with the Microsoft Windows operating system.
• the synchronization service includes a command-line utility that acts as an SCA and triggers synchronization based on a sync profile saved in an XML file.
• This utility makes it very easy to configure the Windows Scheduler to run synchronization either on schedule, or in response to events such as user logon or logoff.
• Conflict handling in the synchronization service is divided into three stages: (1) conflict detection, which occurs at change application time - this step determines if a change can be safely applied; (2) automatic conflict resolution and logging - during this step (that takes place immediately after the conflict is detected) automatic conflict resolvers are consulted to see if the conflict can be resolved - if not, the conflict can be optionally logged; and (3) conflict inspection and resolution - this step takes place if some conflicts have been logged, and occurs outside of the context of the sync session - at this time, logged conflicts can be resolved and removed from the log.
• conflict Detection In the present embodiment, the synchronization service detects two types of conflicts: knowledge-based and constraint-based.
• the synchronization service can take one of three actions (selected by the sync initiator in the Sync Profile): (1) reject the change, returning it back to sender; (2) log a conflict into a conflict log; or (3) resolve the conflict automatically. [0303] If the change is rejected, the synchronization service acts as if the change did not arrive at the replica. A negative acknowledgement is sent back to the originator. This resolution policy is primarily useful on head-less replicas (such as file servers) where logging conflicts is not feasible. Instead, such replicas force the others to deal with the conflicts by rejecting them. [0304] Sync initiators configure conflict resolution in their Sync Profiles.
• This list includes: • local- wins: disregard incoming changes if in conflict with locally stored data; • remote- wins: disregard local data if in conflict with incoming changes; • last- writer- wins: pick either local-wins or remote-wins per Change Unit based on the timestamp of the change (note that the synchronization service in general does not rely on clock values; this conflict resolver is the sole exception to that rule); • Deterministic: pick a winner in a manner that is guaranteed to be the same on all replicas, but not otherwise meaningful - one embodiment of the synchronization services uses lexicographic comparisons of partner IDs to implement this feature. [0306] In addition, ISVs can implement and install their own conflict resolvers.
• conflict Logging A very particular kind of a conflict resolver is the Conflict Logger.
• the synchronization service logs conflicts as Items of type ConflictRecord. These records are related back to the items that are in conflict (unless the items themselves have been deleted). Each conflict record contains: the incoming change that caused the conflict; the type of the conflict: update-update, update-delete, delete-update, insert-insert, or constraint; and the version of the incoming change and the knowledge of the replica sending it. Logged conflicts are available for inspection and resolution as described below.
• conflict Inspection and Resolution [0311] The synchronization service provides an API for applications to examine the conflict log and to suggest resolutions of the conflicts in it.
• the API allows application to enumerate all conflicts, or conflicts related to a given Item. It also allows such applications to resolve logged conflicts in one of three ways: (1) remote wins — accepting the logged change and overwriting the conflicting local change; (2) local wins — ignoring conflicting parts of the logged change; and (3) suggest new change — where the application proposes a merge that, in its opinion, resolves the conflict. Once conflicts are resolved by an application, the synchronization service removes them from the log. (d) Convergence of Replicas and Propagation of Conflict Resolutions [0312] In complex synchronization scenarios, the same conflict can be detected at multiple replicas.
• the synchronization service forwards conflict resolutions to other replicas.
• the synchronization service automatically finds any conflict records in the log that are resolved by this update and eliminates them. In this sense, a conflict resolution at one replica is binding on all the other replicas.
• the synchronization service applies the principle of binding conflict resolution and picks one of the two resolutions to win over the other automatically.
• the storage platform provides an architecture for ISVs to implement Sync Adapters that allow the storage platform to synchronize to legacy systems such as Microsoft Exchange, AD, Hotmail, etc.
• Sync Services The synchronization service provides a number of sync services to adapter writers. For the rest of this section, it is convenient to refer to the machine on which the storage platform is doing synchronization as the "client” and the non-storage platform backend that the adapter is talking to as the "server”.
• Change Enumeration Based on the change-tracking data maintained by the synchronization service, Change Enumeration allows sync adapters to easily enumerate the changes that have occurred to a data store Folder since the last time synchronization with this partner was attempted.
• Adapters using supplied anchors must read the new anchor (which incorporates all of the successfully-applied changes) and send it to their backend.
• Adapters need to store adapter-specific data along with the items they insert into the storage platform data store. Common examples of such data are remote IDs and remote versions (timestamps).
• the synchronization service provides a mechanism for storing this data, and Change Enumeration provides a mechanism to receive this extra data along with the changes being returned. This eliminates the need for adapters to re-query the database in most cases.
• Change Application allows Sync Adapters to apply changes received from their backend to the local storage platform. Adapters are expected to transform the changes to the storage platform schema.
• the conflict Resolution mechanisms described above are available to sync adapters as well.
• Sync adapters may specify the policy for conflict resolution when applying changes. If specified, conflicts may be passed on to the specified conflict handler and resolved (if possible). Conflicts can also be logged. It is possible that the adapter may detect a conflict when attempting to apply a local change to the backend. In such a case, the adapter may still pass the conflict on to the Sync Runtime to be resolved according to policy.
• Sync Adapters may request that any conflicts detected by the synchronization service be sent back to them for processing. This is particularly convenient in the case where the backend is capable of storing or resolving conflicts.
• FOO RemoteChangeCoUection remoteChanges FOO_GetRemoteChanges( remote Anchor );
• the adapter To execute in its own separate process, the adapter defines its own factory class, which is used to instantiate the adapter.
• the factory can return an instance of the adapter in the same process as the invoking application, or return a remote instance of the adapter in a different Microsoft common language runtime application domain or process.
• a default factory implementation is provided which instantiates the adapter in the same process.
• many adapters will run in the same process as the invoking application.
• the out of process model is usually required for one or both of the following reasons: • Security purposes.
• the adapter must run in the process space of a certain process or service. •
• the adapter has to process requests from other sources — for example, incoming network requests — in addition to processing requests from invoking applications. [0358] Referring to Fig.
• one embodiment of the present invention presumes a simple adapter that is unaware of how state is calculated or it associated metadata is exchanged.
• synchronization is achieved by the replica, in regard to the data source with which it wants to synchronize, by first, at step 3702, determining which changes have occurred since it last synchronized with said data source, and the replica then transmits the incremental changes that have occurred since this last synchronization based on its present state information, and this present state information and incremental changes are to the data source via the adapter.
• the adapter upon receiving the change data from the replica in the previous step, implements as many changes to the data source as possible, tracks which changes are successful and which fail, and transmits the success-and-failure info back to WinFS (of the replica).
• the hardware/software interface system of the replica upon receiving the success-and-failure info from the replica, then calculates the new state information for the data source, stores this information for future use by its replica, and transmits this new state info back to the data source, that is, to the adapter for storage and subsequent use by the adapter.
• Each replica is a defined synchronization subset of data from the entirety of a data store — a slice of data having multiple instances.
• Conflict resolution policies are handled by each replica (and adaptor/data source combination) individually — that is, each replica is able to resolve conflicts based on its own criteria and conflict resolution schema. Moreove, while differences in each instance of the data store may result and lead to additional future conflicts, the incremental and sequential enumeration of conflicts as reflected in updated state information is invisible to other replicas that receive that updated state information.
• the replica At the root of the sync schema is the replica which has a base type to define a root folder (in fact, a root Item) that has a unique ID, an ID for the sync community in which it is a member, and whatever filters and other elements are necessary or desireable for the specific replica. •
• Each replica's "mapping" is maintained within the replica and, as such, the mapping for any particular replica is limited to the other replicas such replica knows about. While this mapping may only comprise a subset of the entire sync community, changes to said replica will still propogate to the entire sync community via commonly shared replicas (although any particular replica is unaware of which other replicas it is commonly sharing with an unknown replica).
• the sync schema includes both a plurality of predefined conflict handlers available to all replicas, as well as the ability for user/developer defined custom conflict handlers.
• the schema also may also include three special "conflict resolvers”: (a) a conflict "filter” which resolves different conflicts in different ways based, e.g., (i) how to handle when same change unit changed in two places, (ii) how to handle when a change unit is changed in one place but deleted in another; and (iii) how to handle when two different change units have the same name in two different locations; (b) conflict "handler list” where each element of the list specifies a series of actions to attempt in order until the conflict is successfully resolved; and (c) a "do-nothing" log that tracks the conflict but takes no further action without user intervention.
• conflict resolvers e.g., (i) how to handle when same change unit changed in two places, (ii) how to handle when a change unit is changed in one place but deleted in another
• Every replica has its own metadata for tracking incremental change enumeration and storing state mformation for the other replicas that are known in the sync community.
• Change units have their own metadata comprising: a version comprising a partner key plus a partner change number; an Item/Extension/Relationship versioning for each change unit; Knowledge regarding the changes a replica has seen/received from the sync community; a GUID and Local ID configuration; and a GUID stored on a reference relationship for cleanup.
• the present invention is directed to a storage platform for organizing, searching, and sharing data.
• the storage platform of the present mvention extends and broadens the concept of data storage beyond existing file systems and database systems, and is designed to be the store for all types of data, including structured, non- structured, or semi-structured data, such as relational (tabular) data, XML, and a new form of data called Items.
• structured, non- structured, or semi-structured data such as relational (tabular) data, XML, and a new form of data called Items.
• the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It offers a rich and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also embraces and extends existing file system and database access methods. It is understood that changes may be made to the embodiments described above without departing from the broad inventive concepts thereof.
• This program code may be stored on a computer-readable medium, such as a magnetic, electrical, or optical storage medium, including without limitation a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer or server, the machine becomes an apparatus for practicing the invention.
• a computer-readable medium such as a magnetic, electrical, or optical storage medium, including without limitation a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer or server, the machine becomes an apparatus for practicing the invention.
• the present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, over a network, including the Internet or an intranet, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.
• program code When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

Landscapes

• Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Computing Systems (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Multi Processors (AREA)

Priority Applications (8)

Applications Claiming Priority (6)

Publications (1)

Family

ID=34279606

Family Applications (1)

Country Status (7)

Cited By (28)

Families Citing this family (2)

Citations (2)

Family Cites Families (7)

• 2004
  • 2004-07-29 CA CA2512185A patent/CA2512185C/en not_active Expired - Fee Related
  • 2004-07-29 BR BR0406612-0A patent/BRPI0406612A/pt not_active IP Right Cessation
  • 2004-07-29 MX MXPA05007092A patent/MXPA05007092A/es active IP Right Grant
  • 2004-07-29 EP EP04757349A patent/EP1581894A4/en not_active Ceased
  • 2004-07-29 JP JP2006523857A patent/JP4583376B2/ja not_active Expired - Fee Related
  • 2004-07-29 WO PCT/US2004/024288 patent/WO2005024665A1/en not_active Ceased
  • 2004-07-29 AU AU2004271525A patent/AU2004271525B2/en not_active Ceased

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events