JP2007503050A - System and method for realizing a synchronous processing service for a unit of information manageable by a hardware / software interface system - Google Patents

Abstract

Some embodiments of the present invention employ a synchronization adapter to synchronize information between “WinFS” and non- “WinFS” data sources (FIGS. 36, 3622/3666). An example of an adapter is an adapter that synchronizes address book information between a “WinFS” contact folder and a non-WinFS mailbox (FIGS. 36 and 3642). In these cases, the adapter developer develops schema conversion code between the “WinFS” (FIGS. 36, 3612) schema and the non- “WinFS” data source schema (FIGS. 36, 3624). 36, 3612) It is also possible to use the “WinFS” synchronization processing core service API described herein provided by the synchronization platform. In addition, adapter developers support protocols for communicating non- "WinFS" data source changes. The sync adapter (FIGS. 36, 3662) is called and controlled by using the sync controller API and reports progress and errors using this API (FIG. 36, 3652).

Description

  This application is a US patent filed October 24, 2004 entitled "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM", the entire disclosure of which is incorporated herein. Application No. 10 / 692,515 (reference number MSFT-2844), US patent application filed on August 21, 2003 entitled "SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM" No. 10 / 646,575 (reference number MSFT-2733) and International Application No. PCT / filed on August 21, 2003 entitled “SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM”. The priority of US03 / 26150 specification (reference number 2777) is also claimed.

  This application is hereby incorporated in its entirety by this application (partially summarized for convenience) by the same applicant, "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM BUT US patent application Ser. No. 10 / 647,058 (reference number MSFT-1748), filed August 21, 2003, entitled “INDEPENDENT OF PHYSICAL REPRESENTATION”, “SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION, US patent application Ser. No. 10 / 646,941 (reference number MSFT-1749) filed on August 21, 2003, “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A August 2003 titled "BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" US Patent Application No. 10 / 646,940 filed on the 21st (reference number MSFT-1750), “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY US Patent Application No. 10 / 646,632 (reference number MSFT-1751) filed on August 21, 2003 entitled “A HARDWARE / SOFTWARE INTERFACE SYSTEM”, “SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION US patent application Ser. No. 10 / 646,645 filed Aug. 21, 2003 (reference number MSFT-1752) entitled “MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”, “STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND US patent application Ser. No. 10 / 646,646 filed Aug. 21, 2003 entitled “SHARING DATA” (Reference number MSFT-2734), US patent application Ser. No. 10 / 646,580, filed Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM” No. MSFT-2735), US patent application No. 10 / filed on Oct. 24, 2003 entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”. No. 692,779 (reference number MSFT-2829), 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" US patent application Ser. No. 10 / 692,508 (reference number MSFT-2845), “SYSTEMS AN US Patent Application No. 10 / 693,362, filed Oct. 24, 2003 (reference number MSFT) entitled “D METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM” -2846), and US patent application Ser. No. 10 / 693,574 filed Oct. 24, 2003 entitled “SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”. Relevant to the subject matter of the invention disclosed in (reference number MSFT-2847).

  The present invention relates generally to the field of information storage and retrieval, and more specifically to an active storage platform for organizing, retrieving, and sharing various types of data in a computerized system.

  Individual disk capacities have increased at a rate of almost 70% per year over the last decade. Moore's law accurately predicted the tremendous increase in central processing unit (CPU) power that had been going on for many years. Wired and wireless technology has provided tremendous connectivity and bandwidth. Assuming the current trend will continue, within a few years, the average laptop computer will have roughly 1 terabyte (TB) of storage and store hundreds of files, 500 gigabyte (GB) drive It will be natural.

  Consumers primarily use computers to communicate and organize personal information, whether it is traditional schedule management (PIM) style data, digital music or a medium such as photography. do not do. The amount of digital content and the ability to store raw bytes has increased tremendously, but the methods that consumers can use to organize and integrate such data have not been followed. Knowledge workers spend a great deal of time managing and sharing information, and one study estimates that knowledge workers spend 15-25% of all time on non-productive information-related activities Yes. Other studies speculate that standard knowledge workers spend approximately 2.5 hours searching for information every day.

  Developers and Information Technology (IT) departments have invested considerable time and money to build their own data stores for common storage abstractions that represent people, places, time, and events. This not only duplicates work, but also creates a number of isolated islands of common data that lack a mechanism for common retrieval or sharing of such data. Today, consider how many address books can exist on a computer running the Microsoft Windows® operating system. Many applications, such as e-mail clients and personal finance programs, store address books individually and there is little sharing between applications of address book data that each such program maintains individually. As a result, finance programs (programs such as Microsoft Money) do not share recipient addresses with addresses held in email contact folders (folders provided by Microsoft Outlook). In fact, many users have multiple devices, logically synchronize their personal data among themselves, and span a variety of additional sources, from mobile phones to commercial services such as MSN and AOL. However, collaboration on shared documents is mostly done by attaching documents to email messages, which is done manually and inefficiently.

  One reason for this lack of collaboration is that traditional approaches to organizing information within a computer system use a file-folder / directory-based system ("file system") to store multiple files. It functions mainly on organizing a plurality of files into a directory hierarchy of a folder based on the abstraction of the physical organization of the storage medium used to do this. Developed in the 1960s, the Multitics operating system has gained a high reputation for managing data storable units at the operating system level using files, folders, and directories for the first time. In particular, Multics used symbolic addresses within the hierarchy of files (thus introducing the concept of file paths), and the physical addresses of files were not transparent to users (applications and end users). The file system as a whole was unaware of the file format of any individual file, and the relationship between the files was considered insignificant at the operating system level (ie, other than the location of the file in the hierarchy) . Since the advent of Multics, storable data has historically been organized into files, folders, and directories at the operating system level. These files generally include the file hierarchy itself (“directory”) embodied in special files held by the file system. This directory then maintains a list of entries corresponding to all of the other file in the directory and the node location of such a file in the hierarchy (referred to herein as a folder). Such has been the ultimate technology for about 40 years.

  However, a file system is nevertheless an abstraction of that physical storage system, and therefore of those files, while realizing a sufficiently reasonable representation of the information located within the computer's physical storage system Usage requires some level of instruction (interpretation) between the user's operations (contextual units, features, and relationships with other units) and the operating system's content (files, folders, and directories) And Thus, even though the user (application and / or end user) has no choice, but it is inefficient, inconsistent, or otherwise undesirable in some way, the unit of information is file system Force to structure. In addition, existing file systems know little about the structure of the data stored in individual files, so most of the information is locked up in files that can only be accessed (understood) by the application that wrote them. Will remain. As a result, this lack of a schematic description of information and a mechanism for managing information creates a data storage location with little data sharing between the individual storage locations. . For example, many personal computer (PC) users are at a certain level because file organization is a fairly difficult task for PC users—for example, Outlook Contacts, online account addresses, Windows Address Book, Quicken Payes, and Instant Messaging (IM) buddy list—has more than five different stores that store information about the people they interact with. Most existing file systems use nested folder metaphors for organizing files and folders, so as the number of files increases, the effort required to maintain a flexible and efficient organization scheme can be significant. It becomes. In such situations, having multiple classifications of a single file is very beneficial, but using hard or soft links in existing file systems is cumbersome and difficult to maintain.

  In the past, there have been several attempts to eliminate the flaws of the file system, but it has failed. Some of those previous attempts have made use of associative memory to provide a mechanism that allows data to be accessed by content rather than physical address. However, associative memory has proven useful for small-scale usage by devices such as caches and memory management units, but large-scale usage on devices such as physical storage media is still possible for a variety of reasons As such, these efforts have not been successful, so such a solution simply does not exist. Other attempts using object oriented database (OODB) systems have also been made, but these attempts feature strong database characteristics and good non-file representations, are not effective in handling file representations, and are not hardware / It is also not possible to reproduce the speed, efficiency, and simplicity of file and folder based structures at the system level of the software interface. Other efforts, such as attempts to use SmallTalk (and its derivatives), have proven to be very effective in handling file and non-file representations, but make efficient use of the relationships that exist between various data files. It lacked the necessary database functions to organize and use well, and thus the overall efficiency of such a system was unacceptable. In addition, other attempts to use BeOS (and other such operating system studies) have some of the necessary database functionality to handle non-file representations, even though they can represent the files properly. It has been demonstrated that it is inadequate-the same drawbacks as the central drawbacks of traditional file systems.

  Database technology is another technical field where similar challenges exist. For example, the relational database model has been a great commercial success, but in fact, independent software vendors (ISVs) are generally a small part of the functionality provided by relational database software products (Microsoft SQL Server). Is used. Instead, most of the application interaction with such products is in the form of simple “read” and “write”. One of the most important reasons that are often not noticed, such as the lack of a platform or database, is readily apparent, but the database is not necessarily the exact one that a large business application vendor really needs. This means that no abstraction is performed. For example, in the real world, there is a concept of “items” in “customers” or “orders” (along with items within themselves, and “line items” with orders embedded as their own items), but relational databases Only recognizes tables and rows. As a result, it may be desirable for an application to have (for example) item-level integrity, locking, security, and / or triggering aspects, but in general, a database will have these functions in a table / row. It is prepared only at the level. This can work well if each item is mapped to a single row in a table in the database, but for multiple line item orders, the item is actually mapped to multiple tables. There can be a reason, and if that is the case, a simple relational database system will not do the right abstraction at all. As a result, applications must build logic on the database to implement their basic abstraction. This means that the basic relational model is basically sufficient to store data that can be easily developed by high-level applications because the relational model basically requires some level of indirection between the application and the storage system. Does not provide a secure platform-the semantic structure of the data can only be visible in the application in some cases. Some database vendors have built high-level functionality into their products—including object-relational capabilities, new organizeable models, etc.—but none have achieved the necessary kind of comprehensive solution. This is because a truly comprehensive solution is a useful data abstraction ("Items", "Extensions", "Items", "Extensions", “Relationships” and the like).

  Several documents disclose technical contents related to the conventional technique as described above (for example, see Non-Patent Documents 1 and 2).

WinFS Sync Adapter API spec [SADP] WinFS Sync Controller API [SCTRL] spec

  With regard to the aforementioned shortcomings in existing data storage and database technology, a new storage platform with increased ability to organize, search and share all types of data in computer systems—existing file systems and database systems There is a need for a storage platform that is designed to store all types of data, extending and expanding the data platform beyond. The present invention meets this requirement, along with related inventions incorporated earlier by reference herein.

  The present invention has been made in view of such circumstances, and an object of the present invention is to provide a system and method for realizing a synchronization processing service for a unit of information that can be managed by a hardware / software interface system. It is in.

  The following summary provides an overview of the various aspects of the invention described in the context of the related invention ("Related Invention") incorporated herein by reference earlier. This summary is not intended to be an exhaustive description of all important aspects of the invention or to delineate the scope of the invention. Rather, this summary is intended to be used as an introduction to the following detailed description and drawings.

  The present invention, together with related inventions, is generally directed to a storage platform for data organization, retrieval, and sharing. The storage platform of the present invention extends and extends the concept of data storage over existing file systems and database systems for all types of data, including structured, unstructured, or semi-structured data. Designed to be a store.

  The storage platform of the present invention includes a data store implemented on a database engine. The database engine includes a relational database engine having an object-relational extension function. The data store implements a data model that supports data organization, retrieval, sharing, synchronization, and security. Specific types of data are described in the schema, and the platform provides a mechanism to extend the collection of schemas to define new types of data (essentially child types of the basic types implemented by the schema). The synchronization processing function facilitates sharing of data between users or systems. A file system-like function is provided, which enables data store interoperability with existing file systems without the limitations of such conventional file systems. The change tracking mechanism provides a change tracking function for the data store. The storage platform further comprises a set of application program interfaces for accessing all of the aforementioned functions of the storage platform from the application and accessing the data described in the schema.

  A data model implemented by a data store defines a unit of data storage in terms of items, elements, and relationships. An item is a unit of data that can be stored in a data store and includes one or more elements and relationships. Can be included. An element is an instance of a type that includes one or more fields (also called properties here). A relationship is a link between two items. (As used herein, these and other specific terms may be capitalized in original English to separate them from other terms that are used very closely. However, in English, a capitalized first term is “Item”, and the same term when it is not capitalized in English, for example, “item” is translated into Japanese as an item, but there is no intention to distinguish it. Such distinction should not be assumed or included implicitly).

  The computer system further includes a plurality of Items that constitute a discrete storable unit of information, each Item being operable by a hardware / software interface system, a plurality of Item Folders that constitute an organizational structure for the Items, and Each item belongs to at least one item folder, and includes a hardware / software interface system for operating a plurality of items, which may belong to a plurality of item folders.

  Some of the Item or Item property values can be calculated dynamically as opposed to being derived from the persistent store. That is, the hardware / software interface system does not need to store the Items, but is given the ability to enumerate the current set of Items or the identifier of the storage platform (described in more detail in the session describing the application programming interface or API). Some operations are supported, such as the ability to retrieve an Item when given-for example, the Item can be the current location of the mobile phone or a temperature reading on a temperature sensor. The hardware / software interface system can include multiple Items that operate multiple Items and are interconnected by multiple Relationships managed by the hardware / software interface system.

  The hardware / software interface system of the computer system further comprises a core schema that defines a set of core Items that the hardware / software interface system understands and can directly process in a predetermined and predictable manner. In order to operate a plurality of Items, a computer system interconnects the plurality of Items and a plurality of Relationships at a hardware / software interface system level, and manages the Relationships.

  The storage platform API provides a data class for each item, item extension, and relationship defined in the collection of storage platform schemas. In addition, the application programming interface defines a common set of behaviors for data classes, and implements a set of framework classes that together with the data classes provide a basic programming model for the storage platform API. The storage platform API is a simplified form that can be used by application programmers to build queries based on various properties of items in the data store in a way that separates application programmers from the underlying database engine query language details. Provide a query model. The storage platform API further collects changes made to the items by the application program and then organizes them into the correct updates required by the database engine (or some type of storage engine) on which the data store is implemented. This allows application programmers to make changes to items in memory while leaving the complexity of updating the data store to the API.

  The storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses through a common storage infrastructure and schematized data. This not only makes the functionality specific to the data model available, but also includes a rich and extensible application programming interface that encompasses and extends existing file systems and database access methods.

  As part of this generic structure of interrelated inventions (described in detail in Section II of “Best Mode for Carrying Out the Invention”), the present invention is specifically directed to synchronous APIs (“Inventions” (Detailed description will be given in Section III of the “Best Mode for Carrying Out”). Other features and advantages of the present invention will become apparent from the detailed description of the invention and the accompanying drawings.

  The foregoing summary, together with the following detailed description of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments of the various aspects of the invention, but the invention is not limited to the specific methods and instrumentalities disclosed. The drawings are described below.

Table of Contents Introduction A. Example of computing environment Conventional file-based storage II. WINFS storage platform for data organization, retrieval and sharing Terminology B. Overview of storage platform Data model Items
2. Item identification 2. Item Folders and Categories
4). Schema
a) Base Schema
b) Core Schema
5). Relationship a) Declaration of relationship b) Retention relationship c) Embedding relationship d) Reference relationship e) Rules and constraints f) Ordering of relationships Extensibility a) Item extension b) NestedElement type extension Database engine 1. Implementation of data store using UDT 2. Item mapping Extended mapping 4. Mapping of nested elements Object identification Rules for naming SQL objects 7. Naming rules for columns Search view a) Item
(1) Master item search view
(2) Typed item search view b) Item expansion
(1) Master extended search view
(2) Typed extended search view c) Nested elements d) Relationship
(1) Master relationship search view
(2) Relation instance search view e)
9. Update 10. Change Tracking & Tombstone a) Change Tracking
(1) Change tracking in the “master” search view
(2) Change tracking in “typed” search view b) Tombstone
(1) Item Tombstone
(2) Extended tombstone
(3) Related tombstones
(4) Tombstone cleanup Helper API and functions a) Function [System. Storage]. GetItem
b) Function [System. Storage]. GetExtension
c) Function [System. Storage]. GetRelationship
12 Metadata a) Schema metadata b) Instance metadata e. Security F. Notification and change tracking Interoperability of conventional file system Storage platform API
III. Synchronous API
A. Overview of synchronization Synchronization processing between storage platforms a) Synchronization (sync) control application b) Schema annotation c) Synchronization configuration
(1) Community folder-mapping
(2) Profile
(3) Schedule d) Conflict avoidance process
(1) Competition detection
(A) Knowledge base competition
(B) Constraint-based competition
(2) Competitive processing
(A) Automatic conflict resolution
(B) Create conflict log
(C) Conflict inspection and resolution
(D) Convergence of replica and propagation of conflict resolution Non-storage platform data store synchronization a) Synchronization processing service
(1) Change enumeration
(2) Change Application
(3) Conflict Resolution
b) Mounting the adapter Security 4. Manageability B. Overview of synchronous processing API General terminology Main items of synchronous processing API Synchronous processing API service List of changes 2. Change application Sample code API synchronous processing method Additional aspect of synchronization schema IV. Conclusion

I. Introduction The subject matter of the present invention has been described with specificity to meet legal requirements. However, the description itself is not intended to limit the scope of the invention. Rather, the inventor believes that claimed subject matter, along with other current or future technologies, includes similar or different steps or combinations of steps to the activities or elements described herein. We considered that other methods could be implemented. Furthermore, although the term “step” may be used herein to imply different elements of the method employed, the term explicitly describes the order of the individual steps. Unless otherwise described and explained, they should not be construed as implying a particular order between the various steps disclosed herein.

