EP1573600A2 - Systemes et procedes pour la synchronisation de systemes informatiques par un partage ou dispositif de systeme de fichier intermediaire - Google Patents

Systemes et procedes pour la synchronisation de systemes informatiques par un partage ou dispositif de systeme de fichier intermediaire

Info

Publication number
EP1573600A2
EP1573600A2 EP04779486A EP04779486A EP1573600A2 EP 1573600 A2 EP1573600 A2 EP 1573600A2 EP 04779486 A EP04779486 A EP 04779486A EP 04779486 A EP04779486 A EP 04779486A EP 1573600 A2 EP1573600 A2 EP 1573600A2
Authority
EP
European Patent Office
Prior art keywords
item
intermediary
ofthe
synchronization
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04779486A
Other languages
German (de)
English (en)
Other versions
EP1573600A4 (fr
Inventor
Darshatkumar c/o Microsoft Corporation SHAH
Lev c/o Microsoft Corporation NOVIK
Michael W. c/o Microsoft Corporation THOMAS
Nils H. c/o Microsoft Corporation POHLMANN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/646,646 external-priority patent/US7349913B2/en
Priority claimed from PCT/US2003/027419 external-priority patent/WO2005029314A1/fr
Priority claimed from US10/692,508 external-priority patent/US7483923B2/en
Priority claimed from US10/883,621 external-priority patent/US7512638B2/en
Priority claimed from US10/889,423 external-priority patent/US7401104B2/en
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of EP1573600A2 publication Critical patent/EP1573600A2/fr
Publication of EP1573600A4 publication Critical patent/EP1573600A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles

Definitions

  • MSFT-2854 filed on June 30, 2004, entitled "SYSTEMS AND METHODS FOR PROVIDING CONFLICT HANDLING FOR PEER-TO-PEER SYNCHRONIZATION OF UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM," which is a continuation-in-part of U.S. Patent Application No. 10/692,508 (Atty. Docket No.
  • MSFT-2845 filed on October 24, 2003, entitled “SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM,” which is a continuation-in-part of U.S. Patent Application No. 10/646,646 (Atty. Docket No. MSFT-2734), filed on August 21, 2003, entitled “STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA,”; and also claims priority of International Application No. PCT/US03/27419 (Atty Docket No.
  • MSFT- 1752 filed on August 21, 2003, entitled “SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM”; U.S. Patent Application No. 10/646,575 (Atty. Docket No. MSFT-2733), filed on August 21, 2003, entitled “SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM"; U.S. Patent Application No. 10/646,580 (Atty. Docket No.
  • MSFT- 2735 filed on August 21, 2003, entitled “SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM"; U.S. Patent Application No. 10/692,779 (Atty. Docket No. MSFT-2829), filed on October 24, 2003, entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A
  • MSFT-2846 filed on October 24, 2003, entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM”; and U.S. Patent Application No. 10/693,574 (Atty. Docket No. MSFT-2847), filed on October 24, 2003, entitled “SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM".
  • the present invention relates generally to synchronization and, more particularly, to synchronization between two or more computers utilizing a common storage platform (e.g., WinFS) but synchronizing through an different intermediary file system application programming interface (API) accessible file share or other storage device (e.g., a Win32 file share or other storage device that is API accessible) to support data-sharing, end-user roaming (including but not limited to roaming end-user profiles and their equivalents), and other synchronization purposes.
  • a common storage platform e.g., WinFS
  • API application programming interface
  • Multics used symbolic addresses within a hierarchy of files (thereby introducing the idea of a file path) where physical addresses ofthe files were not transparent to the user (applications and end-users).
  • This file system was entirely unconcerned with the file format of any individual file, and the relationships amongst and between files was deemed irrelevant at the operating system level (that is, other than the location ofthe file within the hierarchy). Since the advent of Multics, storable data has been organized into files, folders, and directories at the operating system level. These files generally include the file hierarchy itself (the "directory") embodied in a special file maintained by the file system. This directory, in turn, maintains a list of entries corresponding to all ofthe other files in the directory and the nodal location of such files in the hierarchy (herein referred to as the folders). Such has been the state ofthe art for approximately forty years.
  • Database technology is another area ofthe art in which similar challenges exits.
  • relational database model has been a great commercial success
  • truth independent software vendors ISV
  • ISV truth independent software vendors
  • most of an application's interaction with such a product is in the form of simple "gets” and "puts”.
  • the basic relational model does not provide a sufficient platform for storage of data on which higher-level applications can easily be developed because the basic relational model requires a level of indirection between the application and the storage system — where the semantic structure ofthe data might only be visible in the application in certain instances.
  • Patent Application No. 10/646,646 (Atty. Docket No. MSFT-2745), filed on October 24, 2003, entitled "SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM" and U.S. Patent Application No. (not yet assigned) (Atty. Docket No.
  • MSFT-2854 / 306955.01 filed on June 30, 2004, entitled "SYSTEMS AND METHODS FOR PROVIDING CONFLICT HANDLING FOR PEER-TO- PEER SYNCHRONIZATION OF UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM.
  • enterprises having synchronization networks comprising various individual computer systems will have mixture in that some individual computer systems will utilize the new storage platform while other individual computer systems will continue to utilize legacy storage platforms.
  • clients two computer systems utilizing the new storage platform (the "clients") to synchronize through a computer system utilizing a legacy storage platform (the “intermediary”).
  • legacy storage platform the “intermediary”
  • some clients may be enrolled in legacy roaming services using software such as Roaming User Profiles (RUP) or Folder Redirection with Client Side Caching (CSC). Since legacy roaming software for these legacy storage platforms does not support roaming data for the new storage platform, a new roaming service for the new storage platform is necessary.
  • Various embodiments ofthe present invention are directed to system and methods for client synchronization through an intermediary.
  • the storage platform comprises a data store implemented on a database engine.
  • the database engine comprises a relational database engine with object relational extensions.
  • the data store implements a data model that supports organization, searching, sharing, synchronization, and security of data. Specific types of data are described in schemas, and the platform provides a mechanism to extend the set of schemas to define new types of data (essentially subtypes ofthe basic types provides by the schemas).
  • a synchronization capability facilitates the sharing of data among users or systems.
  • File-system-like capabilities are provided that allow interoperability ofthe data store with existing file systems but without the limitation of such traditional file systems.
  • a change tracking mechanism provides the ability track changes to the data store.
  • the storage platform further comprises a set of application program interfaces that enable applications to access all ofthe foregoing capabilities ofthe storage platform and to access the data described in the schemas.
  • the data model implemented by the data store defines units of data storage in terms of items, elements, and relationships.
  • An item is a unit of data storable in a data store and can comprise one or more elements and relationships.
  • An element is an instance of a type comprising one or more fields (also referred to herein as a property).
  • a relationship is a link between two items. (As used herein, these and other specific terms may be capitalized in order to offset them from other terms used in close proximity; however, there is no intention whatsoever to distinguish between a capitalized term, e.g.
  • the computer system further comprises a plurality of Items where each Item constitutes a discrete storable unit of information that can be manipulated by a hardware/software interface system; a plurality of Item Folders that constitute an organizational structure for said Items; and a hardware/software interface system for manipulating a plurality of Items and wherein each Item belongs to at least one Item Folder and may belong to more than one Item Folder.
  • An Item or some ofthe Item's property values may be computed dynamically as opposed to being derived from a persistent store.
  • the hardware/software interface system does not require that the Item be stored, and certain operations are supported such as the ability to enumerate the current set of Items or the ability to retrieve an Item given its identifier (which is more fully described in the sections that describe the application programming interface, or API) ofthe storage platform — for example, an Item might be the current location of a cell phone or the temperature reading on a temperature sensor.
  • the hardware/software interface system may manipulate a plurality of Items, and may further comprise Items interconnected by a plurality of Relationships managed by the hardware/software interface system.
  • a hardware/software interface system for the computer system further comprises a core schema to define a set of core Items which said hardware/software interface system understands and can directly process in a predetermined and predictable way.
  • the computer system interconnects said Items with a plurality of Relationships and manages said Relationships at the hardware/software interface system level.
  • the API ofthe storage platform provides data classes for each item, item extension, and relationship defined in the set of storage platform schemas.
  • the application programming interface provides a set of framework classes that define a common set of behaviors for the data classes and that, together with the data classes, provide the basic programming model for the storage platform API.
  • the storage platform API provides a simplified query model that enables application programmers to form queries based on various properties ofthe items in the data store, in a manner that insulates the application programmer from the details ofthe query language ofthe underlying database engine.
  • the storage platform API also collects changes to an item made by an application program and then organizes them into the correct updates required by the database engine (or any kind of storage engine) on wliich the data store is implemented. This enables application programmers to make changes to an item in memory, while leaving the complexity of data store updates to the API. [0021] Through its common storage foundation and schematized data, the storage platform ofthe present invention enables more efficient application development for consumers, knowledge workers and enterprises.
  • Section III ofthe Detailed Description also includes a detailed description of various embodiments ofthe related inventions directed to systems and methods for handling conflicts in a peer-to-peer synchronization system including but not limited to the synchronization system of or storage platform ofthe related inventions.
  • various embodiments ofthe present invention are directed to systems and methods for the synchronization of two clients both utilizing a common storage platform (e.g., the new storage platform ofthe related inventions) to synchronize through an intermediary that is not using the same common storage platform (e.g., instead using a legacy storage platform that does not itself support synchronization for the new storage platform).
  • various embodiments ofthe present invention employ a methodology by which data is synchronized using the existing capabilities ofthe intermediary but where the data structure of the clients is preserved.
  • Various embodiments utilize an "adapter" to enable a client to interact with an intermediary where said adapter effectively compensates for the intermediaries inability to preserve the data structure elements inherent to the new storage platform ofthe client.
  • Various embodiments ofthe present invention are direct to either or both upload-syncing data from a client to a intermediary as well as download-syncing data from an intermediary to a client.
  • certain embodiments are further directed to compaction of data on the intermediary.
  • Fig. 1 is a block diagram representing a computer system in which aspects ofthe present invention may be incorporated
  • Fig. 2 is a block diagram illustrating a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component
  • Fig. 1 is a block diagram representing a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component
  • Fig. 2 is a block diagram illustrating a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component
  • FIG. 2A illustrates the traditional tree-based hierarchical structure for files grouped in folders in a directory in a file-based operating system
  • FIG. 3 is a block diagram illustrating a storage platform
  • Fig. 4 illustrates the structural relationship between Items, Item Folders, and Categories
  • Fig. 5 A is a block diagram illustrating the structure of an Item
  • Fig. 5B is a block diagram illustrating the complex property types ofthe Item of Fig. 5A
  • Fig. 5C is a block diagram illustrating the "Location" Item wherein its complex types are further described (explicitly listed);
  • Fig. 5A is a block diagram illustrating the "Location" Item wherein its complex types are further described (explicitly listed);
  • Fig. 5A is a block diagram illustrating the "Location" Item wherein its complex types are further described (explicitly listed);
  • Fig. 5A is a block diagram illustrating the "Location"
  • FIG. 6A illustrates an Item as a subtype ofthe Item found in the Base Schema
  • Fig. 6B is a block diagram illustrating the subtype Item of Fig. 6 A wherein its inherited types are explicitly listed (in addition to its immediate properties);
  • 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; [0039] Fig.
  • 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;
  • Fig. 11 is a diagram illustrating a reference type hierarchy ofthe data model of the storage platform;
  • Fig. 12 is a diagram illustrating how relationships are classified;
  • Fig. 13 is a diagram illustrating a notification mechanism; [0044] Fig.
  • FIG. 14 is a diagram illustrating an example in which two transactions are both inserting a new record into the same B-Tree; [0045] Fig. 15 illustrates a data change detection process; [0046] Fig. 16 illustrates an exemplary directory tree; [0047] Fig. 17 shows an example in which an existing folder of a directory-based file system is moved into the storage platform data store; [0048] Fig. 18 illustrates the concept of Containment Folders; [0049] Fig. 19 illustrates the basic architecture ofthe storage platform API; [0050] Fig. 20 schematically represents the various components ofthe storage platfo ⁇ n API stack; [0051] Fig.
  • FIG. 21 A is a pictorial representation of an exemplary Contacts Item schema
  • FIG. 2 IB is a pictorial representation ofthe Elements for the exemplary Contacts Item schema of Fig. 21 A
  • Fig. 22 illustrates the runtime framework ofthe storage platform API
  • Fig. 23 illustrates the execution of a "FindAll" operation
  • Fig. 24 illustrates the process by which storage platform API classes are generated from the storage platform Schema
  • Fig. 25 illustrates a schema on which a File API is based
  • Fig. 26 is a diagram illustrating an access mask format used for data security purposes
  • FIG. 27 depicts a new identically protected security region being carved out of an existing security region;
  • Fig. 28 is a diagram illustrating the concept of an Item search view;
  • Fig. 29 is a diagram illustrating an exemplary Item hierarchy;
  • Fig. 30A illustrates an interface Interfacel as a conduit tlirough which first and second code segments communicate;
  • Fig. 30B illustrates an interface as comprising interface objects II and 12 which enable first and second code segments of a system to communicate via medium M;
  • FIG. 31 A illustrates how the function provided by interface Interfacel may be subdivided to convert the commimications ofthe interface into multiple interfaces InterfacelA, Interface IB, Interface IC;
  • Fig. 3 IB illustrates how the function provided by interface II may be subdivided into multiple interfaces Ila, lib, lie;
  • Fig. 32A illustrates a scenario where a meaningless parameter precision can be ignored or replaced with an arbitrary parameter;
  • Fig. 32B illustrates a scenario where an interface is replaced by a substitute interface that is defined to ignore or add parameters to an interface; [0067] Fig.
  • FIG. 33 A illustrates a scenario where a 1st and 2nd Code Segments are merged into a module containing them both; [0068] Fig. 33B illustrates a scenario where part or all of an interface may be written inline into another interface to form a merged interface.
  • Fig. 34 A illustrates how one or more pieces of middleware might convert communications on the first interface to conform them to one or more different interfaces;
  • Fig. 34B illustrates how a code segment can be introduced with an interface to receive the communications from one interface but transmit the functionality to second and third interfaces;
  • Fig. 35 A illustrates how a just-in-time compiler (JIT) might convert communications from one code segment to another code segment; [0072] Fig.
  • JIT just-in-time compiler
  • 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 a system comprising the related inventions that presumes a simple adapter that is unaware of how state is calculated or its associated metadata is exchanged;
  • Figs. 38A-D illustrate how changes are tracked, enumerated, and synchronized using sequential change enumeration methodology to highlight exceptions and solutions to same;
  • Fig. 39A illustrates the conflict handling pipeline;
  • Fig. 39A illustrates the conflict handling pipeline;
  • Fig. 39A illustrates the conflict handling pipeline;
  • FIG. 39B is a flowchart illustrating the logical traversal ofthe pipeline illustrated in Fig. 39 A; and [0078] Fig. 40 is a block diagram illustrating an example where a conflict item is logged with a copy ofthe target item; [0079] Fig. 41 is a block diagram illustrating the scenario in which two clients must synchronize through an intermediary; [0080] Fig. 42 is a flow diagram illustrating the steps by which a client, via an STI Adapter, sends change data to an intermediary (a "send sync" operation); [0081] Fig.
  • Fig. 43 is a flow diagram illustrating the steps by which a client, via an STI Adapter, receives change data from an intermediary (a "receive sync” operation); and [0082]
  • Fig. 44 is a flow diagram illustrating the steps by which an STI Adapter (that is, an STI Adapter that is associated with a client that can both send sync and receive sync) performs a compacts operation for data in a community folder on an intermediary (a "compaction" operation).
  • an STI Adapter that is, an STI Adapter that is associated with a client that can both send sync and receive sync
  • FIG. 1 A. EXEMPLARY COMPUTING ENVIRONMENT
  • FIG. 1 A. EXEMPLARY COMPUTING ENVIRONMENT
  • program modules include routines, programs, objects, components, data structures and the like that perfonn particular tasks or implement particular abstract data types.
  • an exemplary general purpose computing system includes a conventional personal computer 20 or the like, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21.
  • the system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the system memory includes read only memory (ROM) 24 and random access memory (RAM) 25.
  • ROM 24 read only memory
  • RAM random access memory
  • the personal computer 20 may further include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media.
  • 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 tlirough 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).
  • a monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48.
  • personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
  • the exemplary system of Fig. 1 also includes a host adapter 55, Small Computer System Interface (SCSI) bus 56, and an external storage device 62 connected to the SCSI bus 56.
  • SCSI Small Computer System Interface
  • the personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49.
  • 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 ofthe 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 personal computer 20 When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet.
  • the modem 54 which may be internal or external, is connected to the system bus 23 via the serial port interface 46.
  • program modules depicted relative to the personal computer 20, or portions thereof may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. [0089] As illustrated in the block diagram of Fig.
  • a computer system 200 can be roughly divided into three component groups: the hardware component 202, the hardware/software interface system component 204, and the applications programs component 206 (also referred to as the "user component” or “software component” in certain contexts herein).
  • the hardware component 202 may comprise the central processing unit (CPU) 21, the memory (both ROM 24 and RAM 25), the basic input/output system (BIOS) 26, and various input/output (I/O) devices such as a keyboard 40, a mouse 42, a monitor 47, and/or a printer (not shown), among other things.
  • the hardware component 202 comprises the basic physical infrastructure for the computer system 200.
  • the applications programs component 206 comprises various software programs including but not limited to compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users).
  • the hardware/software interface system component 204 comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel.
  • An "operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware.
  • 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 ofthe 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
  • a hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should ran in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports.
  • the hardware/software interface system also sends messages to each application (and, in certain case, to the end-user) regarding the status of operations and any errors that may have occurred.
  • the hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations.
  • batch jobs e.g., printing
  • a hardware/software interface system On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.
  • a hardware/software interface system shell (simply referred to herein as a "shell”) is an interactive end-user interface to a hardware/software interface system.
  • a shell may also be referred to as a "command interpreter” or, in an operating system, as an “operating system shell”).
  • a shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users.
  • a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.
  • computer system is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution ofthe device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.
  • files are units of storable information that may include the hardware/software interface system as well as application programs, data sets, and so forth.
  • files are the basic discrete (storable and retrievable) units of information (e.g., data, programs, and so forth) that can be manipulated by the hardware/software interface system.
  • Groups of files are generally organized in "folders.”
  • a folder is a collection of files that can be retrieved, moved, and otherwise manipulated as single units of information.
  • 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 information 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.
  • each folder is a container for its subfolders and its files —that is, each folder owns its subfolders and files.
  • each folder is deleted by the hardware/software interface system, that folder's subfolders and files are also deleted (which, in the case of each subfolder, further includes its own subfolders and files recursively).
  • each file is generally owned by only one folder and, although a file can be copied and the copy located in a different folder, a copy of a file is itself a distinct and separate unit that has no direct connection to the original (e.g., changes to the original file are not mirrored in the copy file at the hardware/software interface system level).
  • files and folders are therefore characteristically "physical" in nature because folders are the treated like physical containers, and files are treated as discrete and separate physical elements inside these containers.
  • the present invention in combination with the related inventions incorporated by reference as discussed earlier herein, is directed to a storage platform for organizing, searching, and sharing data.
  • the storage platform ofthe present invention extends and broadens the data platform beyond the kinds of existing file systems and database systems discussed above, and is designed to be the store for all types of data, including a new form of data called Items.
  • An "Item” is an unit of storable information accessible to a hardware/software interface system that, unlike a simple file, is an object having a basic set of properties that are commonly supported across all objects exposed to an end-user by the hardware/software interface system shell. Items also have properties and relationships that are commonly supported across all Item types including features that allow new properties and relationships to be introduced (and discussed in great detail later herein).
  • An "operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. An operating system comprises, in most cases, a shell and a kernel.
  • a "hardware/software interface system” is software, or a combination of hardware and software, that serves as the interface between the underlying hardware components of a computer system and applications that execute on the computer system.
  • a hardware/software interface system typically comprises (and, in some embodiments, may solely consist of) an operating system.
  • a hardware/software interface system 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.
  • a storage platform 300 comprises a data store 302 implemented on a database engine 314.
  • the database engine comprises a relational database engine with object relational extensions.
  • the relational database engine 314 comprises the Microsoft SQL Server relational database engine.
  • the data store 302 implements a data model 304 that supports the organization, searching, sharing, synchronization, and security of data. Specific types of data are described in schemas, such as schemas 340, and the storage platform 300 provides tools 346 for deploying those schemas as well as for extending those schemas, as described more fully below.
  • a change tracking mechanism 306 implemented within the data store 302 provides the ability track changes to the data store.
  • the data store 302 also provides security capabilities 308 and a promotion/demotion capability 310, both of which are discussed more fully below.
  • the data store 302 also provides a set of application programming interfaces 312 to expose the capabilities ofthe data store 302 to other storage platform components and application programs (e.g., application programs 350a, 350b, and 350c) that utilize the storage platform.
  • the storage platform ofthe present invention still further comprises an application programming interfaces (API) 322, which enables application programs, such as application programs 350a, 350b, and 350c, to access all ofthe foregoing capabilities ofthe storage platform and to access the data described in the schemas.
  • API application programming interfaces
  • the storage platform API 322 may be used by application programs in combination with other APIs, such as the OLE DB API 324 and the Microsoft Windows Win32 API 326.
  • the storage platform 300 ofthe present invention may provide a variety of services 328 to application programs, including a synchronization service 330 that facilitates the sharing of data among users or systems.
  • the synchronization service 330 may enable interoperability with other data stores 340 having the same format as data store 302, as well as access to data stores 342 having other formats.
  • the storage platform 300 also provides file system capabilities that allow interoperability ofthe data store 302 with existing file systems, such as the Windows NTFS files system 318.
  • 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. [0105] In at least some embodiments, the storage platform is embodied in, or forms an integral part of, the hardware/software interface system of a computer system.
  • the storage platform ofthe present invention may be embodied in, or fonn 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
  • the storage platform 300 ofthe present invention may be referred to as "WinFS.” However, use of this name to refer to the storage platform is solely for convenience of description and is not intended to be limiting in any way.
  • the data store 302 ofthe storage platform 300 ofthe present invention implements a data model that supports the organization, searching, sharing, synchronization, and security of data that resides in the store.
  • an "Item” is the fundamental unit of storage information. The data model provides a mechanism for declaring Items and Item extensions and for establishing relationships between Items and for organizing Items in Item Folders and in Categories, as described more fully below.
  • Types are structures which provide a format which governs the form of an instance ofthe Type.
  • the format is expressed as an ordered set of Properties.
  • a Property is a name for a value or set of values of a given Type. For example 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 GUID.
  • the Properties of a Type may be defined using any ofthe primitive types or (with some restrictions noted below) any ofthe constructed types. For example a Location Type might be defined that had Properties Coordinate and Address where the Address Property is of Type USPostalAddress as described above. Properties may also be required or optional.
  • Relationships can be declared and represent a mapping between the sets of instances of two types. For example there may be a Relationship declared between the Person Type and the Location Type called LivesAt which defines which people live at which locations.
  • the Relationship has a name, two endpoints, namely a source endpoint and a target endpoint. Relationships may also have an ordered set of properties. Both the Source and Target endpoints have a Name and a Type.
  • 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.
  • 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 Intl6, 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 tree is not constrained to be of a uniform depth but cannot contain any cycles.
  • a given Type may have zero or many subtypes and zero or one super type.
  • a given instance may conform to at most one type together with that type's super types. To put it another way, for a given instance at any level in the tree the instance may conform to at most one subtype at that level.
  • a type is said to be Abstract if instances ofthe type must also be an instance of a subtype ofthe type. 1.
  • An Item is a unit of storable information that, unlike a simple file, is an object having a basic set of properties that are commonly supported across all objects exposed to an end-user or application program by the storage platform. Items also have properties and relationships that are commonly supported across all Item types including features that allow new properties and relationships to be introduced, as discussed below. [0113] Items are the objects for common operations such as copy, delete, move, open, print, backup, restore, replicate, and so forth. Items are the units that can be stored and retrieved, and all forms of storable information manipulated by the storage platform exist as Items, properties of Items, or Relationships between Items, each of which is discussed in greater detail herein below.
  • Fig. 5 A is a block diagram illustrating the structure of an Item.
  • the unqualified name ofthe Item is "Location”.
  • the qualified name ofthe 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, MetropolitanRegion, Neighborhood, and PostalAddresses.
  • EAddresses and PostalAddresses are properties of defined types or "complex types” (as denoted herein by capitalization) of types EAddress and PostalAddress respectively.
  • a complex type is type that is derived from one or more simple data types and/or from other complex types.
  • 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 PostalAddressTypes, and so on and so forth.
  • Fig. 5C is a block diagram illustrating the Location Item wherein its complex types are further described. However, it should be understood that this alternative representation ofthe Location Item in this Fig. 5C is for the exact same Item illustrated in Fig. 5 A.
  • the storage platfo ⁇ n ofthe present invention also allows subtyping whereby one property type can be a subtype of another (where the one property type inherits the properties of another, parent property type).
  • Items inherently represent their own Item Types that can also be the subject of subtyping.
  • the storage platform in several embodiments ofthe present invention allows an Item to be a subtype of another Item (whereby the one Item inherits the properties ofthe other, parent Item).
  • every Item is a subtype ofthe "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 ofthe Item Item type found in the Base Schema.
  • the arrow indicates that the Location Item (like all other Items) is a subtype ofthe Item Item type.
  • the Item Item type as the foundational Item from which all other Items are derived, has a number of important properties such as Itemld and various timestamps, and thereby defines the standard properties of all Items in an operating system. In the present figure, these properties ofthe Item Item type are inherited by Location and thereby become properties of Location. [0118] Another way to represent the properties in the Location Item inherited from the Item Item type is to draw Location with the individual properties of each property type from the parent Item listed therein.
  • Fig. 6B is a block diagram illustrating the Location Item wherein its inherited types described in addition to its immediate properties.
  • this Item is the same Item illustrated in Fig. 5 A, although in the present figure Location is illustrated with all of its properties, both immediate — shown in both this figure and Fig. 5A — and inherited — shown in this figure but not Fig. 5 A (whereas in Fig. 5A these properties are referenced by showing with an arrow that the Location Item is a subtype ofthe Item Item type).
  • Items are stand-alone objects; thus, if you delete an Item, all ofthe Items immediate and inherited properties are also deleted. Similarly, when retrieving an Item, what is received is the Item and all of its immediate and inherited properties (including the information pertaining to its complex property types).
  • Certain embodiments ofthe present invention may enable one to request a subset of properties when retrieving a specific Item; however, the default for many such embodiments is to provide the Item with all of its immediate and inherited properties when retrieved.
  • the properties of Items can also be extended by adding new properties to the existing properties of that Item's type. These "extensions" are thereafter bona fide properties ofthe Item and subtypes of that Item type may automatically include the extension properties.
  • the "boundary" ofthe Item is represented by its properties (including complex property types, extensions, and so forth). An Item's boundary also represents the limit of an operation perfo ⁇ ned on an Item such as copy, delete, move, create, and so on.
  • the boundary encompasses the following: • The Item Type ofthe Item and, if the Item is a subtype of another Item (as is the case in several embodiments ofthe present invention where all Items are derived from a single Item and Item Type in the Base Schema), any applicable subtype information (that is, information pertaining to the parent Item Type). If the original Item being copied is a subtype of another Item, the copy may also be a subtype of that same Item. • The Item's complex-type properties and extensions, if any.
  • the copy may also have the same complex types.
  • 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 ofthe storage platform API 322.
  • ItemlDReference is a subtype of ItemReference. It defines a Locator and an ItemlD field.
  • the Locator field names (i.e. identifies) an item domain. It is processed by a locator resolution method that can resolve the value ofthe Locator to an item domain.
  • the ItemlD field is of type ItemlD
  • ItemPathReference is a specialization of ItemReference that defines a Locator and a Path field.
  • the Locator field identifies an item domain. It is processed by a locator resolution method that can resolve the value ofthe Locator to an item domain.
  • the Path field contains a (relative) path in the storage platform namespace rooted at the item domain provided by the Locator.
  • an Item can belong to more than one Item Folder, such that when an Item is accessed in one Item Folder and revised, this revised Item can then be accessed directly from another Item folder.
  • access to an Item may occur from different Item Folders, what is actually being accessed is in fact the very same Item.
  • an Item Folder does not necessarily own all of its member Items, or may simply co-own Items in conjunction with other folders, such that the deletion of an Item Folder does not necessarily result in the deletion ofthe Item.
  • 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.
  • Item Folders 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.
  • Some Items e.g., Item 402, 404, 406, 408, 410, and 412 are also members of one or more Categories 432, 434, and 436, while other times, e.g., Items 414, 416, 418, and 420, may belong to no Categories (although this is largely unlikely in certain embodiments where the possession of any property automatically implies membership in a Category, and thus an Item would have to be completely featureless in order not to be a member of any category in such an embodiment).
  • both Categories and Item Folders have structures more akin to directed graphs as shown. In any event, the Items, Item Folders, and Categories are all Items (albeit of different Item Types).
  • 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 ofthe 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 defines a set of core Item types that, directly (by Item type) or indirectly (by Item subtype), characterize all Items into one or more Core Schema Item types which the Item-based hardware/software interface system understands and can directly process in a predetermined and predictable way.
  • the predefined Item types reflect the most common Items in the Item-based hardware/software interface system and thus a level of efficiency is gained by the Item-based hardware/software interface system understanding these predefined Item types that comprise 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 ofthe Core Schema.
  • the storage platform mandates the use ofthe 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 ofthe 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).
  • the specific property types supported by the Core Schema may include one or more ofthe following: • Certificates (derived from the foundational PropertyBase type in the Base Schema) • Principal Identity Keys (derived from the IdentityKey type in the Base Schema) • Postal Address (derived from the Property type in the Base Schema) • Rich Text (derived from the Property type in the Base Schema) • EAddress (derived from the Property type in the Base Schema) • Identity SecurityPackage (derived from the Relationship type in the Base Schema) • RoleOccupancy (derived from the Relationship type in the Base Schema) • BasicPresence (derived from the Relationship type in the Base Schema) These Items and Properties are further described by their respective properties set forth in Fig.
  • Relationships are binary relationships where one Item is designated as source and the other Item as target.
  • the source Item and the target Item are related by the relationship.
  • the source Item generally controls the life-time ofthe relationship. That is, when the source Item is deleted, the relationship between the Items is also deleted.
  • Relationships are classified into: Containment and Reference relationships. The containment relationships control the life-time ofthe target Items, while the reference relationships do not provide any life-time management semantics.
  • Fig. 12 illustrates the manner in which relationships are classified.
  • the Containment relationship types are further classified into Holding and Embedding relationships. When all holding relationships to an Item are removed, the Item is deleted.
  • a holding relationship controls the life-time ofthe 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 ofthe 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 [0144] The explicit relationship types are defined with the following elements: • A relationship name is specified in the Name attribute. • Relationship type, one ofthe following: Holding, Embedding, Reference. This is specified in the Type attribute. • Source and target endpoints. Each endpoint specifies a name and the type ofthe 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. [0145] The source Item is the owner ofthe relationship.
  • the storage platfonn API 322 provides mechanisms for exposing relationships associated with an Item.
  • ⁇ Relationship Name "Employment" BaseType- 'Reference” > ⁇ Source Name- ⁇ mployee” ItemType- 'Contact.Person” ⁇ ⁇ Target Name- 'Employer” ItemType- 'Contact.
  • the relationship can not be created if the person Item that is referenced by the source reference does not exist. Also, if the person Item is deleted, the relationship instances between the person and organization are deleted. However, if the Organization Item is deleted, the relationship is not deleted and it is dangling.
  • Holding relationships are used to model reference count based life-time management ofthe target Items.
  • An Item can be a source endpoint for zero or more relationships to Items.
  • An Item that is not an embedded Item can be a target of in one or more holding relationships.
  • 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 ofthe 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 ofthe endpoint Items specified in the relationship declaration will generally be enforced when an instance ofthe relationship is created. The types ofthe endpoint Items can not be changed after the relationship is established.
  • Holding relationships play a key role in forming the Item namespace.
  • the holding relationships form a directed acyclic graph (DAG).
  • DAG directed acyclic graph
  • the FolderMembers relationship enables the concept of a Folder as a generic collection of Items.
  • Embedding Relationships model the concept of exclusive control ofthe lifetime ofthe target Item. They enable the concept of compound Items.
  • the creation of an embedding relationship instance and the Item that it is targeting is an atomic operation.
  • An Item can be a source of zero or more embedding relationship.
  • an Item can be a target of one and only one embedding relationship.
  • An Item that is a target of an embedding relationship can not be a target of a holding relationship.
  • 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 ofthe endpoint Items specified in the relationship declaration will generally be enforced when an instance ofthe relationship is created.
  • the types ofthe endpoint Items can not be changed after the relationship is established.
  • Embedding relationships control the operational consistency ofthe 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.
  • the reference relationships do not guarantee the existence ofthe target, nor do they guarantee the type ofthe target as specified in the relationship declaration. This means that the reference relationships can be dangling. Also, the reference relationship can reference Items in other data stores. Reference relationships can be thought of as a concept similar to links in web pages.
  • Any reference type is allowed in the target endpoint.
  • the Items that participate in a reference relationship can be of any Item type.
  • Reference relationships are used to model most non-lifetime management relationships between Items. Since the existence ofthe target is not enforced, the reference relationship is convenient to model loosely-coupled relationships. The reference relationship can be used to target Items in other data stores including stores on other computers.
  • e) Rules and Constraints [0168] The following additional rules and constraints apply for relationships: • An Item must be a target of (exactly one embedding relationship) or (one or more holding relationships). One exception is the root Item. An Item can be a target of zero or more reference relationships • An Item that is a target of embedding relationship can not be source of holding relationships.
  • the storage platfonn ofthe present invention supports ordering of relationships.
  • the ordering is achieved through a property named "Order" in the base relationship definition. There is no uniqueness constraint on the Order field. The order ofthe relationships with the same "order” property value is not guaranteed, however it is guaranteed that they may be ordered after relationships with lower "order” value and before relationships with higher “order” field value.
  • Applications can get the relationships in the default order by ordering on the combination ( SourceltemlD, RelationshipID, Order). All relationship instances sourced from a given Item are ordered as a single collection regardless ofthe type ofthe relationships in the collection. This however guarantees that all relationships of a given type (e.g., FolderMembers) are an ordered subset ofthe relationship collection for a given Item.
  • the data store API 312 for manipulating relationships implement a set of operations that support ordering of relationships.
  • the value ofthe "Order” property ofthe new relationship may be smaller then OrdFirst.
  • InsertAfterLast( SourceltemlD, Relationship) inserts the relationship as the last relationship in the collection. The value ofthe "Order” property ofthe new relationship may be greater then OrdLast.
  • InsertAt( SourceltemlD, ord, Relationship) inserts a relationship with the specified value for the "Order” property.
  • InsertBef or e( ourceltemlD, ord, Relationship) inserts the relationship before the relationship with the given order value.
  • the new relationship may be assigned "Order" value that is between OrdPrev and ord, noninclusive.
  • a Relationship provides a directed binary relationship that is "extended" by one Item (the source) to another Item (the target).
  • a Relationship is owned by the source Item (the Item that extended it), and thus the Relationship is removed if the source is removed (e.g., the Relationship is deleted when the source Item is deleted).
  • a Relationship may share ownership of (co-own) the target Item, and such ownership might be reflected in the IsOwned property (or its equivalent) ofthe Relationship (as shown in Fig. 7 for the Relationship property type).
  • creation of a new IsOwned Relationship automatically increments a reference count on the target Item, and deletion of such a Relationship may decrement the reference count on the target Item.
  • Items continue to exist if they have a reference count greater than zero, and are automatically deleted if and when the count reaches zero.
  • 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 ofthe 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.
  • Logical Relationships are the meanings assigned to a set of Relationships, regardless of physical implementation, which are specifically employed to achieve the functionality described herein.
  • Logical Relationships are established between the Item and its Item Folder(s) or Categories (and vice versa) because, in essence, Item Folders and Categories are each a special type of Item. Consequently, Item Folders and Categories can be acted upon the same way as any other Item — copied, added to an email message, embedded in a document, and so and so forth without limitation — and Item Folders and Categories can be serialized and de-serialized (imported and exported) using the same mechanisms as for other Items.
  • 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.
  • a Relationship that logically extends from an Item Folder to an Item denotes that the Item is public and sharable to that Item Folder
  • the lack of a logical Relationship from the Item Folder to the Item denotes that the Item is private and non-sharable.
  • 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.
  • Categories are described by a commonality that is common to all of its member Items. Consequently the membership of a Category is inherently limited to Items having the described commonality and, in certain embodiments, all Items meeting the description of a Category are automatically made members ofthe Category. Thus, whereas Item Folders allow trivial type structures to be represented by their membership, Categories allow membership based on the defined commonality. [0179] Of course Category descriptions are logical in nature, and therefore a Category may be described by any logical representation of types, properties, and/or values.
  • 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 Catego _r*y 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
  • the storage platform is intended to be provided with an initial set of schemas 340, as described above.
  • the storage platform allows customers, including independent software vendor (ISVs), to create new schemas 344 (i.e. new Item and Nested Element types).
  • ISVs independent software vendor
  • This section addresses the mechanism for creating such schemas by extending the Item types and Nested Element types (or simply "Element" types) defined in the initial set of schemas 340.
  • extension ofthe initial set of Item and Nested Element types is constrained as follows: • an ISV is allowed to introduce new Item types, i.e.
  • 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. [0185] Since an Item type or Nested Element type defined by the initial set of storage platform schemas may not exactly match an ISV application's need, it is necessary to allow ISVs to customize the type. This is allowed with the notion of Extensions.
  • Extensions are strongly typed instances but (a) they cannot exist independently and (b) they must be attached to an Item or Nested Element. [0186] In addition to addressing the need for schema extensibility, 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). a) Item extensions [0187] To provide Item extensibility, the data model further defines an abstract type named Base.Extension. This is a root type for the hierarchy of extension types. Applications can subtype Base.Extension to create specific extension types. [0188] The Base.Extension type is defined in the Base schema as follows:
  • the ItemlD field contains the ItemlD ofthe 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 types have fields; • Fields can be of primitive or nested element types; and • Extension types can be sub-typed.
  • Extensions can not be sources and targets of relationships; • Extension type instances can not exist independently from an item; and • Extension types can not be used as field types in the storage platform type definitions
  • extension types There are no constraints on the types of extensions that can be associated with a given Item type. Any extension type is allowed to extend any item type. When multiple extension instances are attached to an item, they are independent from each other in both structure and behavior. [0193] The extension instances are stored and accessed separately from the item. All extension type instances are accessible from a global extension view. An efficient query can be composed that will return all the instances of a given type of extension regardless of what type of item they are associated with. The storage platform APIs provides a programming model that can store, retrieve and modify extensions on items. [0194] The extension types can be type sub-typed using the storage platfonn single inheritance model. Deriving from an extension type creates a new extension type.
  • Extension type instances can be directly accessed through the view associated with the extension type.
  • the ItemlD ofthe extension indicates which item they belong to and can be used to retrieve the conesponding Item object from the global Item view.
  • the extensions are considered part ofthe 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 ofthe item. [0195]
  • a Contact type is defined in the Windows Type set.
  • CRMExtension and HRExtension are two independent extensions that can be attached to Contact items. They are created and accessed independently of each other. [0199] In the above example, the fields and methods ofthe CRMExtension type cannot override fields or methods ofthe Contact hierarchy. It should be noted that instances ofthe 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. Nested holding, embedded extensions. The elements are part of and soft extension semantics the item Relationships is similar to embedded item semantics
  • 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. [0204]
  • the NestedElement type inherits from this type.
  • the 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 ofthe 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 (ofthe item) are stored. Like other nested sets, the NestedElement extensions are stored in a UDT. They are accessible through the Extensions field ofthe nested element type. • The collection interfaces used to access multi-valued properties is also used for accessing and iterating over set of type extensions. [0207] The following table summarizes and compares Item Extensions and NestedElement extensions.
  • Item extensions vs NestedElement extensions Item Extension NestedElement Extension Storage Item extension hierarchy is Stored like nested elements stored in its own tables Query/Search Can query item extension Can generally only be tables queried within the containing item context Query/Search Can search across all Can generally only search scope instances of an item within nested element type extension type instances of a singe (containing) item Programmability Need special extension NestedElement extensions APIs and special querying are like any other multion extension tables valued field of nested element; normal nested element type APIs are used Behavior Can associate behavior No behavior permitted (?) Relationship No Relationships to item No Relationships to semantics extensions NestedElement extensions Item ID Shares the item id ofthe Does not have its own item item id.
  • the data store is implemented on a database engine.
  • the database engine comprises a relational database engine that implements the SQL query language, such as the Microsoft SQL Server engine, with object relational extensions.
  • This section describes the mapping ofthe data model that the data store implements to the relational store and provides information on the logical API consumed by storage platfo ⁇ n clients, in accordance with the present embodiment. It is understood, however, that a different mapping may be employed when a different database engine is employed. Indeed, in addition to implementing the storage platfonn conceptual data model on a relational database engine, it can also be implemented on other types of databases, e.g.
  • 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 ofthe 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 ofthe 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 [0215]
  • the mapping of storage platform schemas to UDT classes is fairly straightforward at a high level. Generally, a storage platfonn Schema is mapped to a CLR namespace. A storage platform Type is mapped to a CLR class. The CLR class inheritance mirrors the storage platfonn 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 ofthe 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. [0217] 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 UpdateO method ofthe storage platfonn API, through which all data changes are made. Unlike the type family tables, this global Item table contains only the top-level scalar properties ofthe 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.
  • the ItemlD will generally uniquely identify the Item within the data store.
  • the TypelD may be mapped using metadata, which is not described here, to a type name and the view containing the Item. Since finding an Item by its ItemlD may be a common operation, both in the context ofthe global Item table and otherwise, a Getltem() function is provided to retrieve an Item object given an Item's ItemlD. [0219] For convenient access and to hide implementation details to the extent possible, all queries of Items might be against views built on the Item tables described above. Specifically, views may be created for each Item type against the appropriate type family table. These type views may select all Items ofthe associated type, including sub-types.
  • Extensions are very similar to Items and have some ofthe same requirements. As another root type supporting inheritance, Extensions are subject to many ofthe 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 ofthe Item.
  • a function might be provided to retrieve an Extension given its identity, which consists of an ItemlD and ExtensionID pair.
  • Nested Elements are types that can be embedded in Items, Extensions, Relationships, or other Nested Elements to form deeply nested structures. Like Items and Extensions, Nested Elements are implemented as UDT's, but they are stored within an Items and Extensions. Therefore, Nested Elements have no storage mapping beyond that of their Item and Extension containers. In other words, there are no tables in the system which directly store instances of NestedElement types, and there are no views dedicated specifically to Nested Elements. 5. Object Identity [0222] Each entity in the data model, i.e., each Item, Extension and Relationship, has a unique key value.
  • 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 platfonn 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 ofthe 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 Update() method ofthe 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.
  • Each Item search view contains a row for each instance of an Item ofthe specific type or its subtypes. For example, the view for Document could return instances of Document, LegalDocument and ReviewDocument. Given this example, 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 ofthe 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 Item type also has a search view. While similar to the root Item view, this view also provides access to the Item object via the "_Item" column.
  • Each typed item search view is identified in a data store using the name ⁇ schemaName . itemTypeName For example [AcmeCorp.Doc] . [OfficeDoc]. 9. a) Item Extensions [0232] All Item Extensions in a WinFS Store are also accessible using search views.
  • (1) Master Extension Search View [0233] Each instance of a data store defines a special Extension view called the Master Extension View. This view provides summary information on each Extension in the data store.
  • the view has a column per Extension property, a column which describes the type ofthe Extension and several columns which are used to provide change tracking and synclironization information.
  • the master extension view is identified in a data store using the name " [System. Storage] . [Master ! Extension] ".
  • 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].[ ⁇ xtensionlextensionTypeName]. For example [AcmeCorp.Doc]. [Extension ⁇ OfficeDocExt].
  • 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 ofthe relationship data.
  • Each relationship instance search view is identified in a data store using the name [schemaName] . [Relationshi ! relationshipName] . For example [AcmeCorp.Doc] . [Relationship !DocumentAuthor] .
  • Updates All views in the storage platfo ⁇ n data store are read-only. In order to create a new instance of a data model element (item, extension or relationship), or to update an existing instance, the ProcessOperation or ProcessUpdategram methods ofthe storage platform API must be used.
  • the ProcessOperation method is a single stored procedure defined by the data store which consumes an "operation” that details an action to be performed.
  • the ProcessUpdategram method is a stored procedure which takes an ordered set of operations, known as an "updategram", which collectively detail a set of actions to be performed..
  • the operation format is extensible and provides various operations over the schema elements. Some common operations include: 1. Item operations: a.
  • Createltem (Creates a new item in the context of an embedding or holding relationship) b. Updateltem (updates an existing Item) 2.
  • 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 conesponding 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 [0247] Item tombstones are retrieved from the system via the view [System.Storage]. [Tombstone ⁇ tem].
  • Extension Tombstones are retrieved from the system using the view [System.Storage]. [Tomb stone! Extension]. Extension change tracking information is similar to that provided for Items with the addition ofthe Extensionld property.
  • Relationships Tombstone [0249] Relationship tombstones are retrieved from the system via the view [System.Storage]. [TombstonelRelationship]. Relationships tombstone information is similar to that provided for Extensions. However, additional information is provided on the target ItemRef ofthe relationship instance. In addition, the relationship object is also selected.
  • 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. 13.
  • Helper APIs and Functions [0251] 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 ofthe Item and use this value to query the Meta.Type view to return information on the declared type ofthe Item. For example,
  • 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. [0259] According to one embodiment, the storage platfonn 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 ofthe present invention is, in at least some embodiments, intended to be embodied as an integral part ofthe hardware/software interface system of a computer system.
  • the storage platform ofthe 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 ofthe 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 ofthe 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 ofthe 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 ofthe storage platform as well as the traditional NTFS file system.
  • the storage platform uses a naming convention that is a superset ofthe Win32 naming conventions to facilitate easy interoperability.
  • the storage platfo ⁇ n supports accessing files and directories stored in a storage platform volume tlirough the Win32 API.
  • H. STORAGE PLATFORM API [0264]
  • the storage platform comprises an API that enables application programs to access the features and capabilities ofthe storage platform discussed above and to access items stored in the data store. This section describes one embodiment of a storage platform API ofthe storage platform ofthe present invention. Details regarding this functionality can be found in the related applications inco ⁇ orated by reference earlier herein, with some of this information summarized below for convenience. [0265] Referring to Fig.
  • a Containment Folder is an item which contains holding Relationships to other Items and is the equivalent ofthe common concept of a file system folder. Each Item is "contained" within at least one containment folder.
  • Fig. 19 illustrates the basic architecture ofthe storage platform API, in accordance with the present embodiment.
  • 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.
  • DQP Distributed Query Processor
  • Sync storage platform synchronization service
  • 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, hi one embodiment, the storage platform API 322 may also define a limited "provider" architecture so that it can access data in Microsoft Exchange and AD.
  • Fig. 20 schematically represents the various components ofthe storage platfo ⁇ n API.
  • the storage platform API consists ofthe following components: (1) data classes 2002, which represent the storage platform element and item types, (2) runtime framework 2004, which manages object persistence and provides support classes 2006; and (3) tools 2008, which are used to generate CLR classes from the storage platform schemas.
  • Fig. 22 illustrates the runtime framework in operation.
  • the runtime framework operates as follows: 1. An application 350a, 350b, or 350c binds to an item in the storage platform. 2.
  • the framework 2004 creates an ItemContext object 2202 conesponding to the bound item and returns it to the application. 3.
  • the application submits a Find on this ItemContext to get a collection of Items; the returned collection is conceptually an object graph 2204 (due to relationships). 4.
  • the application changes, deletes, and inserts data. 5.
  • Fig. 23 illustrates the execution of a "FindAll" operation.
  • Fig. 24 illustrates the process by which storage platform API classes are generated from the storage platform Schema
  • Fig. 25 illustrates the schema on which the File API is based.
  • the storage platfo ⁇ n API includes a namespace for dealing with file objects. This namespace is called System.Storage.Files.
  • the data members ofthe classes in System.Storage.Files directly reflect the information stored in the storage platform store; this information is "promoted" from the file system objects or may be created natively using the Win32 API.
  • the System.Storage.Files namespace has two classes: Fileltem and Directoryltem.
  • a programming interface (or more simply, 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.
  • segment of code in the preceding sentence is intended to include one or more instructions or lines of code, and includes, e.g., code modules, objects, subroutines, functions, and so on, regardless ofthe terminology applied or whether the code segments are separately compiled, or whether the code segments are provided as source, intermediate, or object code, whether the code segments are utilized in a runtime system or process, or whether they are located on the same or different machines or distributed across multiple machines, or whether the functionality represented by the segments of code are implemented wholly in software, wholly in hardware, or a combination of hardware and software.
  • a programming interface may be viewed generically, as shown in Fig. 30A or Fig. 30B.
  • Fig. 30A illustrates an interface Interfacel as a conduit through which first and second code segments communicate.
  • Fig. 3 OB illustrates an interface as comprising interface objects II and 12 (which may or may not be part ofthe first and second code segments), which enable first and second code segments of a system to communicate via medium M.
  • interface objects II and 12 are separate interfaces ofthe same system and one may also consider that objects II and 12 plus medium M comprise the interface.
  • 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 ofthe information.
  • the underlying transport medium itself may be unimportant to the operation ofthe interface, whether the medium be wired or wireless, or a combination of both, as long as the information is transported in the manner defined by the interface.
  • information may not be passed in one or both directions in the conventional sense, as the information transfer may be either via another mechanism (e.g. information placed in a buffer, file, etc. separate from information flow between the code segments) or non-existent, as when one code segment simply accesses functionality performed by a second code segment. Any or all of these aspects may be important in a given situation, e.g., depending on whether the code segments are part of a system in a loosely coupled or tightly coupled configuration, and so this list should be considered illustrative and non- limiting.
  • Figs. 30A and 30B may be factored to achieve the same result, just as one may mathematically provide 24, or 2 times 2 time 3 times 2.
  • the function provided by interface Interfacel may be subdivided to convert the communications ofthe interface into multiple interfaces InterfacelA, Interface IB, Interface IC, etc. while achieving the same result.
  • the function provided by interface II may be subdivided into multiple interfaces Ila, lib, lie, etc. while achieving the same result.
  • interface 12 ofthe second code segment which receives information from the first code segment may be factored into multiple interfaces I2a, I2b, I2c, etc.
  • the number of interfaces included with the 1st code segment need not match the number of interfaces included with the 2nd code segment.
  • the functional spirit of interfaces Interfacel and II remain the same as with Figs. 30A and 30B, respectively.
  • the factoring of interfaces may also follow associative, commutative, and other mathematical properties such that the factoring may be difficult to recognize.
  • 30A includes a function call Squarerinput, 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 ofthe computing system; however, once it is recognized that precision is not necessary for the nanow pu ⁇ ose of calculating the square, it may be replaced or ignored.
  • a meaningless value such as a birth date could be passed without adversely affecting the result.
  • interface II is replaced by interface II', redefined to ignore or add parameters to the interface.
  • Interface 12 may similarly be redefined as interface 12', redefined to ignore unnecessary parameters, or parameters that may be processed elsewhere.
  • a programming interface may include aspects, such as parameters, that are not needed for some pu ⁇ ose, and so they may be ignored or redefined, or processed elsewhere for other purposes.
  • Inline Coding It may also be feasible to merge some or all ofthe functionality of two separate code modules such that the "interface" between them changes form. For example, the functionality of Figs.
  • 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".
  • interface 12 is divided into I2a and I2b, and interface portion I2a has been coded in-line with interface II to fo ⁇ n interface II".
  • interface II from Fig. 30B performs a function call square (input, output), which is received by interface 12, which after processing the value passed with input (to square it) by the second code segment, passes back the squared result with output.
  • the processing performed by the second code segment can be performed by the first code segment without a call to the interface.
  • Divorce A communication from one code segment to another may be accomplished indirectly by breaking the communication into multiple discrete communications. This is depicted schematically in Figs. 34A and 34B.
  • 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. 35A and 35B.
  • Fig. 35 A 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 ofthe operating system.
  • the storage platform provides a synchronization service 330 that (i) allows multiple instances ofthe storage platform (each with its own data store 302) to synchronize parts of their content according to a flexible set of rales, and (ii) provides an infrastructure for third parties to synchronize the data store ofthe storage platform ofthe 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.
  • the synchronization capability ofthe 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; detennine 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 [0288] The primary application ofthe synchronization service 330 ofthe storage platfo ⁇ n ofthe present invention is to synchronize multiple instances ofthe storage platfo ⁇ n (each with its own data store).
  • the synchronization service operates at the level ofthe storage platform schemas (rather than the underlying tables ofthe database engine 314). Thus, for example, "Scopes" are used to define synchronization sets as discussed below. [0289]
  • 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.
  • 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 ofthe parameters needed to perform synchronization (see sync profile below). Such applications are refened 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 ofthe machines having an instance ofthe storage platform that is to participate in the synchronization (as described below).
  • a fundamental concept ofthe 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 pvuposes. 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 ofthe 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.
  • 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 ofthe 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.
  • 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 rales 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.
  • 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.
  • This element requests that newly generated local IDs be assigned to all ofthe items mapped from the community folder, rather than reusing community IDs.
  • the Sync Runtime will maintain ID mappings to convert items back and forth.
  • This element requests that all root items in the community folder be made children ofthe specified root.
  • 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 info ⁇ nation 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 [0312] 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 detennines 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 (or "conflict handlers”) 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 ofthe context ofthe sync session — at this time, logged conflicts can be resolved and removed from the log.
  • Vartious embodiments ofthe present invention direct to conflict handling are discussed in much greater detail herein below at Section III. 2. Synchronizing to Non-Storage Platform Data Stores [0314] According to another aspect ofthe storage platform ofthe present invention — and closely related to the various embodiments ofthe present invention described in Section IV herein below — 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 Adapters benefit from the many Sync Service provided by the synchronization service, as described below. [0315] Despite the name, Sync Adapters do not need to be implemented as plug-ins into some storage platform architecture.
  • a "sync adapter" can simply be any application that utilizes the synchronization service runtime interfaces to obtain services such as change enumeration and application.
  • Sync Adapter writers are encouraged to expose the standard Sync Adapter interface, which runs sync given the Sync Profile as described above.
  • the profile provides configuration infonnation to the adapter, some of which adapters pass to the Sync Runtime to control runtime services (e.g. the Folder to synchronize).
  • a) Sync Services [0317] The synchronization service provides a number of sync services to adapter writers.
  • Sync adapters utilizing change enumeration services fall into two broad categories: those using "stored anchors” vs. those using “supplied anchors”.
  • the distinction is based on where the information about the last sync is stored — on the client, or on the server. It is often easier for adapters to store this information on the client — the backend is often not capable of conveniently storing this information.
  • the backend is often not capable of conveniently storing this information.
  • storing this info ⁇ nation on the client is inefficient and in some cases inconect — it makes one client unaware ofthe changes that the other client has already pushed up to the server.
  • an adapter wants to use a server-stored anchor, the adapter needs to supply it back to the storage platform at the time of change enumeration.
  • the storage platform In order for the storage platform to maintain the anchor (either for local or remote storage), the storage platform needs to be made aware ofthe changes that were successfully applied at the server. These and only these changes can be included in the anchor.
  • Sync Adapters use an Acknowledgement interface to report which changes were successfully applied.
  • adapters using supplied anchors must read the new anchor (which inco ⁇ orates all ofthe 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
  • 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.
  • Fig. 24 illustrates the process by which storage platform API classes are generated from the storage platform Schema.
  • the primary function of change application is to automatically detect conflicts.
  • a conflict is defined as two overlapping changes being made without knowledge of each other.
  • Change Application When adapters use Change Application, they must specify the anchor with respect to which conflict detection is performed. Change Application raises a conflict if an overlapping local change that is not covered by the adapter's knowledge is detected. Similar to Change Enumeration, adapters may use either stored or supplied anchors. Change Application supports efficient storage of adapter-specific metadata. Such data may be attached by the adapter to the changes being applied, and might be stored by the synchronization service. The data might be returned on next change enumeration. (3) Conflict Resolution [0325] The Conflict Resolution mechanisms described below (which include logging and automatic resolution options) 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. In addition, 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. b) Adapter Implementation [0326] While some "adapters" are simply applications utilizing runtime interfaces, adapters are encouraged to implement the standard adapter interfaces.
  • the synchronization service strives to introduce as little as possible into the security model implemented by the storage platform. Rather than defining new rights for synchronization, existing rights are used. Specifically, • anyone who can read a data store Item can enumerate changes to that item; • anyone who can write to a data store Item can apply changes to that item; and anyone who can extend a data store Item can associate sync metadata with that item. [0328] The synchronization service does not maintain secure authorship information.
  • the synchronization service may use a "sweep" algorithm to collect and distribute information about the status ofthe replicas.
  • the properties ofthe sweep algorithm ensure that information about all configured replicas is eventually collected and that failing (non-responsive) replicas are detected.
  • This community-wide monitoring information is made available at every replica. Monitoring tools can be run at an arbitrarily-chosen replica to examine this monitoring information and make administrative decisions. Any configuration changes must be made directly at the affected replicas.
  • Sync Replica Most applications are only interested in tracking, enumerating and synchronizing changes for a given subset of items within the WinFS store. The set of items that take part in a synchronization operation is termed as a Synchronization Replica.
  • a Replica is defined in terms of items contained within a given WinFS containment hierarchy (usually rooted at a Folder item). All synchronization services are carried out within the context of a given replica.
  • WinFS Sync provides a mechanism to define, manage and cleanup replicas.
  • Every replica has a GUID identifier that uniquely identifies it within a given WinFS store.
  • Sync Partner A sync partner is defined as an entity capable of affecting changes on WinFS items, extensions and relationships. Thus, every WinFS store can be termed as a sync partner. When synchronizing with a non-WinFS store, the external data source (EDS) is also termed as a sync partner. Every partner has a GUID identifier that uniquely identifies it.
  • Sync Community A synchronization community is defined as a collection of replicas that are kept in sync by means of peer-to-peer synchronization operations.
  • WinFS sync does not prescribe or mandate any specific topology for the community, especially if the only sync operations in the community are through the WinFS Sync service (WinFS adapter). Synchronization adapters (defined below) may introduce their own topology restrictions.
  • Sync Knowledge represents the state of a given sync replica at any time, i.e. it encapsulates meta-data about all the changes a given replica is aware of, either local or from other replicas. WinFS sync maintains and updates knowledge for sync replicas across sync operations. Important thing to note is that the Knowledge representation allows it to be inte ⁇ reted with respect to the entire community and not just relative to the particular replica where the Knowledge is stored.
  • a synchronization adapter is a managed code application that accesses WinFS Sync services through the Sync Runtime API and enables synchronization of WinFS data to a non-WinFS data store. Depending on the requirements ofthe scenario, it's upto the adapter developer as to which subset of WinFS data and what WinFS data types to synchronize.
  • the adapter is responsible for communication with the EDS, transforming WinFS schemas to and from EDS supported schemas and defining and managing its own configuration and metadata. Adapters are strongly encouraged to implement the WinFS Sync Adapter API to take advantage ofthe common configuration and control infrastructure for adapters provided by the WinFS Sync team.
  • SADP WinFS Sync Adapter API spec
  • SCTRL WinFS Sync Controller API
  • WinFS Sync provides services to obtain remote knowledge that can be used for subsequent change enumeration or application operations.
  • the adapter may wish to store this remote knowledge on the backend or on the local WinFS store.
  • a synchronization "replica” is a structure that represents a set of data in a "WinFS" store that exists in a single logical location, whereas data on a non-"WinFS” store is called a “data source” and generally requires the use of a adapter.
  • Remote Knowledge When a given sync replica wishes to obtain changes from another replica it provides it's own knowledge as a baseline against which the other replica enumerates changes. Similarly, when a given replica wishes to send changes to another replica, it provides it's own knowledge as a baseline which can be used by the remote replica for detecting conflicts. This knowledge about the other replica that's provided during sync change enumeration and application is termed a Remote Knowledge. 2.
  • the synchronization API separates into two parts: the synchronization configuration API and the synchronization controller API.
  • the synchronization Configuration API enables applications to configure synchronization and to specify parameters for a particular synchronization session between two replicas.
  • configuration parameters include the set of Items to be synchronized, the type of synchronization (one-way or two-way), information about the remote data source, and the conflict resolution policy.
  • the synchronization controller API initiates a synchronization session, cancels synchronization, and receives progress and enor information about the on-going synchronization.
  • Such systems may include scheduling mechanism to customize scheduling.
  • synchronization adapters for synchronizing infonnation between "WjuiFS" and non-"WinFS" data sources.
  • Examples of adapters include an adapter that synchronizes address book information between a "WinFS” contacts folder and a non-WinFS mailbox.
  • adapter developers might use the "WinFS" synchronization core services API described herein for accessing services provided by the "WinFS” synchronization platform in order to develop schema transformation code between the "WinFS" schema and the non-"WinFS” data source schema.
  • the adapter developer provides protocol support for communicating changes with the non-" WinFS" data source.
  • a synchronization adapter is invoked and controlled by using the synchronization controller API and reports progress and enors using this API.
  • a synchronization adapter may be unnecessary if "WinFS” to "WinFS” synchronization services are integrated within the hardware/software interface system.
  • several such embodiments provides a set of synchronization services for both "WinFS” to "WinFS” and synchronization adapter solutions that include: • Tracking of changes to "WinFS" items, extensions and relationships.
  • FIG. 36 which illustrates a three instances of a common data store and the components for synchronizing them.
  • a first system 3602 has a WinFS data store 3612 comprising a WinFS-to-WinFS Sync services 3622 and Core Sync Services 3624, for WinFS-to- nonWinFS synchronization, which exposes 3646 a Sync API 3652 for utilization.
  • a second system 3604 has a WinFS data store 3614 comprising a WinFS-to- WinFS Sync services 3632 and Core Sync Services 3634, for WinFS-to-nonWinFS synchronization, which exposes 3646 a Sync API 3652 for utilization.
  • the first system 3602 and the second system 3604 synclironize 3642 via their respective WinFS-to-WinFS Sync services 3622 and 3632.
  • a third system 3606, which is not a WinFS system, has an application for using WinFS Sync 3666 to maintain a data source in a sync community with WinFS replicas.
  • This application can utilize either a WinFS Sync Config/Control service 3664 to directly interface 3644with the WinFS data store 3612 via the WinFS to WinFS synch services 3622 (if it is so capable of virtualizing itself as a WinFS data store) or via a Sync Adapter 3662 that interfaces 3648 with the Sync API 3652.
  • the first system 3602 is aware of and directly synchronizes with both the second system 3604 and third system 3606.
  • neither the second system 3604 nor the third system 3606 are aware of each other and, thus, do not synchronize their changes directly with each other but, instead, changes that occur on one system must propogate through the first system 3602.
  • 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 based on the change-tracking data maintained by the synchronization service.
  • change enumeration several embodiments ofthe present invention are directed to: • the efficient enumeration of changes to Items, Extensions and Relationships in a given replica, relative to a specified Knowledge instance.
  • change application allows Sync Adapters to apply changes received from their backend to the local storage platform since the adapters are expected to transfonn the changes to the storage platfonn schema.
  • several embodiments ofthe present invention are directed to: • the application of incremental changes from other replicas (or non-WinFS stores) with conesponding updates to WinFS change metadata. • the detection of conflicts on change application at change unit granularity. • the reporting of success, failure and conflicts at individual change unit level on change application, so that applications (including adapters and sync controlling apps) can use that information for progress, enor and status reporting and for updating their backend state, if any.
  • ItemContext ctx new ItemContext ( " ⁇ . ⁇ System ⁇ UserData ⁇ dshah ⁇ My Contacts", true );
  • Guid replicaltemld FOO_GetReplicaId()
  • Guid remotePartnerld FOO_Get_RemotePartnerId()
  • remoteKnowledge ctx.ReplicaSynchronizer.GetUpdatedRemoteKnowledge(); reader.CloseQ;
  • ctx.ReplicaSynchronizer.ConflictPolicy conflictPolicy
  • ctx.ReplicaSynchronizer.RemotePartnerld remotePartnerld
  • ctx.ReplicaSynchronizer.RemoteKnowledge remoteKnowledge
  • Adapter // Obtain changes from remote store. Adapter is responsible for retrieving // it's backend specific metadata from the store. This can be an extension // on the replica.
  • remoteAnchor FOO_GetRemoteAnchorFromStore();
  • FOO_RemoteChangeCollection remoteChanges FOO_GetRemoteChanges( remoteAnchor );
  • the adapter API provides: • A standard mechanism to register adapters with the hardware/software interface system synchronization framework. • A standard mechanism for adapters to declare their capabilities and the type of configuration information needed to initialize the adapter. • A standard mechanism for passing initialization information to the adapter. • A mechanism for adapters to report progress status back to the applications invoking synchronization. • A mechanism to report any enors that occur during synchronization. • A mechanism to request cancellation of an ongoing synchronization operation. [0355] There are two potential process models for adapters, depending on the requirements ofthe scenario. The adapter can execute in the same process space as the application invoking it or in a separate process all by itself.
  • 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 ofthe adapter in the same process as the invoking application, or return a remote instance ofthe 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 ofthe following reasons: • Security pu ⁇ oses.
  • 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.
  • one embodiment ofthe 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 (ofthe replica).
  • WinFS The hardware/software interface system ofthe replica (WinFS)
  • WinFS 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 maintains an incremental and sequential enumeration of its changes, with each such change assigned a corresponding incremental and sequential change number (i.e., the first change is 1, the second change is 2, the third change is 3, and so on and so forth).
  • each replica also maintains the state information for the other known replicas (sync partners) in its sync community for tracking which changes it has received from these other replicas.
  • the first replica can then use this number thereafter to request, receive, or process only those changes that are greater than the number of this last applied change. Figs.
  • FIG. 38A-D illustrate how changes are tracked, enumerated, and synchronized using this sequential change enumeration methodology.
  • sync partners A and B are relicas in a common sync community and are shown in their present state which, since no changes have yet been made, equates to a change number of zero for each replica — for example, AO and BO for each replica respectively.
  • each replica aware of its own state and tracking the state of its sync partner, reflects this information in its "vector” as shown herein (which, as illustrated, lists the relicas own state first followed by the last known state of each of its partners based on the last synchronization or, in this case, initialization).
  • the initial vector for replica A is "[AO, BO]” and the initial vector for replica B is "[BO, AO]", and the two replicas are presently fully in sync. [0359] In Fig.
  • replica A make a change and assigns that change the unique incremental change number Al (the change number comprising a unique identification for the replica itself, "A", as well as a unique and incremented number for the change on that replica, "1").
  • Replica B makes two changes and assigns those changes the unique incremental change numbers of Bl and B2 respectively.
  • the replicas are now out of sync, and the vector for replica A is now [Al, B0] and the vector for replica B is [B2, A0] (which, again, reflects the last changes known).
  • replica A synchronizes with replica B by sending replica B its cunent vector to request changes (step 1).
  • Replica B receiving replica A's vector, calculates that it needs to send both changes, Bl and B2, to replica A, and thus proceeds to do so (step 2).
  • Replica A receives Replica B's changes (the change units, that is) identified as Bl and B2, applies them, and updates its own vector to [Al, B2] (step 3).
  • replica B along with calculating and sending the conect changes to replica A (step 2), also determines, based on the replica A's vector, that there have been changes made to replica A that replica B does not have, and thus replica B also sends its own vector and a request for changes to replica A (step 2').
  • Replica A when Replica A receives Replica B's changes, applies them, and updates its own vector to [Al, B2] (during step 3), it also calculates which of its changes to send to replica B and transmits them as well (step 3').
  • Replica B upon receiving this information, makes the changes and updates it vector to [B2, Al] (step 4).
  • a conflict might arise in a number of circumstances. For example, Al and B2 may have been changes made to the same change unit, or Al might be a deletion to the same change unit that B2 was modifying.
  • Synchronizing Parent-Child Disordering it is a general principal that, for synchronization, a parent Item is always sent before the child item (e.g., if Item K, a child, is embedded in Item J, a parent, Item K cannot be transmitted before Item J is transmitted). However, for replica A it is possible that, between synchronizations, both Items J and K are changed but where child Item K has a lower sorting number (based on, for example, the sequential precedence of its identification number) than child Item J, and thus would normally be transmitted first.
  • One solution to this problem for synchronization in various embodiments of the present invention is to break the changes into two groups, one that reflects only changes made to Item K, and a second that reflects only the changes made to Item J, and send them in the correct order (that is, send the group of changes for the child Item K after sending those for the parent Item J).
  • Tombstones Propogation As discussed earlier herein, tombstones are used to mark deleted change units for pu ⁇ oses of synchronization. However, because synchronization is asynchronous for multiple vectors in a sync community, these tombstones must propogate throughout the entire data platform.
  • replica A may create an Item and, during a sync with replica B, send that Item to replica B.
  • Replica A may then delete the Item and, during a sync with replica C, it would send nothing regarding the Item because there is nothing to send (since the Item was deleted).
  • replica B and replica C attempt to sync, replica C would receive the Item from replica B and there on B persist.
  • the solution to this problem for various embodiments ofthe present invention is for replica A to mark the deleted item with a tombstone. Then, when replica A deletes the Item, during a sync with replica C it sends the tombstone to replica B.
  • Relationship Name Swapping [0368] As previously discussed, Relationships have names, and thus it is possible for one replica (Pl) to swap the names for two Relationships (Rl and R2) tlirough the use of a temporary name element (X) — that is, Rl's name is copied to X, R2's name is then copied to Rl, X is then copied to R2, and lastly X is deleted.
  • P2 a partner replica
  • P2 does not know about the temporary name element X
  • an enor will occur during synchronization because, recognizing that Rl has a new name, P2's attempt to change this name results in an enor for using the same name for both Rl and R2.
  • P2 upon receiving or recognizing this same-name error, to presume a possible name swap scenario and automatically create its own temporary name element (Y) and, if a subsequent change does indeed involve renaming R2 to the name in X, then it completes the swap (otherwise, it generates the scenario as a regular conflict event). 6.
  • the solution to this problem for several embodiments ofthe present invention is to instead reorder the changes such that all reference relationships (e.g., R) are sent after all other changes are sent from Pl to P2, and thus the problem is avoided altogether by first creating the Items A and B and then relating them to each other with R.
  • all reference relationships e.g., R
  • 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 handlers 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 ofthe context ofthe sync session — at this time, logged conflicts can be resolved and removed from the log.
  • Various embodiments ofthe present invention are specifically directed to conflict handling for conflicts that occur in a peer-to-peer synchronization system (such as for the synchronization system described herein above).
  • the ability to conectly and efficiently handle conflicts minimizes data loss while retaining good usability and reduces the need for user intervention during synchronization.
  • a conflict handling schema comprising one or more ofthe follow conflict handling elements: (a) schematized representation of conflicts; (b) detection of conflicts; (c) logging of conflicts into a durable store; (d) automatic resolution of conflicts according to a flexible and configurable conflict resolution policy; (e) composable and extensible conflict handlers to filter and resolve conflicts; (f) automatic detection and removal of obsolete conflicts; and (g) programmatic conflict resolutions.
  • each of these conflict handling elements are themselves respresentative of additional embodiments ofthe present invention.
  • a knowledge-based conflict occurs when two replicas make independent changes to the same Change Unit. Two changes are called independent if they are made without knowledge of each other — in other words, the version ofthe first is not covered by the knowledge ofthe second and vice versa.
  • the synchronization service automatically detects all such conflicts based on the replicas' knowledge as described above and handles these conflicts as described herein below.
  • Some specific types of knowledge conflicts include Update-Delete, Delete-Update and Update-Update conflicts (where each name refers to the local action and the remote action in order; for example, the Update-Delete conflict is due to a local update and a remote delete to the same data).
  • Update-Delete, Delete-Update and Update-Update conflicts where each name refers to the local action and the remote action in order; for example, the Update-Delete conflict is due to a local update and a remote delete to the same data).
  • knowledge conflicts occur as a result of knowledge and version processing.
  • a constraint-based conflict involves two independent changes, just as for a knowledge-based conflict; however, a constraint-based conflict comprises changes that do not affect the same Change Unit but instead affect different Change Units with a constraint existing between them.
  • a constraint-based conflict can result from a single change, such as when syncing between two different types of systems where one has a constraint and the other does not. For example, if a system has a constraint that the maximum file name length is eight (8) characters long, and if that system receives a change to a file from another system that has no such constraint where the change is to the filename making it greater than eight characters long, a constraint conflict results (which occuned from the single change one a single machine).
  • constraint conflicts include but are not limited to: • Insert-Insert conflict: This occurs when two synchronization partners each create an object with the same logical identifier, such as a file with the same name. • No-Parent conflict: This occurs when the parent of an incoming object to be created does not exist. An example is when a file is received before its parent folder. • Undefined-Type conflict: This occurs when the schema of an incoming object is not installed, preventing the object from being created. [0379] In summary, constraint conflicts are caused by failures to apply changes for various reasons.
  • constraint conflicts if they if they can be meaningfully handled, either in the form of a resolution that results in eventual convergence, or if they can be logged for ultimate resolution through user interaction. Failures that cannot be meaningfully handled other than being reported are simply called change application errors. For certain embodiments, all change application failures are treated as enors — that is, there are no recognized constraint conflicts. And for certain embodiments, all conflicts that occur during Send synchronization are ignored as knowledge conflicts are expected to be re-presented at the next Receive synchronization. (Other failures that lead to non-convergence may also be ignored.) 2. Conflict Detection [0380] The synchronization service detects constraint violations at change application time and raises constraint-based conflicts automatically.
  • Resolving constraint-based conflicts usually requires custom code that modifies the changes in such as way as to not violate the constraint, and a synchronization service may or may not provide a general-pu ⁇ ose mechanism for doing so.
  • conflicts are detected per change unit by checking whether the local knowledge is aware ofthe remote version and vice versa.
  • knowledge-based conflicts here are four conflict detection scenarios: 1. Local knowledge aware of remote version, remote knowledge unaware of local version: This means that the incoming change is obsolete, and is therefore discarded. 2. Local knowledge unaware of remote version, remote knowledge aware of local version: This means that the incoming change is more recent than the local version, and is therefore accepted. 3. Local knowledge aware of remote version, remote knowledge aware of local version.
  • Sync initiators configure conflict resolution in their Sync Profiles.
  • the synchronization service supports combining multiple conflict handlers in a single profile. Because the conflict handling mechanism is extensible, there are several ways to combine multiple conflict handlers. One particular method involves specifying a list of conflict handlers to be tried one after another until one of them succeeds (as described herein below).
  • Another method involves associating conflict handlers with conflict types such as, for example, directing update-update knowledge-based conflicts to one conflict handler, and directing all the other conflicts to the log.
  • the synchronization service can take one of three actions (selected by the sync initiator in the Sync Profile): (1) reject the change (2) resolve the conflict automatically; or (3) log the conflict into a conflict log. a) Reject Changes [0386] If a change is rejected, the synchronization service acts as if the change did not arrive at the replica and 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.
  • Automatic conflict resolution is the process of resolving conflicts synchronously according to specified policy.
  • policy can be specified independently for send operations and receive operations.
  • Automatic conflict resolution policy is specified via the synchronization profile. Conflicts that are raised are passed to the top-level conflict handler specified in the profile. This conflict handler may resolve the conflict, log it, or pass the conflict to another conflict handler for further processing along the conflict handling pipeline.
  • Fig. 39A illustrates the conflict handling pipeline for several embodiments of the present invention.
  • a conflict handler list (or "list”) 3910 receives a conflict item 3902 and passes the conflict to the first handler 3912 on the first path of the pipeline which, in this case, is a filter.
  • the filter 3912 is a gatekeeper that evaluates the conflict 3902 and either lets it pass to the next handler 3914 or rejects it back to the list 3910 which then passes it back to the list 3912 which, in turn, passes it to the first handler 3922 on the next path in the pipeline.
  • the conflict 3902 is passed by the first filter 3912 to the second handler 3914 which, in this case, is a resolver, then the conflict is either resolved by the resolver 3914 if possible or, if not possible, the conflict is rejected back to the first handler 3922 and back to the list 3910 and then passed on the next path in the pipeline to resolver 3922.
  • Fig. 39B is a flowchart illustrating the logical traversal ofthe pipeline illustrated in Fig. 39A. In Fig. 39B, and in reference to Fig.
  • a conflict 3902 enters the pipeline at conflict handler list 3910 and is initially sent, at step 3952, to the filter 3912. If the conflict 3902 passes this filter 3912 then, at step 3954, the conflict 3902 proceeds, at step 3956, to the resolver 3914 which attempts to resolve the conflict 3902 at step 3958. If successful, at step 3998 the process returns; otherwise, the conflict proceeds, at step 3960, to the resolver 3922 which, at step 3962, attempts to resolve the conflict 3902.
  • step 3998 the process returns; otherwise, the conflict proceeds, at step 3964, to list 3932 and from there, at step 3966, to filter 3934 and if the conflict 3902 passes this filter 3934, at step 3968, then the conflict 3902, at step 3972, is logged into the conflict log (not shown) by the logger 3936 at step 3970 and the process returns at step 3998; otherwise, conflict 3902 is sent, at step 3972, to the filter 3938 and if the conflict 3902 passes this filter 3938, at step 3974, then the conflict 3902 proceeds, at step 3976, to the resolver 340 which attempts to resolve the conflict 3902 at step 3978.
  • step 3998 the process returns; otherwise, the conflict proceeds, at step 3980, to the resolver 3942 which, at step 3982, attempts to resolve the conflict 3902. If successful, at step 3998 the process returns; otherwise, the conflict 3902 is logged into the conflict log (not shown) by the resolver 3936 at step 3984 and the process returns at step 3998.
  • a path of consecutive conflict resolvers can also be constructed where, if a conflict cannot be resolved by one resolver, that conflict is passed on to the next resolver which then attempts to resolve the conflict, and so on and so forth.
  • a pipeline does not necessarily have to begin with a list; on the contrary, it may start with any type of conflict handler such as, for example, a filter. Regardless, however, if a conflict is passed back up a path to the first conflict handler in the pipeline, and that conflict handler has no additional paths to try (which would only be the case for a conflict handler list where all ofthe paths have not been attempted), then the conflict passes out ofthe pipeline and is, automatically and by default, logged to the Conflict Log.
  • the ConflictHandler type is the base type for conflict handlers, including the conflict hander list, the conflict log, and conflict filters, and other types of conflict handlers.
  • the synchronization service may also provide a number of default conflict handlers which includes but is not limited to: • local- wins: resolves the conflict by selecting the locally stored data as the winner over the incoming data • remote- wins: resolves the conflict by selecting the incoming data as the winner over the locally stored data; • last- writer- wins: pick either local-wins or remote-wins per Change Unit based on the timestamp ofthe change unit (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 ofthe synchronization services might use lexicographic comparisons of partner IDs to implement this feature. [0393] For example, a conflict handler may specify that, for Update-Delete conflicts, a Local Wins resolution should be applied, and that for all other conflicts a Last Writer Wins resolution should be applied, as follows:
  • the conflict log is also a conflict handler.
  • ISVs can implement and install their own conflict handlers. Custom conflict handlers may accept configuration parameters, though such parameters must be specified by the SCA in the Conflict Resolution section ofthe Sync Profile.
  • a conflict resolver When a conflict resolver handles a conflict, it returns the list of operations that need to be performed (in lieu ofthe conflicting change) back to the runtime. The synchronization service then applies these operations, having properly adjusted remote knowledge to include what the conflict handler has considered.
  • It is possible that another conflict is detected while applying the resolution. In such a case, the new conflict must be resolved or logged before the original processing resumes.
  • conflict resolutions When thinking of conflicts as branches in the version history of an item, conflict resolutions can be viewed as joins — combining two branches to form a single point. Thus, conflict resolutions turn version histories into directed acyclic graphs (DAGs).
  • DAGs directed acyclic graphs
  • conflict Logging While some reported conflicts may be synchronously resolved using Automatic Conflict Resolution, others may be logged for later programmatic resolution. Conflict logging allows the conflict resolution process to proceed asynchronously — that is, the conflicts do not have to be resolved at the time they are detected but may be logged for future resolution. For example, a Conflict Viewer application may allow a user to inspect and manually resolve the logged conflicts after the fact.
  • a very particular kind of a conflict handler is the Conflict Logger (or, more simply, the "logger").
  • the synchronization service logs conflicts in a conflict log as Items of type ConflictRecord (or, in alternative embodiments, simply as type Conflict). 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 ofthe conflict (e.g., update-update, update-delete, delete-update, insert-insert, or constraint); and the version ofthe incoming change and the knowledge ofthe replica sending it.
  • each such conflict item contains the conflicting change data and metadata, a description ofthe conflict as well as other contextual information such as the change applier information, the enlistment data, and the remote partner name.
  • the change data is stored in a format that can be used to apply the change.
  • each type derived from Conflict can add new fields that are relevant to that type of conflict. For example, the InsertlnsertConflict type adds the item ID ofthe item that caused the uniqueness constraint to be violated.
  • a conflict item to be logged will also include a copy ofthe target item either as an extension to the conflict item or merely as a separate item also stored in the conflict log with a relationship defined between it and the conflict item itself or, alternately, as part ofthe conflict item itself (such as a set of property- value pairs).
  • This target item to be stored as part of or in conjunction with the conflict item in the conflict log will reflect the specific changes that gave rise to the conflict in the first place.
  • Fig. 40 is a block diagram illustrating this approach using an example contact item.
  • the contact item 4002 (the "target item") comprises a name field 4004 which is initially set to "John” as ofthe last successful synchronization. This field 4004 is then changed locally to "Bob" by the local system. During a subsequent synchronization, if an attempt to change this same field 4004 to "Jane" results in a conflict because the local system cannot ascertain which name change, "Bob” or “Jane,” should be applied, then the local change (“Bob") is retained and a conflict 4006 is logged in the Conflict Log 4008 along with a copy of the contact item 4002' reflecting the application ofthe change ("Jane") that led to the conflict.
  • the Conflict Log comprises the complete target item which gave rise to a conflict, and this particular target item is updated to reflect the change that was attempted to be made on the item that led to the conflict.
  • the log is first searched to determine if there are other conflicts on the same change unit(s). If there are any existing conflicts on the same change unit, they are examined for possible removal. An existing conflict is removed if its change awareness is subsumed by the change awareness ofthe new conflict.
  • 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 ofthe logged change; and (3) suggest new change — where the application proposes a merge that, in its opinion, resolves the conflict.
  • the synchronization service removes them from the log.
  • Convergence of Replicas and Propagation of Conflict Resolutions [0404] 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 ofthe two resolutions to win over the other automatically.
  • the winner is picked in a deterministic fashion that is guaranteed to produce the same results at all times (one embodiment uses replica ID lexicographic comparisons).
  • the synchronization service treats this new conflict as a special conflict and uses the Conflict Logger to prevent it from propagating to other replicas. Such situation commonly arises with manual conflict resolution.
  • Each replica is a defined synchronization subset of data from the entirety of a data store — a slice of data having multiple instances.
  • At the root ofthe 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 ofthe 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 and use of replicas enables a true distributed peer-to-peer mutli- master synchronization community. Moreover, there is no sync community type, but the sync community exists simply as a value in the community field ofthe replicas themselves.
  • Every replica has its own metadata for tracking incremental change enumeration and storing state information 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 following are additional (or more specific) aspects ofthe conflict handling schema for various embodiments ofthe present invention.
  • 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.
  • 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 comprise three special "conflict handlers”: (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 handlers 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.
  • conflict "handler list” where each element of the list specifies a
  • Various embodiments ofthe present invention are directed to system and methods for the synchronization of two clients both utilizing a common storage platform (e.g., the new storage platform ofthe related inventions) through an intermediary that is not using the same common storage platfonn (e.g., instead using a legacy storage platfo ⁇ n that does not itself support synchronization for the new storage platform).
  • a common storage platform e.g., the new storage platform ofthe related inventions
  • an intermediary that is not using the same common storage platfonn (e.g., instead using a legacy storage platfo ⁇ n that does not itself support synchronization for the new storage platform).
  • STI Synchronization Through Intermediary
  • STI Adapters are designed to serialize results of change enumeration from a replica client to an non-replica intermediary, as well as deserialize these change results from a non-replica intermediary to a replica client.
  • Fig. 41 is a block diagram illustrating the scenario in which two clients must synchronize through an intermediary.
  • the intermediary computer system 4102 utilizing a legacy storage platform is connected to both client A 4112 and client B 4114 which are both utilizing a new storage storage platform (e.g., an embodiment ofthe related inventions described herein which, for convenience, we will hereafter refer to as "WinLH," WinLH comprising what is refened to herein as the WinFS file system, as shown).
  • WinLH an embodiment ofthe related inventions described herein which, for convenience, we will hereafter refer to as "WinLH,” WinLH comprising what is refened to herein as the WinFS file system, as shown.
  • the intermediary 4102 can be thought of as merely a "pass-through” for changes that are synchronized from client A 4112 to client B 4114 and vice versa.
  • the intermediary 4102 is not itself “syncing" with client A 4112 or client B 4114 for its own pu ⁇ oses, and thus the intermediary 4102 does not directly utilize nor change data it receives from client A 4112 or client B 4114. For this reason, and using the terminology utilized earlier herein, the intermediary 4102 is not a replica, although both client A 4112 and client B 4114 which are replicas interact with the intermediary 4102 as if it were a replica via a Sync Throught Intermediary (STI) Adapters.
  • STI Sync Throught Intermediary
  • Clients A 4112 and client B 4114 interface with the intermediary 4102 via STI Adapters 4122 and 4124 respectively, said STI Adapters being specifically tailored to intereface between the new storage platform ofthe clients 4112 and 4114 and the specific legacy platfo ⁇ n ofthe intennediary 4102.
  • STI Adapters being specifically tailored to intereface between the new storage platform ofthe clients 4112 and 4114 and the specific legacy platfo ⁇ n ofthe intennediary 4102.
  • STI Adapters being specifically tailored to intereface between the new storage platform ofthe clients 4112 and 4114 and the specific legacy platfo ⁇ n ofthe intennediary 4102.
  • STI Adapters being specifically tailored to intereface between the new storage platform ofthe clients 4112 and 4114 and the specific legacy platfo ⁇ n ofthe intennediary 4102.
  • these files are written to a specific folder (a "community folder") conesponding to the specific synchronization community, and differenct synchronization communities would have different community folders.
  • This aforementioned triplet of files includes a change data file (CDF), a prerequisite knowledge file (PKF), and a learned knowledge file (LKF).
  • CDF contains information pertaining to the specific changes to WinFS items at the change unit level.
  • the PKF specifies what a synchronization peer must already know in order to apply the associated changes.
  • the LKF specifies what the synchronization peer will learn if it applies the associated changes.
  • the STI Adapter only serializes change unit info ⁇ nation (the "changed parts" and its associated metadata), and for several embodiments this data may only comprise (for a specific change to an Item) the Item type, the Item version number, the change unit version, and the value ofthe property that was changed.
  • the triplet of files are written to the intermediary using a sequential naming convention based on the message sequence ofthe serializations (for reasons discussed later herein); for example, the first serialization could comprise three files that are stored as 1. PKF (the PKF file), l.CDF (the CDF file), and l.LKF (the LKF file) on the intermediary, and the second serialization may comprise 2. PKF, 2.CDF, and 2.LKF, and so on and so forth.
  • PKF the PKF file
  • l.CDF the CDF file
  • l.LKF the LKF file
  • STI ADAPTER PROCESSES For several embodiments ofthe present invention, The STI Adapter comprises three core operations: send sync, receive sync, and data compaction. 1. Send Sync Operation [0416]
  • Fig. 42 is a flow diagram illustrating the steps by which a client, via an STI Adapter, sends change data to an intermediary (a "send sync" operation). At step 4202, the STI Adapter first ascertains if a community folder exists on the intermediary conesponding to the synchronization community ofthe client.
  • the STI Adapter then scans and deserializes all ofthe contents of LKFs in the community folder ofthe intermediary to ascertain the current state ofthe intermediary's local knowledge (ILK) for that synchronization community.
  • ILK intermediary's local knowledge
  • the ILK is deemed to be null at step 4206 and a community folder is created on the intermediary.
  • the STI Adapter concunently acquires "write mode" process locks on the intermediary's community folder (via the intermediary's file system) in order to preserve data integrity by preventing other clients (or other peers or processes) from reading or writing to the community folder for the duration ofthe send sync operation.
  • the STI Adapter then communicates the ILK to the client. Based on the ILK and its own client local knowledge (CLK), at step 4212 the client determines if there are any changes not covered by the ILK and, if not, the process skips to step 4220. On the other hand, if the client determines there are changes not covered by the ILK, at step 4214 the client prepares the enumerated changes not covered by the ILK and passes them to the STI Adapter. At step 4216 the STI Adapter serializes each batch of change information (change data and knowledge) and, at step 4218, the STI Adapter then writes the serialized change batches to the intermediary's community folder as sequentially- increasings triplets of files as previously discussed.
  • CLK client local knowledge
  • the STI Adapter then releases the "write mode" process locks to allow other clients (or other peers or processes) to examine the updated content on the intermediary.
  • the send sync operation is completed, it should be noted that the STI Adapter stores the identity (or reference number) ofthe last and highest sequentially-increasing change triplet (HCT) that was written to the intermediary for later reference (discussed below). It should also be noted that no conflict handling is performed as part of a send sync operation.
  • Fig. 43 is a flow diagram illustrating the steps by which a client, via an STI Adapter, receives change data from an intermediary (a "receive sync" operation).
  • the STI Adapter first receives the client local knowledge (CLK) which, for several embodiments ofthe present invention, occurs when the client sends a sync request to the intermediary thru the STI Adapter, said sync request inherently including the CLK per the peer-to-peer synchronization scheme discussed earlier herein.
  • CLK client local knowledge
  • the STI Adapter acquires "read mode" process locks on the intermediary's community folder (via the intermediary's file system) in order to preserve data integrity by preventing other clients (or other peers or processes) from writing to (but, for certain embodiments, not reading from) the community folder for the duration ofthe receive sync operation.
  • this "read mode" can might be optimized to lock each triplet rather than the entire directory for better concunency.
  • the STI Adapter scans the community folder on the intermediary for the next higher change triplet (a) that is sequentially higher than the HCT, (b) where the CLK (client local knowledge) is greater than the prerequisite knowledge (from the PKF) for that change triplet, and (c) where the CLK is less than the learned knowledge (from the LKF) for the change triplet.
  • step 4308 If there is such a change triplet (an ACT) at step 4308, then at step 4310 the Sync Adapter deserializes the contents of that change triplet (the ACT) into a replica-undersrtandable enumerated change and at step 4312 sends the change to the client for processing. The process then returns to step 4306 for the next ACT and the process continues until none remain, at which time the STI Adapter unlocks the read mode at step 4314 and the process ends. 3.
  • Intermediary File Data Compression/Compaction For various embodiments of the present invention it is necessary to routinely compact the serialized data and knowledge files created by the STI Adapter; otherwise the ever- increasing number of change triplets would fill up all available storage space on the intermediary.
  • the goal of data compaction is to ensure that the growth of data and knowledge files is appropriately bounded on the intermediary.
  • One method employed by several embodiments ofthe present invention is to set an "upper threshold" on the number of change packets which are allowed to exist on the shared file system and, once that tlireshold is exceeded, the next STI Adapter capable of doing so is required to compact the shared file system (the files in the community folder) on the intermediary via a compaction operation.
  • the compaction operation reduces the amount of data stored in the shared file system by (a) compacting the change history for individual existing objects and (b) removing the changes broadcast for objects which have been deleted (either explicitly, via conflict resolution, or as a result of tombstone cleanup).
  • compaction can only be carried out by by an STI Adapter for a client which has just performed a receive sync and which can immediately perform a "full" send sync (that is, full change enumeration with zero baseline as if there was no community folder on the intermediary).
  • a "full" send sync that is, full change enumeration with zero baseline as if there was no community folder on the intermediary.
  • compaction cannot be performed by clients who only do send syncs or only do receive syncs with an intermediary.
  • FIG. 44 is a flow diagram illustrating the steps by wliich an STI Adapter (that is, an STI Adapter that is associated with a client that can both send sync and receive sync) performs a compacts operation for data in a community folder on an intermediary (a "compaction" operation).
  • an STI Adapter that is, an STI Adapter that is associated with a client that can both send sync and receive sync
  • the STI Adapter checks the community folder on the intermediary to see if the upper threshold has been exceeded; if not, the process ends (and the sync receive process finishes up by releasing locks, etc.).
  • the STI Adapter deletes all ofthe change triplet files in the community folder ofthe intermediary and then, at step 4408, the STI Adapter proceeds to initiate a full read sync operation (including write mode process locks) between the client and the intermediary by indicating that the knowledge of the intermediary is null to the client (which, following the deletion, is indeed the case).
  • a full read sync operation including write mode process locks
  • the process differs slightly in that the STI Adapter checks to see if compaction is needed before the STI Adapter then acquires "read mode" process locks on the intermediary's community folder (via the intermediary's file system) (at step 4304 of Fig. 43) and, if compaction is needed, using the standard (not optimized) "read mode" in order to preserve data integrity by preventing other clients (or other peers or processes) from writing to (but, for certain embodiments, not reading from) the community folder for the duration ofthe receive sync operation.
  • the data on the intermediary is not deleted until after the client has uploaded all change triplets by overwriting the existing change triplets starting with the first one, and then once all change triplets have been uploaded (and the old ones rewritten), all remaining change triplets of a higher sequence number than the last one uploaded during the full read sync are deleted.
  • certain alternative embodiments also begin compaction after the complete receive sync operation has completed (include release ofthe read mode process locks). For such embodiments, the process starts with acquiring a write mode process blocks and then proceeds to perform all ofthe steps previously alluded to.
  • FIG. STI AND DOWN-LEVEL CLIENT SUPPORT In addition to the foregoing, several additional embodiments ofthe present invention are directed to variations ofthe sync-through-intermediary technology described earlier herein. Certain embodiments are directed to a system that further comprise a client that is also running a legacy storage platform where said "legacy client" can also access all data files. It is also anticipated that certain legacy clients and other applications and processes would be able to access these data files for other pu ⁇ oses. For example, for a legacy client that synchronizes files based on date of creation or some other inherent file characteristic. Another example would be a legacy client that directly accesses any or all of files (e.g., a *.CDK file) and copies same. I many regards, a legacy client might be thought of in the same tenns as a second intermediary that communicates directly (perhaps using legacy synchronization techniques) with the first intermediary, and thus multi-intermediary synchronization is possible and hereby disclosed.
  • a legacy client might be thought of in the
  • the present invention is directed to a storage platform for organizing, searching, and sharing data.
  • the storage platform ofthe present invention 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 ofthe present invention enables more efficient application development for consumers, knowledge workers and ente ⁇ rises. 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.
  • 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-pu ⁇ ose 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)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Hardware Redundancy (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

La présente invention a trait à des systèmes et des procédés pour la synchronisation de deux clients tous deux utilisant une plate-forme de mémoire commune (par exemple, la nouvelle plate-forme de mémoire associée aux inventions) pour la synchronisation via un intermédiaire qui n'utilise pas la même plate-forme commune (par exemple, utilisant une plate-forme de mémoire partagée qui elle-même ne supporte pas de synchronisation pour la nouvelle plate-forme de mémoire). Une donnée est synchronisée au moyen des capacités existantes de l'intermédiaire mais où la structure de donnée des clients est préservée. Un adaptateur est utilisé pour permettre l'interaction d'un client avec un intermédiaire par la compensation de l'incapacité de l'intermédiaire à préserver les éléments de la structure de donnée inhérents à la plate-forme de mémoire du client. Des modes de réalisation spécifiques ont trait soit à une synchronisation de téléchargement en amont de données depuis un client vers un intermédiaire et/ou une synchronisation de téléchargement en aval de données depuis un intermédiaire vers un client ou aux deux types de synchronisation. D'autres modes de réalisation ont trait à un compactage de données sur l'intermédiaire.
EP04779486A 2003-08-21 2004-07-29 Systemes et procedes pour la synchronisation de systemes informatiques par un partage ou dispositif de systeme de fichier intermediaire Ceased EP1573600A4 (fr)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US646646 2003-08-21
WOPCT/US03/27419 2003-08-21
US10/646,646 US7349913B2 (en) 2003-08-21 2003-08-21 Storage platform for organizing, searching, and sharing data
PCT/US2003/027419 WO2005029314A1 (fr) 2003-08-21 2003-08-21 Plate-forme de stockage pour organiser, rechercher et partager des donnees
US692508 2003-10-24
US10/692,508 US7483923B2 (en) 2003-08-21 2003-10-24 Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
US56714104P 2004-04-30 2004-04-30
US567141P 2004-04-30
US10/883,621 US7512638B2 (en) 2003-08-21 2004-06-30 Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system
US883621 2004-06-30
US889423 2004-07-12
US10/889,423 US7401104B2 (en) 2003-08-21 2004-07-12 Systems and methods for synchronizing computer systems through an intermediary file system share or device
PCT/US2004/024441 WO2005024551A2 (fr) 2003-08-21 2004-07-29 Systemes et procedes pour la synchronisation de systemes informatiques par un partage ou dispositif de systeme de fichier intermediaire

Publications (2)

Publication Number Publication Date
EP1573600A2 true EP1573600A2 (fr) 2005-09-14
EP1573600A4 EP1573600A4 (fr) 2006-04-19

Family

ID=37616475

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04779486A Ceased EP1573600A4 (fr) 2003-08-21 2004-07-29 Systemes et procedes pour la synchronisation de systemes informatiques par un partage ou dispositif de systeme de fichier intermediaire

Country Status (4)

Country Link
EP (1) EP1573600A4 (fr)
JP (1) JP4580389B2 (fr)
CN (1) CN100565505C (fr)
WO (1) WO2005024551A2 (fr)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8131739B2 (en) 2003-08-21 2012-03-06 Microsoft Corporation Systems and methods for interfacing application programs with an item-based storage platform
US8238696B2 (en) 2003-08-21 2012-08-07 Microsoft Corporation Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system
US7590643B2 (en) 2003-08-21 2009-09-15 Microsoft Corporation Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
US8166101B2 (en) 2003-08-21 2012-04-24 Microsoft Corporation Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US7805422B2 (en) 2005-02-28 2010-09-28 Microsoft Corporation Change notification query multiplexing
US7801912B2 (en) * 2005-12-29 2010-09-21 Amazon Technologies, Inc. Method and apparatus for a searchable data service
US8412676B2 (en) * 2008-10-21 2013-04-02 Microsoft Corporation Forgetting items with knowledge based synchronization
US10303787B2 (en) 2008-10-21 2019-05-28 Microsoft Technology Licensing, Llc Forgetting items with knowledge based synchronization
US20120036188A1 (en) * 2010-08-06 2012-02-09 Nokia Corporation Method and Apparatus for Aggregating Document Information
CN106484867B (zh) * 2016-10-10 2019-06-07 Oppo广东移动通信有限公司 一种多开应用引用关系的删除方法、装置及终端
US10866963B2 (en) 2017-12-28 2020-12-15 Dropbox, Inc. File system authentication
CN109086032B (zh) * 2018-06-28 2022-02-25 山东鲁软数字科技有限公司智慧能源分公司 一种全适应一体化电源监控方法和装置
CN114579190B (zh) * 2022-02-17 2022-10-14 中国科学院计算机网络信息中心 基于流水线机制的跨中心协同计算的编排方法与系统
CN115328997B (zh) * 2022-07-15 2023-04-07 深圳市数帝网络科技有限公司 数据同步方法、系统、设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002075539A2 (fr) * 2001-03-16 2002-09-26 Novell, Inc. Modele client-serveur pour la synchronisation de fichiers

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6694336B1 (en) * 2000-01-25 2004-02-17 Fusionone, Inc. Data transfer and synchronization system
US6671757B1 (en) * 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
EP1130511A3 (fr) * 2000-01-25 2004-04-07 FusionOne, Inc. Système de transfert de données et de synchronisation

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002075539A2 (fr) * 2001-03-16 2002-09-26 Novell, Inc. Modele client-serveur pour la synchronisation de fichiers

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
GRAY J ET AL: "The dangers of replication and a solution" SIGMOD RECORD, SIGMOD, NEW YORK, NY, US, vol. 25, no. 2, 4 June 1996 (1996-06-04), pages 173-182, XP002146555 ISSN: 0163-5808 *
HELAL S ET AL: "A three-tier architecture for ubiquitous data access" COMPUTER SYSTEMS AND APPLICATIONS, ACS/IEEE INTERNATIONAL CONFERENCE ON. 2001 BEIRUT, LEBANON 25-29 JUNE 2001, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 25 June 2001 (2001-06-25), pages 177-180, XP010551207 ISBN: 0-7695-1165-1 *
KISTLER J J ED - CABRERA L-F ET AL: "Increasing file system availability through second-class replication" MANAGEMENT OF REPLICATED DATA, 1990. PROCEEDINGS., WORKSHOP ON THE HOUSTON, TX, USA 8-9 NOV. 1990, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 8 November 1990 (1990-11-08), pages 65-69, XP010021244 ISBN: 0-8186-2085-4 *
KISTLER J J ET AL: "DISCONNECTED OPERATION IN THE CODA FILE SYSTEM" ACM TRANSACTIONS ON COMPUTER SYSTEMS, ACM, NEW YORK, NY, US, vol. 10, no. 1, 1 February 1992 (1992-02-01), pages 3-25, XP000323223 ISSN: 0734-2071 *
See also references of WO2005024551A2 *
SESHADRI P ET AL: "SQLServer for Windows CE-a database engine for mobile and embedded platforms" DATA ENGINEERING, 2000. PROCEEDINGS. 16TH INTERNATIONAL CONFERENCE ON SAN DIEGO, CA, USA 29 FEB.-3 MARCH 2000, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 29 February 2000 (2000-02-29), pages 642-644, XP010378761 ISBN: 0-7695-0506-6 *
SYNCML CONSORTIUM: "SyncML Sync Protocol, version 1.0" SYNCML CONSORTIUM, 7 December 2000 (2000-12-07), XP002217356 *

Also Published As

Publication number Publication date
JP4580389B2 (ja) 2010-11-10
CN1781096A (zh) 2006-05-31
JP2007527053A (ja) 2007-09-20
WO2005024551A3 (fr) 2005-05-19
WO2005024551A2 (fr) 2005-03-17
EP1573600A4 (fr) 2006-04-19
CN100565505C (zh) 2009-12-02

Similar Documents

Publication Publication Date Title
US7401104B2 (en) Systems and methods for synchronizing computer systems through an intermediary file system share or device
US7512638B2 (en) Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system
US7483923B2 (en) Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
US7743019B2 (en) Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system
US8166101B2 (en) Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US7917534B2 (en) Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
CA2512185C (fr) Systemes et procedes permettant de fournir des services de synchronisation pour des unites d'informations pouvant etres gerees par un systeme d'interface materiel/logiciel
WO2005024550A2 (fr) Systemes et procedes pour la mise en oeuvre d'un schema d'images numeriques pour l'organisation d'unites d'information aptes a etre gerees par un systeme d'interface materielle/logicielle
CA2815562C (fr) Systemes et procedes d'extension et d'heritage pour des unites d'informations pouvant etre gerees par un systeme d'interface materiel/logiciel
JP4580389B2 (ja) 仲介ファイルシステム共有または仲介デバイスを介してコンピュータシステムを同期させるためのシステムおよび方法
EP1573508A1 (fr) Systemes de mise en oeuvre d'une logique de synchronisation
KR101149959B1 (ko) 중간 파일 시스템 공유 또는 장치를 통해 컴퓨터 시스템을동기화하는 시스템 및 방법
NZ540221A (en) Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050617

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: POHLMANN, NILS, H.,C/O MICROSOFT CORPORATION

Inventor name: THOMAS, MICHAEL, W.,C/O MICROSOFT CORPORATION

Inventor name: SHAH, DARSHATKUMAR,C/O MICROSOFT CORPORATION

Inventor name: ECHERU, OKECHUKWU C.

Inventor name: NOVIK, LEV,C/O MICROSOFT CORPORATION

RIN1 Information on inventor provided before grant (corrected)

Inventor name: THOMAS, MICHAEL, W.,C/O MICROSOFT CORPORATION

Inventor name: POHLMANN, NILS, H.,C/O MICROSOFT CORPORATION

Inventor name: NOVIK, LEV,C/O MICROSOFT CORPORATION

Inventor name: SHAH, DARSHATKUMAR,C/O MICROSOFT CORPORATION

Inventor name: ECHERUO, OKECHUKWO

A4 Supplementary search report drawn up and despatched

Effective date: 20060307

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ECHERUO, OKECHUKWOC/O MICROSOFT CORPORATION

Inventor name: POHLMANN, NILS, H.,C/O MICROSOFT CORPORATION

Inventor name: THOMAS, MICHAEL, W.,C/O MICROSOFT CORPORATION

Inventor name: SHAH, DARSHATKUMAR,C/O MICROSOFT CORPORATION

Inventor name: NOVIK, LEV,C/O MICROSOFT CORPORATION

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080530

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170407