A. Exemplary Computing Environment Numerous embodiments of the present invention can be executed on a computer. FIG. 1 and the following description is a general description briefly describing a suitable computing environment in which the invention may be implemented. Although not required, various aspects of the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer such as a client workstation or server. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Furthermore, the present invention can be implemented using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

  As shown in FIG. 1, an example general purpose computing system includes a conventional personal computer 20 that includes a processor 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processor 21. including. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral device bus, and a local bus using various bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input / output system 26 (BIOS) including basic routines for helping information transmission between elements in the personal computer 20 at the time of startup or the like is stored in the ROM 24. The personal computer 20 further includes a hard disk drive 27 for reading and writing to a hard disk not shown in the figure, a magnetic disk drive 28 for reading and writing to a removable magnetic disk 29, and a CD-ROM or other light. An optical disk drive 30 is provided for reading from and writing to a removable optical disk 31 such as a medium. 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 drive and associated computer readable media implement non-volatile storage for storing computer readable instructions, data structures, program modules, and other data for the personal computer 20. The example environment described in the present invention employs a hard disk, a removable magnetic disk 29, and a removable optical disk 31, but those skilled in the art will appreciate that a magnetic cassette, flash memory card, digital video disk, Bernoulli cartridge, It will be appreciated that other types of computer readable media capable of storing computer accessible data such as multiple random access memories (RAM), multiple read only memories (ROM) may be used in this operating environment. Similarly, the environment can further include various types of monitoring devices such as heat detectors and security or fire alarm devices, and other sources of information.

  Many program modules, including operating system 35, one or more application programs 36, other program modules 37, and program data 38, are stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25. Can. A user can input commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) include a microphone, joystick, game pad, satellite dish, scanner, and the like. These input devices and other input devices are often connected to the processor 21 via a serial port interface 46 coupled to the system bus, such as a parallel port, game port, or universal serial bus (USB). It can also be connected by other interfaces. 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. In addition to the monitor 47, the personal computer usually includes other peripheral output devices (not shown) such as a speaker and a printer. The system example of FIG. 1 further includes a host adapter 55, a SCSI (Small Computer System Interface) bus 56, and an external storage device 62 connected to the SCSI bus 56.

  The personal computer 20 can operate in a network connection 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, server, router, network PC, peer device, or other common network node, and typically includes many or all of the above-described elements associated with the personal computer 20, but with memory Only the storage device 50 is shown in FIG. The logical connections described in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

  When used in a LAN networking environment, the personal computer 20 is connected to the LAN 51 via a network interface or adapter 53. When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over a 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. In a network connection environment, the program modules shown for personal computer 20 or portions thereof may be stored on a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means can be used to establish a communications link between the computers.

  As illustrated in the block diagram of FIG. 2, the computer system 200 broadly includes a hardware component 202, a hardware / software interface system component 204, and an application program component 206 (here, context sensitive). And can be divided into three component groups (also referred to as “user components” or “software components”).

  In various embodiments of the computer system 200, referring again to FIG. 1, the hardware components 202 include a central processing unit (CPU) 21, memory (both ROM 24 and RAM 25), basic input / output system (BIOS). 26, and various input / output (I / O) devices such as a keyboard 40, mouse 42, monitor 47, and / or printer (not shown), among others. Hardware component 202 comprises the basic physical infrastructure for computer system 200.

  Application program component 206 comprises various software programs, including but not limited to compilers, database systems, word processors, business programs, video games, and the like. The application program comprises means for solving problems for various users (machines, other computer systems, and / or end users), providing solutions, and utilizing computer resources to process the data.

  The hardware / software interface system component 204 itself comprises an operating system that includes, in most cases, a shell and a kernel (and can be configured with only such an operating system in some embodiments). 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 further include a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or functional equivalent thereof, or Other such software components may also be included in place of or in addition to the operating system in the computer system. The purpose of the hardware / software interface system is to prepare an environment in which a user can execute an application program. The goal of a hardware / software interface system is not only to make the computer system easier to use, but also to make the computer hardware available in an efficient manner.

  The hardware / software interface system is generally loaded into the computer system at startup and thereafter manages all application programs in the computer system. Application programs interact with the hardware / software interface system by requesting services via an application program interface (API). In some application programs, end users can interact with a hardware / software interface system via a user interface, such as a command language or a graphical user interface (GUI).

  A hardware / software interface system conventionally executes various services for an application. In a multitasking hardware / software interface system in which multiple programs can be executed simultaneously, the hardware / software interface system executes which application in what order, and how much before switching to the next application for each application. Decide what time you should allow. The hardware / software interface system further manages the sharing of internal memory among multiple applications, and further inputs to and outputs from connected hardware devices such as hard disks, printers, and dialup ports. To process. The hardware / software interface system further sends a message regarding the status of the operation and any errors that may have occurred to the respective application (and possibly the end user). The hardware / software interface system may also remove the burden of managing batch jobs (eg, printing) and allow the initiating application to be freed from such work and resume other processing and / or operations. it can. In a computer having a parallel processing function, the hardware / software interface system further manages a shell of the hardware / software interface system that manages that the program is divided and executed on a plurality of processors at once. (Referred to herein simply as a “shell”) is an interactive end-user interface with a hardware / software interface system. (A shell is also called a “command interpreter” or, in the operating system, an “operating system shell.”) A shell is a hardware / software interface system that is directly accessible by application programs and / or end users. Is the outer layer. In contrast to the shell, the kernel is the innermost layer of the hardware / software interface system that interacts directly with the hardware components.

  Although many embodiments of the present invention may be particularly well suited for computerized systems, it is not intended herein to limit the invention to such embodiments in any way. Rather, as used herein, the term “computer system” can store and process information and / or use the stored information to perform the behavior or execution of the device itself. It is intended to encompass any and all devices that can be controlled regardless of whether such devices are electronic devices, mechanical devices, logical devices, virtual devices in nature. Yes.

B. Traditional File-Based Storage In most modern computer systems, a “file” is a storable unit of information that can include not only hardware / software interface systems, but also application programs, data sets, and the like. In all modern hardware / software interface systems (Windows (R), Unix (R), Linux, Mac OS, virtual machine systems, etc.), files are information that can be manipulated by the hardware / software interface system A fundamentally discrete (storable and retrievable) unit of data (eg, data, program, etc.). A group of files is generally organized in units of “folders”. Microsoft Windows (R), Macintosh OS, and other hardware / software interface systems, folders are collections of files that can be retrieved, moved, and manipulated by some other means as a single information unit. . These folders are then organized in a tree-based hierarchical management called “directories” (detailed below). In some other hardware / interface systems such as DOS, z / OS, and most Unix-based operating systems, the terms “directory” and / or “folder” may be used interchangeably. Yes, and previous Apple computer systems (eg, Apple IIe) used the term “catalog” instead of directory, but as used herein, all of these terms are synonymous And is intended to include all other equivalent terms and references to the hierarchical information storage structure and its folder and file components.

  Conventionally, directories (also known as folder directors) have a tree-based hierarchical structure, files are grouped into a plurality of folders, and the folders are further arranged according to relative node positions including the directory tree. For example, as illustrated in FIG. 2A, a base folder (or “root directory”) 212 of a DOS-based file system may include a plurality of folders 214, each folder further including an additional folder ( 216) (as “subfolders” of that particular folder), each of which can further include an additional folder 218, and so on, and so on. Each of these folders can hold one or more files 220, but at the hardware / software interface system level, individual files within a folder have nothing in common except for their location in the tree hierarchy. . This approach of organizing files into folder hierarchies indirectly involves the physical organization of standard storage media (eg, hard disks, floppy disks, CD-ROMs, etc.) used to store those files. It is not surprising to reflect it.

  In addition to the above, each folder is a container for its subfolders and its files--that is, each folder owns its subfolders and files. For example, when a folder is deleted by the hardware / software interface system, the subfolders and files of the folder are also deleted (in the case of each subfolder, its own subfolders and files are recursively included). Similarly, each file is generally owned by only one folder, the file is copied, and the copy can be placed in a different folder, but the copy of the file itself is directly Different units that are not related to each other (eg, changes to the original file are not reflected in the copy file at the hardware / software interface system level). In this regard, therefore, files and folders are “physical” in nature, but folders are treated like physical containers, and files are discrete and separate physical within those containers. This is because it is treated as a specific element.

II. WINFS Storage Platform for Organizing, Retrieving, and Sharing Data The present invention is combined with related inventions incorporated by reference as described earlier in this specification to organize, retrieve, and It is intended for storage platforms for sharing. The storage platform of the present invention extends and extends the concept of data storage beyond existing file systems and database systems of the type described above, for all types of data, including a new form of data called Items. Designed to be a store.

A. Terms As used herein and in the claims, the following terms have the following meanings.
“Item”, unlike a simple file, is a hardware / software object that has a basic set of properties that are generally supported across all objects exposed to the end user by the hardware / software interface system shell A unit of storable information that can access the interface system. Items also have properties and relationships that are generally supported across all Item types, including the ability to introduce new properties and relationships (detailed later in this document).
An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. Most operating systems include a shell and a kernel.
A “hardware / software interface system” is software, or a combination of hardware and software, used as an interface between a computer system running on a computer system and the underlying hardware components of an application. A hardware / software interface system typically comprises an operating system (in some embodiments, it consists only of an operating system). The hardware / software interface system further includes a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or functional equivalent thereof, or a computer system. Other such software components can also be included in place of or in addition to the internal operating system. The purpose of the hardware / software interface system is to prepare an environment in which a user can execute an application program. The goal of a hardware / software interface system is not only to make the computer system easier to use, but also to make the computer hardware available in an efficient manner.

B. Storage Platform Overview Referring to FIG. 3, the storage platform 300 includes a data store 302 implemented on a database engine 314. In one embodiment, the database engine includes a relational database engine with object-relational extensions. In one embodiment, the relational database engine 314 includes a Microsoft SQL Server relational database engine. The data store 302 implements a data model 304 that supports data organization, retrieval, sharing, synchronization, and security. Certain types of data are described in a schema, such as schema 340, and storage platform 300 includes tools 346 for expanding and extending those schemas, as described in detail below.

  A change tracking mechanism 306 implemented within the data store 302 provides the ability to track changes to the data store. The data store 302 further includes a security function 308 and an upgrade / demotion function 310, both described in detail below. The data store 302 further includes a set of application programming interfaces 312 to transfer the functions of the data store 302 to other storage platform components and application programs that utilize the storage platform (eg, application programs 350a, 350b, and 350c). Publish. The storage platform of the present invention further provides an application programming interface (API) that allows application programs such as application programs 350a, 350b, and 350c to access all of the aforementioned functions of the storage platform and access data described in the schema. 322. The storage platform API 322 can be used in combination with other APIs such as OLE DB API 324 and Microsoft Windows (registered trademark) Win32 API 326, depending on the application program.

  The storage platform 300 of the present invention can provide various services 328 to application programs, including a synchronization processing service 330 that facilitates sharing of data between users or systems. For example, the synchronization processing service 330 may allow interoperability with other data stores having the same format as the data store 302 as well as access to data stores 342 having other formats. The storage platform 300 further includes a file system function that enables interoperation between the data store 302 and an existing file system such as the Windows (registered trademark) NTFS file system 318. In at least some embodiments, the storage platform 320 may also add additional functionality to the application programming to allow manipulation of data and to interact with other systems. These functions can be implemented not only in the form of an additional service 328 such as the Info Agent service 334 and the notification service 332 but also in the form of other utilities 336.

  In at least some embodiments, the storage platform is embodied in, or forms an integral part of, the hardware / software interface system of the computer system. For example, without limitation, the storage platform of the present invention can be an operating system, a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, or a Java virtual machine (JVM) or its It can be embodied in or equivalent to form a functional equivalent. The storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses through a common storage infrastructure and schematized data. This not only makes the functionality specific to the data model available, but also encompasses existing file systems and database access methods and provides a rich and rich programming surface area.

  In the following description and in the various figures, the storage platform 300 of the present invention may be referred to as “WinFS”. However, using this name to refer to the storage platform is for convenience of explanation only and is not intended to be limiting in any way.

C. Data Model The data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data located within the store. In the data model of the present invention, “Item” is a basic unit of storage information. This data model, described in detail below, provides a mechanism for declaring Items and Item extensions, establishing relationships between Items, and organizing Items within Item Folders and Categories.

  The data model relies on two primitive mechanisms: Types and Relationships. Types is a structure that defines a form that controls the form of an instance of Type. The format is represented as an ordered set of Properties. Property is a name for a given Type value or set of values. For example, the USPostAddress type can have properties Street, City, Zip, and State, where Street, City, and State are types String, and Zip is Type Int32. Since the address can have a plurality of values for the Street property, the Street can be multi-valued (that is, a set of values). The system defines several primitive types that can be used in other types of configurations-these include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal, and GUID. Including. Type Properties can be defined using any of the primitive types or any of the constructed types (although there are some constraints below). For example, a Location Type having Properties Coordinate and Address can be defined, but the Address Property is Type USPostAddress as described above. Properties can also be required or optional.

  Relationships are declared and can represent a mapping between a set of instances of two types. For example, a Relationship between a Person Type and a Location Type called LivesAt that defines which people live in which place can be declared. A Relationship has one name, two endpoints, a source endpoint and a target endpoint. Relationships can also have an ordered set of properties. Both the Source and Target endpoints have Name and Type. For example, Lives At Relationship has a Source called Occupant of Type Person and a Target called Dwelling of Type Location, and also has properties StartDate and EndDate that indicate how long the resident has lived in the residence. Person may have lived in multiple residences over a long period of time, and there may be multiple inhabitants in the residence, so the relationship itself is most likely to contain StartDate and EndDate information. Please note that.

  Relationships defines a mapping between instances that is constrained by a given type as an endpoint type. For example, the LivesAt relationship cannot be a relationship in which Automobile is an Occupant because Automobile is not a Person.

  The data model allows the definition of child type-parent type relationships between types. A child-to-parent relationship, also called a BaseType relationship, is defined such that if Type A is a BaseType for Type B, then all instances of B must also be instances of A. Another way of expressing this is that every instance that matches B must also match A. For example, if A has the Type Name property Name, but B has the Type Int16 property Age, then all instances of B must have both Name and Age. A type hierarchy can be thought of as a tree with a single parent type at the root. A branch from the root defines a first-level child type, a branch at this level defines a second-level child type, and so on, and so on to the leftmost child type that does not have a child type in itself. The tree is not constrained to have a uniform depth, but cannot contain cycles. A given Type can have zero or more child types and zero or one parent type. A given instance can match at most one type with its type's parent type. In other words, for an instance given at any level in the tree, that instance can fit at most one child type at that level. A type is called Abstract if an instance of the type must also be an instance of a child type of the type.

1. Items
An Item, unlike a simple file, is a unit of storable information that is an object with a basic set of properties that are generally supported across all objects exposed to end users or application programs by the storage platform. Items also have properties and relationships that are generally supported across all Item types, including the ability to introduce new properties and relationships, as described below.

  Items are objects for common operations such as copy, delete, move, open, print, backup, restore, and copy. Items are units that can be stored and retrieved, and all forms of storable information manipulated by the storage platform exist as Items, Items properties, or Relationships between Items, each of which is described below. Is done.

Items are intended to represent units of data that are easily understood in the real world, such as Contacts, People, Services, Locations, Documents (any kind). FIG. 5A is a block diagram illustrating the structure of an Item. The unqualified name of Item is “Location”. The qualified name of Item is “Core.Location”, which indicates that this Item structure is defined as a specific type of Item in Core Schema. (The Core Schema is described in detail later in this document.)
The Location Item has multiple properties including EAddresses, MetropolitanRegion, Neighborhood, and PostalAddresses. The specific type of property for each is shown immediately after the property name and separated from the property name by a colon (":"). To the right of the type name is the number of values allowed for that property type, which is shown between square brackets ("[]") and is placed to the right of the colon (":") with an asterisk (" ^* ") Indicates an unspecified and / or unlimited number (" many "). A “1” to the right of the colon indicates that there can be at most one value. A zero ("0") to the left of the colon indicates that the property is optional (no value is possible). A “1” to the left of the colon indicates that there must be at least one value (the property is mandatory). Neighborhood and MetropolitanRegion are both the type “nvarchar” (or equivalent type), which is a predefined data type or “simple type” (also represented by not capitalization herein). However, EAddresses and PostAddresses are properties of predefined types or “composite types” (represented herein in capital letters) of types EAddress and PostAddress, respectively. A complex type is a type derived from one or more simple data types and / or other complex types. Complex types for Item properties also constitute “nested elements” because the details of the complex type are nested within the Immediate Item to define the property, and the information related to those complex types is: Retained with Items with those properties (within the boundaries of the Item, as described later in this specification). These concepts of typing are well known and readily understood by those skilled in the art.

  FIG. 5B is a block diagram illustrating the composite property types PostAddress and EAddress. The PostalAddress property type can be expected to have an Item of property type PostAddress having 0 or 1 City value, 0 or 1 CountryCode value, 0 or 1 MailStop value, and any number (0 to many) of PostalAddressTypes, etc. Define as a thing. In this way, the shape of the data for a particular property in the Item is thereby defined. The EAddress property type is similarly defined as shown. Although used optionally in this Application, another way to represent a complex type in a Location Item is to render the Item with the individual properties of the complex type listed there. FIG. 5C is a block diagram illustrating a Location Item in which the composite type is further described. However, it should be understood that this alternative representation of Location Item in FIG. 5C is for the exact same Item illustrated in FIG. 5A. The storage platform of the present invention can also be subtyped so that one property type can be a child type of the other (where one property type is a property of the other parent property type). Is inherited).

  Items, similar to but different from properties and their property types, essentially represent self-Item Types that can also be subtyped. That is, in the storage platform in some embodiments of the present invention, an Item can be a child of another Item (so that one Item inherits the properties of the other parent Item). . Further, for the various embodiments of the present invention, all Items are children of the “Item” Item type, which is the first basic Item type found in the Base Schema. (The Base Schema is further described in detail later in this specification.) FIG. 6A illustrates the Item, that is, the Location Item of this Instance as a child of the Item Item type in the Base Schema. Yes. In this figure, the arrows indicate that Location Items (like all other Items) are child types of Item Item type. The Item Item type has many important properties such as ItemId and various timestamps as the underlying Item from which all other Items are derived, thereby defining the standard properties for all Items in the operating system. To do. In this figure, these properties of type Item Item are inherited by Location and thereby become Location properties.

  Another way to represent a property in a Location Item inherited from the Item Item type is to draw the Location with the individual properties of each property type from the parent Item listed there. FIG. 6B is a block diagram illustrating a Location Item in which an inheritance type is described in addition to an immediate property. This Item is the same Item illustrated in FIG. 5A, but in this figure, Location is illustrated with all of its properties, both are immediate—shown in both this figure and FIG. 5A. Note that it is inherited--shown in this figure, but not shown in FIG. 5A--but in FIG. 5A, Location is a child type of Item Item type. (These properties are referenced by showing them with arrows.)

  Items are stand-alone objects, so deleting an Item deletes all its immediate and inherited properties. Similarly, what is received when an Item is retrieved is the Item and all of its immediate and inherited properties (including information related to complex property types). In some embodiments of the invention, it is possible to request a subset of properties when retrieving a particular Item, but as a default for many such embodiments, immediate and inherited properties when retrieved All of the above are supplied to Item. In addition, Items properties can be extended by adding new properties to existing properties of the Item type. These “extensions” are hereafter the real properties of the Item, and its Item child types can automatically include extended properties.

The “boundary” of an Item is represented by its properties (including complex property types, extensions, etc.). Item boundaries also represent the limits of operations performed on Items such as copy, delete, move, and create. For example, in some embodiments of the present invention, when an Item is copied, everything within that Item's boundary is also copied. For each Item, the boundary includes:
If the Item Type and Item of the Item are child types of other Items (as in some embodiments of the invention where all Items are derived from a single Item and Item Type in the Base Schema), Any applicable child type information (ie, information related to the parent Item Type). If the original Item of the copy source is a child type of another Item, the copy can also be a child type of the same Item.
• Item complex types and extensions, if any. If the original Item has a complex type property (native or extended), its copy can also have the same complex type.
Item records relating to “ownership”, that is, the own list of Items of other Items (“Target Items”) owned by this Item (“Owning Items”). This is particularly relevant with respect to Item Folders, which will be described in detail below, and the rules provide that all Items must belong to at least one Item Folder. Further, with respect to embedded items—as described in more detail below—embedded items are considered part of an item that is embedded for operations such as copy, delete, etc.

2. Item Identification Items are uniquely identified within a global items space with ItemID. Base. The Item type defines a field of type GUID that stores an Item ID. An Item must have exactly one ID in the data store 302.

  An item reference is a data structure that stores information for identifying and identifying an Item. In the data model, an abstract type is defined as having the name ItemReference from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves ItemReference and returns Item. This method is overridden by a concrete child type of ItemReference that implements a function that retrieves the Item being referenced. The Resolve method is invoked as part of the storage platform API 322.

  ItemIDReference is a child type of ItemReference. This defines the Locator and ItemID fields. In the Locator field, the item area is named (that is, identified). This is handled by a locator resolution method that can resolve the value of the Locator into an item area. The ItemID field is a type ItemID.

  ItemPathReference is a specialization of ItemReference that defines Locator and Path fields. The Locator field identifies the item area. This is handled by a locator resolution method that can resolve the value of the Locator into an item area. The Path field contains a (relative) path in the storage platform namespace rooted at the item area given by the Locator.

  This type of reference cannot be used in a set operation. References must generally be resolved through a path resolution process. The Resolve method of the storage platform API 322 has this function.

  The above reference form is represented through the reference type hierarchy illustrated in FIG. Additional reference types that inherit from these types can be defined in the schema. They can be used in relationship declarations as target field types.

3. Item Folders and Categories
As will be described in detail below, a group of Items can be organized into special Items called Item Folders (not to be confused with file folders). However, unlike most file systems, an Item can belong to multiple Item Folders, so if an Item is accessed and revised in one Item Folder, this revised Item will be in the other Item folder. Can be accessed directly from. In essence, access to an Item can originate from different Item Folders, but what is actually accessed is in fact the exact same Item. However, Item Folder does not necessarily own all of its member Items, or can simply co-own Items with other folders, and deleting Item Folder will result in the deletion of Item as well. Not necessarily done. However, in some embodiments of the present invention, an Item must belong to at least one Item Folder, and thus when an individual Item Folder for a particular Item is deleted, in one embodiment, the Item Is automatically deleted, or in other embodiments, the Item is automatically deleted by default Item Folder (eg, a “similar name folder” with a similar name folder used in various file-folder based systems). Member of “Trash Can” Item Folder).

  Also, as will be described in detail below, Items may further be defined as: (a) Item Type (or Types), (b) a specific immediate or inherited property (or properties), or (c) a specific Item property It may belong to Categories based on common described characteristics such as value (or values). For example, an Item containing a specific property of personal contact information may automatically belong to the Contact Category, and then an Item containing contact information property will automatically belong to this Category as well. Similarly, an Item in which a location property having a value “New York City” is set can automatically belong to the New York City Category.

  A Category can contain Items that are not related to each other (ie, no common described properties), but a Category Item can be a common type, property, or value described for that Category. It is conceptually different from Item Folders in that this commonality has ("commonality") and forms the basis for relationships between other Items in the Category. Further, although an Item's membership to a particular Folder is not mandatory based on that Item's particular aspect, in some embodiments, all Items whose commonality is related to Category for a category are: It is possible to become a Category member automatically at the hardware / software interface system level. Conceptually, Categories can be thought of as virtual Item Folders (as defined in the background of the database) whose attribution is based on the results of a particular query, and can also be defined in this query (defined by Category commonality). An Item that satisfies the condition will include a Category membership.

  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. There are also Items belonging to multiple Item Folders, for example Item 402 belongs to Item Folders 422 and 424. Some Items, eg, Items 402, 404, 406, 408, 410, and 412 are also members of one or more Categories 432, 434, and 436, but at other times, for example, Items 414, 416 418 and 420 cannot belong to any Category (but this is rarely possible in some embodiments where property ownership automatically implies attribution to Category, and Item In order not to be a member of a category in, it would have to be completely featureless). In contrast to the folder hierarchy, both Categories and Item Folders are more similar to directed graphs as shown in the figure. In any case, Items, Item Folders, and Categories are all Items (although they are different Item Types).

  In contrast to files, folders, and directories, Items, Items Folders, and Categories of the present invention have no concept equivalent to physical containers, and thus Items may exist in such multiple locations. Therefore, it has essentially no “physical” characteristics. Along with the ability for Items to exist in multiple Item Folder locations and organized into Categories, the capabilities of data manipulation and storage structures are enhanced and enriched at the hardware / software interface level beyond the level currently available in the art. It has become.

4). Schema
a) Base Schema
In order to provide a universal foundation for the creation and use of Items, various embodiments of the storage platform of the present invention comprise Base Schema that establishes a conceptual framework for use in creating and organizing Items and properties. Base Schema defines some special types of Items and properties, and the characteristics of these special base types from which child types can be further derived. By using this Base Schema, programmers can conceptually distinguish Items (and their respective types) from properties (and their respective types). Furthermore, in Base Schema, the properties that all Items can possess when all Items (and their corresponding Item Types) are derived from this underlying Item (and its corresponding Item Type) in Base Schema. Define the basic set.

  As illustrated in FIG. 7, and for some embodiments of the present invention, Base Schema defines three top-level types: Item, Extension, and PropertyBase. As shown, the Item type is defined by the properties of this basic “Item” Item type. In contrast, the top-level property type “PropertyBase” has no defined properties and is just an anchor when all derived property types are related to each other, from which all other property types are derived. Only (usually derived from a single property type). The Extension type property defines which items are extended by an extension when an Item can have multiple extensions, and also defines an identification to distinguish one extension from the other. .

  ItemFolder is an Item Item type child that features a Relationship that establishes a link to the member (if any) in addition to the properties inherited from Item, but both IdentityKey and Property are children of PropertyBase. It is a type. Then, CategoryRef is a child type of IdentityKey.

b) Core Schema
Various embodiments of the present invention further include Core Schema, which provides a conceptual framework for top-level Items-type structures. FIG. 8A is a block diagram illustrating an Item in the Core Schema, and FIG. 8B is a block diagram illustrating a property type in the Core Schema. The distinction between files with different extensions ( ^* .com, ^* .exe, ^* .bat, ^* .sys, etc.) and files with such other criteria in file-folder based systems is a function of Core Schema. Is similar. Core Schema is an Item-based hardware / software interface system that understands all Items, either directly (by Item type) or indirectly (by Item child type), by an Item-based hardware / software interface system And define a set of core Item types that characterize one or more Core Schema Item types that can be processed in a predetermined and predictable manner. Predefined Item types reflect the most common Items within an Item-based hardware / software interface system, and thus a certain level of efficiency is Item-based hardware that recognizes pre-defined Item types, including Core Schema. / Obtained by software interface system.

  In some embodiments, the Core Schema is not extensible—that is, subtype the additional Item types directly from the Base Schema Item types, except for certain predefined derived Item types that are part of the Core Schema. I can't. Since all subsequent Item types are necessarily child types of the Core Schema Item type, by prohibiting extensions to the Core Schema (ie, prohibiting adding new Items to the Core Schema), the storage platform Indicates the use of the Core Schema Item type. This structure also increases the degree of freedom to define additional Items while maintaining the advantage of having a predefined set of core Item types.

For various embodiments of the present invention, and referring to FIG. 8A, certain Item types supported by Core Schema can include one or more of the following.
Category: Items of this Item Type (and child types derived from it) represent valid Categories of the Item-based hardware / software interface system.
• Commodities: Items that are valuable and identifiable.
Devices: Items with a logical structure that supports information processing functions.
Documents: Items with content that is not interpreted by the Item-based hardware / software interface system, but instead is interpreted by an application program that corresponds to the document type.
Events: Items that record any events that occur in the environment.
Locations: Items that represent physical locations (eg, geographical location).
Messages: Items for communication between two or more principals (defined below).
• Principles: Items that have at least one definable ID as well as ItemID (eg, identification of people, organizations, groups, households, institutions, services, etc.).
Statements: Items with special information about the environment, including but not limited to policies, subscriptions, credits, etc.

Similarly, referring to FIG. 8B, certain property types supported by Core Schema may include one or more of the following.
Certificates (derived from the underlying PropertyBase type in Base Schema)
・ Principal Identity Keys (derived from IdentityKey type in Base Schema)
-Post Address (derived from Property type in Base Schema)
・ Rich Text (derived from Property type in Base Schema)
・ EAddress (derived from Property type in Base Schema)
・ IdentitySecurityPackage (derived from Relationship type in Base Schema)
-RoleOccupancy (Derived from Relationship type in Base Schema)
-BasicPresence (derived from the Relationship type in Base Schema)

  These Items and Properties are further described by their respective properties described in FIGS. 8A and 8B.

5). Relationships Relationships are binary relationships in which one Item is specified as a source and the other Item is specified as a target. The source Item and the target Item are related by this relationship. The source Item generally controls the lifetime of the relationship. That is, the source Item is deleted, and the relationship between those Items is also deleted.

  Relationships are classified into an inclusion relationship Containment and a reference relationship Reference. The containment relationship controls the duration of the target Items, but the reference relationship has no meaning for surviving organization management. FIG. 12 illustrates how the relationships are classified.

  The Containment relationship type is further classified into a holding relationship Holding and an embedding relationship Embedding. When all retention relationships for an Item are deleted, the Item is also deleted. The retention relationship uses a reference counting mechanism to control the lifetime of the target. Using an embedded relationship allows modeling of complex Items, which can be considered an exclusive holding relationship. An Item can be the target of one or more retention relationships, while an Item can be the target of exactly one embedding relationship. An Item that is an embedding target cannot be another retention or embedding target.

  The reference relationship does not control the lifetime of the target Item. These may be dangling—the target Item may not exist. Reference relationships can be used to model references to Items anywhere in the global Item namespace (ie, including remote data stores).

  When an Item is fetched, the relationship is not automatically fetched. The application must explicitly request Item relationships. Furthermore, modifying the relationship does not modify the source or target Item, and similarly, adding a relationship does not affect the source / target Item.

a) Declaration of relationship The explicit relationship type is defined by the following elements.
-The relation name is specified by the Name attribute.
-One of Holding, Embedding, Reference as the relation type. This is specified by the Type attribute.
• Source and target endpoints. At each end point, specify the name and type of the referenced Item.
The source endpoint field is typically of type ItemID (not declared) and must refer to an Item in the same data store as the relationship instance.
For a Holding and Embedding relationship, the target endpoint field must be of type ItemIDReference and must reference an Item in the same store as the relationship instance. For the Reference relationship, the target endpoint may be of any ItemReference type and can reference Items in the data store of other storage platforms.
• Optionally, you can declare one or more fields of type scalar or propertybase. These fields can store data associated with the relationship.
• Relationship instances are stored in a global relationship table.
• All relationship instances are uniquely identified by the combination (source ItemID, relationship ID). The relationship ID is unique within a given source ItemID for all relationships sourced from the given Item regardless of its type.

  The source Item is the owner of the relationship. The Item designated as the owner controls the lifetime of the relationship, but the relationship itself is separate from the Items to which it is related. The storage platform API 322 provides a mechanism for publishing relationships associated with Items.

  An example of a relationship declaration is shown below.

  This is an example of a Reference relationship. This relationship cannot be created if there is no Item of the person referenced by the source reference. Furthermore, when a person's Item is deleted, the relationship instance between the person and the organization is deleted. However, when the Organization Item is deleted, the relationship is not deleted, and it becomes dangling.

b) Retention relationship The retention relationship is used to model the reference count-based lifetime management of the target Item.

  Item can be a source endpoint for zero or more relationships with Items. An Item that is not an embedded Item can be a target in one or more retention relationships.

  The target endpoint reference type must be ItemIDReference and must reference an Item in the same store as the relationship instance.

  The retention relationship enforces lifetime management of the target endpoint. Creating a retention relationship instance and the Item it is targeting is an atomic operation. It is possible to create an additional holding relationship instance that targets the same Item. When the last holding relationship instance having the given Item as the target end point is deleted, the target Item is also deleted.

  The type of endpoint Item specified in the relationship declaration is generally enforced when the relationship instance is created. After the relationship is established, the type of the endpoint Item cannot be changed.

  Retention relationships play an important role in forming the Item namespace. These include a “Name” property that defines the name of the target Item relative to the source Item. This relative name is unique for all retention relationships originating from a given Item. This ordered list of relative names starting from the root Item and leading to the given Item forms the complete name for the Item.

  The holding relationship forms an acyclic directed graph (DAG). When a retention relationship is created, the system ensures that no cycles are created, so the Item namespace always forms a DAG.

  The retention relationship controls the duration of the target Item, but does not control the operational consistency of the target endpoint Item. A target Item is independent of operation from the Item that owns it through a holding relationship. Copy, Move, Backup, and other operations on an item that is the source of a retention relationship will not affect the item that is the target of the same relationship-for example, if you back up a Folder Item, all Items will be foldered (FolderMember-related target) is not automatically backed up.

  The following is an example of the retention relationship.

  The FolderMembers relationship enables the concept of Folder to be used as a generic collection of Items.

c) Embedding relationship The embedding relationship models the concept of exclusive control of the lifetime of the target Item. These validate the concept of complex items.

  The creation of an embedded relationship instance and the Item it is targeting is an atomic operation. Item can be zero or more embedded source. However, Item can be the only embedding target. An Item that is an embedding target cannot be a retention target.

  The target endpoint reference type must be ItemIDReference and must reference an Item in the same data store as the relationship instance.

  The type of endpoint Item specified in the relationship declaration is generally enforced when the relationship instance is created. After the relationship is established, the type of the endpoint Item cannot be changed.

  The embedding relationship controls the operation consistency of the target end point. For example, an operation that serializes an Item can include all the serializations of its target as well as all embedding relationships originating from that Item, and also copies all its embedded Items that copy the Item.

  The following is an example declaration:

d) Reference relationship The reference relationship does not control the lifetime of the referenced Item. Furthermore, a reference relationship does not guarantee the existence of the target, nor does it guarantee the target type as specified in the relationship declaration. This means that the reference relationship can become dangling. In addition, the reference relationship can refer to Items in another data store. A reference relationship can be considered as a concept similar to a link in a Web page.

  An example of a reference relationship declaration is shown below.

  A reference type can be used at the target endpoint. Items related to the reference relationship can be of any Item type.

  Reference relationships are used to model most non-lifetime management relationships between Items. The presence of the target is not enforced, and the reference relationship is convenient for modeling loosely coupled relationships. Reference relationships can be used to target Items in other data stores, including stores on other computers.

e) Rules and constraints The following additional rules and constraints apply for relationships.
Item must be the target of (exactly one embedding relationship) or (one or more holding relationships). One exception is the root item. Item can be the target of zero or more reference relationships.
-Items that are targets of embedding relationships cannot be the source of retention relationships. This can be the source of a reference relationship.
-If promoted from a file, it cannot be the source of a retention relationship. This can be the source of embedding and reference relationships.
-Items upgraded from files cannot be targeted for embedding.

f) Relationship Ordering In at least one embodiment, the storage platform of the present invention supports relationship ordering. Ordering is performed through a property named “Order” in the basic relational definition. There is no uniqueness constraint on the Order field. The order of relationships with the same “order” property value is not guaranteed, but it is guaranteed that they can be ordered after a relationship with a low “order” value and before a relationship with a high “order” field value.

  In the application, relationships can be acquired in a predetermined order by ordering combinations (SourceItemID, RelationshipID, Order). All relationship instances originating from a given Item are ordered as a single collection, regardless of the type of relationship within that collection. However, this ensures that all relationships of a given type (eg, FolderMembers) are an ordered subset of the relationship collection for a given Item.

The data store API 312 for manipulating relationships implements a set of operations that support ordering of relationships. The following terms are introduced as an aid to describing operations.
RelFirst is the first relationship in the ordered collection with the order value OrdFirst.
RelLast is the last relationship in the ordered collection with the order value OrdLast.
RelX is a given relationship in the collection with the order value OrdX.
RelPrev is the closest relationship to RelX in the collection where the order value OrdPrev is less than OrdX.
RelNext is the closest relationship to RelX in the collection, where the order value OrdNext is greater than OrdX.

These operations include, but are not limited to:
InsertBeforeFirst (SourceItemID, Relationship) inserts the relationship into the collection as the first relationship. The value of the “Order” property of the new relationship may be less than OrdFirst.
InsertAfterLast (SourceItemID, Relationship) inserts the relationship into the collection as the last relationship. The value of the “Order” property of the new relationship may be greater than OrdLast.
InsertAt (SourceItemID, ord, Relationship) inserts a relationship with the specified value for the “Order” property.
InsertBefore (SourceItemID, ord, Relationship) inserts a relationship before a relationship with a given order value. The new relationship can be assigned an “Order” value between, but not including, OrdPrev and ord.
InsertAfter (SourceItemID, ord, Relationship) inserts a relationship after a relationship with a given order value. The new relationship can be assigned an “Order” value between ord and OrdNext, but not including.
MoveBefore (SourceItemID, ord, RelationshipID) moves the relationship with the given relationship ID before the relationship with the specified “Order” value. This relationship can be assigned a new “Order” value between, but not including, OrdPrev and ord.
MoveAfter (SourceItemID, ord, RelationshipID) moves after the relationship with the specified “Order” value for the relationship with the given relationship ID. This relationship can be assigned a new order value between ord and OrdNext, but not including.

  As already mentioned, every Item must be a member of Item Folder. With respect to Relationships, every Item must have a relationship with Item Folder. In some embodiments of the invention, specific relationships are represented by Relationships that exist between Items.

  As implemented in various embodiments of the present invention, Relationship provides a directed binary relationship that is “extended” by one Item (source) to the other Item (target). A Relationship is owned by a source Item (an Item that extends it), and thus a Relationship is deleted when the source is deleted (eg, a Relationship is deleted when the source Item is deleted). In addition, in some instances, Relationships can share (jointly own) ownership of the target Item, and such ownership is reflected in the Relationship's IsOwned property (or its equivalent). Is possible (as shown for the Relationship property type in FIG. 7). In these embodiments, creating a new IsOwned Relationship will automatically increment the reference count of the target Item, and deleting such a Relationship will decrement the reference count of the target Item. In these particular embodiments, Items continue to exist if the reference count is greater than zero, and are automatically deleted when the count reaches zero. Also, Item Folder is an Item having (or can have) a set of Relationships with other Items, and these other Items include Item Folder attribute. Other actual implementations of Relationships are possible, and it is anticipated that the present invention will provide the functionality described herein.

  Regardless of the actual implementation, Relationship is a selectable connection from one object to the other. An Item-based structure can determine whether an Item can belong to multiple Item Folders, and can belong to one or more Categories, and whether these Items, Folders, and Categories are public but private Determined by the meaning given to being present (or not present). These logical Relationships are the meanings assigned to the set of Relationships that are specifically employed to implement the functions described herein, regardless of the physical implementation. Logical Relationships are established between an Item and its Item Folder (s) or Categories (and vice versa), because essentially Item Folders and Categories are each a special type of Item. It is. Thus, Item Folders and Categories can act in the same way as other Items—but not limited to, but can be copied, added to an email message, embedded in a document, etc., and Item Folders and Categories can receive In contrast, serialization and deserialization (import and export) can be performed using the same mechanism as for other Items. (For example, in XML, all Items can have a serialized format, which applies equally to Item Folders, Categories, and Items.)

  The aforementioned Relationships represent the relationship between an Item and its Item Folder (s), but can be logically extended from Item to Item Folder, from Item Folder to Item, or both. Relationship that logically extends from Item to Item Folder indicates that Item Folder is public to that Item and shares attribution information with that Item, but conversely, from Item to Item Folder logically The absence of Relationship indicates that the Item Folder is private to the Item and does not share attribution information with the Item. Similarly, a Relationship that logically extends from Item Folder to Item indicates that the Item is public and sharable to the Item Folder, but there is no logical Relationship from Item Folder to Item. The item is private and can be shared. So when an Item Folder is exported to another system, it is a “public” Item shared in a new context, and when an Item searches for other searchable Items within that Item Folders, it “Public” Item Folders that provide information about sharable Items belonging to it.

  FIG. 9 is a block diagram illustrating Item Folder (which is also Item itself), its Member Items, and the interconnection Relationships between Item Folder and its Member Items. The Item Folder 900 has a plurality of Items 902, 904, and 906 as members. Item Folder 900 is an Item 902 that is public and Item Folder 900, its members 904 and 906, and other Item Folders, Categories, or Items (not shown) that may access Item Folder 900. It has a Relationship 912 from itself to Item 902 indicating that it can be shared. However, there is no Relationship from Item 902 to Item Folder 900 indicating that Item Folder 900 is private to Item 902 and does not share attribution information with Item 902. On the other hand, Item 904 has a Relationship 924 from itself to Item Folder 900 indicating that Item Folder 900 is public and shares attribution information with Item 904. However, Item 904 is private and Item Folder 900, its other members 902 and 906, and other Item Folders, Categories, or Items that may access Item Folder 900 (not shown) There is no Relationship from Item Folder 900 to Item 904, which indicates that it cannot be shared. In contrast to its Relationships for Items 902 and 904 (or the absence thereof), Item Folder 900 has a Relationship 916 from itself to Item 906, and Item 906 has a Relationship 926 that returns to Item Folder 900. Together, Item 906 is public, Item Folder 900, its members 902 and 904, and other Item Folders, Categories, or Items that may access Item Folder 900 (not shown) ) And Item Folder 900 is public, and Item 906 and Indicating to share genus related information.

  As already explained, the Items in the Item Folder do not need to share commonality because the Item Folders are not “described”. On the other hand, Categories are described by a commonality common to all of its members Items. Thus, Category membership is inherently limited to Items with the described commonality, and in some embodiments, all Items that meet the Category description are automatically made members of Category. . Thus, in Item Folders, a trivial type structure can be represented by its membership, but in Categories, membership can be based on predefined commonality.

  Of course, the Category description is logical in nature, and thus the Category can be described by a logical representation of types, properties, and / or values. For example, the logical representation of Category may be that the attribution relationship including Items has one or both of two properties. If these described properties for Category are “A” and “B”, then Category attributions are Items with property A but without B, Items with property B but without A, and properties A and Items with both B can be included. This logical representation of the property is described by the logical operator “OR”, and the set of members described by the Category is an Item having the property A OR B. Those skilled in the art will recognize that similar logical operands (including but not limited to “AND”, “XOR”, and “NOT”, alone or in combination) can also be used to describe a category. You will understand.

  Despite the distinction between Item Folders (not described) and Categories (described), Categories Relationships vs. Items and Items Relationships vs. Categories are described herein for Item Folders and Items in many embodiments of the present invention. Is essentially the same as previously disclosed in the book.

  FIG. 10 is a block diagram illustrating Category (also Item itself), its Member Items, and the interconnection Relationships between Category and its Member Items. The Category 1000 has multiple Items 1002, 1004, and 1006 as members, all of which are any combination of common properties, values, or types 1008 as described by the Category 1000 (Commonness Description 1008 ') Share Category 1000 is shared to Item 1000, its folders 1004 and 1006, and other Categories, Item Folders, or Items (not shown) that may access Category 1000, as Item 1002 is public It has a Relationship 1012 from itself to Item 1002, indicating that it is possible. However, there is no Relationship from Item 1002 to Category 1000 indicating that Category 1000 is private to Item 1002 and does not share attribution information with Item 1002. On the other hand, Item 1004 has Relationship 1024 from itself to Category 1000 indicating that Category 1000 is public and shares attribution information with Item 1004. However, for Item 1004 is private and for Category 1000, its other members 1002 and 1006, and other Categories, Item Folders, or Items (not shown) that may access Category 1000 There is no Relationship from Category 1000 to Item 1004 indicating that it is not sharable. In contrast to its Relationships for Items 1002 and 1004 (or the absence of them), Category 1000 has a Relationship 1016 from itself to Item 1006, and Item 1006 has a Relationship 1026 back to Category 1000, which is In addition, Item 1006 is public and for Category 1000, its Item members 1002 and 1004, and other Categories, Item Folders, or Items (not shown) that may access Category 1000 Shareable and Category 1000 is public and Item 1006 and sharing attribution information.

  Finally, in some other embodiments, Categories and Item Folders are Items themselves, Items has a Relationship to each other, Categories have a Relationship to Item Folders and vice versa, and Categories Folds, Items Folds, And Items can have Relationships to other Categories, Item Folders, and Items, respectively. However, in various embodiments, the Item Folder structure and / or Category structure is approximated to include cycles at the hardware / software interface system level. The Item Folder and Category structures are similar to valid graphs, and the embodiment that prohibits cycles is a directed graph in which no path starts and ends at the same vertex, due to the mathematical definition of the field of graph theory. , Similar to acyclic directed graphs (DAGs).

6). Extensibility It is intended to give the storage platform an initial set of schemas 340 as described above. In addition, however, in at least some embodiments, the storage platform allows customers, including independent software vendors (ISVs), to create new schemas 344 (ie, new Item and Nested Element types). This section addresses the mechanism for creating such a schema by extending the Item and Nested Element types (or simply the “Element” type) defined in the initial set of schemas 340.

The expansion of the initial set of Item and Nested Element types is preferably constrained as follows.
ISV is a new Item type, that is, a child type Base. It is allowed to introduce Item.
ISV is a new nested element type, that is, a child type Base. It is allowed to introduce a nested element.
ISV is a new extension, ie child type Base. It is allowed to introduce a nested element. But,
ISVs cannot subtype types (Item, Nested Element, or Extension types) defined by an initial set 340 of storage platform schemas.

  Since the Item type or the Nested Element type defined by the initial set of storage platform schema may not exactly match the requirements of the ISV application, it is necessary to be able to customize the type on the ISV side. This is possible with the concept of Extensions. Extensions are strongly typed instances, but (a) they cannot exist independently and (b) must accompany an Item or a Necessary Element.

  In addition to meeting the need for schema extensibility, Extensions is also intended to solve the “multi-typing” problem. In some embodiments, the storage platform may not support multiple inheritance or duplicate types, so Extensions can be used as a way to model instances of duplicate types on the application side ( For example, Document is a legal document as well as a security document).

a) Item extension To perform Item extension, in the data model, Base. Define an abstract type named Extension. This is the root type for the extended type hierarchy. In the application, Base. Extensions can be subtyped to create specific extensions.

  Base. The Extension type is defined by Base schema as follows.

  The ItemID field contains the ItemID of the item with which the extension is associated. An Item with this ItemID must exist. An extension cannot be created if there is no item with a given ItemID. When an Item is deleted, all extensions with the same ItemID are deleted. A tuple (ItemID, ExtensionID) uniquely identifies an extension instance.

The extension type structure is similar to the item type.
-The extension type has a field.
A field can be a primitive or nested element type.
• Extended types can be subtyped.

The following constraints apply to extended types:
• Extensions cannot be the source and target of a relationship.
• Extended instances cannot exist independently of items.
-Extended types cannot be used as field types in storage platform type definitions.

  There are no restrictions on the type of extension associated with a given Item type. Any extension type can be used to extend the item type. When multiple extension instances are attached to an item, they are independent of each other in both structure and behavior.

  Extension instances are stored and accessed separately from the item. All extended type instances are accessible from the global extended view. Regardless of the type of the associated item, you can create an efficient query that returns all instances of a given extension type. The storage platform API provides a programming model that can store, retrieve, and modify extensions on items.

  Extended types can be subtyped using the storage platform's single inheritance model. Deriving from an extension type creates a new extension type. An extension structure or behavior cannot override or replace an item type hierarchy structure or behavior. Similar to the Item type, the Extension type instance can be accessed directly through the view associated with the extension type. The extension's ItemID indicates which item it belongs to and can be used to retrieve the corresponding Item object from the global Item view. Extensions are considered part of an item for the purpose of behavioral consistency. Copy / Move, Backup / Restore, and other common operations defined by the storage platform can operate on extensions as part of that item.

  Consider the following example: The Contact type is defined by the Windows (registered trademark) Type setting.

  CRM application developers want to attach CRM application extensions to contacts stored in the storage platform. Application developers define CRM extensions that contain additional data structures that can be manipulated on the application side.

  The HR application developer also wants to attach additional data to the Contact. This data is independent of the CRM application data. Again, this application developer can create an extension.

  CRMExtension and HRExtension are two independent extensions that can be attached to a Contact item. These are created and accessed independently of each other.

  In the above example, CRMExtension type fields and methods cannot override fields or methods in the Contact hierarchy. An instance of the CRMExtension type can be associated with an Item type other than Contact.

  When a Contact item is retrieved, the item extension is not automatically retrieved. Given a Contact item, the associated item extension can be accessed by querying the global extended view of the extension with the same ItemId.

  All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of which item they belong to. All item extensions for an item share the same item id. In the above example, the Contact item instance and the accompanying CRMExtension and HRExtension instantiate the same ItemID.

  The following table summarizes similarities and differences between Item, Extension, and NestedElement types.

b) Extension of the NestedElement type The NestedElement type is not extended by the same mechanism as the Item type. Nested element extensions are stored and accessed by the same mechanism as nested element type fields.

  The data model defines a root for a nested element type named Element.

  The NecessaryElement type inherits from this type. The NestedElement element type further defines a field that is a multiple set of Elements.

The nested element extension differs from the item extension in the following points.
-Nested element extensions are not extension types. They are based on Base. It does not belong to the extended type hierarchy whose root is the Extension type.
Nested element extensions are stored with the other fields of the item and are not globally accessible—you cannot create a query that retrieves all instances of a given extension type.
These extensions are stored in the same way that other nested elements (items) are stored. Like other nested sets, NestedElement extensions are stored in the UDT. These are accessible through the Extensions field of the nested element type.
The collection interface used to access multi-valued properties is also used to access and iterate over a set of type extensions.

  The following table is a summary and comparison of Item Extensions and NestedElement extensions.

D. Database Engine As described above, the data store is implemented on the database engine. In the present invention, the database engine includes a relational database engine that implements an SQL query language, such as Microsoft SQL Server, along with object-relational extensions. This section describes the mapping of the data model that the data store implements to the relational store, and also provides information about the logical API consumed by the storage platform client according to the present invention. However, it is understood that different mappings can be employed when different database engines are used. Indeed, in addition to implementing the storage platform conceptual data model on a relational database engine, it can also be implemented on other types of databases, such as object-oriented and XML databases.

  An object oriented (OO) database system provides persistence and transactions for programming language objects (eg, C ++, Java). The concept of “items” in the storage platform maps well to “Objects” in object-oriented systems, but embedded collections will have to be added to Objects. Other storage platform type concepts, such as inherited and nested element types, also map object-oriented systems. Object-oriented systems typically already support object identification, so item identification can be mapped to object identification. Item behaviors (operations) map nicely to object methods. However, object-oriented systems usually lack organizational functions and have poor search capabilities. Also, object oriented systems do not support unstructured and semi-structured data. To support the full storage platform data model described herein, concepts such as relationships, folders, and extensions will need to be added to the object data model. In addition, mechanisms such as upgrades, synchronization, notifications, and security will also need to be implemented.

  Similar to object-oriented systems, XML databases are based on XSD (XML Schema Definition) and support a single inheritance based type system. The item type system of the present invention can also be mapped to an XSD type model. XSD also does not support behaviors. The XSD for an item will have to be augmented by an item behavior. An XML database handles a single XSD document and lacks organization and extensive search capabilities. As with object-oriented databases, other concepts such as relationships and folders need to be incorporated into such XML databases to support the data model described herein, Mechanisms such as notifications and security also need to be implemented.

  With respect to the following subsections, several diagrams have been prepared to facilitate use of the disclosed general information, and FIG. 13 is a block diagram illustrating a notification mechanism. FIG. 14 is a diagram illustrating an embodiment in which two transactions both insert a new record into the same B-Tree. FIG. 15 is a diagram illustrating a data change detection process. FIG. 16 shows an example of a directory tree. FIG. 17 is a diagram illustrating an example in which an existing folder in a directory-based file system is moved to the data store of the storage platform.

1. Implementing a Data Store Using UDT In an embodiment of the invention, the relational database engine 314, which in one embodiment includes the Microsoft SQL Server engine, supports a built-in scalar type. Built-in scalar types are “native” and “simple”. They are native in that users cannot define their own types and are simple in that they cannot encapsulate composite structures. User-defined types (hereafter UDT) are for type extensibility on and beyond the native scalar type system by allowing users to extend the type system by defining complex structured types. Prepare the mechanism. Once the UDT has been defined by the user, it can be used anywhere the built-in scalar type can be used in the type system.

  According to one aspect of the invention, the storage platform schema is mapped to a UDT class in the database engine store. The data store Items is based on Base. Maps to a UDT class derived from the Item type. Like Items, Extensions are also mapped to UDT classes and use inheritance. The root extension type is Base. Extension, from which all Extension types are derived.

  UDT is a CLR class-it has a state (ie, a data field) and a behavior (ie, a routine). UDT is a managed language-C #, VB. It is defined using NET etc. UDT methods and operators can be called in T-SQL on instances of that type. The UDT can be a type of one column in a row, a parameter type of a T-SQL routine, or a variable type of a T-SQL.

  Mapping storage platform schemas to UDT classes is fairly easy at a high level. In general, the storage platform Schema is mapped to the CLR namespace. The storage platform Type is mapped to the CLR class. The CLR class inheritance reflects the storage platform Type inheritance, and the storage platform Property is mapped to the CLR class property.

2. Item Mapping It is desirable for Items to be globally searchable, and with the relational database support of the present invention for inheritance and type substitutability, one possible implementation of Item storage in a database store is all Items of type Base. It is stored in a single table that contains a column of Items. Using type substitutability, it is possible to store all types of Items, and use Yukon's “is of (Type)” operator to filter the search by Item and child types Is possible.

  However, in an embodiment of the present invention, due to the overhead concerns associated with such an approach, the Items are divided by the top-level type, and each type of “family” Item is stored in a separate table. . According to this partitioning scheme, Base. One table is created for each Item type that directly inherits from Item. These lower type inheritances are stored in the appropriate type family table using type substitutability as described above. Base. Only the first level of inheritance from Item is specially handled.

  A “shadow” table is used to store a globally searchable copy of the properties for all Items. This table can be maintained by the Update () method of the storage platform API that is used when all data changes are made. Unlike type family tables, global Item tables contain only the top-level scalar properties of Items, not complete UDT Item objects. In the global Item table, it is possible to navigate to the Item object stored in the type family table by publishing the ItemID and TypeID. The ItemID generally uniquely identifies the Item in the data store. A TypeID can be mapped to a view that includes a type name and an Item using metadata not described here. Finding an Item by its ItemID is a normal operation, and in the context of both the global Item table and some other means, there is a GetItem () function that retrieves an Item object when an ItemID is specified. .

  In order to simplify access and hide implementation details as much as possible, all Items queries can be made against views built on the Item table described above. In particular, a view can be created for each Item type against the corresponding type table. In these type views, all Items of the associated type, including child types, can be selected. For convenience, in addition to UDT objects, those views can expose columns for all of the top-level fields of that type, including inherited fields.

3. Extension Mapping Extensions are very similar to Items and have some of the same requirements. As another root type that supports inheritance, Extensions are subject to many of the same storage considerations and tradeoffs. For this reason, the similar type family mapping is not a single table approach, but rather applies to Extensions. Of course, in other embodiments, a single table approach can be used. In an embodiment of the present invention, an Extension is associated with exactly one Item by ItemID and includes an ExtensionID that is unique in the context of the Item. As in the case of Items, it is possible to prepare a function that takes out an extension given an identification, which consists of a pair of ItemID and ExtensionID. A View is created for each Extension type and is similar to an Item type view.

4). Nested Element Mappings Nested Elements is a type that can be embedded within Items, Extensions, Relationships, or other Nested Elements to form deeply nested structures. Like Items and Extensions, Nested Elements are implemented as UDTs, but are stored within Items and Extensions. Thus, a nested element has no storage mapping beyond that of its Item and Extension containers. In other words, there is no table in the system that directly stores a nested element type instance, and there is no view dedicated to nested elements.

5). Object Identification Each entity in the data model, ie, each Item, Extension, and Relationship has a unique key value. Item is uniquely identified by ItemID. Extension is uniquely identified by a composite key of (ItemId, ExtensionId). The Relationship is identified by a composite key (ItemId, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.

6). SQL Object Naming Conventions All objects created in the data store can be stored with a SQL schema name derived from the storage platform schema name. For example, a storage platform Base schema (often referred to as “Base”) can be typed with a “[System.Storage]” SQL schema such as “[System.Storage] .Item”. The generated name is prefixed with a qualifier to eliminate naming conflicts. Where appropriate, exclamation points (!) Are used as dividers for each logical part of the name. The following table outlines the naming convention used for objects in the data store. Each schema element (Item, Extension, Relationship, and View) is listed with a decorated naming convention used to access instances in the data store.

7). Column naming conventions When mapping an object model to a store, additional information is stored with the application object, which can lead to naming conflicts. To avoid naming conflicts, an underscore (_) character is prepended to all non-type-specific columns (columns that are not directly mapped to named properties in the type declaration). In the embodiment of the present invention, the underscore (_) character is prohibited as the first character of the identifier property. In addition, all properties of storage platform types or schema elements (such as relationships) must be capitalized in order to unify naming between CLRs and data stores.

8). Search view A view is provided by the storage platform to search stored content. The SQL view is prepared for each Item and Extension type. In addition, views are also provided to support Relationships and Views (as defined in the Data Model). All SQL views and underlying tables in the storage platform are read-only. Data can be stored or modified using the Update () method of the storage platform API, as described in detail below.

  Each view that is explicitly defined in the storage platform schema (defined by the schema designer and not automatically generated by the storage platform) is named SQL view [<schema-name>]. [View! <View-name>] is accessible. For example, a view named “BookSales” in the schema “AccumPublisher.Books” is accessible using the name “[AcmePublisher.Books]. [View! BookSales]”. Since the view output format can vary from view to view (defined by any query provided by the party defining the view), the columns are mapped directly based on the schema view definition.

All SQL search views in the storage platform data store use the following ordering rules for the columns:
ItemId, ElementId, RelationshipId,. . . The logical “key” column of view results such as
Metadata information about the result type, such as TypeId.
CreateVersion, UpdateVersion,. . . Change tracking columns such as
(S) type-specific columns (property of declared type)
• Type-specific views (family views) also include object specific objects that return objects.

  Members of each type family can be searched using a series of Item views, with one view for each Item type in the data store. FIG. 28 is a block diagram illustrating the concept of an item search view.

a) Items Each Item search view contains one row for each instance of an item of a particular type or its child types. For example, a view for Document can return an instance of Document, LegalDocument, and ReviewDocument. In this example, the Item view can be conceptualized as shown in FIG.

(1) Master Item Search View Each instance of the storage platform data store defines a special Item view called the Master Item View. This view shows summary information about each Item in the data store. The view shows one column for each Item type property, which describes the Item and multiple column types that are used to provide change tracking and synchronization information. The master item view is identified in the data store using the name “[System.Storage]. [Master! Item]”.

(2) Typed item search view Each Item type further has a search view. Similar to the root Item view, but this view can also access Item objects via the “_Item” column. Each typed item search view has a name [schemaName]. Identified in the data store using [itemTypeName]. For example, [Acme Corp. Doc]. [OfficeDoc].

b) Item Extensions All Item Extensions in the WinFS Store can also be accessed using a search view.

(1) Master Extended Search View Each instance of the data store defines a special Extension view called Master Extended View. This view shows summary information about each Extension in the data store. The view has one column for each Extension property, which describes the Extension and the types of columns used to provide change tracking and synchronization information. The master extended view is identified in the data store using the name “[System.Storage]. [Master! Extension]”.

(2) Typed Extended Search View Each Extension type further has a search view. Similar to the master extended view, but this view can also access the Item object via the “_Extension” column. Each typed extended search view has the name [schemaName]. [Extension! It is identified in the data store using extensionTypeName]. For example, [Acme Corp. Doc] [Extension! OfficeDocExt].

c) Nested elements All nested elements are stored in an Items, Extensions, or Relations instance. Thus, these are accessed by querying the appropriate Item, Extension, or Relationship probation view.

d) Relationships As mentioned above, Relationships form the basic unit of linking between Items within the storage platform data store.

(1) Master Relationship Search View Each data store provides a Master Relationship View. This view shows information about all relationship instances in the data store. The master relationship view is identified in the data store using the name “[System.Storage]. [Master! Relationship]”.

(2) Relationship Instance Search View Each declared Relationship further has a search view that returns all instances of a particular relationship. Similar to the master relationship view, but this view also shows a named column for each property of the relationship data. Each relationship instance search view has a name [schemaName]. [Relationship! relationName] is identified in the data store. For example, [Acme Corp. Doc]. [Relationship! DocumentAuthor].

e)
9. Update All views in the storage platform data store are read-only. To create a new instance of a data model element (item, extension, or relationship) or update an existing instance, the ProcessOperation or ProcessUpdategram method of the storage platform API must be used. The ProcessOperation method is a single stored procedure defined by the data store that consumes the “operation” that determines the details of the action to be performed. The ProcessUpdategram method is a stored procedure that receives an ordered set of operations called an “updategram” that comprehensively determines the details of the set of actions to be performed.

The operation format is extensible and provides various operations for schema elements. Common operations include the following.
1. Item operations:
a. CreateItem (creates a new item in the context of an embedding or holding relationship)
b. UpdateItem (updates an existing Item)
2. Relationship operation:
a. CreateRelationship (create a reference or retention relationship instance)
b. UpdateRelationship (update relationship instance)
c. DeleteRelationship (delete relationship instance)
3. Extension operation:
a. CreateExtension (adds an extension to an existing Item)
b. UpdateExtension (updates an existing extension)
c. DeleteExtension (delete extension)

10. Change tracking & tomb stones
Change tracking and tombstone services are provided by the data store as detailed below. This section outlines the change tracking information published in the data store.

a) Change Tracking Each search view provided by the data store includes columns that are used to provide change tracking information, and these columns are common across all Item, Extension, and Relationship views. The storage platform's Schema Views is explicitly defined by the schema designer and does not automatically supply change tracking information-such information is supplied indirectly through the search view on which the view itself is built. .

  For each element in the data store, change tracking information is available from two locations—a “master” element view and a “typed” element view. For example, Acme Corp. Document. The change tracking information for the Document Item type includes the master item view “[System.Storage]. [Master! Item]” and the typed item search view [AcmeCorp. Document]. Available from [Document].

(1) Change tracking in the “master” search view The change tracking information in the master search view includes information about the creation and update version of the element, information about the synchronization partner that created the element, and information about the synchronization partner that last updated the element. And the version number from each partner for creation and update. Partners (described later) that are in a synchronous relationship are identified by a partner key. Type [System. Storage. Store]. A single UDT object named _ChangeTrackingInfo in ChangeTrackingInfo stores this information. This type is described in System. It is defined in the Storage schema. _ChangeTrackingInfo is available in all global search debuts for Items, Extensions, and Relationships. The type definition of ChangeTrackingInfo is as follows.

  These properties include the following information:

(2) Change tracking in “typed” search views In addition to providing the same information as the global search views, each typed search view has additional information that records the synchronization status of each element in the synchronization topology. Supply.

b) Tombstone The data store provides tombstone information for Items, Extensions, and Relationships. The tombstone view shows information about both live and tombstoned entities (items, extensions, and relationships) at a location. Item and extended tombstone views do not have access to the corresponding object, but relationship tombstone views have access to the relationship object (the relationship object is NULL for tombstone state relationships) .

(1) Item Tombstone Item Tombstone is a view [System. Storage]. [Tombstone! It is retrieved from the system via [Item].

(2) Extended Tombstone Extended Tombstone is a view [System. Storage]. [Tombstone! It is retrieved from the system using Extension. Extended change tracking information is similar to the information provided for Items, including the addition of the ExtensionId property.

(3) Relation Tombstone Relation Tombstone is a view [System. Storage]. [Tombstone! Retrieved from the system via Relationship. The related tombstone information is similar to the information given for Extensions. However, additional information is given on the target ItemRef of the relationship instance. In addition, related objects are also selected.

(4) Tombstone cleanup To prevent endless proliferation of tombstone information, the data store provides a tombstone cleanup task. This task determines when tombstone information can be discarded. This task calculates the limits for the local create / update version and then truncates the tombstone information by discarding all old tombstone versions.

11. Helper APIs and Functions Base mapping also includes a number of helper functions. These functions are provided to assist common operations on the data model.

  a) Function [System. Storage]. GetItem

  b) Function [System. Storage]. GetExtension

  c) Function [System. Storage]. GetRelationship

12 There are two types of metadata represented in the metadata store: instance metadata (such as Item types) and type metadata.
a) Schema metadata Schema metadata is stored in the data store as an Item type instance from the Meta schema.
b) Instance metadata Instance metadata is used by an application to query for the type of Item, thereby finding the extension associated with the Item. Given an ItemId for the Item, the application queries the global item view to return the Item type and uses this value to get the Meta. Queries the Type view and returns information about the declared type of the Item. For example:

E. Security In general, all security-configurable objects set their access rights using the access mask format shown in FIG. In this format, the lower 16 bits are used for object-specific permissions, the next 7 bits are used for standard permissions, which apply to most types of objects, and the upper 4 bits are standard and object for each object type. Used to specify universal access rights that can be mapped to a specific set of rights. The ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the SACL of the object.

  In the access mask structure of FIG. 26, item-specific rights are placed in the “Object Specific Rights” section (lower 16 bits). In embodiments of the present invention, the storage platform exposes two sets of API-Win32 and storage platform API- that manage security, so file system object specific rights are the motivation for designing storage platform specific rights. It must be considered in order to apply.

  The security model of the storage platform of the present invention is described in detail in the related application incorporated by reference earlier in this specification. In this regard, FIG. 27 (parts a, b, and c) illustrates a new, exactly the same protected security area that is cut out from an existing security area, according to one embodiment of the security model.

F. Notification and Change Tracking According to another aspect of the present invention, the storage platform comprises a notification function that allows an application to track data changes. This functionality is primarily for applications that maintain volatile state or execute business logic for data change events. The application registers notifications about items, item extensions, and item relationships. Notifications are sent asynchronously after the data changes are committed. On the application side, notifications can be filtered by item, extension, and relation type as well as the type of operation.

  According to one embodiment, the storage platform API 322 provides two types of interfaces for notification. First, the application registers simple data change events triggered by changes to items, item extensions, and item relationships. Second, the application creates a “watcher” object that monitors the collection of items, item extensions, and relationships between items. The state of the watcher object can be saved and recreated after a system failure or after the system has been offline for a long time. A single notification may reflect multiple updates.

  Additional details regarding this functionality are described in related applications incorporated by reference earlier in this specification.

G. Conventional File System Interoperability As described above, the storage platform of the present invention is embodied, at least in some embodiments, as an integral part of the hardware / software interface system of a computer system. Is intended. For example, the storage platform of the present invention may be embodied as an important part of an operating system, such as the Microsoft Windows® family of operating systems. In such capacity, the storage platform API becomes part of the operating system API that application programs use to interact with the operating system. Thus, the storage platform provides a means for application programs to use to store information about the operating system, so that the storage platform's Item-based data model is an alternative to the traditional file system of such operating system. For example, as embodied in the operating system of the Microsoft Windows (registered trademark) family, the storage platform can also replace the NTFS file system implemented in the operating system. Currently, application programs access services of the NTFS file system through the Win32 API published by the Windows (registered trademark) family of operating systems.

  However, it will be appreciated that in order to completely replace the NTFS file system with the storage platform of the present invention, it is necessary to recode existing Win32-based application programs and that such recoding is undesirable. It would be beneficial to achieve some interoperability with existing file systems such as NTFS with the inventive storage platform. Thus, in one embodiment of the present invention, in a storage platform, an application that relies on the Win32 programming model can access the contents of both the storage platform data store and the traditional NTFS file system. For this purpose, the storage platform uses a naming convention that is a superset of the Win32 naming convention that enhances simple interoperability. In addition, the storage platform supports access to files and directories stored in the storage platform volume through the Win32 API.

  Additional details regarding this functionality are described in related applications incorporated by reference earlier in this specification.

H. Storage platform API
The storage platform provides an API that can be used on the application program side to access the functions and capabilities of the storage platform described above and to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform of the present invention. Details regarding this functionality are described in the related applications incorporated by reference earlier in this specification, but some of this information is summarized below for convenience.

  Referring to FIG. 18, Content Folder is an item including retention Relationships with other Items, and is equivalent to a common concept of a folder in a file system. Each Item is “included” in at least one inclusion folder.

  FIG. 19 illustrates the basic architecture of the storage platform API, according to one embodiment of the invention. The storage platform API can interact with the local data store 302 using SQL Client 1900 and can interact with a remote data store (eg, data store 340) using SQL Client 1900. The local store 302 can also interact with the remote data store 340 using a DQP (distributed query processor) or through a storage platform synchronization service (“Sync”) described below. The storage platform API 322 further functions as a bridge API for data store notifications, passing application subscriptions to the notification engine 332 as described above, and notifications to applications (eg, applications 350a, 350b, or 350c). Route. In one embodiment, the storage platform API 322 may further define a “provider” architecture that is restricted to allow access to data with Microsoft Exchange and AD.

  FIG. 20 is a schematic diagram representing the various components of the storage platform API. The storage platform API includes (1) a data class 2002 representing storage platform elements and item types, (2) a runtime framework 2004 that manages object persistence and provides support classes 2006, and (3) a storage platform schema. Each component of the tool 2008 used to generate a CLR class from

  The hierarchy of classes that arise from a given schema directly reflects the hierarchy of types within that schema. For example, consider the Item type defined in the Contacts schema as shown in FIGS. 21A and 21B.

FIG. 22 illustrates the runtime framework in operation. The runtime framework works as follows.
1. Applications 350a, 350b, or 350c bind to items in the storage platform.
2. The framework 2004 creates an ItemContext object 2202 corresponding to the bound item and returns it to the application.
3. The application submits Find on this ItemContext to obtain a collection of Items, and the returned collection is conceptually an object graph 2204 (depending on the relationship).
4). The application changes, deletes, and inserts data.
5). The application saves the changes by calling the Update () method.

  FIG. 23 illustrates execution of a “FindAll” operation.

  FIG. 24 illustrates the process by which the storage platform API class is generated from the storage platform Schema.

  FIG. 25 illustrates a schema on which the File API is based. The storage platform API includes a namespace for handling file objects. This namespace is System. Storage. Called Files. System. Storage. The data members of the Files class directly reflect the information stored in the storage platform store, which can be “upgraded” from the file system object or created natively using the Win32 API. be able to. System. Storage. The Files namespace has two classes: FileItem and DirectoryItem. The members of these classes and their methods can be easily guessed by looking at the schema diagram of FIG. FileItem and DirectoryItem are read-only from the storage platform API. To modify them, use the Win32 API or use System. It is necessary to use the IO class.

  With respect to an API, a programming interface (or, more simply, an interface) is a mechanism, process that allows one or more segments of code to communicate or access functions provided by one or more other segments of code. Can be regarded as a protocol. Alternatively, the programming interface may include one or more mechanisms of the components of the system that can be communicatively coupled to one or more mechanisms, methods, function calls, modules, etc. of the other component (s), It can be regarded as a method, function call, module, object, etc. The term “segment of code” in the preceding sentence refers to the term applied, whether the code segment is compiled separately, whether the code segment is supplied as source code, intermediate code, or object code, Whether the runtime system or process is used, whether they are located on the same or different machines, or distributed across multiple machines, the functionality represented by the segment of code is fully implemented in software Intended to include one or more instructions or lines of code, whether implemented in hardware, fully implemented in hardware, or a combination of hardware and software, eg code Module, object, support Includes blue tin, functions, etc.

  Conceptually, the programming interface can be shown generically, as shown in FIG. 30A or FIG. 30B. FIG. 30A illustrates an interface Interface1 as an information transmission route used by the first and second code segments for communication. FIG. 30B illustrates interface objects I1 and I2 (which may or may not be part of the first and second code segments) that allow the first and second code segments of the system to communicate over the medium M. ) As an example. Looking at FIG. 30B, interface objects I1 and I2 can be thought of as another interface of the same system, and objects I1 and I2 and media M can also be thought of as containing that interface. 30A and 30B show a bidirectional flow and an interface on either side of that flow, but in some implementations there is information flow in only one direction (or no information flow as described below). Or there may be an interface object on one side only. For example, but not limited to, terms such as application programming interface (API), entry point, method, function, subroutine, remote procedure call, and component object model (COM) interface are encompassed within the definition of a programming interface.

  Several aspects of such a programming interface allow the first code segment to send information ("information" is used in the broadest sense and includes data, commands, requests, etc.) to the second code segment. A method for the second code segment to receive the information, and a structure, sequence, syntax, organization, schema, timing, and content of the information. In this regard, the underlying carrier medium itself, regardless of whether the medium is wired, wireless, or a combination of both, is not relevant to the operation of that interface as long as the information is carried in a manner defined by the interface. Not considered important. In some situations, information may not be passed unidirectionally or bidirectionally in the traditional sense, but only when one code segment accesses a function performed by a second code segment. As such, information transfer may be through other mechanisms (eg, information is placed in a buffer, file, etc., separate from the information flow between code segments) or may not exist. Any or all of these aspects may be important in a given situation, for example depending on whether the code segment is part of a loosely coupled or tightly coupled configuration system, so this list is explained Should be considered as intended and not intended to be limiting.

  This concept of programming interface is known to those skilled in the art and is apparent from the foregoing detailed description of the invention. However, there are other ways to implement the programming interface, and unless otherwise noted, these are also intended to be incorporated by the claims appended hereto. Such other methods may appear as more detailed or complex than the simplified diagrams of FIGS. 30A and 30B, but nonetheless similar functions that yield the same overall results. Execute. We will now briefly describe some descriptive other implementations of the programming interface.

  Factorization: Communication from one code segment to the other can be performed indirectly by dividing the communication into a plurality of discrete communications. This is illustrated schematically in FIGS. 31A and 31B. As shown in the figure, some interfaces can be described in terms of a separable set of functions. Thus, the interface function of FIGS. 30A and 30B can be factored so as to obtain the same result that can be mathematically shown as exactly 24, or 2 × 2 × 3 × 2. Therefore, as illustrated in FIG. 31A, the function provided by the interface Interface1 may be subdivided to convert the interface communication into a plurality of interfaces Interface1A, Interface1B, Interface1C, and to obtain the same result. it can. As illustrated in FIG. 31B, the function provided by interface I1 can be subdivided into a plurality of interfaces I1a, I1b, I1c, and the same result can be obtained. Similarly, the interface I2 of the second code segment that receives information from the first code segment can be factored into a plurality of interfaces I2a, I2b, I2c, etc. During the factorization, the number of interfaces included with the first code segment need not match the number of interfaces included with the second code segment. In both cases of FIGS. 31A and 31B, the essence of the functions of interfaces Interface1 and I1 remains the same as in FIGS. 30A and 30B, respectively. Interface factorization is also subject to associative, commutative, and other mathematical characteristics, which may be difficult to understand. For example, the order of operations may not be important, so a function executed by an interface may be executed some time before reaching that interface by code or other piece of the interface, or another component of the system Can be executed by. Further, those having ordinary skill in programming techniques will appreciate that there are various ways to execute different function calls that produce the same result.

  Redefinition: In some cases, it may be possible to ignore, add, or redefine some aspect of the programming interface (eg, parameters) while still achieving the intended result. This is illustrated in FIGS. 32A and 32B. For example, the interface Interface1 of FIG. 30A includes a function call Square (input, precision, output), and the call includes three parameters input, precision, and output, and is issued from the first Code Segment to the second Code Segment. Assume that. If the middle parameter precision is irrelevant in a given scenario, it can simply be ignored or even replaced by a meaningless parameter (in this situation) as shown in FIG. 32A. It is also possible to add additional parameters that are not relevant. In any case, the square function can be achieved as long as the output is returned after the input is squared by the second code segment. The precision could be a meaningful parameter for any downstream or other part of the computing system, but if it turns out that the precision is not necessary for the narrow purpose of calculating the square, replace it, or Can be ignored. For example, instead of passing a valid precision value, passing a meaningless value, such as a birthday date, will not adversely affect the result. Similarly, as shown in FIG. 32B, interface I1 is replaced with interface I1 ′ and redefined to ignore or add parameters to that interface. Interface I2 can similarly be redefined as interface I2 ′ and can be redefined to ignore unwanted parameters or parameters that can be processed elsewhere. The point here is that, in some cases, the programming interface may include aspects such as parameters that are not necessary for one purpose, and therefore ignore or redefine them, or for other purposes. It can be processed elsewhere.

  Inline coding: It may also be possible to merge some or all of the functions of two separate code modules so that the intervening “interface” changes form. For example, the functions of FIGS. 30A and 30B can be converted to the functions of FIGS. 33A and 33B, respectively. In FIG. 33A, the first and second code segments before FIG. 30A are merged into one module that includes both. In this case, the code segment can still be in communication with other interfaces, but the interface can be adapted to a more suitable form by a single module. Thus, for example, formal Call and Return statements are no longer needed, but similar processing or response by interface Interface1 is still valid. Similarly, as shown in FIG. 33B, a portion (or all) of interface I2 from FIG. 30B can be written inline to interface I1 to form interface I1 ″. Thus, the interface I2 is divided into I2a and I2b, and the interface unit I2a is coded in-line with the interface I1 to form the interface I1 ″. As a specific example, interface I1 of FIG. 30B processes the value received by interface I2 and passed with the input (to square) by the second code segment, and then returns the squared result with the output. The function call square (input, output) is assumed to be executed. In this case, the processing (input square) performed by the second code segment can be performed by the first code segment without calling the interface.

  Separation: Communication from one code segment to the other can be performed indirectly by dividing the communication into a plurality of discrete communications. This is illustrated schematically in FIGS. 34A and 34B. As shown in FIG. 34A, one or more pieces of middleware are provided (since the function (s) and / or interface functions are separated from the original interface), The communication on the first interface Interface1 is converted to be compatible with another interface, in this case the interfaces Interface2A, Interface2B, and Interface2C. This is for example an installed base of applications designed to communicate with the operating system according to the Interface1 protocol, when the operating system uses different interfaces, in this case the interfaces Interface2A, Interface2B and Interface2C It can be done when changed. The main point is that the original interface used by the second code segment is changed and is not compatible with the interface used by the first code segment, so the intermediary is used to connect the old and new interfaces. It is a point of taking compatibility. Similarly, as shown in FIG. 34B, a third code segment is introduced with the separation interface DI1 to receive communication from the interface I1, and the interface function works with, for example, DI2, but with the same functional result. Can be introduced with the separation interface DI2 to send to the redesigned interfaces I2a and I2b. Similarly, DI1 and DI2 can work together to translate the functionality of interfaces I1 and I2 of FIG. 30B into a new operating system, while ensuring the same or similar functional results.

  Rewriting: Yet another possible modification is to dynamically rewrite the code to replace the interface function with some other function, but to achieve the same overall result. For example, code segments written in an intermediate language (eg, Microsoft IL, Java® ByteCode, etc.) can be executed by an execution environment (.Net framework, Java® runtime environment, or other similar runtime type environment). Some systems send to just-in-time (JIT) compilers or interpreters within (as implemented). The JIT compiler dynamically translates communication from the first code segment to the second code segment, that is, as the second code segment (either the original or a different second code segment) requires. They can be written to fit different interfaces. This is illustrated in FIGS. 35A and 35B. As can be seen from FIG. 35A, this approach is similar to the separation scenario described above. This can be done, for example, if the application install base is designed to communicate with the operating system according to the Interface1 protocol, but at that time the operating system is changed to use a different interface. is there. The JIT compiler can be used when the installation system adapts communications on the fly from the installed base application to the new interface. Applying this approach of dynamically rewriting the interface (s), as shown in FIG. 35B, dynamically modifies the interface (s) either by factoring or by some other means can do.

  The above scenarios that obtain the same or similar results as the interface via other embodiments can also be combined in various ways, serially and / or in parallel, or using other intervention codes. it can. Thus, the other embodiments described above are not mutually exclusive and can be mixed, collated, and combined to produce the same or equivalent scenario as the generic scenario shown in FIGS. 30A and 30B. Also, as is the case with most programming syntaxes, there are still other similar methods that cannot be described here, but that still implement the same or similar functions of the interface, represented by the spirit and scope of the present invention. Note also that, at least in part, the functionality represented by the interface underlying the value of the interface and the beneficial results to be enabled.

III. Synchronous API
Several approaches to synchronization are possible in an Item-based hardware / software interface system. Section A discloses several embodiments of the present invention, and Section B focuses on various embodiments of the API with respect to synchronization.

A. Synchronization Overview In some embodiments of the present invention, with respect to FIG. 3, the storage platform is: (i) multiple instances of a storage platform (each with its own data store 302) are part of its content according to a flexible set of rules. And (ii) provide a synchronization service 330 comprising a third-party infrastructure that synchronizes the data store of the storage platform of the present invention with other data sources that implement a dedicated protocol.

  Inter-storage platform synchronization is performed among the participating “replica” groups. For example, referring to FIG. 3, the storage platform 300's data store 302 and other remote data store 308 are under the control of other instances of the storage platform, possibly running on different computer systems. It may be desirable to provide synchronization. The overall membership of this group is not necessarily known to a given replica at a given time.

  Different replicas can make changes independently (ie, simultaneously). The process of synchronization is defined as making all replicas aware of changes made by other replicas. This synchronization function is essentially multi-master.

In the synchronization function of the present invention, the replica can be as follows.
Determine what changes other replicas will recognize.
Request information about changes not recognized by this replica.
Communicate information about changes that are not recognized by other replicas.
Determine when two changes conflict with each other.
• Apply changes locally.
Communicate competing solutions to other replicas to ensure convergence.
-Resolve the conflict condition based on the specified policy for conflict resolution.

1. Synchronization Processing Between Storage Platforms The main application of the storage platform synchronization processing service of the present invention is to synchronize multiple instances of the storage platform (each with its own data store). The synchronous processing service operates at the schema level of the storage platform (not the underlying table of the database engine 314). Thus, for example, “Scopes” is used to define synchronization as described below.

  The synchronous processing service operates on the principle of “net changes”. Synchronous processing services send the final results of those operations, rather than recording and sending individual operations (such as transactional replication), thus consolidating the results of multiple operations into a single change Often to do.

  Synchronous processing services generally do not respect transaction boundaries. That is, if two changes are made to the storage platform data store in a single transaction, it is not guaranteed that those changes will be applied to all other replicas as a granular unit-one appears without the other There is. An exception to this principle is that if two changes are made to the same Item in the same transaction, they are sent and guaranteed to be applied as a minimum unit to other replicas. Therefore, Items is the consistency unit of the synchronous processing service.

a) Synchronization Control Application Any application can connect to the synchronization processing service and initiate a synchronization processing operation. Such an application provides all the parameters necessary to execute the synchronization process (see sync profile below). Such an application is referred to herein as a synchronous control application (SCA).

  When synchronizing two storage platform instances, sync is initiated on one side by the SCA. The SCA notifies the local synchronization service that it will synchronize with the remote partner. On the other side, the synchronization service is awakened by a message sent by the synchronization service from the originating machine. This responds based on persistent configuration information (see mapping below) present on the destination machine. The synchronous processing service can be executed according to a schedule or in response to an event. In these cases, the synchronous processing service that executes the schedule is the SCA.

  Two steps need to be performed to enable the synchronization process. First, the schema designer must annotate the storage platform schema with the appropriate sync meaning (specify Change Units as described below). Second, the synchronization process must be properly configured on all machines that have storage platform instances involved in the synchronization process (as described below).

b) Schema annotation The basic concept of the synchronous processing service is the concept of Change Unit. The Change Unit is the smallest schema fragment that is tracked individually by the storage platform. For all Change Units, the synchronization processing service can determine whether it has changed since the last sync or not.

  Specifying Change Units in the schema is used for multiple purposes. First, it determines how busy the synchronization service is on the line. When a change is made in the Change Unit, the synchronization processing service does not know which part of the Change Unit has been changed, so the entire Change Unit is sent to the other replicas. Second, it determines the accuracy of conflict detection. If two simultaneous changes (these terms are defined in detail in later sections) are made to the same Change Unit, the synchronization service will issue a conflict notification, while the Change Units will have different simultaneous changes. Will not be notified of the conflict and changes will be merged automatically. Third, this strongly affects the amount of metadata held by the system. Most of the metadata of the synchronization processing service is held for each change unit. Therefore, if the change unit is reduced, the sync overhead increases.

  To define Change Units, we need to find the right tradeoff. That's why using the synchronous processing service allows the schema designer to participate in the process.

  In one embodiment, the synchronization processing service does not support Change Units larger than the element. However, it is supported that the schema designer specifies Change Units that are smaller than the element—that is, grouping multiple attributes of an element into one independent Change Units. In that embodiment, this is done using the following syntax:

c) Synchronous configuration A group of storage platform partners that wants to keep a particular part of the data synchronized is called the sync community. If community members want to remain synchronized, they do not necessarily represent the data in exactly the same way, that is, the sync partner can convert the data being synchronized.

  In a peer-to-peer scenario, it is impractical for a peer to maintain a transformation mapping for all of its partners. Instead, the synchronization processing service takes an approach of defining “community folders”. A community folder is an abstraction that represents a virtual “shared folder” in which all community members are synchronized.

  This concept is best understood with an example. When Joe wants to synchronize My Documents folders on multiple computers, Joe defines, for example, a community folder called Joes Documents. Next, on all computers, Joe configures a mapping between the virtual Joe Documents folder and the local My Documents folder. From this point on, if Joe's computers synchronize with each other, they will interact with the document in JoesDocuments, not its local items. In this way, all Joe's computers understand each other without knowing who they are—the community folder is the common language for the sync community.

  The configuration of the synchronization processing service consists of (1) defining the mapping between the local folder and the community folder, (2) what is synchronized (eg, what to synchronize with, the subset to be transmitted, and what to receive). It consists of three steps: defining a sync profile to determine (kimono), and (3) defining a schedule on which different sync profiles are executed or executing manually.

(1) Community folder-mapping Community folder mapping is stored as an XML configuration file on each machine. Each mapping has the following schema.
/ mappings / communityFolder
This element specifies the name of the community folder that is the target of this mapping. The name follows the folder syntax rules.

/ mappings / localFolder
This element specifies the name of the local folder to which this mapping is converted. The name follows the folder syntax rules. The folder must already exist for the mapping to be valid. Items in this folder are considered for synchronization according to this mapping.

/ mappings / transformations
This element defines how to convert an item from a community folder to a local folder and vice versa. If not present or empty, no conversion is performed. In particular, this means that no ID is mapped. This configuration is mainly used when creating a folder cache.

lmappings / transformations / mapIDs
This element requires that the newly generated local ID is assigned to all of the mapped items from the community folder, rather than reusing the community ID. Sync Runtime holds ID mapping that performs round-trip conversion of items.

/ mappings / transformations / localRoot
This element requires that all root items in the community folder be children of the specified root.

/ mappings / runAs
This element controls the authority with which requests for this mapping are processed. If not present, a sender is assumed.

/ mappings / runAs / sender
If this element is present, the sender of the message to this mapping is impersonated and the request must be processed according to its credentials.

(2) Profile The synchronization profile is a set of parameters necessary for kicking off synchronization. This is supplied by the SCA to Sync Runtime to start the synchronization process. The synchronization profile for synchronizing storage platforms includes the following information.
• Local Folder, used as a change source and destination.
Remote Folder name to synchronize-This Folder must be published from the remote partner using the mapping as defined above.
Direction-synchronization service supports transmission only, reception only, and transmission / reception synchronization.
Local Filter—Selects local information to send to the remote partner. Expressed as a storage platform query for local folders.
Remote Filter—Select remote information to retrieve from remote partner—Represented as a storage platform query for community folders.
Transformations—Defines how to convert items in local format.
Local security-specifies whether changes retrieved from the remote endpoint are applied with the permission of the remote endpoint (impersonation) or with the permission of the user who initiated the synchronization locally.
Conflict resolution policy-specifies whether conflicts are rejected, logged or automatically resolved-in the latter case, specify the configuration parameters for it along with the conflict resolver to use.

  The synchronization processing service provides a runtime CLR class that allows simple construction of synchronization profiles. Profiles can also be serialized with XML files for easy storage (often with schedules). However, there is no standard place in the storage platform where all profiles are stored, and the SCA is hopeless because it can build profiles on the fly without persisting it. Note that there is no need to provide a local mapping to initiate synchronization. All synchronization information can be specified in the profile. However, mapping is necessary to respond to synchronization requests initiated on the remote side.

(3) Schedule In one embodiment, the synchronization processing service does not provide its own scheduling infrastructure. Instead, it relies on other components to perform this task-using the Windows (R) Scheduler that comes with the Microsoft Windows (R) operating system. The synchronization processing service comprises a command line utility that operates as an SCA and triggers synchronization based on a synchronization profile stored in an XML file. Using this utility, Windows® Scheduler can be very easily configured to perform a synchronization process according to a schedule or in response to an event such as a user logging on or off.

d) Conflict avoidance process The conflict process in the synchronous processing service is: (1) Conflict detection executed at the time of applying a change-this step determines whether the change can be safely applied; (2) Automatic conflict resolution and logging- This step (executed immediately after a conflict is detected) queries the auto-conflict resolver to see if it can be resolved, and optionally logs the conflict (3) Conflict checking and resolution-this The step is executed if any conflicts are logged and executed outside the status of the sync session so that the logged conflicts are resolved and removed from the log Can be divided into three stages.

(1) Conflict detection In the embodiment of the present invention, the synchronization processing service detects two types of conflicts, knowledge base and constraint base.

(A) Knowledge Base Conflict Knowledge base conflict occurs when two replicas make independent changes to the same Change Unit. Two changes are called independently if they are made without knowing each other's changes-that is, the first version is not subject to knowledge of the second version and vice versa. I can say that. The synchronization processing service automatically detects all such conflicts based on replica knowledge, as described above.

  It can be useful to think of a conflict as a fork in the Change Unit version history. If no conflict occurs during the life of the Change Unit, its version history is a simple chain—each change occurs after the previous change. In the case of knowledge base conflicts, the two changes occur in parallel, so the chain is split into a version tree.

(B) Constraint-based conflicts When applied together, independent changes may violate integrity constraints. For example, if two replicas try to create a file with the same name in the same directory, such a conflict may occur.

  Constraint-based conflicts involve two independent changes (just like knowledge-based conflicts) but do not affect the same Change Unit. Rather, it affects different Change Units, but there are constraints between them.

  Synchronous processing services detect constraint violations when applying changes and automatically issue constraint-based conflict notifications. To resolve constraint-based conflicts, a custom modification usually does not violate the constraint. Although code is required, synchronous processing services do not provide a general purpose mechanism for doing so.

(2) Conflict processing When a conflict is detected, the synchronization processing service (1) action to reject the change and send it back to the sender, (2) action to record the conflict in the conflict log, or (3) conflict One of the actions that automatically resolves (selected by the synchronization initiator in the synchronization profile) can be performed.

  If the change is rejected, the synchronization processing service behaves as if the change did not arrive at the replica. A negative response is sent back to the caller. This resolution policy can be used primarily with headless replicas (such as file servers) where conflict logging is not possible. Instead, such replicas force other replicas to handle the conflict by rejecting.

  The synchronization initiator configures conflict resolution with the synchronization profile. The synchronous processing service supports the combination of multiple conflict resolvers in a single profile as follows-first, specify a list of conflict resolvers that will be tried one after the other until one succeeds; First, associate a conflict resolver with a type of conflict, for example, direct knowledge-based conflicts between updates to one resolver and all other conflicts to the log.

(A) Automatic conflict resolution The synchronization processing service includes a number of default conflict resolvers. This list includes:
Local-wins: discard changes received when there is a conflict with locally stored data.
Remote-wins: Discard local data if there is a conflict with the received change.
Last-writer-wins: select either local-wins or remote-wins according to the Change Unit based on the timestamp of the change (note that synchronization processing services are generally independent of clock values. This contention The resolver is the only exception to that rule).
Deterministic: Selects the winner in a way that is guaranteed to be the same on all replicas, but otherwise has no meaning—in one embodiment of the synchronization processing service, a partner is required to implement this functionality. Use ID lexicographic comparison.

  In addition, ISVs can implement and install their own competitive resolvers. A custom conflict resolver can accept configuration parameters, and such parameters must be specified by the SCA in the Conflict Resolution section of the synchronization profile.

  When the conflict resolver handles the conflict, it returns to the runtime a list of operations that need to be performed (instead of changing the conflict). After that, the synchronous processing service appropriately adjusts the remote knowledge so as to include the content considered by the contention handler side, and then applies those operations.

  Other conflicts may be detected while applying the solution. In such cases, the new conflict must be resolved before the original process resumes.

  Considering a conflict as a branch in an item's version history, the conflict resolution can be considered as combining—combining two branches to form a point. Thus, conflict resolution changes the version history to DAG.

(B) Competing Log Creation A truly special type of competing resolver is the Confict Logger. The synchronization processing service logs the conflict as Items of type ConflictRecord. These records are again related to the item in conflict (unless the item itself has been deleted). Each conflict record contains the received change that caused the conflict, the type of conflict, update-update, update-delete, delete-update, insert-insert, or constraint, and the version of the received change and the replica that sends it. Includes knowledge. Logged conflicts can be used for inspection and resolution, as described below.

(C) Conflict inspection and resolution The synchronization processing service includes an API for examining the contention log on the application side and proposing the resolution of the contention therein. This API allows an application to enumerate all conflicts or conflicts related to a given Item. This further allows such applications to: (1) accept remote changes—overwrite conflicting local changes to resolve logged conflicts, ( 2) local wins--ignore the conflicting part of the logged change, and (3) suggest new change--optionally proposes a merge that resolves the conflict, one of three ways One can be used. After the conflicts are resolved by the application, the synchronous processing service deletes them from the log.

(D) Replica Convergence and Conflict Resolution Propagation In complex synchronization scenarios, the same conflict may be detected by multiple replicas. When this happens, either (1) the conflict can be resolved at one replica and the resolution sent to the other replica, or (2) the conflict is automatic on both replicas Or (3) conflicts are resolved manually on both replicas (through a conflict checking API).

  To guarantee convergence, the synchronization processing service forwards the conflict resolution to other replicas. When changes that resolve conflicts arrive at the replica, the synchronization processing service automatically finds the conflict records contained in the log resolved by this update and deletes them. In this sense, conflict resolution at one replica becomes binding on all other replicas.

  When different winners are selected by different replicas for the same conflict, the synchronization service applies the principle of binding conflict resolution, picking one of the two solutions and automatically acquiring the other. The winner is chosen in a deterministic manner that ensures that the same result is always obtained (in one embodiment, a replica ID lexicographic comparison is used).

  If different “new changes” are proposed by different replicas for the same conflict, the sync service will treat this new conflict as a special conflict and use Conflict Logger to prevent it from propagating to other replicas. . Such a situation typically occurs in manual conflict resolution.

2. Non-Storage Platform Data Store Synchronization Processing According to another aspect of the storage platform of the present invention, the storage platform implements Sync Adapters that allow the ISV to synchronize the storage platform with legacy systems such as Microsoft Exchange, AD, and Hotmail. An architecture for Sync Adapters use many Sync Services provided by the synchronization processing service, as will be described later.

  Despite its name, Sync Adapters do not need to be implemented as plug-ins in any storage platform architecture. If desired, the “sync adapter” can simply be an application that utilizes a synchronous processing service runtime interface to obtain services such as change enumeration and applications.

  To make it easy to configure and execute synchronization with a given backend, Sync Adapter authors can use standard Sync Adapter to perform synchronization processing when given a synchronization profile as described above. You are encouraged to publish the interface. With this profile, configuration information is communicated to the adapter, which passes a portion of it to the Sync Runtime that controls the runtime service (eg, the Folder to be synchronized).

a) Synchronization processing service The synchronization processing service provides a number of synchronization processing services to the adapter creator. For the remainder of this session, it is convenient to call the machine on which the storage platform is performing the synchronization process as the “client” and the non-storage platform backend with which the adapter communicates as the “server”.

(1) Change enumeration
Using Change Enumeration, based on the change tracking data maintained by the sync processing service, the sync processing adapter can easily enumerate the changes that have occurred since the last attempt to synchronize with this partner for the data store folder. can do.

  Changes are enumerated based on the concept of “anchors” —hidden structures that represent information about the last synchronization. Anchors take the form of storage platform knowledge, as described in the previous section. Synchronous processing adapters that use the change enumeration service fall into two broad categories: those that use “stored anchors” and those that use “supplied anchors”.

  This distinction is based on where the information about the last synchronization is stored-the client or the server. The adapter is often easy to store this information on the client-the back end often cannot easily store this information. On the other hand, when multiple clients synchronize with the same backend, it is inefficient to store this information on the client and in some cases is incorrect-one client has already pushed the other client to the server. Do not notice the changes that are up. If you want to use a server stored anchor on the adapter side, the adapter must send it back to the storage platform when enumerating changes.

  In order for the storage platform to hold an anchor (either local storage or remote storage), it is necessary to make the storage platform aware of changes that have been successfully applied on the server side. These changes and only these changes can be included in the anchor. During change enumeration, Sync Adapters uses the Acknowledgment interface to report successfully applied changes. At the end of synchronization, adapters that use the supplied anchor need to read the new anchor (which incorporates all successfully applied changes) and send it to the backend.

  In many cases, Adapters need to store adapter specific data along with items to insert into the storage platform data store. Common examples of such data include remote ID and remote version (time stamp). The local processing service has a mechanism for storing this data, and Change Enumeration has a mechanism for receiving this additional data along with the returned changes. This eliminates the need for the adapter to re-query the database in most cases.

(2) Change Application
Using Change Application, changes received from the back end on the Sync Adapters side can be applied to the local storage platform. The adapter is expected to convert changes to the storage platform schema. FIG. 24 illustrates the process by which the storage platform API class is generated from the storage platform Schema.

  The main function of change application is to automatically detect conflicts. As in the case of storage platform-to-storage platform synchronization, contention is defined as two overlapping changes made without knowledge of each other. If the adapter uses Change Application, the adapter must specify an anchor as to which conflict detection is performed. Change Application issues a conflict notification when an overlapping local change that is not subject to adapter knowledge is detected. Similar to Change Enumeration, adapters can use either stored anchors or supplied anchors. Change Application supports efficient storage of adapter-specific metadata. Such data can be attached to the applied changes by the adapter and can also be stored by a concurrent processing service. Data could be returned at the next change enumeration.

(3) Conflict Resolution
The Conflict Resolution mechanism described above (logging and automatic resolution options) can also be used with the synchronous processing adapter. The synchronous processing adapter can specify a conflict resolution policy when applying changes. If specified, the conflict can be passed to the specified conflict handler and resolved (if possible). Conflicts can also be logged. The adapter may detect conflicts when attempting to apply local changes to the backend. In such cases, the adapter can still pass the conflict to Sync Runtime and resolve according to policy. In addition, the synchronous processing adapter may request that conflicts detected by the concurrent processing service be sent back for processing. This is useful when the backend can store or resolve conflicts.

b) Adapter implementation If some "adapter" is simply an application that uses a runtime interface, it is encouraged to implement a standard adapter interface on the adapter side. By using these interfaces, Sync Controlling Applications requests that the adapter perform synchronization processing according to a given synchronization profile, cancels ongoing synchronization processing, and reports on ongoing synchronization (completed). Rate).

3. Security Synchronous processing services attempt to introduce as little as possible into the security model implemented by the storage platform. Rather than defining new rights for the synchronization process, existing rights are used. In particular,
Anyone who can read a data store Item can enumerate changes to that item,
• Anyone who can write to the data store Item can apply changes to the item,
Anyone who can extend the data store Item is able to associate sync metadata with the item.

  The synchronous processing service does not hold copyright information protected by security. If a change is made at replica A by user U and forwarded to replica B, the fact that the change was originally made at A (or by U) is lost. If B forwards this change to Replica C, this is performed under B's authority instead of A's authority. This creates a restriction that changes made by others cannot be transferred if the replica is not trusted to make its own changes to the item.

  When the synchronization processing service is started, it is executed by Sync Controlling Application. The synchronization processing service impersonates the SCA identity and performs all operations (both local and remote) under that identity. For illustration purposes, user U observes that the local synchronization processing service cannot have changes retrieved from the remote storage platform for items for which user U does not have read access.

4). Manageability Managing a distributed community of replicas is a complex issue. Synchronous processing services can collect and distribute information about the status of replicas using a “sweep” algorithm. The nature of the sweep algorithm ensures that information about all configured replicas is eventually collected and that failed (non-response) replicas are detected.

  This community-wide monitoring information is available to all replicas. A monitoring tool can be run on an arbitrarily selected replica, and this monitoring information can be examined to make administrative decisions. Configuration changes must be made directly at the affected replica.

B. Synchronous Processing API Overview In the digital world, which is increasingly decentralized, individuals and workgroups are increasingly storing information and data on various devices and locations. This has been a driving force in the development of data synchronization processing services that can always synchronize these independent and often disparate data stores with minimal user intervention.

The synchronous processing platform of the present invention is part of the rich storage platform (also known as “WinFS”) described in Section II of this specification and addresses three main goals:
Data can be efficiently synchronized between “WinFS” stores with different applications and services.
• Developers can build rich solutions that synchronize data between “WinFS” and non- “WinFS” stores.
Provide the developer with a suitable interface for customizing the synchronization user experience.

1. General Terminology As used herein, this section III. Some other refined definitions and key concepts related to the later explanation of B are given.

  Sync Replica: Most applications are only interested in tracking, enumerating, and synchronizing changes to a given subset of items in the WinFS store. A collection of items involved in a synchronization processing operation is called a synchronization replica. Replicas are defined for items contained within a given WinFS containment hierarchy (usually rooted at the Folder item). All synchronous processing services are executed within the context of a given replica. WinFS Sync provides a mechanism for defining, managing, and cleaning up replicas. Every replica has a GUID identifier that uniquely identifies it within a given WinFS store.

  Sync Partner: A synchronization partner is defined as an entity that can affect changes to WinFS items, extensions, and relationships. Thus, every WinFS store can be called a synchronization partner. When synchronizing with a non-WinFS store, an external data source (EDS) is also called a synchronization partner. Every partner has a GUID identifier that uniquely identifies it.

  Sync Community: A sync community is defined as a collection of replicas that are kept in sync using peer-to-peer sync processing operations. These replicas can all appear in the same WinFS store, in different WinFS stores, or even as virtual replicas on non-WinFS stores. WinFS Sync does not prescribe or command a specific topology of the community, especially when only the synchronization processing operations within the community are performed through the WinFS Sync service (WinFS adapter). Synchronous adapters (defined below) can introduce their own topology constraints.

Change tracking, change unit, and version: All WinFS stores track changes to all local WinFS Items, Extensions, and Relationships. Changes are tracked at the level of change unit accuracy defined in the schema. The top-level fields of Item, Extension, and Relationship types can be subdivided into multiple change units by the schema designer, with a minimum accuracy of one top-level field. For change tracking, all change units are assigned a version that is a pair of synchronization partner id and version number (the version number is a monotonically increasing number unique to the partner). The Version is updated when a change occurs in the local store or is obtained from another replica.
Synchronization knowledge: Knowledge represents the state of a given synchronous replica at any time, that is, encapsulates metadata about all changes recognized by a given replica from a local or other replica. WinFS Sync maintains and updates the knowledge of making a synchronous replica between synchronous processing operations. It is important to note that knowledge representation can be interpreted for the whole community, not just for the particular replica in which the knowledge is stored.

Synchronous adapter: The synchronous adapter accesses the WinFS Sync service through the Sync Runtime API and can synchronize WinFS data with the non-WinFS data store according to the requirements of the scenario, which is a managed code application. It is up to the adapter developer which subset and what WinFS data type to synchronize. The adapter is responsible for communication with the EDS, conversion between the WinFS schema and the EDS support schema, the definition and management of the unique configuration and metadata. Adapters are strongly encouraged to implement the WinFS Sync Adapter API and take advantage of the adapter's common configuration and control infrastructure provided by the WinFS Sync team. For details, refer to documents (for example, Non-Patent Document 1 and Non-Patent Document 2).
For adapters that synchronize WinFS data with an external non-WinFS store but cannot output or maintain knowledge in the WinFS format, WinFS Sync provides a service to obtain remote knowledge that can be used for subsequent change enumeration or application operations. provide. Depending on the capabilities of the backend store, the adapter may want to store this remote knowledge on the backend or local WinFS store.
For simplicity, a synchronous “replica” is a structure that represents a collection of data in a “WinFS” store that resides in a single logical location, while data on a non- “WinFS” store is a “data source”. It is generally necessary to use an adapter.

  Remote knowledge: If you want to get changes from other replicas at a given synchronous replica, provide your own knowledge as a baseline to which other replicas match when enumerating changes. Similarly, if a given replica wants to send changes to another replica, it provides its own knowledge as a baseline that can be used by the remote replica for conflict detection. Knowledge of other replicas provided when enumerating and applying synchronous changes is called remote knowledge.

2. Key Issues of the Synchronization Processing API In some embodiments, the synchronization API is divided into two parts: a synchronization configuration API and a synchronization controller API. Using the synchronization configuration API, the application can configure synchronization and specify parameters for a particular synchronization session between two replicas. For a given synchronization session, the 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 a conflict resolution policy. The sync controller API starts a simultaneous session, cancels sync, and receives progress and error information regarding the ongoing sync process. Further, in certain embodiments where the synchronization process needs to be performed according to a predetermined schedule, such a system can include a scheduling mechanism for customizing the scheduling.

  Some embodiments of the present invention employ a synchronization adapter to synchronize information between “WinFS” data sources and non- “WinFS” data sources. An example of an adapter is an adapter that synchronizes address book information between a “WinFS” contact folder and a non-WinFS mailbox. In these cases, the adapter developer is described herein provided by the “WinFS” synchronization platform to develop schema conversion code between “WinFS” schemas and non- “WinFS” data source schemas. It is also possible to use the “WinFS” synchronous processing core service API. In addition, adapter developers support protocols for communicating non- "WinFS" data source changes. The sync adapter is called and controlled by using the sync controller API and reports progress and errors using this API.

However, in some embodiments of the present invention, when the “WinFS” data store is synchronized with another “WinFS” data store, the “WinFS”-“WinFS” synchronization processing service is not included in the hardware / software interface. If it is integrated in the system, the synchronization adapter is considered unnecessary. In any case, some such embodiments provide a collection of synchronization processing services for both “WinFS” — “WinFS” and a synchronization adapter solution, which include:
• Track changes to “WinFS” items, extensions, and relationships.
Support for efficient incremental change enumeration since a given past state.
・ Application of external changes to “WinFS”.
-Conflict handling when applying changes.

  Referring to FIG. 36, this illustrates three instances of a common data store and components for synchronizing them. The first system 3602 exposes a synchronous API 3652 for use (3646), and includes a WinFS data store 3612 including a WinFS-WinFS synchronization processing service 3622 and a core synchronization processing service 3624 for WinFS-non-WinFS synchronization. . Similar to the first system 3602, the second system 3604 exposes a synchronous API 3652 for use (3646), a WinFS-WinFS synchronization processing service 3632 and a core synchronization processing service for WinFS-non-WinFS synchronization. WinFS data store 3614 including 3634 is provided. The first system 3602 and the second system 3604 synchronize via their respective WinFS-WinFS synchronization processing services 3622 and 3632 (3642). The third system 3606 is not a WinFS system, but includes an application for using WinFS synchronization 3666 to maintain a data source in a synchronized community with a WinFS replica. This application uses the WinFS Sync Config / Control service 3664 to interface via the WinFS-WinFS synchronization processing service 3622 (if it can be virtualized as a WinFS data store) or with the synchronization API 3652 (3648). It can interface (3644) directly with the WinFS data store 3612 via the synchronization adapter 3661.

  As illustrated in this figure, the first system 3602 recognizes both the second system 3604 and the third system 3606 and is in direct synchronization. However, neither the second system 3604 nor the third system 3606 are aware of each other and, therefore, do not synchronize changes directly with each other, but instead changes that occur in one system propagate through the first system 3602. Must.

C. Synchronous Processing API Service Some embodiments of the present invention are directed to a synchronous processing service that includes two basic services: change enumeration and change application.

1. Change Enumeration As explained earlier in this document, change enumeration allows the sync processing adapter to synchronize with this partner last based on the change tracking data maintained by the sync processing service. Changes that have occurred to the data store Folder since it was attempted can be easily listed. With respect to change listing, some embodiments of the invention are directed to the following.
Efficient enumeration of Changes to Items, Extensions, and Relationships in a given replica for a given Knowledge instance.
• Enumerate changes at the level of change unit accuracy specified in the WinFS schema.
• Grouping of changes listed for compound items. A composite item consists of an item, all its extensions, all holding relationships with that item, and all composite items corresponding to that embedded item. Changes in the reference relationship between items are listed separately.
• Batch processing for change enumeration. The accuracy of batch processing is a composite item or a relationship change (of a reference relationship).
Specification of a filter for items in a replica when enumerating changes, for example, a replica consists of all items in a given folder, but for this particular change enumeration, on the application side the first name is "A We only want to enumerate the changes to all Contact items that begin with "(this support is added after the B Milestone).
Use of remote knowledge for enumerated changes that can record individual change units (or items, extensions, or entire relationships) in the knowledge as synchronization failures and have them re-enumerated next time.
• Use of advanced adapters that may be able to understand WinFS synchronous metadata by returning metadata along with the changes when enumerating changes.

2. Change Application As explained earlier in this document, change application expects the sync adapter to convert the changes to the storage platform schema, so that changes received from its backend are local. Applicable to storage platforms. With respect to modification applications, some embodiments of the invention are directed to:
Apply progressive changes from other replicas (or non-WinFS stores) with corresponding updates to WinFS change metadata.
• Detection of conflicts after applying changes with change unit accuracy.
Success, failure, and conflict reports that occur at the individual change unit level after changes are applied, and applications (including adapters and synchronization control applications) report that information on progress, errors, and status reports, and if any A report that can be used to update the backend state.
Update remote knowledge when applying changes to prevent “reflection” of changes supplied by the application in the next change enumeration operation.
• Use advanced adapters that can understand and provide WinFS synchronization metadata with changes.

3. Sample Code Below is a code sample that shows how the FOO Sync Adapter interacts with the Sync Runtime (all adapter specific functions are prefixed with FOO).

4). API Synchronization Processing Method In one embodiment of the present invention, synchronization between a WinFS store and a non-WinFS store is possible via a synchronization API published by a WinFS-based hardware / software interface system. is there.

In one embodiment, all synchronization adapters must implement a synchronization adapter API, a common language runtime (CLR) managed API, so that they can be deployed, initialized, and controlled consistently. The adapter API includes:
A standard mechanism for registering adapters in the hardware / software interface system synchronization framework.
A standard mechanism for declaring the type of configuration information necessary for an adapter to initialize its functionality and adapter.
A standard mechanism for passing initialization information to the adapter.
A mechanism for the adapter to report progress back to the application calling the synchronization.
-A mechanism for reporting errors that occur during synchronous processing.
A mechanism for requesting cancellation of ongoing synchronization processing operations.

Depending on the scenario requirements, there are two potential process models for the adapter. The adapter can all run automatically in the same process space as the application that calls it, or in a separate process. The adapter defines its own factory class that is used to instantiate the adapter for execution in another own process. The factory can return an instance of the adapter in the same process as the calling application, or it can return a remote instance of the adapter in a different Microsoft common language runtime application area or process. A default factory implementation is instantiated that instantiates an adapter in the same process. In practice, many adapters run in the same process as the calling application. Out-of-process models are usually necessary for one or both of the following reasons.
• Security purposes. An adapter must run within the process space of a particular process or service.
In addition to processing requests from the calling application, the adapter must handle requests from other sources-eg received network requests.

  Referring to FIG. 37, one embodiment of the present invention assumes a simple adapter that does not recognize how the state is calculated or how its associated metadata is exchanged. In this embodiment, the synchronization process is performed by the replica with respect to the data source to be synchronized. For this purpose, first, in step 3702, the change that has occurred since the last synchronization with the data source is determined, and thereafter The replica sends incremental changes that have occurred since this last synchronization based on the current state information, and the state information and incremental changes are sent to the data source via the adapter. In step 3704, after receiving the change data from the replica in the previous step, the adapter implements changes to as much data as possible, keeps track of which changes have succeeded and which have failed, and success-failure. Send information back to WinFS (replica). The replica (WinFS) hardware / software interface system receives the success-failure information from the replica in step 3706 and then calculates new state information for the data source and stores this information for future use by the replica. This new state information is sent back to the data source, ie, the adapter, where it is stored for later use by the adapter.

D. Additional Aspects of Synchronization Schema The following are additional (or more specific) aspects of the synchronization schema for the various aspects of the present invention.
Each replica is a predefined synchronized subset taken from the entire data store-a slice with multiple instances.
Conflict resolution policies are handled by each replica (and adapter / data source combination)-that is, each replica can resolve conflicts based on its own criteria and conflict resolution schema. In addition, differences between each instance of the data store will result in further conflicts in the future, but the progressive and sequential enumeration of conflicts as reflected in the updated state information Invisible to other replicas that receive.
The root of the synchronization schema includes a replica with a basic type for defining a root folder with a unique ID (actually a root Item), an ID for the synchronization community of which it is a member, and a specific replica There are some filters and other elements that are necessary or desirable.
The “mapping” of each replica is kept in the replica, so the mapping of any particular replica is restricted to other replicas that such replica knows about. This mapping includes only a subset of the entire sync community, but changes to the replica are still propagated to the entire sync community via a common shared replica (however, a particular replica may Does not know which replicas are normally shared).
The synchronization schema includes user / developer defined custom conflict handler functionality along with multiple predefined conflict handlers available from all replicas. The schema is further divided into three special “competing resolvers”: (a) for example, (i) how to handle the same change unit when it is changed in two locations, and (ii) the change unit is changed in one location A conflict “filter that resolves different conflicts in different ways based on how it is handled and deleted in the other location, and (iii) two different change units have the same name in two different locations (B) Conflict “handler list” to specify a series of actions to try in order until each conflict in the list is successfully resolved, and (c) Track the conflict, but without user intervention It can also include a “do nothing” log that does not perform further.
Replica synchronization schema and usage enables a truly distributed peer-to-peer multi-master synchronization community. Furthermore, although there is no sync community type, the sync community exists only as a value in the community field of the replica itself.
All replicas have their own metadata to track incremental change enumeration and store state information for other replicas known in the sync community.
The change unit has its own metadata, which is the version number including the partner key and the partner change number, the version / item / extension / relationship versioning of each change unit, and knowledge of the changes seen / received by the replica from the synchronization community. , GUID and local ID configuration, and GUID stored on the reference relationship for cleanup.

IV. CONCLUSION As exemplified above, the present invention is directed to a storage platform for organizing, retrieving, and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file systems and database systems, and includes structured data such as relational (tabular) data, new data forms called XML, and Items. Designed to be a store for all types of data, including unstructured or semi-structured data. The storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses through a common storage infrastructure and schematized data. This not only makes the functionality specific to the data model available, but also includes a rich and extensible application programming interface that encompasses and extends existing file systems and database access methods. It will be understood that modifications may be made to the embodiments described above without departing from the broad concepts of the present invention. Accordingly, the invention is not limited to the specific embodiments disclosed, but is intended to cover all modifications within the spirit and scope of the invention in accordance with the definitions of the appended claims.

  As will be apparent from the foregoing, all or some of the various systems, methods, and aspects of the present invention may be embodied in the form of program code (ie, instructions). The program code includes, but is not limited to, a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or other machine-readable storage medium. Can be stored on a computer readable medium, such as a magnetic, electrical, or optical storage medium, and when the program code is loaded and executed in a machine such as a computer or server, the machine is adapted to practice the invention. It becomes a device. The invention is further embodied in the form of program code transmitted in some transmission medium, such as electrical or cable wiring, the use of optical fibers, networks including the Internet or Intranet, or via other forms of transmission. When the program code is received, read and executed by a machine such as a computer, the machine becomes an apparatus for carrying out the present invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

And FIG. 7 is a block diagram illustrating a computer system in which aspects of the present invention may be incorporated. FIG. 2 is a block diagram illustrating a computer system divided into three component groups: a hardware component, a hardware / software interface system component, and an application program component. FIG. 3 illustrates a conventional tree-based hierarchical structure of files grouped into multiple folders in a directory in a file-based operating system. 1 is a block diagram illustrating a storage platform. FIG. FIG. 6 illustrates a structural relationship between Items, Item Folders, and Categories. It is a block diagram which illustrates the structure of Item. FIG. 5B is a block diagram illustrating a complex property type of Item in FIG. 5A. FIG. 6 is a block diagram illustrating a “Location” Item in which a composite type is further described (explicitly listed). It is a figure which illustrates Item as a child type of Item in Base Schema. FIG. 6B is a block diagram illustrating the child type Item of FIG. 6A with inherited types explicitly listed (in addition to immediate properties). FIG. 3 is a block diagram illustrating a Base Schema, Item and PropertyBase including two top level class types, and an additional Base Schema type derived therefrom. It is a block diagram which illustrates Item in Core Schema. It is a block diagram which illustrates the property type in Core Schema. FIG. 6 is a block diagram illustrating Item Folder, its member Items, and the interconnection relationships between Item Folder and its member Items. FIG. 3 is a block diagram illustrating Category (also Item itself), its Member Items, and the interconnection Relationships between Category and its Member Items. It is a figure which illustrates the reference type hierarchy of the data model of a storage platform. It is a figure which illustrates the method of classifying a relationship. It is a block diagram which illustrates a notification mechanism. FIG. 6 is a diagram illustrating an embodiment in which two transactions both insert a new record into the same B-Tree. FIG. 6 illustrates a data change detection process. It is a figure which shows the example of a directory tree. FIG. 3 is a diagram illustrating an example in which an existing folder of a directory-based file system is moved to a storage platform data store. It is a figure which illustrates the concept of Containment Folders. It is a figure which illustrates the basic architecture of storage platform API. FIG. 2 is a schematic diagram representing various components of a storage platform API stack. FIG. 6 is a diagram of an example Contact Items schema. FIG. 21B is a diagram of Elements in the example Contact Items schema of FIG. 21A. It is a figure which illustrates the runtime framework of storage platform API. FIG. 6 is a diagram illustrating execution of a “FindAll” operation. FIG. 6 is a diagram illustrating a process in which a storage platform API class is generated from a storage platform Schema. It is a figure which illustrates the schema based on File API. FIG. 6 illustrates an access mask format used for data security purposes. (Parts a, b, and c) A new and exactly the same protected security area that is cut out from an existing security area. It is a block diagram which illustrates the concept of a search view of Item. It is a block diagram which shows the Item hierarchy example. It is a figure which illustrates interface Interface1 as an information transmission route which the 1st and 2nd code segment uses for communication. FIG. 3 illustrates the interface as including interface objects I1 and I2 that allow the first and second code segments of the system to communicate over the medium M. It is a figure which illustrates the method of subdividing the function provided by interface Interface1, and converting the communication of an interface into several interface Interface1A, Interface1B, and Interface1C. It is a figure which illustrates the method of subdividing the function provided by the interface I1 into several interface I1a, I1b, I1c. It is a figure which illustrates the scenario which can ignore a meaningless parameter precision or can be replaced by arbitrary parameters. FIG. 5 illustrates a scenario where an interface is replaced by an alternative interface defined to ignore parameters or add to the interface. FIG. 6 illustrates a scenario where first and second Code Segments are merged into a module that includes both. FIG. 6 illustrates a scenario in which part or all of an interface is written inline to another interface to form a merged interface. FIG. 6 illustrates a method for one or more of the middleware to convert communications on a first interface to adapt to one or more different interfaces. FIG. 6 illustrates a method for introducing a code segment with an interface to receive communications from one interface but send functions to a second and third interface. FIG. 6 is a diagram illustrating a method in which a just-in-time compiler (JIT) converts communication from one code segment to another code segment. FIG. 6 illustrates that a JIT scheme that dynamically rewrites one or more interfaces is applied and that the interfaces can be dynamically factored or changed in some other way. FIG. 3 illustrates three instances of a common data store and components for synchronizing them. FIG. 6 illustrates an embodiment of the present invention that assumes a simple adapter that does not recognize how the state is calculated or how its associated metadata is exchanged.

Claims (30)

A storage platform system (eg, WinFS) for a hardware / software interface system,
Multiple instances of storage platforms,
A storage platform system comprising: a native synchronization subsystem of the hardware / software interface system that enables the system to synchronize the plurality of instances of the storage platform.   The system of claim 1, wherein the synchronization subsystem synchronizes only a subset of data from the entire data on the data store during a synchronization operation.   The first instance of the storage platform is a replica, that is, running on a hardware / software interface system with the synchronization subsystem (eg, WinFS), and the second instance of the storage platform is The system of claim 1, wherein the system is running on a hardware / software interface system that is a data source, i.e., does not have the synchronization subsystem (e.g., non-WinFS).   The synchronization between the replica and the data source is facilitated by a synchronization adapter that virtualizes the data source by interfacing with an application programming interface (API) of the hardware / software interface system of the replica. The system according to claim 3.   The first pair of instances synchronizes independently of the second pair of instances, and the first pair of instances and the second pair of instances are part of a common synchronization community. Item 4. The system according to Item 1.   The system of claim 1, wherein synchronization conflicts are automatically detected and resolved based on predefined determinable criteria.   The system of claim 6, wherein some of the conflicts are resolved by allowing them to be logged for manual resolution by an end user.   The synchronization subsystem keeps track of the previous synchronization state with a synchronization partner, thereby only synchronizing the change unit ("net change") that has changed since the last synchronization with that partner. Item 4. The system according to Item 1. A method for synchronizing multiple instances of a storage platform (eg, WinFS) for a hardware / software interface system comprising:
Dividing the storage platform into basic precision units (eg, change units);
Sequentially enumerate changes and track the changes for each change unit;
For each instance, tracking the status of changes to other known instances in a sync community (synchronization partner) along with the status of changes to that instance;
Identifying, for synchronization, new changes by comparing the listed changes for a particular instance with the status of changes for that instance.   The first instance, the replica, is instantiated on a hardware / software interface system that directly supports Item-based synchronization (WinFS), and the second instance, the data source, directly handles Item-based synchronization. Instantiated on a non-supporting hardware / software interface system (non-WinFS), the method further comprises using an adapter to virtualize the non-WinFS instance via a synchronous processing application programming interface. The method according to claim 9.   The method of claim 10, further comprising detecting synchronization contention at a level of change unit accuracy. An instance that reports success, failure, and / or conflict at the individual change unit level on the change application (synchronous data);
11. The method of claim 10, further comprising: applications that use synchronization data to update backend state (including but not limited to adapters and other synchronization control applications). A method of synchronizing a replica with a data source (per synchronization partner), wherein both the replica and the data source have change state information held by their respective synchronization partners, and the data source (non-WinFS) ) Interface with the replica (WinFS) hardware / software system using an adapter, the method comprising:
Changes made by the replica since the last synchronization as reflected in the last state information for the data source based on the last state information for the data source ("new change") ) To send updated status information for the replica reflecting
The adapter receives the updated status information and the new changes for the replica, implements as many changes as possible to the data source, and tracks success or failure for each change on the change unit on a change unit basis And a method comprising: The adapter calculates the new state of the data source based on the success or failure for each change on the change unit by change unit, stores the new state information, and stores the new state information in the hardware / Sending to a software interface system (WinFS);
14. The method of claim 13, further comprising: storing the new state information for the data source for future use by the replica of the hardware / software interface system (WinFS) of the replica. . The adapter sends the success or failure for each change on a change unit to the hardware / software interface system (WinFS) of the replica for each change unit;
The hardware / software interface system (WinFS) of the replica calculates new state information for the data source based on the success or failure for each change to the data source on a change unit by change unit; ,
The hardware / software interface system (WinFS) of the replica sends the new state information to the adapter and stores the new state information for future use by the replica;
The method of claim 13, wherein the adapter further comprises receiving and storing the new status information.   A computer readable medium storing computer readable instructions for a storage platform system (eg, WinFS) on a hardware / software interface system, wherein the storage system is a local instance of a plurality of instances of the storage platform. A computer readable medium comprising instructions for synchronizing.   The system of claim 16, wherein the synchronization subsystem synchronizes only a subset of data from the entire data on the data store during a synchronization operation.   The first instance of the storage platform is a replica, that is, running on a hardware / software interface system with the synchronization subsystem (eg, WinFS), and the second instance of the storage platform is 17. Computer-readable instructions according to claim 16, wherein the instructions are executed on a hardware / software interface system that is a data source, i.e., does not have the synchronization subsystem (e.g., non-WinFS).   The synchronization between the replica and the data source is a synchronization adapter that virtualizes the second instance by interfacing with an application programming interface (API) of the hardware / software interface system of the first instance The computer readable instructions of claim 18, wherein the computer readable instructions are facilitated by:   The first pair of instances synchronizes independently of the second pair of instances, and the first pair of instances and the second pair of instances are part of a common synchronization community. Item 17. A computer-readable instruction according to Item 16.   The computer-readable instructions of claim 16, wherein synchronization conflicts are automatically detected and resolved based on predefined determinable criteria.   The computer-readable instructions of claim 21, wherein some of the conflicts are resolved by allowing them to be logged for manual resolution by an end user.   The synchronization subsystem keeps track of the previous synchronization state with a synchronization partner, thereby only synchronizing the change unit ("net change") that has changed since the last synchronization with that partner. Item 17. A computer-readable instruction according to Item 16. A computer-readable medium storing computer-readable instructions for synchronizing multiple instances of a storage platform (eg, WinFS) for a hardware / software interface system, the computer-readable instructions comprising:
Instructions to divide the storage platform into basic precision units (eg, change units);
Instructions to enumerate changes sequentially and track said changes per change unit;
Instructions for each instance to track the state of changes to other known instances in the sync community (synchronization partner), as well as the state of changes to that instance;
A computer readable medium comprising: for synchronization, instructions for identifying new changes by comparing the listed changes for a particular instance with the status of changes for that instance.   The first instance, instructions that allow the replica to be instantiated on a hardware / software interface system that directly supports Item-based synchronization (WinFS), and the second instance, the data source is Item-based Further comprising instructions to be instantiated on a hardware / software interface system that does not directly support synchronization (non-WinFS) and the method virtualizes a non-WinFS instance via a synchronous processing application programming interface 25. The computer readable instructions of claim 24, further comprising using an adapter for the purpose.   The computer-readable instructions of claim 25, further comprising detecting synchronization conflicts at a modified unit accuracy level. An instance that reports success, failure, and / or conflict at the individual change unit level on the change application (synchronous data);
26. The computer readable instructions of claim 25, further comprising: applications that use synchronization data to update backend state, including but not limited to adapters and other synchronization control applications.   A computer readable medium for storing computer readable instructions for synchronizing a replica with a data source (for each synchronization partner), wherein both the replica and the data source are maintained by their respective synchronization partners The data source (non-WinFS) uses an adapter to interface with the hardware (software) system of the replica (WinFS), and the computer readable instructions include the last state information for the data source by the replica Updated status information for the replica reflecting changes made since the last synchronization ("new changes") as reflected in the last status information for the data source To the replica and the adapter Upon receiving the updated status information for the new change, includes instructions to implement as many changes as possible to the data source and track the success or failure of each change on the change unit by change unit A computer-readable medium characterized by the above.   Further comprising instructions for the hardware / software interface system (WinFS) of the replica to store the new state information for the data source for future use by the replica, wherein the adapter is on each change unit on a change unit basis. Has already calculated the new state of the data source based on the success or failure to the change, and has this new state information and sends this new state information to the hardware / software interface system (WinFS) of the replica 29. The computer readable instructions of claim 28, provided that: The adapter sends the success or failure for each change on a change unit to the hardware / software interface system (WinFS) of the replica for each change unit,
Instructions for the hardware / software interface system (WinFS) of the replica to calculate new state information for the data source based on the success or failure for each change to the data source on a change unit by change unit When,
The hardware / software interface system (WinFS) of the replica sends the new state information to the adapter, stores the new state information for future use by the replica, and the adapter receives the new state information. 29. The computer readable instructions of claim 28, further comprising instructions for enabling storage.

Images