KR20060117872A - Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system - Google Patents

Abstract

Several embodiments of the present invention employ synchronization adapters for synchronizing information between "WinFS" and non-"WinFS" data sources (3622/3666). Examples of adapters include an adapter that synchronizes address book information between a "WinFS" contacts folder and a non-WinFS mailbox (3642). In these instances, adapter developers might use the "WinFS" synchronization core services API described herein for accessing services provided by the " WinFS" (3612) synchronization platform in order to develop schema transformation code between the "WinFS" (3612) schema and the non-"WinFS" data source schema (3624). Additionally, the adapter developer provides protocol support for communicating changes with the non-"WinFS" data source. A synchronization adapter (3662) is invoked and controlled by using the synchronization controller API and reports progress and errors using this API (3652).

Description

System and method for providing synchronization service for units of information manageable by a hardware / software interface system

<Cross Reference>

This application discloses US patent application Ser. No. 10 / 692,515, entitled "System and Method for Providing Synchronization Services for Units of Information Manageable by Hardware / Software Interface System" filed Oct. 24, 2004 No. MSFT-2844); US Patent Application No. 10 / 646,575 entitled Agent Control No. MSFT-2733, filed August 21, 2003 entitled "System and Method for Interfacing Application Programs with Item-Based Storage Platforms"; And International Application No. PCT / US03 / 26150 (Attorney Control No. 2777) entitled "System and Methods for Interfacing Application Programs with Item-Based Storage Platforms," filed August 21, 2003. And the disclosures of these applications are incorporated herein by reference in their entirety.

This application is related to the inventions disclosed in the following assigned applications, and the contents of these applications are incorporated herein in their entirety (and partly summarized for convenience): 2003 US Patent Application No. 10 / 647,058 entitled "System and Method for Representing Units of Information Manageable by a Hardware / Software Interface System but Not Physically Representative," filed Aug. 21 -1748); U.S. Patent Application No. 10 / 646,941 filed on August 21, 2003 entitled "System and Method for Separating Units of Information Manageable by a Hardware / Software Interface System from Their Physical Mechanisms" (Agent Control Number MSFT- 1749); U.S. Patent Application No. 10 / 646,940 entitled "System and Method for Implementation of a Basic Schema for Organizing Units of Information Manageable by a Hardware / Software Interface System," filed August 21, 2003 MSFT-1750); US Patent Application No. 10 entitled "System and Method for Implementation of a Core Schema Providing a Top-Level Structure for Organizing Units of Information Manageable by a Hardware / Software Interface System", filed August 21, 2003 / 646,632 (agent management no. MSFT-1751); US Patent Application No. 10 / 646,645 entitled "System and Method for Expressing Relationships Between Units of Information Manageable by Hardware / Software Interface System," filed August 21, 2003 (Agent Control Number MSFT- 1752); US patent application Ser. No. 10 / 646,646 filed on August 21, 2003 entitled "Storage Platform for Systematization, Retrieval and Sharing of Data," Representative Application No. MSFT-2734; US Patent Application No. 10 / 646,580 entitled Agent Control No. MSFT-2735, filed Aug. 21, 2003, entitled "Systems and Methods for Data Modeling in Item-Based Storage Platforms"; US Patent Application No. 10 / 692,779, entitled "System and Method for the Implementation of a Digital Image Schema that Organizes Units of Information Manageable by a Hardware / Software Interface System," filed October 24, 2003 MSFT-2829); US Patent Application No. 10 / 692,508 entitled "System and Method for Providing Hierarchical Synchronization Services and Relationships to Units of Information Manageable by Hardware / Software Interface System, filed Oct. 24, 2003" Control number MSFT-2845); US Patent Application No. 10 / 693,362, entitled "System and Method for Implementation of a Synchronization Schema for Units of Information Manageable by a Hardware / Software Interface System," filed October 24, 2003 MSFT-2846); And US Patent Application No. 10 / 693,574 entitled "System and Method for Expansion and Inheritance of Units of Information Manageable by Hardware / Software Interface System," filed Oct. 24, 2003. MSFT-2847).

The present invention generally relates to the field of information storage and retrieval, and more particularly to an active storage platform for organizing, retrieving, and sharing different types of data in computerized systems.

Individual disk capacity has increased approximately 70% annually over the last decade. Moore's Law accurately predicted a remarkable increase in CPU performance over the years. Wired and wireless technologies provided tremendous connectivity and bandwidth. Assuming current trends continue, within a few years the average laptop computer will have a storage capacity of about 1 terabyte (TB), contain millions of files, and a 500 gigabyte (GB) drive will be common. .

Consumers use their computers primarily for the organization of communications and personal information, whether it is traditional personal information manager (PIM) style data or media such as digital music or photos. The amount of digital content, and the ability to store raw bytes, has increased tremendously, but the methods consumers can use to organize and integrate data have not kept pace. Knowledge workers spend an enormous amount of time managing and sharing information, and some studies estimate that knowledge workers spend 15-25% of their time on unproductive information-related activities. According to other studies, the average knowledge worker spends about 2.5 hours a day searching for information.

Developers and information technology (IT) sectors spend significant amounts of time and money building their own data stores for a common storage abstraction for representing things such as people, places, time and events. Not only does this cause redundant work, but it also creates islands of common data that have no mechanism for common retrieval or sharing of common data. Consider how many address books can exist today on a computer running the Microsoft Windows operating system. Many applications, such as email clients and personal accounting programs, maintain separate address books, and there is little sharing of applications for the address book data that each program maintains individually. As a result, the accounting program (e.g., Microsoft Money) does not share the address for the payee with the address stored in the email contact folder (e.g., the folder in Microsoft Outlook). Indeed, many users have a variety of devices and need to logically synchronize their personal data between themselves and to use services such as MSN and AOL through various additional sources, including mobile phones. By attaching them to an email message, ie manually and inefficiently.

One reason for this lack of collaboration is that traditional approaches to the organization of information in computer systems organize multiple files into a directory hierarchy of folders based on the abstraction of the physical organization of storage media used to store files. The focus has been on the use of file-folder-directory based systems ("file systems"). The Multics operating system, developed in the 1960s, can be thought of as pioneering the use of files, folders and directories to manage the units of data that can be stored at the operating system level. Specifically, Multics used symbolic addresses within the hierarchy of files (and thus introduced the idea of file paths), and the physical addresses of the files were not transparent to the user (application and end user). This file system was not interested in the file format of any individual file at all, and the relationships between the files were considered irrelevant at the operating system level (ie, not the location of the files in the hierarchy). Since the advent of multics, storable data has been organized into files, folders and directories at the operating system level. These files generally contain the file hierarchy itself ("directory") inserted into a special file maintained by the file system. This directory also maintains a list of entries corresponding to all of the other files in the directory, and the node location of these files in the hierarchy (referred to herein as folders). This has been the state of the technology for about 40 years.

However, the file system provides a reasonable representation of the information residing in the computer's physical storage system, but is nevertheless an abstraction of the physical storage system, so that the use of files is what the user manipulates (relations to context, features and other units). ) And an indirect (interpretation) level between what the operating system provides (files, folders, and directories). As a result, users (applications and / or end-users) can only choose to make units of information into a file system structure even if doing so is inefficient, inconsistent or undesirable. Moreover, existing file systems know little about the structure of the data stored in individual files, so that much of the information remains locked in files that can only be accessed (and understood) by the application that created them. As a result, the lack of an overview of this information and the lack of information management mechanisms leads to the creation of data stores where data is rarely shared between individual stores. For example, many PC users have five or more different repositories that contain information about people with whom they interact at a given level, such as Outlook contacts, online account addresses, Windows address books, Quicken Payees. And instant messaging (IM) buddy lists, because the organization of files presents a serious problem for PC users. Most existing file systems use nested folder metaphors to organize their files and folders, so as the number of files increases, the effort required to maintain a flexible and efficient organizing scheme has grown tremendously. In this situation, having various classifications for a single file would be very useful, but using hard or soft links in existing file systems is cumbersome and difficult to manage.

Several unsuccessful attempts to address the shortcomings of file systems have been made in the past. Some of these previous attempts involve the use of content addressable memory to provide a mechanism by which data can be accessed by content rather than by physical address. However, these efforts have proved unsuccessful, while content addressable memory has proven useful for small-scale use by devices such as caches and memory management units, while large-scale use in devices such as physical storage media has varied. This is because it is not yet possible for this reason, so such a solution does not exist. Other attempts have been made using the object-oriented database (OODB) system, but these features feature strong database characteristics and good non-file representations, but have not been effective in handling file representations, and are hardware / software interfaces. At the system level, the speed, efficiency and simplicity of file and folder-based hierarchies could not be replicated. Other efforts, such as those attempting to use SmallTalk (and other derivatives), are very effective at handling file and non-file representations, but lack the database capabilities needed to efficiently organize and use the relationships that exist between the various data files. Overall system efficiency has proven unacceptable. Another attempt to use BeOS (and other such operating system studies) is not appropriate for the handling of non-file representations (although they have the same core drawbacks as traditional file systems), although they can properly represent files while providing some necessary database functionality. ) Has been proven.

Database technology is another technical area where similar problems exist. For example, the relational database model has been a great commercial success, but in practice individual software vendors (ISVs) typically use a small portion of the functionality available in relational database software products (eg, Microsoft SQL Server). Instead, most of the application's interaction with these products is in the form of simple "gets" and "puts". There are many obvious reasons for this (eg, the platform or database is agnostic), but one important reason that is often overlooked is that databases do not always provide the exact abstraction that a major business application vendor really needs. For example, the real world has the concept of "items" such as "customers" or "orders" (with an embedded "line item" of an order as an item within and an item therein), but a relational database is merely a table and a row. Only speaks about. As a result, an application may want to have aspects of consistency, locks, security, and / or triggers at the item level (for example), but in general the database provides this functionality only at the table / row level. This may work well if each item is mapped to a single row within a table in the database, but for orders with multiple line items, there may be reasons why the item is actually mapped to multiple tables, In such cases, a simple relational database system does not provide the correct abstraction at all. As a result, the application must build logic on top of the database to provide this basic abstraction. In other words, the basic relationship model does not provide a sufficient platform for data storage where higher level applications can be easily developed because the basic relationship model requires an indirect level between the application and the storage system (where, The semantic structure of the data is only visible to the application at any given instance). Some database vendors are building higher levels of functionality into their products (eg, providing object relational capabilities, new organizational models, etc.), but none of them yet offer the kind of comprehensive solution they need, but truly comprehensive In solutions are solutions that provide both useful data model abstractions (eg, "items", "extensions", "relationships", etc.) and useful domain abstractions (eg, "persons", "locations", "events", etc.).

In view of the above deficiencies of existing data storage and database technology, a new storage platform, namely, existing file systems and database systems, which provides an improved ability to organize, search and share all types of data in computer systems, You need a storage platform designed to extend and extend your data platform and to be a repository for all types of data. The present invention satisfies this need with the related inventions incorporated by reference earlier in this specification.

The following summary provides an overview of various aspects of the invention described in connection with the related invention ("related invention") incorporated herein by reference. This Summary is not intended to provide a description that encompasses all of the important aspects of the invention, nor is it intended to limit the scope of the invention. Rather, this summary is intended to serve as an introduction to the following detailed description and drawings.

The invention as well as the related invention generally relates 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 is designed to be a repository for all types of data including structured data, unstructured data, or semi-structured data. It is.

The storage platform of the present invention includes a data store implemented on a database engine. The database engine includes a relational database engine with object relational extensions. The data store implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data. Specific types of data are described in the schema, and the platform provides a mechanism for extending the schema set to define new types of data (essentially subtypes of the base types provided by the schema). The synchronization capability makes it easy to share data between users or systems. File system-like capabilities are provided that allow the interworking of these conventional file systems with data storage without limitation to conventional file systems. The change tracking mechanism provides the ability to track changes to the data store. The storage platform also includes a set of application program interfaces that allow an application to access all of the aforementioned capabilities of the storage platform and to access data described in the schema.

The data model implemented by the data store defines the units of data storage by items, elements, and relationships. An item is a unit of data that can be stored in a data store and can contain one or more elements and relationships. An element is an instance of a type that includes one or more fields (also referred to herein as attributes). A relationship is a link between two items. (These and other specific terms used herein may be capitalized to separate them from other terms used in close proximity, but may be capitalized terms such as "Item" and the same term not capitalized, such as " There is no intention to distinguish between "items" and no differences should be assumed or implied.)

Each item constitutes a separate storeable information unit that can be operated by a hardware / software interface system, the computer system comprising: a plurality of items; A plurality of item folders constituting a systematic structure for the items; And a hardware / software interface system for manipulating a plurality of items, each item belonging to at least one item folder and belonging to one or more item folders.

Some of the item or its attribute values may be calculated dynamically as opposed to being derived from the persistent store. That is, the hardware / software interface system does not require the item to be stored, and has the ability to enumerate the current set of items, or to retrieve the item given its identifier for the storage platform (application programming interface). Or certain actions (such as described in more detail in the section describing the API), for example, the item may be the current location of the phone or the temperature read by the temperature sensor. The hardware / software interface system can manipulate a number of items and can further include items interconnected by a number of relationships managed by the hardware / software interface system.

The hardware / software interface system of the computer system further includes a core schema for defining a set of core items that the hardware / software interface system can understand and directly process in some predictable manner. To manipulate multiple items, a computer system interconnects the items with multiple relationships and manages the relationships at the hardware / software interface system level.

The storage platform's API provides data classes for each item, item extension, and relationship defined in the storage platform schema set. In addition, the API provides a set of framework classes that define a common set of behaviors for data classes and provide the basic programming model for the storage platform API with the data classes. The storage platform API provides a simplified query model that enables application programmers to form queries based on various attributes of items in the data store in a manner that isolates application programmers from information in the query language of the underlying database engine. . The storage platform API also collects changes to items made by the application program and then organizes them into the exact updates required by the database engine (or any kind of storage engine) in which the data store is implemented. This enables application programmers to change items in memory and to pass the complexity of data store updates to the API.

The storage platform of the present invention enables the development of more efficient applications for consumers, knowledge workers and enterprises through its common storage foundation and schematized data. Not only does this enable the capabilities unique to his data model, it also provides a rich and extensible API to accommodate and extend existing file system and database access methods.

As part of the foremost structure of these interrelated inventions (described in detail in section II of the detailed description), the present invention relates in particular to the synchronization API (described in detail in section III of the detailed description). Other features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings.

The foregoing summary and the following detailed description of the invention are better understood when read in conjunction with the accompanying drawings. To illustrate the invention, various embodiments of the invention are shown in the drawings, but the invention is not limited to the specific methods and instrumentalities disclosed.

1 is a block diagram illustrating a computer system in which aspects of the present invention may be implemented.

2 is a block diagram illustrating a computer system divided into three component groups: hardware components, hardware / software interface system components, and application program components.

2A illustrates a conventional tree-based hierarchy of files grouped in folders in a directory in a file-based operating system.

3 is a block diagram illustrating a storage platform.

4 is a diagram illustrating a structural relationship between items, item folders, and categories.

5A is a block diagram showing the structure of an item.

5B is a block diagram illustrating the complex attribute type of the item of FIG. 5A.

FIG. 5C is a block diagram illustrating a “location” item in which complex types are described in detail (explicitly listed).

6A is a diagram illustrating an item as a subtype of the item found in the base schema.

FIG. 6B is a block diagram illustrating the subtype item of FIG. 6A with inheritance types explicitly listed (in addition to direct attributes).

7 is a block diagram illustrating a base schema comprising two top level class types, namely Item and PropertyBase, and additional base schema types derived therefrom.

8A is a block diagram illustrating items in a core schema.

8B is a block diagram illustrating attribute types in a core schema.

9 is a block diagram illustrating an item folder, its member items, and an interconnect relationship between an item folder and its member items.

10 is a block diagram illustrating a category (again, the item itself), its member items, and an interconnection relationship between the category and its member items.

11 is a diagram illustrating a reference type hierarchy of a data model of a storage platform.

12 is a diagram illustrating how relationships are classified.

13 is a diagram illustrating a notification mechanism.

14 is a diagram illustrating an example in which two transactions insert a new record in the same B tree.

15 is a diagram illustrating a data change detection process.

16 is a diagram illustrating an exemplary directory tree.

17 is a diagram illustrating an example of moving an existing folder of a directory-based file system into a storage platform data store.

18 is a diagram illustrating the concept of an included folder.

19 is a diagram illustrating a basic structure of a storage platform API.

20 is a diagram schematically illustrating various components of a storage platform API stack.

21A is a diagram of an exemplary contact item schema.

FIG. 21B is a diagram of elements for the example contact item schema of FIG. 21A.

22 illustrates a runtime framework of the storage platform API.

Fig. 23 is a view showing execution of the "FindAll" operation.

24 is a diagram illustrating a process in which storage platform API classes are generated from a storage platform schema.

25 is a diagram illustrating a schema on which a file API is based.

26 is a diagram illustrating an access mask format used for data security.

27 (a, b, and c parts) is a diagram showing that a new security zone that is equally protected is separated from an existing security zone.

28 is a diagram illustrating the concept of an item search view.

29 is a diagram illustrating an exemplary item hierarchy.

FIG. 30A is a diagram illustrating interface Interface1 as a path through which first and second code segments communicate. FIG.

FIG. 30B shows the interface as including interface objects I1 and I2 that enable the first and second code segments of the system to communicate over the medium M. FIG.

FIG. 31A is a diagram illustrating how the functionality provided by interface Interface1 is subdivided into multiple interfaces Interface1A, Interface1B, and Interface1C to convert communication of the interface.

31B is a diagram showing how the functionality provided by interface I1 is subdivided into a number of interfaces I1a, I1b, I1c.

32A is a diagram illustrating a scenario in which meaningless parameter precision may be ignored or replaced with any parameter.

32B is a diagram illustrating a scenario in which an interface is replaced by an alternative interface defined to ignore an interface or add a parameter.

33A is a diagram illustrating a scenario in which first and second code segments are merged into a module including both of them.

33B illustrates a scenario in which some or all of the interfaces may be written inline within another interface to form a merged interface.

FIG. 34A is a diagram illustrating how one or more portions of middleware may translate them to adapt communications on a first interface to one or more different interfaces. FIG.

34B illustrates how a code segment can be introduced with an interface to receive communication from one interface but to transfer functionality to the second and third interfaces.

35A is a diagram illustrating how the Just-In-Time (JIT) compiler converts communication from one code segment to another code segment.

35B is a diagram illustrating that a JIT method that dynamically rewrites one or more interfaces may be applied to dynamically factorize or change the interface.

36 is a diagram illustrating three instances of a common data store and the components that synchronize them.

FIG. 37 is a diagram illustrating one embodiment of the present invention assuming a simple adapter that does not know how a state is calculated or associated metadata is exchanged.

Contents

I. Introduction

A. Example Computing Environment

B. Normal File-Based Storage

II. WINFS storage platform for organizing, searching, and sharing data

A. Glossary

B. Overview of Storage Platforms

C. Data Model

1. Item

2. Item Identification

3. Item Folders and Categories

4. Schema

a) basic schema

b) core schema

5. Relationship

a) relationship declaration

b) maintenance relationship

c) insertion relationship

d) reference relationships

e) rules and restrictions

f) relationship ordering

6. Scalability

a) item expansion

b) Nested element type extension

D. Database Engine

1. Data storage using UDT

2. Item Mapping

3. Extension Mapping

4. Nested Element Mapping

5. Object Identification

6. Naming SQL Objects

7. Column Naming

8. 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) relationships

(1) Master Relationship Search View

(2) relationship instance search view

e)

9. Renewal

10. Change tracking and tombstone

a) change tracking

(1) Change tracking in the "master" search view

(2) Change tracking in "typed" search views

b) tombstone

(1) item tombstone

(2) tombstone

(3) relationship tombstone

(4) tombstone elimination

11. Helper APIs 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. Notice and Change Tracking

G. Normal File System Interoperability

H. Storage Platform API

III. Sync API

A. Overview of Synchronization

1. Storage platform vs storage platform synchronization

a) Sync control application

b) schema annotation

c) Sync configuration

(1) community folder-mapping

(2) profile

(3) Schedule

d) conflict handling

(1) collision detection

(a) knowledge base conflict

(b) restriction-based conflicts

(2) conflict handling

(a) Automatic conflict resolution

(b) conflict logging

(c) collision detection and resolution

(d) dissemination of copies and dissemination of conflict resolution;

2. Synchronize for non-storage platform data store

a) synchronization service

(1) change enumeration

(2) apply changes

(3) conflict resolution

b) adapter implementation

3. Security

4. Manageability

B. Overview of the Sync API

1. General Terminology

2. The principle of the synchronization API

C. Sync API Service

1. Change enumeration

2. Apply changes

3. Sample Code

4. Method of API Synchronization

D. Additional Aspects of the Synchronization Schema

IV. conclusion

I. Introduction

The subject matter of the present invention is specifically described to satisfy legal requirements. However, the description itself is not intended to limit the scope of the invention. Rather, the inventors have contemplated that the claimed subject matter may be embodied in other manners, including other steps or combinations of steps similar to those described herein, along with other current or future technologies. Moreover, although the term "step" may be used herein to mean different elements of the methods of use, this term refers to any particular between various steps except when the order of individual steps is explicitly stated. It should not be construed as meaning an order.

A. Example Computing Environment

Various embodiments of the invention may be implemented on a computer. 1 and the following description are intended to provide a brief general description of a suitable computing environment in which the present 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. Moreover, the present invention may be practiced in 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 may be located in both local and remote memory storage devices.

As shown in FIG. 1, an exemplary general-purpose computing system includes a system bus 23 that couples various system components, including the processing unit 21, system memory 22, and system memory, to the processing unit 21. Ordinary personal computer 20, and the like, which are included. The system bus 23 may be one of several types of bus architectures including a memory bus or a memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes a ROM 24 and a RAM 25. BIOS 26 is stored in ROM 24 that includes, for example, a basic routine to help transfer information between elements in personal computer 20 during startup. The personal computer 20 includes a hard disk drive 27 for reading and writing to a hard disk not shown, a magnetic disk drive 28 for reading and writing to a removable magnetic disk 29 not shown, and a CD. It may further comprise an optical disc drive 30 for reading and writing to a removable optical disc 31, such as a ROM or other optical medium. The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are each connected to a system bus by the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical disk drive interface 34. 23). The drives and associated computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for the personal computer 20. Although the exemplary environment described herein uses a hard disk, a removable magnetic disk 29 and a removable optical disk 21, it may be used by a computer such as a magnetic cassette, flash memory card, DVD, Bernoulli cartridge, RAM, ROM, or the like. Those skilled in the art should understand that other types of computer readable media capable of storing data that can be accessed may also be used in the exemplary computing environment. Likewise, example environments may include many types of monitoring devices, such as thermal sensors and security or fire alarm systems, and other sources of information.

A number of program modules, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38, may include hard disks, magnetic disks 29, optical disks 31, ROMs. 24 or RAM 25. A user may enter commands and information into the personal computer 20 through input devices such as keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 via a serial port interface 46 that is coupled to the system bus, but may be connected via another interface, such as a parallel port, game port or USB. A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, personal computers generally include other peripheral output devices (not shown) such as speakers and printers. The example system of FIG. 1 also includes a host adapter 55, a SCSI bus 56, and external storage 62 connected to the SCSI bus 56.

Personal computer 20 may operate in a network environment using logical connections to one or more remote computers, such as remote computer 49. Remote computer 49 may be another personal computer, server, router, network PC, peer device, or other common network node, although only memory storage device 50 is shown in FIG. 1, but generally with personal computer 20. It includes most or all of the elements described above in connection with. The logical connection shown in FIG. 1 includes a LAN 51 and a WAN 52. Such networking environments are commonplace in offices, corporate computer networks, intranets and the Internet.

The personal computer 20 is connected to the LAN 51 via a network interface or adapter 53 when used in a LAN networking environment. Personal computer 20 generally includes a modem or other means for establishing communications over WAN 52, such as the Internet, when used in a WAN networking environment. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules or portions thereof described in connection with personal computer 20 may be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means for establishing a communications link between the computers can be used.

As shown in the block diagram of FIG. 2, computer system 200 can be divided into three major groups of components: hardware component 202, hardware / software interface system component 204, and application program component 206 (as described herein). In some situations, also referred to as "user component" or "software component".

In various embodiments of computer system 200, and referring again to FIG. 1, hardware component 202 may include CPU 21, memory (ROM 24 and RAM 25), BIOS 26, and in particular Various input / output (I / O) devices such as keyboard 40, mouse 42, monitor 47 and / or printer (not shown) may be included. Hardware component 202 includes a basic physical infrastructure for computer system 200.

The application program component 206 includes a variety of software programs, including but not limited to compilers, database systems, word processors, business programs, video games, and the like. Application programs provide a means of using computer resources to solve problems, provide solutions, and process data of various users (machines, other computer systems, and / or end users).

The hardware / software interface system component 204 most often includes an operating system (OS) that itself includes a shell and a kernel (and in some embodiments consists solely of an operating system). An OS is a special program that acts as an intermediary between an application program and computer hardware. The hardware / software interface system component 204 also replaces or replaces a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or a functional equivalent thereof, or an operating system within a computer system. In addition, it may include other such software components. The purpose of the hardware / software interface system is to provide an environment in which a user can execute an application program. The purpose of any hardware / software interface system is to use the computer hardware in an efficient manner as well as to make the computer system convenient to use.

The hardware / software interface system is generally loaded into the computer system at startup and then manages all application systems within the computer system. The application program interacts with the hardware / software interface system by requesting a service through an API. Some application programs allow end users to interact with a hardware / software interface system through a user interface such as a command language or a GUI.

Hardware / software interface systems typically perform various services for applications. In a multitasking hardware / software interface system in which multiple programs can run simultaneously, the hardware / software interface system determines which applications should be executed in what order and how many for each application before switching to another application for alternation. Determine if time should be allocated. The hardware / software interface system also manages the allocation of internal memory among multiple applications, and handles input and output to attached hardware devices such as hard disks, printers, and dial-up ports. The hardware / software interface system also sends a message to each application (and in some cases, the end user) about the status of the operation and any errors that may have occurred. The hardware / software interface system can also offload the management of batch jobs (eg printing), allowing the initiating application to be freed from these jobs and resume other processing and / or operations. On a computer capable of providing parallel processing, the hardware / software interface system also manages the division of the program so that the program runs simultaneously on two or more processors.

The hardware / software interface system shell (herein simply referred to as "shell") is an interactive end user interface to the hardware / software interface system. (A shell may also be referred to as a "command interpreter" or "operating system shell" in the operating system.) A shell is an outer layer of a hardware / software interface system that can be accessed directly by applications and / or end users. Unlike the shell, the kernel is the inner layer of the hardware / software interface system that interacts directly with the hardware components.

While various embodiments of the invention are deemed particularly suitable for computerized systems, nothing herein is intended to limit the invention to these embodiments. Alternatively, the term "computer system" as used herein may store and process information regardless of whether the devices are in fact electronic, machine, logical or virtual devices, and / or use the stored information to determine the behavior or behavior of the device itself. It is intended to include any and all devices capable of controlling the execution.

B. Normal File-Based Storage

In most computer systems today, a "file" is a unit of storage information that can include a hardware / software interface system as well as application programs, data sets, and the like. In all modern hardware / software interface systems (Windows, Unix, Linux, Mac OS, virtual machine systems, etc.), files are the basic discrete pieces of information (eg, data, programs, etc.) that can be manipulated by the hardware / software interface system. Units can be stored and searched. File groups are usually organized in folders. In Microsoft Windows, Macintosh OS, and other hardware / software interface systems, a folder is a collection of files that can be retrieved, moved, and manipulated as a single unit of information. In addition, these folders are organized in a tree-based hierarchy called directories (described below). In some other hardware / software interface system, such as DOS, z / OS, and most Unix-based operating systems, the terms "directory" and / or "folder" are used interchangeably and may be used in conjunction with early Apple computer systems (e.g., , Apple IIe) used the term "catalog" instead of directories, but as used herein, all of these terms are considered synonymous and interchangeable and refer to hierarchical information storage structures and their folder and file components. It is intended to further include all other equivalent terms and references.

Typically, a directory (directory of folders) is a tree-based hierarchy in which files are grouped into folders and folders are arranged according to the relative node location that contains the directory tree. For example, as shown in FIG. 2A, the DOS-based file system default folder (or “root directory”) 212 may include a number of folders 214, each of which may also include additional folders (specific folders). 216), each of which may also include additional folders 218 (which can be repeated indefinitely). Each of these folders may have one or more files 220 at the hardware / software interface system level, although the individual files in the folder may have nothing in common other than their location in the tree hierarchy. Not surprisingly, this approach to organizing files within a folder hierarchy indirectly reflects the physical organization of common storage media (eg, hard disks, floppy disks, CD-ROMs, etc.) used to store these files.

In addition to the foregoing, each folder is a container for its subfolders and their files, ie each folder owns its subfolders and files. For example, when a folder is deleted by the hardware / software interface system, its subfolders and files are also deleted (for each subfolder, it further includes its own subfolders and files repeatedly). Similarly, each file is typically owned by only one folder, and the file can be copied and the copy can be located in another folder, but the copy of the file itself is a different, separate unit that does not have a direct connection with the original. (For example, changes to the original file are not reflected in the copy file at the hardware / software interface system level). In accordance with this relationship, files and folders are "physical" in nature because the folder is treated like a physical container and the files are treated as different and separate physical elements within this container.

II. WINFS storage platform for organizing, searching, and sharing data

The present invention relates to a storage platform for organizing, retrieving, and sharing data with the related inventions incorporated herein by reference as described earlier. The storage platform of the present invention is designed to extend and expand the data platform beyond the types of existing file systems and database systems described above, and to be a repository for all data types, including new data types called items.

A. Glossary

The following terms used in the present specification and claims have the following meanings.

"Item" is a unit of storable information that can be accessed by the hardware / software interface system and, unlike a simple file, is commonly supported across all objects exposed to the end user by the hardware / software interface system shell. An object with a set of default attributes. An item also has attributes and relationships that are commonly supported across all item types, including features that allow new properties and relationships to be introduced (described below).

"Operating System (OS)" is a special program that functions as an intermediary between an application program and computer hardware. The OS in most cases includes a shell and a kernel.

A "hardware / software interface system" is software or a combination of hardware and software that functions as an interface between the underlying hardware components of a computer system and the applications running on the computer system. The hardware / software interface system generally includes an operating system (and in some embodiments consists solely of an operating system). The hardware / software interface system may also be such software in place of or in addition to a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or functional equivalent thereof, or an operating system within a computer system. It may include a component. The purpose of the hardware / software interface system is to provide an environment in which a user can execute an application program. The purpose of any hardware / software interface system is to use the computer hardware in an efficient manner as well as to make the computer system convenient to use.

B. Overview of Storage Platforms

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

The change tracking mechanism 306 implemented within the data store 302 provides the ability to track changes to the data store. Data store 302 also provides security capability 308 and promotion / demotion capability 310, both of which are described below. The data store 302 also provides a set of APIs 312 for exposing the capabilities of the data store 302 to other storage platform components and application programs (eg, application programs 350a, 350b, 350c) that use the storage platform. do. The storage platform of the present invention further includes an API 322 that allows an application program, such as the application program 350a, 350b, 350c, to access all the capabilities of the storage platform described above and to access data described in the schema. . The storage platform API 322 may be used by the application program in conjunction with other APIs such as the OLE DB API 324 and the Microsoft Windows Win32 API 326.

The storage platform of the present invention can provide a variety of services 328 to application programs, including a synchronization service 330 that facilitates data sharing between users or systems. For example, the synchronization service 330 may enable interworking with other data stores 340 having the same format as the data store 302 as well as access to data stores 342 having other formats. The storage platform 300 also provides file system capabilities that allow for interworking of the data store 302 with existing file systems such as the Windows NTFS file system 318. In at least some embodiments, storage platform 300 may also provide application programs with additional capabilities to enable data to operate on other systems and to interact with other systems. These capabilities may be implemented in the form of additional services 328, such as information agent service 334 and notification service 332, as well as other utilities 336.

In at least some embodiments, the storage platform is implemented within or forms an integral part of the hardware / software interface system of the computer system. For example, and without limitation, the storage platform of the present invention may be implemented within, or form part of, an operating system, a virtual machine manager (VMM), a CLR or a functional equivalent thereof, or a JVM or a functional equivalent thereof. The storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises through its common storage foundation and schematized data. The storage platform not only makes available the capabilities inherent in its data model, but also provides a rich and extensible programming surface area that accommodates and extends existing file system and database access methods.

In the following description, and in the various figures, the storage platform 300 of the present invention may be referred to as "WinFS". However, the use of names to refer to such storage platforms is for convenience of description 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 residing in the store. In the data model of the present invention, an "item" is a basic unit of stored information. The data model provides a mechanism for declaring items and item extensions, establishing relationships for items, and organizing items into item folders and into categories, as described below.

The data model depends on two basic mechanisms: type and relationship. Types are structures that provide a format that governs the type of instances of a type. The format is represented as a set of ordered attributes. An attribute is a name for a value or set of values of a given type. For example, the USPostalAddress type may have attributes of Street, City, Zip, and State, where Street, City, and State are string types, and Zip is an Int32 type. Street may be multivalent (ie, a set of values), allowing an address to have more than one value for the Street attribute. The system defines certain base types that can be used for other types of construction, including String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DataTime, Decimal and GUID. Attributes of a type may be defined using either one of the base types or any of the built types (with certain restrictions described below). For example, a location type with coordinate and address attributes can be defined, where the address attribute is of type USPostalAddress. The attributes may also be required or optional.

A relationship can be declared between sets of two types of instances, representing a mapping between them. For example, a relationship can be declared between a person type and a location type called LivesAt, which defines which locations live in which locations. The relationship has a name, two endpoints, a source endpoint and a target endpoint. A relationship can also have a set of ordered attributes. Both source and target endpoints have a name and type. For example, a LivesAt relationship has a target called a dwelling of a source type and a location type called a dweller of a person type, and also has a StartDate and EndDate attribute indicating the length of time the dweller has lived in the dwelling. People can live in multiple dwellings over time, and dwellings can have multiple dwellers, so the most likely place to put StartDate and EndDate information is the relationship itself.

Relationships define the mapping between instances that are limited by a given type to an endpoint type. For example, the LivesAt relationship cannot be a car-resident relationship, because the car is not a person.

The data model allows the definition of subtype-supertype relationships between types. The subtype-supertype relationship, also known as the BaseType relationship, is defined in such a way that when all the instances of B are also instances of A, where type A is the BaseType for type B. Another way to express this is that every instance following B must also follow A. For example, if A has an attribute name of type string and B has an attribute age of type Int16, then any instance of B must have both a name and an age. A type hierarchy can be thought of as a tree with a single supertype at the root. Branches from the root provide subtypes of the first level, which provide subtypes of the second level, and so on, up to the terminal subtype which itself does not have any subtypes. The tree is not limited to having a uniform depth, but may contain no circulation. A given type may have zero or many subtypes and zero or one supertype. A given instance can depend on at most one type and its supertypes. As another method, for a given instance of any level in the tree, this instance may conform to at most one subtype at that level. A type is said to be abstract when instances of that type must also be instances of subtypes of that type.

1. Item

An item is a unit of storable information that, unlike a simple file, is an object with a basic set of attributes that is commonly supported across all objects exposed to the end user or application program by the storage platform. An item also has properties and relationships that are commonly supported across all item types, including features that allow new properties and relationships to be introduced, as described below.

Items are objects for common operations such as copy, delete, move, open, print, backup, restore, duplicate, and so on. An item is a unit that can be stored and retrieved, and all forms of storeable information manipulated by the storage platform exist as items, attributes of items, or relationships between items, each of which will be described later.

An item represents an easily understandable unit of the real world of data such as contact, person, service, location, document (all various kinds), and the like. 5A is a block diagram showing the structure of an item. The unique name of the item is "location". The qualified name of an item is "Core.Location", which indicates that the structure of this item is defined as a specific type of item in the core schema. (The core schema will be described later.)

Location entries have a number of attributes including EAddress, MetropolitanRegion, Neighborhood, and PostalAddress. The specific type of attribute for each is shown immediately after the attribute name and is separated from the attribute name by a colon (":"). On the right side of the type name, the number of allowed values for that attribute type is shown between square brackets ("[]"), with an asterisk ("*") on the right side of the colon unspecified and / or unrestricted number ("many"). ). "1" to the right of the colon indicates that at most one value can be present. Zero ("0") to the left of the colon indicates that the attribute is optional (no value may be present). "1" to the left of the colon indicates that at least one value must be present (attribute required). Neighborhood and MetropolitanRegion are both "nvarchar" (or equivalent) types, which are either predefined data types or "simple types" (and shown without capitalization herein). However, EAddress and PostalAddress are attributes of the defined type or “composite type” (here indicated by capitalization) of the EAddress and PostalAddress types, respectively. A complex type is a type derived from one or more simple data types and / or other complex types. The complex type for the attributes of an item also constitutes a "nesting element", in which the details of the complex type are nested directly within the item to define its attributes, and information about the complex type is accompanied by an item with these attributes ( This is because it is maintained within the boundary of the item as described later. The concept of such typing is known and easily understood by those skilled in the art.

5B is a block diagram illustrating PostalAddress and EAddress, which are complex attribute types. The PostalAddress attribute type may be expected that an item of the PostalAddress attribute type has a City value of 0 or 1, a CountryCode value of 0 or 1, a MailStop value of 0 or 1, and any number (0 to many) PostalAddressType, and so forth. In this way, the shape of the data for a particular attribute in an item is defined accordingly. The EAddress attribute type is defined similarly to that shown. Although optionally used herein, another way to represent a complex type in a location item is to draw the item with the individual attributes of each complex type listed therein. 5C is a block diagram illustrating a location item in which complex types are further described. However, it should be understood that this alternative representation of the location item in FIG. 5C is for the exact same item as shown in FIG. 5A. The storage platform of the present invention also allows for subtypes, whereby one attribute type can be a subtype of another attribute type (one attribute type inherits attributes of another parent attribute type).

Similar to the attributes and their attribute types, but differently, the entries uniquely represent their own item types, which may be the subject of the subtyped. That is, the storage platform in various embodiments of the present invention allows an item to be a subtype of another item (whereby one item inherits the attributes of another parent item). Moreover, in various embodiments of the present invention, all items are subtypes of the "item" item type, which are the first and basic item types found in the base schema. (Basic schema is also described later). 6A shows an item that is a subtype of the Item item type found in the base schema, and a location item within this instance. In this figure, the arrow indicates that the location item (as with all other items) is a subtype of the Item item type. The Item item type, which is the base item from which all other items are derived, has a number of important properties, such as ItemId and various time stamps, thereby defining the standard properties of all items within the operating system. In this figure, the properties of this Item item type are inherited by the location, thereby becoming the property of the location.

Another way to express the properties of a location item inherited from the Item type is to draw the location with the individual properties of each property type from the parent item listed in it. 6B is a block diagram illustrating a location item in which inherited types in addition to direct attributes are described. In this figure, the position, along with all of its attributes, i.e., the direct attribute shown in both this figure and FIG. 5A, and which is shown in this figure but not in FIG. 5A (whereas in FIG. Note that these properties are referenced by indicating that they are subtypes), with inherited properties shown, but it should be noted and understood that this location item is the same item as shown in FIG. 5A.

An item is an independent object, so when you delete an item, both its direct and inherited attributes are also deleted. Likewise, when retrieving an item, what is received is the item and all its direct and inherited attributes (including information about their compound attribute types). While certain embodiments of the present invention make it possible to require a subset of attributes when searching for a particular item, the default for many of these embodiments is to provide the item with all its direct and inherited attributes in the search. Moreover, an item's attributes can also be extended by adding new attributes to existing attributes of the item's type. This "extension" then becomes the true attribute of the item, and the subtype of that item may automatically include the extension attribute.

The "boundary" of an item is represented by its attributes (including complex attribute types, extensions, etc.). The boundary of an item also expresses the limits of the actions performed on the item, such as copying, deleting, moving, creating, etc. For example, in various embodiments of the invention, when an item is copied, everything within that item's bounds is also copied. For each item, the boundary includes:

The item type of the item, and if the item is a subtype of another item (as in the case of various embodiments of the invention, where all items are derived from a single item and item type in the base schema), any applicable subtype information ( That is, information about the parent item type). If the original item to be copied is a subtype of another item, the copy may also be a subtype of the same item.

• the complex type attribute and extension of the item, if any. If the original item has a property of a complex type (raw or extended), the copy may have the same complex type.

A record of the "ownership" of an item, i.e., a list of the item itself, indicating which other item (target item) this item owns. This is particularly relevant to item folders as described below, and the rule below indicates that all items must belong to at least one item folder. Moreover, with regard to the insertion item described later, the insertion item is considered as part of the item into which the insertion item is inserted for an operation such as copying, deleting, and the like.

2. Item Identification

An item is uniquely identified within the global item space by ItemID. Base.Item type defines the field ItemID of the type GUID that stores the identifier for the item. The item must have exactly one identifier in the data store 302.

An item reference is a data structure that contains information for finding and identifying an item. In the data model, an abstract type named ItemReference is defined from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves an ItemReference and returns an item. This method is overridden by concrete subtypes of ItemReference that implement a function to retrieve an item when given a reference. The Resolve method is called as part of the storage platform API 322.

ItemIDReference is a subtype of ItemReference. This defines the Locator and ItemID fields. The Locator field names (ie, identifies) the item domain. This is handled by the Locator analysis method, which can resolve the value of the Locator for the item domain. The ItemID field is of ItemID type.

ItemPathReference is a special form of ItemReference that defines Locator and Path fields. The Locator field identifies the entry domain. This is handled by the Locator analysis method, which can resolve the value of the Locator for the item domain. The Path field contains the (relative) path in the storage platform namespace rooted at the entry domain provided by the Locator.

This type of reference cannot be used in set operations. References should generally be resolved through the path analysis process. The Resolve method of the storage platform API 322 provides this functionality.

The aforementioned reference type is represented through the reference type hierarchy shown in FIG. 11. Additional reference types inheriting from these types can be defined in the schema. These can be used as the type of the target field in the relationship declaration.

3. Item Folders and Categories

As described later, item groups are organized in special items called item folders (not to be confused with file folders). However, unlike most file systems, an item can belong to more than one item folder, so when an item is accessed and modified in one item folder, this modified item can be accessed directly from another item folder. In essence, access to an item may be from different item folders, but what is actually accessed is actually the same item. However, an item folder does not necessarily own all of its member items or may simply share items with other folders, so deletion of an item folder does not necessarily result in deletion of an item. Nevertheless, in various embodiments of the present invention, an item must belong to at least one item folder, so when the only item folder for a particular item is deleted, in some embodiments the item is automatically deleted, or in other embodiments This automatically becomes a member of the default item folder (eg, the "Trash Can" item folder conceptually similar to the similarly named folders used in various file-folder based systems).

As further described below, an item may also be associated with (a) an item type (or types), (b) a specific direct or inherited property (or properties), or (c) a specific value (or values) corresponding to the item property. It may belong to a category based on the same common technical characteristics. For example, an item that includes a particular attribute for personal contact information may automatically belong to the Contact category, and any item with a contact information attribute will automatically belong to this category. Similarly, any item with a location attribute of "New York City" value may automatically belong to the NewYorkCity category.

Categories are conceptually different from item folders, where item folders may contain items that are not related to each other (ie, they do not have common technical characteristics), while each item within a category has a common type, attribute, or value described for that category. It is because of this commonality that has (commonity) and forms the basis for the relationships between and within the categories. Moreover, while a member of an item within a particular folder is not forcibly based on any particular aspect of that item, in some embodiments all items with commonalities that are absolutely related to the category are automatically at that hardware / software interface system level. Can be a member of Conceptually, a category may also be considered a virtual item folder with members based on the results of a particular query (eg, with respect to a database), thus satisfying the conditions of this query (defined by category commonality). The items to be included include members of the category.

4 shows the structural relationship between items, item folders and categories. Multiple items 402, 404, 406, 408, 410, 412, 414, 416, 418, 420 are members of various item folders 422, 424, 426, 428, 430. Some items may belong to more than one item folder, for example item 402 belongs to item folders 422 and 424. Some items, such as items 402, 404, 406, 408, 410, and 412, are also members of one or more categories 432, 434, and 436, and other items, for example, items 414, 416, 418, and 420 (However, this is rarely possible in some embodiments where ownership of any attribute automatically means a member in a category, and therefore an item must be completely uncharacteristic in order for an item not to be a member of any category). . Unlike the hierarchical structure of folders, both category and item folders have a more similar structure to the direction graph as shown. In any event, the item, item folder, and category are all items (the item types are different).

Unlike files, folders, and directories, items, item folders, and categories of the present invention are not "physical" in nature because they do not have the conceptual equivalent of a physical container, and therefore items may exist in more than one location. The ability for items to be present in more than one item folder location and to be organized within categories provides an enhanced and rich data manipulation and storage structure capability at the hardware / software interface system level beyond what is currently available in the art.

4. Schema

a) basic schema

To provide a universal basis for the creation and use of items, various embodiments of the storage platform of the present invention include a basic schema that sets up a conceptual framework for creating and organizing items and attributes. The base schema defines certain special types of items and attributes, and the characteristics of these special base types from which subtypes can be further derived. The use of this base schema allows the programmer conceptually to distinguish between items (and their respective types) and attributes (and their respective types). Moreover, the base schema describes a base set of attributes that all items can own when all items (and their corresponding item types) are derived from the base items (and corresponding item types) in the base schema.

As shown in FIG. 7 and with respect to various embodiments of the present invention, the base schema defines three top-level types, Item, Extension and PropertyBase. As shown, the item type is defined by the attributes of the basic "item" item type. In contrast, the top level property type "PropertyBase" has no predefined properties, it is just an anchor from which all other property types are derived and all derived property types are correlated (collected from a single property type). . The extension type attribute defines not only which item the extension extends, but also an identifier that can distinguish one extension from another when an item can have multiple extensions.

ItemFolder is a subtype of the Item item type that features a relationship for establishing a link to its members (if any) in addition to the properties inherited from the item. IdentityKey and Property are subtypes of PropertyBase. Also, CategoryRef is a subtype of IdentityKey.

b) core schema

Various embodiments of the storage platform of the present invention further include a core schema that provides a conceptual framework for the top level item type structure. 8A is a block diagram illustrating an item in a core schema, and FIG. 8B is a block diagram illustrating an attribute type in a core schema. In file-folder based systems, the differences between files with different extensions (* .com, * .exe, * .bat, * .sys, etc.) and other criteria are similar to functions in the core schema. In an item based hardware / software interface system, the core schema may be directly (by item type) or indirectly (by item subtype) understood and directly processed by the item based hardware / software interface system in some predictable manner. One or more core schema item types that define a set of core item types that characterize all items. Predefined item types reflect the most common items in an item-based hardware / software interface system, so that some level of efficiency is achieved by an item-based hardware / software interface system that understands a predefined item type that includes the core schema. Obtained.

In certain embodiments, the core schema is not extensible, that is, no additional item type can be directly subtyped from an item type in the base schema except for certain predefined and derived specific item types that are part of the core schema. By preventing extensions to the core schema (that is, by preventing the addition of new items to the core schema), the storage platform dictates the use of core schema item types, which means that all subsequent item types must be subtypes of the core schema item type. Because it is. This structure allows for a reasonable degree of flexibility in defining additional item types while maintaining the benefits of having a predefined set of core item types.

In various embodiments of the present invention, and with reference to FIG. 8A, a particular item type supported by the core schema includes one or more of the following.

Category: Items of this item type (and subtypes derived therefrom) represent categories that are valid in an item based hardware / software interface system.

Commodity: An item whose value can be identified.

ㆍ Device: Item with a logical structure that supports information processing capability

Document: An item whose content is not interpreted by the item-based hardware / software interface system, but instead interpreted by the application program corresponding to the document type.

Event: Item that records a certain occurrence in the environment

Location: An item representing a physical location (eg, geographic location).

Message: A communication item between two or more principles (defined below).

Principal: an item with at least one identifier (eg, an identifier of a person, organization, group, generation, author, service, etc.) that can be clearly identified separately from the ItemID.

Statement: An item with special information about the environment, including, without limitation, policies, subscriptions, certifications, etc.

Likewise, and with reference to FIG. 8B, a particular attribute type supported by the core schema may include one or more of the following.

Certificate (derived from the base PropertyBase type in the base schema)

Principal Identity Key (derived from the IdentityKey type in the base schema)

Postal Address (derived from the attribute type in the base schema)

Rich Text (derived from attribute type in base schema)

EAddress (derived from the attribute type in the base schema)

IdentitySecurityPackage (derived from the relationship type in the base schema)

RoleOccupancy (derived from the relationship type in the base schema)

BasicPresence (derived from the relationship type in the basic schema)

These items and attributes are also described by their respective attributes described in FIGS. 8A and 8B.

5. Relationship

A relationship is a binary relationship in which one item is specified as the source and the other item is targeted. Source items and target items are related by relationship. Source items generally control the lifetime of a relationship. That is, when a source item is deleted, the relationship between the items is also deleted.

Relationships are classified into include and reference relationships. Inclusion relationships control the lifetime of target items, while reference relationships do not provide any life management semantics. 12 illustrates how the relationships are classified.

Inclusion relationship types are further classified into maintenance and insertion relationships. When all maintenance relationships for an item are removed, the item is deleted. The maintenance relationship controls the life of the target through a reference counting mechanism. Insertion relationships allow the modeling of complex items and can be considered as exclusive maintenance relationships. An item may be a target of one or more maintenance relationships, but an item may be a target of only one insertion relationship. An item that is a target of an insertion relationship cannot be a target of any other maintenance or insertion relationship.

Reference relationships do not control the life of the target item. The reference relationship may be in the air, i.e., 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).

The withdrawal of an item does not automatically withdraw its relationship. The application must explicitly request the relationship of items. Also, modifying a relationship does not modify the source or target item, and similarly, adding a relationship does not affect the source / target item.

a) relationship declaration

Explicit relationship types are defined with the following elements:

Relationship name is specified within the name attribute.

The relationship type is one of the following: hold, insert, reference. This is specified within the type attribute.

Source and target endpoints. Each endpoint specifies the name and type of the referenced item.

The source endpoint field is typically of type ItemID (not declared) and must reference an item in the same data store as the relationship instance.

For maintenance and insertion relationships, the target endpoint field must be of type ItemIDReference and must reference an item in the same repository as the relationship instance. For reference relationships, the target endpoint can be of any ItemReference type and can reference items in other storage platform data stores.

Optionally, one or more fields of scalar or PropertyBase type can be declared. These fields may contain data related to the relationship.

Relationship instances are stored in the global relationship table.

Every relationship instance is uniquely identified by a combination (source ItemID, relationship ID). Relationship IDs are unique within a given source ItemID for all relationships that have a source on a given item, regardless of their type.

The source item is the owner of the relationship. While the item designated as the owner controls the lifetime of the relationship, the relationship itself is separated from the item to which it relates. Storage platform API 322 provides a mechanism for exposing a relationship associated with an item.

The following is an example of a relationship declaration:

This is an example of a reference relationship. The relationship cannot be created if there is no person entry referenced by the source reference. Also, when a person entry is deleted, the relationship instance between the person and the organization is deleted. However, when an organization item is deleted, the relationship is not deleted but becomes in the air.

b) maintenance relationship

Maintenance relationships are used to model reference number based life management of target items.

An item can be the source endpoint of a relationship to zero or more items. Items that are not inserted items may be targets of one or more maintenance relationships.

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

The maintenance relationship enforces lifecycle management of the target endpoint. The creation of a maintenance relationship instance and the item it targets is an atomic operation. Additional maintenance relationship instances can be created that target the same item. If the final maintenance relationship instance with the item given as the target endpoint is deleted, the target item is also deleted.

The type of endpoint entry specified in the relationship declaration is usually enforced when an instance of the relationship is created. The type of the endpoint item cannot be changed after the relationship is established.

Maintenance relationships play an important role in the formation of the item namespace. These include a "name" attribute that defines the name of the target item for the source item. This relative name is unique for all maintenance relationships that source the given item. The ordered list of relative names from the root item to the given item forms the complete name for the item.

The maintenance relationship forms a directional acyclic graph (DAG). When a maintenance relationship is created, the system ensures that no item namespace forms a DAG by ensuring that no recursion is created.

While the maintenance relationship controls the lifetime of the target item, it does not control the behavioral consistency of the target endpoint item. The target item is operationally independent from the item that owns the target item through a maintenance relationship. Copying, moving, backing up, and other actions on items that are the source of a maintenance relationship do not affect items that are targets of the same relationship, for example, backing up a folder item means that all items within the folder (targets of the FolderMember relationship) Does not back up automatically.

The following is an example of a maintenance relationship.

The FolderMember relationship enables the concept of folders as a collection of common items.

c) insertion relationship

Insertion relationships model the concept of exclusive control of the lifetime of a target item. Insertion relationships enable the concept of compound items.

The creation of an insert relationship instance and the item it targets is a minimal action. An item can be a source of zero or more insertion relationships. However, an item may be a target of one and only one insertion relationship. An item that is a target of an insertion relationship cannot be a target of a maintenance relationship.

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

The type of endpoint entry specified in the relationship declaration is usually enforced when an instance of the relationship is created. The type of the endpoint item cannot be changed after the relationship is established.

The insertion relationship controls the behavioral consistency of the target endpoint. For example, the serialization operation of an item may include serialization of all insertion relationships from both the item as well as their targets, and copying of the item also copies all of the inserted items.

The following is an example of a declaration.

d) reference relationships

Reference relationships do not control the lifetime of the item it references. Even a reference relationship does not guarantee the existence of the target, nor does it guarantee the type of the target specified in the relationship declaration. This means that the reference relationship can be suspended. Reference relationships can also refer to items in other data stores. Reference relationships can be thought of as concepts similar to links within web pages.

The following is an example of a reference relationship declaration.

Any reference relationship is allowed at the target endpoint. Items participating in the reference relationship can be of any item type.

Reference relationships are used to model most non-life management relationships between items. Since the presence of a target is not enforced, reference relationships are convenient for modeling loosely coupled relationships. Reference relationships can be used to target items in other data stores, including repositories on other computers.

e) rules and restrictions

The following additional rules and restrictions apply to relationships.

The item must be a target of (only one insertion relationship) or (one or more maintenance relationships). One exception is the root entry. An item may be a target of zero or more reference relationships.

An item that is a target of an insertion relationship cannot be a source of a maintenance relationship. This may be the source of the reference relationship.

An item cannot be the source of a maintenance relationship if it is promoted from a file. This can be the source of insertion and reference relationships.

An item promoted from a file cannot be the target of an insert relationship.

f) ordering of relationships

In at least one embodiment, the storage platform of the present invention supports the ordering of relationships. Ordering is accomplished through an attribute named "Order" in the basic relationship definition. There is no uniqueness restriction on the order field. The order of relationships with the same "order" attribute value is not guaranteed, but it is guaranteed that they can be ordered after a relationship with a lower "order" value and before a relationship with a higher "order" field value.

The application can obtain the relationships in the default order by ordering on the combination (SourceItemID, RelationshipID, Order). All relationship instances from a given item are ordered as a single set, regardless of the type of relationship in the set. However, this ensures that all relationships of a given type (eg FolderMembers) are an ordered subset of the relationship set for a given item.

Data store API 312 for manipulating relationships implements a set of operations that support the ordering of relationships. The following terms are introduced to help explain the operation.

RelFirst is the first relationship in the ordered set with the order value OrdFirst.

RelLast is the final relationship in the ordered set with the order value OrdLast.

RelX is a predetermined relationship in the set with the order value OrdX.

RelPrev is the closest relation to RelX in a set with an OrdPrev ordinal value less than OrdX.

RelNext is the closest relation to RelX in a set with ordNext greater than OrdX.

The operations include, but are not limited to:

InsertBeforeFirst (SourceItemID, Relationship) inserts a relationship as the first relationship in the set. The order attribute value of the new relationship may be less than OrdFirst.

InsertAfterLast (SourceItemID, Relationship) inserts a relationship as the final relationship in the set. The order attribute value of the new relationship may be greater than OrdLast.

InsertAt (SourceItemID, ord, Relationship) inserts a relationship with the specified value for the order attribute.

InsertBefore (SourceItemID, ord, Relationship) inserts the relationship before the relationship with the given order value. The new relationship may be assigned an order value between OrdPrev and ord (not including these values).

InsertAfter (SourceItemID, ord, Relationship) inserts the relationship after the relationship with the given order value. The new relationship may be assigned an order value between ord and OrdNext (not including these values).

MoveBefore (SourceItemID, ord, Relationship) moves the relationship with the given relationship ID before the relationship with the specified order value. The relationship may be assigned a new order value between OrdPrev and ord (not including these values).

MoveAfter (SourceItemID, ord, Relationship) moves the relationship with the given relationship ID after the relationship with the specified order value. The relationship may be assigned a new order value between ord and OrdNext (not including these values).

As mentioned above, every item must be a member of an item folder. By relationship, every item must have a relationship with an item folder. In various embodiments of the invention, certain relationships are represented by relationships that exist between items.

As implemented in various embodiments of the present invention, a relationship provides a directional binary relationship that is extended by one item (source) to another item (target). The relationship is owned by the source item (an item that expands the relationship), so if the source is removed, the relationship is removed (eg, the relationship is deleted when the source item is deleted). Moreover, in some examples, a relationship may share (co-ownership) ownership of the target item, which ownership may be within the IsOwned attribute (or equivalent thereof) of the relationship (as shown in FIG. 7 for the relationship attribute type). Can be reflected. In these embodiments, the creation of a new IsOwned relationship automatically increases the reference number for the target item, and the deletion of this relationship can reduce the reference number for the target item. In this particular embodiment, items continue to exist if they have a reference number greater than zero and are automatically deleted when the reference number reaches zero. Also, an item folder is an item that has (or may have) a set of relationships to other items, which include members of the item folder. Other practical relationships are possible and are foreseen by the present invention to achieve the functions described herein.

Regardless of the actual implementation, a relationship is a selectable connection from one object to another. The ability of an item to belong to more than one category of folders, as well as to more than one category, and whether these items, folders, and categories are public or private, depends on the meaning given for their existence (or absence) in the item infrastructure. Is determined by These logical relationships are the meanings assigned to a set of relationships specifically used to achieve the functions described herein, regardless of their physical implementation. Logical relationships are established between an item and its item folder (s) or categories (and vice versa), because essentially an item folder and category are each a special type of item. As a result, item folders and categories can be operated in the same way as any other item, without limitations being copied, added to email messages, inserted into documents, etc., and item folders and categories are the same mechanism as for other items Can be serialized and deserialized using (import and import). (For example, every item in XML can have a serialization format, which applies equally to item folders, categories, and items.)

The foregoing relationship, which represents a relationship between an item and its item folder, may logically extend from item to item folder, item folder to item, or both. A relationship that extends from item to item folder indicates that the item folder is public to the item and shares the item and its member information, but conversely, the lack of a logical relationship from item to item folder means that the item folder is private to the item. , Does not share the item and its member information. Similarly, a relationship that logically extends from an item folder to an item indicates that the item is public and can be shared with the item folder, while the lack of a logical relationship from the item folder to the item indicates that the item is private and cannot be shared. Indicates. As a result, when an item folder is exposed to another system, it is a "public" item that is shared in this new situation, and when the item retrieves other shareable items from its item folder, it is a shareable item belonging to the item. These are "public" item folders that provide information about these.

9 is a block diagram showing the item folder (which is also the item itself), its member items, and the interconnection relationship between the item folder and its member items. The item folder 900 has a number of items 902, 904, 906. The item folder 900 has a relationship 912 from itself to the item 902, where the item 902 is public and the item folder 900, its members 904, 906, and the item folder It can be shared with any other item folders, categories, or items (not shown) that can access 900. 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 its member information with item 902. Item 904, on the other hand, does not have a relationship from itself to item folder 900, indicating that item folder 900 is public and shares its member information with item 904. However, item 904 is private and not shared with item folder 900, its other members 902, 906, and item folder, category, or item (not shown) that can access item folder 900. There is no relationship from item folder 900 to item 904, which is different from the relationship (or lack of relationship) to items 902 and 904 in the item folder, item folder 900 itself. Has a relationship 916 to item 906, which in turn has a relationship 926 to item folder 900, which together makes item 906 public and item folder 900. , Its members 902, 904, and any other item folder, category, or item (not shown) that can access the item folder 900, and the item folder 900 is public and 906 and sharing his member information.

As mentioned above, the items in the item folder do not need to share commonality because the item folder is not "described." On the other hand, categories are described by commonalities common to all of their member items. As a result, members of a category are uniquely limited to items with the described commonalities, and in some embodiments all items that satisfy the description of the category automatically become members of the category. Thus, item folders allow ordinary types of structures to be represented by their members, while categories allow members based on defined commonalities.

Of course, category descriptions are logical in nature, and thus categories can be described by any logical representation of types, attributes and / or values. For example, a logical representation of a category can be a member thereof that includes items with one or both of two attributes. If these attributes described for the category are "A" and "B", then the category member has attributes A but no B, those with attribute A and B, and both attributes A and B It may include items having. The logical representation of these attributes is described by the logical operator "OR", where the set of members described by the category are items with attributes A OR B. Similar logical operators (including without limitation " AND ", " XOR " and " NOT " alone or in combination) can also be used to describe categories as those skilled in the art will understand.

Notwithstanding the differences between item folders (not described) and categories (described), the relationship of categories to items and the relationship of items to categories is inherently above that for item folders and items in many embodiments of the invention. It has the same manner as disclosed.

10 is a block diagram illustrating a category (item itself), its member items, and the interconnection relationship between the category and its member items. Category 1000 has a number of items 1002, 1004, 1006 as members, all of which share some combination of common attributes, values, or types 1008 as described by category 1000. do. Category 1000 itself has a relationship 1012 to item 1002, which is that item 1002 is public, category 1000, its members 1004, 1006, and category 1000. ) Can be shared with any other category, item folder, or item (not shown) that has access. However, there is no relationship from item 1002 to category 1000, indicating that category 1000 is private to item 1002 and does not share its member information with item 1002. Item 1004, on the other hand, does not have a relationship 1024 to itself in category 1000, indicating that category 1000 is public and shares its member information with item 1004. However, item 1004 is private, with category 1000, its other members 1002, 1006, and any other category, item folder or item (not shown) that can access category 1000; There is no relationship extending from item 10004 to category 1004 indicating that it cannot be shared. Unlike the relationship (or lack thereof) with items 1002 and 1004 of a category, category 1000 has a relationship to item 1006 on its own, and item 1006 is conversely to category 1000. Together, these relationships together indicate that item 1006 is public and can access category 1000, its item members 1002, 1004, and any other category, item folder, or item (shown) And the category 1000 is public, sharing item 1006 with its member information.

Finally, because categories and item folders themselves are items, in some other embodiments, items may have a relationship to each other, categories may have a relationship to item folders, and item folders may have a relationship to categories. Categories, item folders, and items may have relationships to other categories, item folders, and items. However, in various embodiments, the item folder structure and / or category structure is prohibited to include recursion at the hardware / software interface system level. If the item folder and category structure is similar to a direction graph, embodiments that prohibit cycling are similar to a direction acyclic graph (DAG), which is a direction graph where no path starts or ends at the same vertex by mathematical definition in the field of graph theory.

6. Scalability

The storage platform has an initial schema set 340 as described above. In addition, however, in at least some embodiments, the storage platform allows customers, including individual software vendors (ISVs), to create a new schema 344 (ie, new items and nested element types). This section deals with the mechanism for creating such a schema by extending the item types and nested element types (or simply element types) defined in the initial schema set 340.

Preferably, the initial item and nested element type set are limited as follows.

ISVs are allowed to introduce new item types, that is, subtype Base.Item.

ISVs are allowed to introduce new nested element types, that is, subtype Base.NestedElement.

ISVs are allowed to introduce new extensions, that is, the subtype Base.NestedElement.

However, the ISV cannot subtype any type (item, nested element or extended type) defined by the initial set 340 of the storage platform schema.

Because item types or nested element types defined in the initial set of storage platform schemas may not exactly meet the needs of ISV applications, it is necessary to allow ISVs to customize the types. This is allowed with the concept of extension. Extensions are strongly typed extensions, but (a) they cannot exist independently and (b) must be attached to an item or nested element.

In addition to addressing the need for schema extensibility, extensions also address the "multi-type" problem. In some embodiments, since the storage platform may not support multiple inheritance or nested subtypes, applications may use extensions as a method for modeling nested type instances (eg, documents may be secure as well as legal documents). Document).

a) item expansion

In order to provide item scalability, the data model also uses Base. Defines an abstract type named Extension. This is the root type for the hierarchy of extended types. An application can subtype Base.Extension to create a specific extension type.

Base.Extension type is defined in Base.Extension 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. Tuples (ItemID, ExtensionID) uniquely identify an extension instance.

The structure of the extension type is similar to that of the item type.

Extension type has a field.

The field may be a basic or nested element type.

Extension type can be subtyped.

Other restrictions apply to extension types.

Extension cannot be the source and target of a relationship.

Extension type instances cannot exist separately from items.

Extension types cannot be used as field types in storage platform type definitions.

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

Extension instances are stored and accessed individually from the item. All extension type instances can be accessed from the global extension view. An efficient query can be constructed that returns all instances of a given extension type, regardless of what type of item it is associated with. The storage platform API provides a programming model for storing, retrieving, and modifying extensions to items.

The extended type may be a subtyped type using the storage platform single inheritance model. Derivation from an extension type creates a new extension type. The structure or behavior of an extension cannot override or replace the structure or behavior of an item type hierarchy. Similar to item types, extension type instances can be accessed directly through views associated with the extension type. The ItemID of the extension indicates which item they belong to and can be used to retrieve the corresponding item object from the global item view. Extensions are considered part of the item for consistency of operation. Copy / move, backup / restore, and other general operations defined by the storage platform may operate on extensions as part of the item.

Consider the following example. The contact type is defined within the window type set.

CRM application developers want to attach CRM application extensions to contacts stored on the storage platform. The application developer defines a CRM extension that contains additional data structures that the application can manipulate.

HR application developers may also want to attach additional data to the contact. This data is independent of CRM application data. In addition, application developers can create extensions.

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

In the example above, fields and methods of type CRMExtension cannot override fields or methods of the contact hierarchy. Note that instances of the CRMExtension type can be attached to an item type rather than a contact.

When a contact is retrieved, its item extension is not automatically retrieved. Given a contact item, the item extension associated with it can be accessed by querying the global extension view for the extension with the same ItemID.

All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of which items they belong to. All item extensions of an item share the same item ID. In the example above, the contact item instance and the attached CRMExtension and HRExtension instances share the same ItemID.

The following table summarizes the similarities and differences between item, extension, and nested element types.

Item-to-item expansion vs. nested elements

Item Item extension Nested elements Item ID Has its own item ID. Share the item ID of the item. It does not have its own item ID. Nested elements are part of an item. Save The item hierarchy is stored in its own table. The item extension hierarchy is stored in its own table. It is stored with the item. Query / Search You can query the item table. You can query the item extension table. In general, it can be queried only within the context of the containing item. Query / search scope You can retrieve all instances of an item type. You can search all instances of the item extension type. In general, you can only search within nested element type instances of a single (contained) item. Relationship semantics It can have a relationship to items. No relationship to item expansion. No relationship to nested elements Association to the item Retain, insert, and soft relationships can be associated with other items. Generally only relevant through expansion. Extension semantics are similar to the inserted item semantics. Associated with an item via a field, nested elements are part of the item.

b) nested element expansion

Nested element types do not extend to the same mechanism as item types. Extension of nested elements is stored and accessed with the same mechanism as fields of nested element types.

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

Nested element types inherit from this type. The NestElement element type further defines a field that is a multiset of elements.

Nested element expansion differs from item expansion in the following ways:

Nested element expansion is not an extension type. It is not part of the extension type hierarchy rooted in the Base.Extension type.

Nested element extensions are stored with other fields in the item, are not globally accessible, and no query can be constructed that retrieves all instances of a given extension type.

These extensions are stored in the same way as other overlapping elements (of items) are stored. Like other nested sets, nested element extensions are stored in UDTs. These can be accessed through extension fields of nested element types.

The aggregation interface used to access multivalent attributes is also used for access and iteration over the type extension set.

The following table summarizes and compares item expansion and nested element expansion.

Item Expansion vs. Nested Element Expansion

Item extension Nested Element Extensions Save The item extension hierarchy is stored in its own table. Stored with nested elements Query / Search You can query the item extension table. In general, it can only be queried within the context of the containing item. Query / search scope You can search all instances of the item extension type. In general, you can only search within nested element type instances of a single (contained) item. Programmability Special queries for special extension APIs and extension tables are required. Nested element extensions are similar to any other multivalent field of nested elements, and normal nested element type APIs are used. motion You can correlate the behavior. Behavior not allowed (?) Relationship semantics No relationship to item expansion No relationship to nested element expansion Item ID Share the item ID of the item. It does not have its own item ID. Nested element expansion is part of the item.

D. Database Engine

As mentioned above, the data store is implemented on a database engine. In this embodiment, the database engine includes a relational database engine that implements an SQL query language such as the Microsoft SQL Server engine with object relational extensions. This section describes the mappings to relational stores in the data model that implements the data store according to this embodiment, and provides information about the logical APIs consumed by the storage platform client. However, it should be understood that different mappings may be used 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, for example, object-oriented and XML databases.

Object-Oriented (OO) database systems provide persistence and transactions for programming language objects (eg, C ++, Java). The storage platform concept of "items" is well mapped to "objects" in object-oriented systems, although inserted sets must be added to an object. Other storage platform type concepts, such as inheritance and nested element types, also map to object-oriented type systems. Object-oriented systems generally already support object identifiers, so item identifiers can be mapped to object identifiers. Item behavior (behavior) is well mapped to object methods. However, object-oriented systems generally lack systematic capabilities and are poorly searched. In addition, object-oriented systems do not provide support for unstructured and semi-structured data. To support the complete storage platform data model described herein, concepts such as relationships, folders, and extensions need to be added to the object data model. In addition, mechanisms such as promotion, synchronization, notification and security need to be implemented.

Similar to object-oriented systems, XML databases based on XSD (XML Schema Definition) support a single inheritance based type system. The item type system of the present invention may be mapped to an XSD type model. XSD also does not provide support for behavior. The XSD for the item should be reinforced for the item behavior. An XML database handles a single XSD document and lacks organizational and extensive search capabilities. As with object-oriented databases, to support the data model described herein, other concepts, such as relationships and folders, need to be included in this XML database, and mechanisms such as synchronization, notification, and security also need to be implemented.

Regarding the following subsections, some explanations are provided to facilitate the general information disclosed, and FIG. 13 illustrates the notification mechanism. 14 is a diagram illustrating an example in which two transactions both insert a new record in the same B tree. 15 shows a data change detection process. 16 illustrates an example directory tree. 17 shows an example in which an existing folder of a directory-based file system is moved to a storage platform data store.

1. Data storage using UDT

In this embodiment, the relational database engine 314, which in one embodiment includes the Microsoft SQL Server engine, supports built-in scalar types. Built-in scalar types are "primitive" and "simple". This is primitive in the sense that the user cannot define his own type, and it is simple in that it cannot encapsulate complex structures. User-defined types (hereinafter referred to as UDTs) provide a mechanism for type extensibility above and beyond the primitive scalar type system by allowing users to extend the type system by defining complex and structured types. If a UDT is defined by the user, it can be used anywhere in the type system where built-in scalar types can be used.

According to one aspect of the invention, the storage platform schema is mapped to a UDT class in a database engine repository. Data store items are mapped to UDT classes derived from the Base.Item type. Like items, extensions are also mapped to UDT classes, using inheritance. The root extension type is Base.Extension from which all extension types are derived.

UDTs are CLR classes, which have state (ie data fields) and behavior (ie routines). UDTs are defined using any of managed languages: C #, VB.NET, and so on. UDT methods and operators can be called in T-SQL for instances of that type. The UDT may be the type of a column in a row, the type of a parameter of a routine in T-SQL or the type of a variable in T-SQL.

The mapping of storage platform schemas to UDT classes is very simple at a high level. In general, the storage platform schema is mapped to the CLR namespace. Storage platform types are mapped to CLR classes. CLR class inheritance mirrors storage platform type inheritance, and storage platform properties are mapped to CLR class properties.

2. Item Mapping

If the items are preferably globally searchable and inheritance and type substitution are supported in the relational database of this embodiment, one possible implementation for storing items in the database repository is that all items in a single table with a column of type Base.Item. To save it. With type substitution, items of any type can be stored, and searches can be filtered by item type and subtype using Yukon's "is of" operator.

However, due to the concern with the overhead associated with this approach, in this embodiment the items are sorted by top level type, so that items of each type "family" are stored in separate tables. Under this partitioning scheme, a table is created for each item type that inherits directly from Base.Item. Types inherited below them are stored in the appropriate type family using type substitution as described above. Only the first level of inheritance from Base.Item is specially handled.

A "shadow" table is used to store a copy of the global searchable attributes for all items. This table can be maintained by the Update () method of the storage platform API, which makes all data changes. Unlike type family tables, this global item table contains only the top-level scalar attributes of the item, not the complete UDT item object. The global item table allows navigation to item objects stored in the type family table by exposing ItemID and TypeID. The ItemID typically uniquely identifies an item in the data store. TypeID may be mapped to a view containing the type name and item using metadata not described herein. With respect to the global item table, and with respect to other situations, finding an item by its ItemID may be a normal operation, so given the ItemID of the item, a GetItem () function is provided to retrieve the item object.

For convenient access, and to the extent possible to hide implementation details, all queries for an item may be for views built on the item table described above. Specifically, views can be created for each item type for the appropriate type family table. This type view may select all items of related types including subtypes. For convenience, in addition to UDT objects, views can expose columns for all top-level fields of that type, including inherited fields.

3. Extension Mapping

The extension is very similar to the item and has some of the same requirements. As another root type that supports inheritance, extensions are subject to much of the same considerations and tradeoffs in storage. Because of this, similar type family mappings apply to extensions rather than single table approaches. Of course, in other embodiments a single table approach may be used. In this embodiment, an extension is associated with exactly one item by ItemID and includes a unique ExtensionID with respect to the item. As with the item, a function for searching for an extension may be provided when an extension identifier consisting of an ItemID and ExtensionID pair is given. Similar to the item type view, a view is created for each extension type.

4. Nested Element Mapping

Nesting elements are of a type that can be inserted into items, extensions, relationships, or other nesting elements that form deeply nested structures. Like items and extensions, nested elements are implemented as UDTs, but are stored within items and extensions. Thus, nested elements have no storage mapping beyond the mapping of their item and extension containers. That is, there is no table in the system that directly stores instances of nested element types, and there are no views specifically dedicated to nested elements.

5. Object Identification

Each entity in the data model, namely items, extensions and relationships, has a unique key value. An item is uniquely identified by its ItemID. Extensions are uniquely identified by a composite key of (ItemID, ExtensionID). Relationships are identified by composite keys (ItemID, RelationID). ItemID, ExtensionID and RelationID are GUID values.

6. Naming SQL Objects

All objects created in the data store can be stored in the SQL schema name derived from the storage platform schema name. For example, the storage platform base schema (often referred to as "Base") may create a type such as "[System.Storage] .Item" in the "[System.Storage]" SQL schema. Generated names are prefixed with qualifiers to eliminate naming conflicts. Where appropriate, an exclamation point (!) Is used as a separator for each logical part of the name. The table below gives an overview of the naming conventions used for objects in the data store. Each schema element (item, extension, relationship, and view) is listed with a decorative naming convention used to access instances within the data store.

Object Name Decoration Explanation Yes Master Item Search View Master! Item Provides a summary of items in the current item domain. [System.Storage]. [Master! Item] Typed Item Search View ItemType Provide all attribute data from the item and any parent type (s). AcmeCorp.Doc. [OfficeDoc] Master extended search view Master! Extension Provides a summary of all extensions within the current item domain. [System.Storage]. [Master! Extension] Typed extended search view Extension! ExtensionType Provides all the attribute data for the extension. AcmeCorp.Doc. [Extension! StickyNote] Master relationship view Master! Relationship Provides a summary of all relationships within the current item domain. [System.Storage]. [Master! Relationship] Relationship view Relation! RelationshipName Provide all data related to a given relationship. AcmeCorp.Doc. [Relationship! AuthorsFromDocument] View View! ViewName Provide columns / types based on the schema view definition. AcmeCorp.Doc. [View! DocumentTitles]

7. Column Naming

When mapping an arbitrary object model to a repository, the possibility of naming conflicts arises from the extra information stored with the application object. To avoid naming conflicts, all non-type specific columns (those that do not map directly to naming attributes in the type declaration) are prefixed with an underscore (_) character. In this embodiment, the underscore (_) character is not allowed as the start character of any identifier attribute. In addition, to unify the naming between the CLR and the data store, all attributes of the storage platform type or schema element (such as a relationship) must have a capitalized first character.

8. Search view

The view is provided by the storage platform to retrieve the stored content. SQL views are provided for each item and extension type. In addition, views are provided (as defined in the data model) to support relationships and views. All SQL views and base tables in the storage platform are read only. As described below, data may be stored or changed using the Update () method of the storage platform API.

Each view explicitly defined within the storage platform schema (as defined by the schema designer, not automatically generated by the storage platform) is named SQL view [<schema-name>]. [View! <View-name> ] Can be accessed. For example, a view named "BookSales" within the schema "AcmePublisher.Books" may be accessed using the name "[AcmePublisher.Bookks]. [View! BookSales]". Since the output format of the view is tailored on a per view basis (defined by any query provided by the definer of the view), the columns are mapped directly based on the schema view definition.

All SQL search views within the storage platform data store use the following column ordering convention:

Logical "key" columns of view results, such as ItemId, ElementId, RelationshipId, etc.

Metadata information about the type of the result, such as TypeId

Change tracking columns such as CreateVersion, UpdateVersion, etc.

Type-specific columns (attributes of declared types)

The type specific view (family view) also contains an object string that returns an object.

Members of each type family can be searched using a series of item views. There is one view per item type in the data store. 28 is a diagram illustrating the concept of an item search view.

a) item

Each item search view includes a row for each instance of an item of a particular type or subtype thereof. For example, a view on a document can return instances of Document, LegalDocument, and ReviewDocument. Given 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 called a master item view. This view provides a summary of each item in the data store. The view provides one column per item type attribute, a column describing the type of the item, and several columns 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]".

Heat type Explanation ItemId ItemId Storage platform identifier of the item _TypeId TypeId The Item's TypeId identifies the exact type of the item and can be used to retrieve information about the type using the metadata catalog. _RootItemId ItemId The ItemId of the first non-insert ancestor controlling the lifetime of this item <global change tracking> ... Global change tracking information <Item props> n / a One column per item type attribute

(2) Typed Item Search View

Each item type also has a search view. Similar to the root item view, this view also provides access to the item object via the "_Item" column. Each typed item search view is identified in the data store using the name [schemaName]. [ItemTypeName]. For example, [AcmeCorp.Doc] [OfficeDoc].

Heat type Explanation ItemId ItemId Storage platform identifier of the item <type change tracking> ... Type change tracking information <parent props> <property specific> One column per parent property <item props> <property specific> One column per exclusive attribute of this type _Item The CLR type of the item Type of CLR object-declaration item

b) item expansion

All item extensions in the WinFS repository can also be searched using the search view.

(1) master extended search view

Each instance of the data store defines a special extended view called the master extended view. This view provides a summary of each extension in the data store. The view has one column per extension attribute, one column describing the extension type, and several columns used to provide change tracking and synchronization information. The master extension view is identified in the data store using the name [System.Storage]. [Master! Extension] ".

Heat type Explanation ItemId ItemId The storage platform identifier of the item with which the extension is associated. ExtensionId ExtensionId (GUID) ID of this extension instance _TypeId TypeId The extension's TypeId identifies the exact type of extension and can be used to retrieve information about the extension using the metadata catalog. <global change tracking> ... Global change tracking information <ext properties> <property specific> One column per extended type attribute

(2) typed extended search view

Each type of extension also has a search view. Similar to the master extension view, this view also provides access to items through the _Extension column. Each typed extension search view is identified in the data store using the name [schemaName]. [Extension! ExtensionTypeName]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt].

Heat type Explanation ItemId ItemId Storage platform identifier of the item that this extension is associated with ExtensionId ExtensionId (GUID) ID of this extension instance <type change tracking> ... Type change tracking information <parent props> <property specific> One column per parent property <ext props> <property specific> One column per exclusive attribute of this type _Extension CLR type of extension instance Types of CLR Object-Declaration Extensions

c) nested elements

All nested elements are stored within an item, extension, or relationship instance. Accordingly, they are accessed by querying the appropriate item, extension, or relationship search view.

d) relationships

As mentioned above, relationships form the basic unit of connection between items in a storage platform data store.

(1) Master Relationship Search View

Each data store provides a master relationship view. This view provides information about all relationship instances within the data store. The master relationship view is identified in the data store using the name "[System.Storage]. [Master! Relationship]".

Heat type Explanation ItemId ItemId Identifier of the source endpoint (ItemId) RelationshipId RelationshipId (GUID) ID of the relationship instance _RelTypeId RelationshipTypeId The RelTypeId of the relationship identifies the type of the relationship instance using the metadata catalog. <global change tracking> ... Global change tracking information TargetItemReference Itemreference Identifier of the target endpoint _Relationship Relationship An instance of the relationship object for this instance

(2) relationship instance search view

Each declared relationship also has a search view that returns all instances of that particular relationship. Similar to the master relationship view, this view also provides named columns for each attribute of the relationship data. Each relationship instance search view is identified in the data store using the name [schemaName]. [Relationship! RelationshipName]. For example, [AcmeCorp.Doc]. [Relationship! DocumentAuthor].

Heat type Explanation ItemId ItemId Identifier of the source endpoint (ItemId) RelationshipId RelationshipId (GUID) ID of the relationship instance <type change tracking> ... Type change tracking information TargetItemReference Itemreference Identifier of the target endpoint <source name> ItemId Named attribute of the source endpoint identifier (alias for ItemId) <target name> ItemReference or derived class Named attribute of the target endpoint identifier (alias and cast to TargetItemReference) <rel property> <property specific> One column per attribute in the relationship definition _Relationship CLR type of the relation instance Types of CLR Object-Declaration Relationships

e)

9. Renewal

All views within 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 methods of the storage platform API must be used. The ProcessOperation method is a single stored procedure defined by the data store that consumes an "action" that specifies the action to be performed. The ProcessUpdategram method is a stored procedure that takes an ordered set of actions known as an "updategram" that collectively specifies a set of actions to be performed.

The operation format is extensible and provides various operations on schema elements. Certain general operations include the following.

1. Item Action

a. CreateItem (create a new item related to an insert or maintenance relationship)

b. UpdateItem (Update Existing Item)

2. Relationship Behavior

a. CreateRelationship (create an instance of a reference or maintenance relationship)

b. UpdateRelationship (Update Relationship Instance)

c. DeleteRelationship (remove relationship instance)

3. Extended operation

a. CreateExtension (add extension to existing item)

b. UpdateExtension (Update Existing Extension)

c. DeleteExtension

10. Change tracking and tombstone

Change tracking and tombstone services are provided by the data store as described below. This section provides an overview of the change tracking information exposed to the data store.

a) change tracking

Each search view provided by the data store contains columns used to provide change tracking information, which are common across all item, extension, and relationship views. Storage platform schema views explicitly defined by the schema designer do not automatically provide change tracking information, which is indirectly provided through the search view in which the view itself is built.

For each element in the data store, change tracking information is available from two places, the master element view and the typed element view. For example, change tracking information for the AcmeCorp.Document.Document item type is available from the master item view "[System.Storage]. [Master! Item] and the typed search view [AcmeCorp.Document]. [Document]. Do.

(1) Change tracking in master search view

The change tracking information in the master search view provides information about the creation and update versions of the elements, information that is the target of the elements created and last updated by the sync partner, and version numbers from each partner for creation and update. Partners in a motivational relationship (described below) are defined by partner key. A single UDT object named _ChangeTrackingInfo of type [System.Storage.Store] .ChangeTrackingInfo contains all of this information. Types are defined in the System.Storage schema. _ChangeTrackingInfo can be used in all global search views for items, extensions, and relationships. The type definition of ChangeTrackingInfo is as follows.

These attributes include the following information:

Heat Explanation _CreationLocalTS Creation time stamp by local machine _CreatingPartnerKey PartnerKey of the partner that created this entity. If the entity was created locally, this is the PartnerKey of the local machine. _CreatingPartnerTS Timestamp of the time this entity was created on the partner corresponding to _CreatingPartnerKey. _LastUpdateLocalTS Local time stamp corresponding to update time on local machine _LastUpdatingPartnerKey PartnerKey of the partner that last updated this entity. If the last update to the entity was performed locally, this is the PartnerKey of the local machine. _LastUpdatingPartnerTS Timestamp of when this entity was updated at the partner corresponding to _LastUpdatingPartnerKey

(2) change tracking in typed search views

Each typed search view provides the same information as the global search view, as well as providing additional information to record the synchronization status of each element in the synchronous topology.

Heat type Explanation <global change tracking> ... Information from Global Change Tracking _ChangeUnitVersions MultiSet <ChangeUnitVersion> A description of the version number of the change unit in the particular element _ElementSyncMetadata ElementSyncMetadata Additional version-independent metadata for items related only to the synchronization run time _VersionSyncMetadata VersionSyncMetadata Additional version specific metadata for versions relevant only at runtime of synchronization

b) tombstone

The data store provides tombstone information about items, extensions, and relationships. Gravestone views provide information about both living entities and entities with tombstones (items, extensions, and relationships) in one place. Item and extended tombstone views do not provide access to corresponding objects, while relationship tombstones provide access to relationship objects (relational objects are blank for relationships with tombstones).

(1) item tombstone

Item tombstones are retrieved from the system via the view [System.Storage]. [Tombstone! Item].

Heat type Explanation ItemId ItemId Identifier of the item _TypedID TypedID The type of the item <Item properties> ... Attribute defined for all items _RootItemId ItemId ItemId of the first non-inserted item containing this item _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this item _IsDeleted BIT This is a flag of 0 for living items and 1 for items with gravestones. _DeletionWallclock UTCDATETIME UTC wall clock date according to the partner who deleted the entry. This is blank if the item is alive.

(2) tombstone

Extension tombstones are retrieved from the system using the view [System.Storage]. [Tombstone! Extension]. Extension change tracking information is similar to that provided for items with the ExtensionId attribute added.

Heat type Explanation ItemId ItemId Identifier of the item that owns the extension ExtensionId ExtensionId Extension ID of the extension _TypedID TypedID Type of extension _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this extension _IsDeleted BIT This is a flag of 0 for living items and 1 for items with gravestones. _DeletionWallclock UTCDATETIME UTC wall clock date according to the partner who deleted the entry. This is blank if the extension is alive.

(3) relationship tombstone

Relationship gravestones are retrieved from the system through the view [System.Storage]. [Tombstone! Relationship]. The relationship tombstone information is similar to that provided for the extension. However, additional information is provided about the target ItemRef of the relationship instance. The relationship object is also selected.

Heat type Explanation ItemId ItemId Identifier of the entity that owns the relationship (identifier of the relationship source endpoint) RelationshipId RelationshipId RelationshipId of the relationship _TypedID TypedID Type of relationship _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this relationship _IsDeleted BIT This is a flag of 0 for living items and 1 for items with gravestones. _DeletionWallclock UTCDATETIME UTC wall clock date according to the partner who deleted the relationship. This is blank if the relationship is alive. _Relationship CLR instance of a relationship This is a relationship object for a living relationship. This is blank for relationships with gravestones. TargetItemReference Itemreference Identifier of the target endpoint

(4) tombstone removal

To prevent an unlimited increase in tombstone information, the data store provides tombstone removal. This task determines when tombstone information can be discarded. The task computes the boundary for the locally created / updated version and then shortens the tombstone information by discarding all initial tombstone versions.

11. Helper APIs and Functions

Basic mappings also provide a number of helper functions. These functions are provided to help with common operations through the data model.

a) function [System.Storage] .GetItem

b) function [System.Storage] .GetExtension

c) function [System.Storage] .GetRelationship

12. Metadata

There are two types of metadata represented in the repository: instance metadata (type of item, etc.) and type metadata.

a) schema metadata

Schema metadata is stored in the data store as instances of item types from the meta schema.

b) instance metadata

Instance metadata is used by the application to query for the type of the item, looking for extensions associated with the item. Given an ItemId for an item, the application can query the global item view to return the item's type and use this value to query the metatype view to return information about the item's declaration type. Here is an example:

E. Security

In general, all security capable objects arrange their access rights using the access mask format shown in FIG. In this format, the lower 16 bits are for object-specific access management, the next 7 bits are for standard access rights that apply to most object types, and the higher 4 bits are for each object type for standard and object. Used to specify general access rights that can be mapped to a specific set of rights. The ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the object's SACL.

In the access mask structure of FIG. 26, the item specific rights are placed in the object specific rights section (16 bits of low rank). Since the storage platform in this embodiment exposes two sets of APIs for security management, Win32 and the storage platform API, file system object specific rights should be considered to stimulate the design of storage platform object specific rights.

The security model for the storage platform of the present invention is fully described in the related applications, which are initially incorporated herein by reference. In this regard, Figure 27 (a, b, c) shows that a new security zone that is equally protected according to one embodiment of the security model is separated from the existing security zone.

F. Notice and Change Tracking

According to another aspect of the invention, the storage platform provides a notification capability that allows an application to track data changes. This feature is primarily intended for applications that maintain volatility or execute business logic on data change events. The application registers for notifications on items, item extensions and item relationships. Notifications are delivered asynchronously after data changes have been made. An application can filter notifications by type of action, as well as item, extension, and relationship types.

According to one embodiment, storage platform API 322 provides two kinds of interfaces for notifications. First, the application registers for simple data change events triggered by changes to items, item extensions, and item relationships. Second, the application creates a "watcher" object to monitor the set of items, item extensions, and relationships between items. The state of the watcher object can be stored and recreated after a system crash or after the system has been offline for an extended period of time. A single notification can reflect multiple updates.

Further details of this functionality can be found in the related application, which is incorporated herein by reference in its entirety.

G. Normal File System Interoperability

As mentioned above, the storage platform of the present invention is implemented as an integral part of the hardware / software interface system of the computer system in at least some embodiments. For example, the storage platform of the present invention may be implemented as an integral part of an operating system, such as the Microsoft Windows operating system family. In that capacity, the storage platform API becomes part of the operating system API that allows application programs to interact with the operating system. Thus, the storage platform is a means for application programs to store information in the operating system, so the item-based data model of the storage platform replaces the usual file system of the operating system. For example, as implemented in the Microsoft Windows operating system family, the storage platform can replace the NTFS file system implemented in this operating system. Currently, application programs access services in the NTFS file system through Win32 APIs exposed by the Windows operating system family.

However, considering that the complete replacement of the NTFS file system with the storage platform of the present invention requires recoding existing Win32-based application programs, and such recoding may be undesirable, the storage platform of the present invention may be characterized by NTFS. It would be advantageous to provide some interoperability with the same existing file system. Thus, in one embodiment of the present invention, the storage platform enables application programs that rely on the Win32 programming model to access the contents of both data stores of the storage platform as well as the conventional NTFS file system. Because of this, the storage platform uses a naming convention that is a superset of the Win32 naming convention to facilitate interoperability. In addition, the storage platform supports accessing files and directories stored on storage platform volumes via the Win32 API.

Further details of this functionality can be found in the related applications, which are incorporated herein by reference in their entirety.

H. Storage Platform API

The storage platform includes an API that allows application programs to access the functionality 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 of this function can be found in the related applications, which are hereby incorporated by reference, and some of this information is summarized below for convenience.

Referring to FIG. 18, an include folder is an item including a maintenance relationship with another item, and is equivalent to a general concept of a file system folder. Each item is included in at least one include folder.

Figure 19 illustrates the basic architecture of the storage platform API in accordance with the present invention. The storage platform API may use SQLClient 1900 to communicate with the local data store 302, and also use SQLClient 1900 to communicate with a remote data store (eg, data store 340). Local store 302 may also communicate with remote data store 340 using a distributed query processor (DQP) or via a storage platform synchronization service (“Sync”), described below. The storage platform API 322 acts as a bridge API for data store notifications that delivers subscriptions of applications to the notification engine 332 and routes notifications to applications (eg, applications 350a, 350b or 350c) as described above. In one embodiment, storage platform API 322 may also define a limited "provider" architecture to allow access to data in Microsoft Exchange and AD.

20 schematically illustrates various components of a storage platform API. The storage platform API includes the following components: (1) a data class (2002) representing the storage platform element and item type, (2) a runtime framework (2004) that manages the persistence of objects and provides a support class (2006). , And (3) a tool 2008 used to generate CLR classes from the storage platform schema.

The hierarchy of classes resulting from a given schema directly reflects the hierarchy of types in that schema. For example, consider item types defined in a contact schema such as those shown in FIGS. 21A and 21B.

22 illustrates the operation of the runtime framework. The runtime framework works as follows.

1. Application 350a, 350b or 350c is coupled to items in a storage platform.

2. The framework 2004 creates an ItemContext object 2202 corresponding to the combined item and returns it to the application.

3. The application submits a Find on this ItemContext to get a set of items, which is conceptually an object graph 2204 (due to relationships).

4. The application changes, deletes, and inserts data.

5. The application calls the Update () method to save the change.

Fig. 23 shows execution of the "FindAll" operation.

24 illustrates a process in which storage platform API classes are generated from a storage platform schema.

25 shows a schema on which the File API is based. The storage platform API includes a namespace for handling file objects. This namespace is called System.Storage.Files. The data members of the classes in System.Storage.Files directly reflect the information stored in the storage platform repository, which can be promoted from file system objects or generated uniquely using the Win32 API. The System.Storage.Files namespace has two classes, FileItem and DirectoryItem. Members of this class and their methods can be easily found by looking at the schema diagram of FIG. FileItem and DirectoryItem are read only from the storage platform API. To modify these, you must use the Win32 API or the classes in System.IO.

In the context of an API, a programming interface (or more simply an interface) may be viewed as any mechanism, process, or protocol that enables one or more code segments to communicate with or access the functionality provided by one or more other code segments. Can be. Alternatively, the programming interface may be viewed as one or more mechanisms, methods, function calls, modules, objects, etc. of components of the system that may be communicatively coupled to one or more mechanisms, methods, function calls, modules, etc. of other components. The term "code segment" in the preceding sentence is intended to include one or more instructions or lines of code and, regardless of the terminology applied, or the code segments are compiled separately, or the code segments are source, intermediate or object code. Regardless of what is provided, the functionality of code segments may be used in a runtime system or process, they may be located on the same or different machines or distributed across multiple machines, or the functionality represented by the code segments is entirely in software, Including code modules, objects, subroutines, functions, etc., whether implemented entirely in hardware or a combination of hardware and software.

Conceptually, the programming interface may be generally seen as shown in FIG. 30A or 30B. FIG. 30A shows interface Interface1 as a path through which the first and second code segments communicate. 30B includes 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 medium M. As shown in FIG. The interface is shown. With reference to FIG. 30B, the interface objects I1 and I2 can be regarded as separate interfaces of the same system, and also the objects I1 and I2 plus medium M contain the interface. 30A and 30B illustrate a bidirectional flow, and an interface on each side of the flow, but certain implementations have an information flow in one direction (or no information flow as described below), or only one interface object on one side. Can have For example, terms such as API, entry point, method, function, subroutine, remote procedure call, and COM interface are included in, but not limited to, the definition of a programming interface.

Aspects of the programming interface include methods that enable a first code segment to transmit information to a second code segment, where “information” is used in a broad sense and includes data, commands, requests, and the like; A method for enabling the second code segment to receive information; And structure, sequence, syntax, organization, schema, timing, and content of the information. In this regard, the underlying transmission medium itself may not be important to the operation of the interface, regardless of whether the medium is wired or wireless, or a combination thereof, as long as information is transmitted in a manner defined by the interface. In some situations, information transfer may be via other mechanisms (e.g., information placed between buffers, files, etc.), such as when one code segment simply accesses a function performed by a second code segment (eg, information between code segments). Information may not be transmitted in one or both directions in the conventional sense when it may not be present. Any or all of these aspects may be important in a given situation, for example depending on whether the code segments are part of a system in a loosely coupled or closely coupled configuration, so this list is illustrative only. Should be considered non-restrictive.

The concept of such a 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 of implementing a programming interface, and unless expressly excluded, they are also intended to be included in the claims set forth at the end of this specification. Such other methods may appear to be more complex than the simple diagrams of FIGS. 30A and 30B, but nevertheless they perform a similar function to achieve the same overall result. Now, some exemplary alternative implementations of the programming interface are briefly described.

Factorization : Communication from one code segment to another can be accomplished indirectly by breaking down the communication into a number of separate communications. This is shown schematically in FIGS. 31A and 31B. As shown, some interfaces may be described by a set of partitionable functions. Thus, the interface functionality of FIGS. 30A and 30B can be factored to achieve the same result, as can mathematically provide 24 or 2 × 2 × 3 × 2. Thus, as shown in FIG. 31A, the functionality provided by interface Interface1 can be subdivided into a number of interfaces Interface1A, Interface1B, Interface1C, etc. to convert the communication of the interface while achieving the same result. As shown in FIG. 31B, the functionality provided by interface I1 may be subdivided into a number of interfaces I1a, I1b, I1c, etc. while achieving the same result. Similarly, interface I2 of the second code segment receiving information from the first code segment may be factored into multiple interfaces I2a, I2b, I2c, and the like. In factoring, the number of interfaces included in the first code segment need not match the number of interfaces included in the second code segment. In any of the cases of FIGS. 31A and 31B, the functional idea of interfaces Interface1 and I1 remains the same as in FIGS. 30A and 30B, respectively. Factorization of the interface may also follow coupling, exchange, and other mathematical properties, so factorization may be difficult to recognize. For example, the ordering of the operations may not be important, and consequently the functionality performed by one interface may be performed by another code or interface before reaching this interface, or by individual components of the system. . Moreover, one of ordinary skill in the art appreciates that there are various ways of making different function calls that achieve the same result.

Override : In some cases, one may ignore, add, or redefine certain aspects (eg, parameters) of the programming interface while still achieving the intended result. This is shown in Figures 32A and 32B. For example, assume that interface Interface1 of FIG. 30A includes a function call Square (input, precision, output), which is a call that includes three parameters: input, accuracy, and output and is issued from the first code segment to the second code segment. do. As shown in FIG. 32A, if the intermediate parameter accuracy is not important in a given scenario, this parameter may be ignored or replaced with a meaningless parameter (in this situation). It is also possible to add additional parameters that are not important. In either case, the square function can be achieved as long as the output is returned after the input is squared by the second code segment. Accuracy may very well be a meaningful parameter to any downstream or other portion of the computing system, but if it is recognized that accuracy is not needed for the narrow purpose of calculating the square, accuracy may be replaced or ignored. For example, instead of delivering a valid accuracy value, meaningless values, such as birthdays, can be delivered without adversely affecting the results. Similarly, as shown in FIG. 32B, interface I1 is replaced with interface I1 'redefined to ignore or add parameters to the interface. Interface I2 can likewise be overridden with interface I2 'redefined to ignore unnecessary parameters, or parameters that can be handled elsewhere. The point here is that in some cases the programming interface may include aspects such as parameters that are not needed for a given purpose, so that they may be ignored or redefined or otherwise processed for other purposes.

Inline coding : It is possible to merge some or all of the functionality of two separate code modules so that the interface between them changes shape. For example, the functionality of FIGS. 30A and 30B may be converted to the functionality of FIGS. 33A and 33B, respectively. In FIG. 33A, the previous first and second code segments of FIG. 30A are merged into a module that includes both. In this case, the code segments can still communicate with each other, but the interface can be adapted to a more suitable form for a single module. Thus, for example, formal call and return statements may no longer be needed, but similar processing or responses according to interface Interface1 may still be executed. Similarly, as shown in FIG. 33B, some (or all) of interface I2 from FIG. 30B may be written inline within interface I1 to form interface I1 ′. As shown, interface I2 is divided into I2a and I2b, and interface portion I2a is inline coded with interface I1 to form interface I1 ''. As a specific example, a function call that interface I1 from FIG. 30B processes the value received by interface I2 and passed as input by the second code segment (squares the input value) and passes the squared result to the output. Assume you do square (input, output). In this case, the processing performed by the second code segment (input squared) may be performed by the first code segment without a call to the interface.

Separation : Communication from one code segment to another can be achieved indirectly by separating the communication into multiple individual communications. This is shown schematically in FIGS. 34A and 34B. As shown in FIG. 34A, one or more middleware (separated interface since it separates functions and / or interface functions from the original interface) converts communications on the first interface Interface1 so that they can be replaced with different interfaces, in this case Interface Interface2A, Interface2B and Interface2C Provided for compliance. This may be done, for example, if there are installation-based applications designed to communicate with the operating system, for example according to the Interface 1 protocol, but then the operating system is changed to use a different interface, in this case interfaces Interface2A, Interface2B and Interface2C. The point is that the original interface used by the second code segment has been changed so that it is no longer compatible with the interface used by the first code segment, and therefore the medium is used to make the old and new interfaces compatible. Similarly, as shown in FIG. 34B, a third code segment may be introduced with a split interface DI1 that receives communications from interface I1 and a split interface DI2 that transfers interface functions, for example, to interfaces I2a and I2b. I2b is redesigned to work with DI2 but provides the same functional results. Likewise, DI1 and DI2 can work together to deliver the functionality of interfaces I1 and I2 of FIG. 30B to a new operating system while providing the same or similar functional results.

Rewrite : Another possible variant is to dynamically rewrite the code to replace the interface functionality with something else that achieves the same overall result. For example, a system in which a code segment expressed in an intermediate language is provided to a just-in-time compiler or interpreter in a runtime environment (eg, provided by a network framework, a Java runtime environment, or other similar runtime type environment). This may exist. The JIT compiler dynamically converts communications from the first code segment to the second code segment, i.e., to conform these communications to different interfaces as may be required by the second code segment (original or other second code segment). Can be rewritten to This is shown in Figures 35A and 35B. As shown in Figure 35A, this approach is similar to the separation scenario described above. This can be done, for example, if the installation based applications are designed to communicate with the operating system according to the Interface1 protocol, but then the operating system is changed to use a different interface. The JIT compiler can be used to allow communications to follow on-the-fly to the new interface of the operating system in install-based applications. As shown in FIG. 35B, this approach of dynamically rewriting an interface may be applied to dynamically factor or change the interface.

It should be noted that the above-described scenarios, which achieve the same or similar results as the interface through alternative embodiments, may also be combined in various ways, serially and / or in parallel, or with other arbitration code. Thus, the alternative embodiments described above are not mutually exclusive and can be mixed, matched, and combined to create a scenario that is the same as or equivalent to the general scenario provided in FIGS. 30A and 30B. It should also be noted that, as with most programming structures, there are other similar ways of achieving the same or similar functionality of the interface, which may not be described herein but represented by the spirit and scope of the present invention, that is, at least Note that the functions are represented in part by the interface on which the value of the interface is based, and the beneficial results made possible by the interface.

III. Sync API

Several approaches to synchronization are possible with item-based hardware / software interface systems. Section A discloses several embodiments of the present invention, and Section B focuses on various embodiments of APIs for synchronization.

A. Synchronization Overview

In various embodiments of the present invention, and in connection with FIG. 3, the storage platform may be configured such that (i) multiple instances of the storage platform, each having its own data store 302, of their content in accordance with a flexible set of rules. Provide a synchronization service 330 that allows for synchronizing portions and (ii) provides an infrastructure for the third party to synchronize the data repository of the storage platform of the present invention with other data sources implementing proprietary protocols.

Storage platform to storage platform synchronization occurs between a group of participating "copyings". For example, referring to FIG. 3, perhaps providing control between the data store 302 of the storage platform 300 and the other remote data store 338 under the control of another instance of the storage platform running on another computer system. It may be desirable. All members of this group do not necessarily know any given copy at any given time.

Other copies can make changes independently (ie, at the same time). The synchronization process is defined as making all copies aware of the changes made by other copies. Synchronization capability is inherently multimaster.

The synchronization capability of the present invention is that

Determine what changes the other copy is aware of,

Request information about changes that this copy does not know;

Communicate information about changes that other copies are not aware of,

Determining when two changes conflict with each other,

Apply the change locally,

Deliver conflict resolution to other copies to ensure convergence,

Allow to resolve conflicts based on specified policies for conflict resolution.

1. Storage platform vs storage platform synchronization

The primary application of the synchronization service 330 of the storage platform of the present invention is to synchronize multiple instances of the storage platform, each with its own data store. The synchronization service operates at the storage platform schema level (not the base table of the database engine 314). Thus, for example, "Scopes" are used to define a synchronization set as described below.

The synchronization service operates on the principle of "net change". The synchronization service does not record and transmit individual operations (eg, transactional replication), but sends the final results of these operations, thus often integrating the results of multiple operations into a single result change.

Synchronization services generally do not respect transaction boundaries. That is, if two changes are made to the storage platform data store in a single transaction, there is no guarantee that these changes will be applied atomically to all other copies, i.e. one change may appear without another. The exception to this principle is that if two changes are made to the same item in the same transaction, then these changes are guaranteed to be sent and applied to the other replicas in minimal units. Thus, items are the unit of consistency of the synchronization service.

a) Sync control application

Any application can connect to a synchronization service to initiate a synchronization operation. This application provides all of the parameters needed to perform synchronization (see Sync Profile below). This application is referred to herein as a Synchronization Control Application (SCA).

When synchronizing two storage platform instances, synchronization is initiated on one side by the SCA. The SCA notifies the local synchronization service to synchronize with the remote partner. On the other side, the synchronization service is started by a message sent by the synchronization service from the starting machine. The synchronization service responds based on persistent configuration information (see mapping below) present on the reaching machine. The synchronization service may be executed according to a schedule or in response to an event. In these cases, the synchronization service implementing the schedule is the SCA.

In order to enable synchronization, two steps must be taken. First, the schema designer should annotate the appropriate synchronization semantics (representing units of change as described below) in the storage platform schema. Second, synchronization must be properly configured on all machines with instances of the storage platform that will participate in the synchronization.

b) annotating the schema

The basic concept of the synchronization service is the concept of change units. The change unit is the smallest part of the schema that is tracked separately by the storage platform. For every change unit, the synchronization service may determine whether the change unit has changed since the last synchronization.

Displaying change units in a schema has several purposes. First, it determines how empty the synchronization service is on the wire. When a change is made within a change unit, the entire change unit is sent to the other copies, since the synchronization service does not know which part of the change unit has changed. Second, this determines the granularity of collision detection. When two concurrent changes (the term is defined in detail in subsequent sections) are made for the same change unit, the synchronization service causes a conflict, whereas if concurrent changes are made for different change units, no conflict occurs. , Changes are automatically merged. Third, this has a strong impact on the amount of metadata maintained by the system. Much of the synchronization service metadata is maintained for change units, so that change units add less synchronization overhead.

Defining change units requires finding the right tradeoffs. Because of this, the synchronization service allows schema designers to participate in the process.

In one embodiment, the synchronization service does not support larger units of change than elements. However, the synchronization service supports the ability of schema designers to specify smaller units of change than elements, that is, the ability to group multiple attributes of an element into individual change units. In this embodiment, this is accomplished using the following syntax.

c) Configure synchronization

The group of storage platform partners who want to keep some portion of their data in synchronization is referred to as the synchronization community. While members of the community want to stay in sync, they do not need to present the data in exactly the same way, that is, synchronization partners can transform the data they are synchronizing.

In a peer to peer scenario, it is impractical for peers to maintain translation mappings for all of their partners. Instead, the synchronization service takes the approach of defining "community folders". Community folders are abstract concepts that represent virtual "shared folders" where all community members are synchronized.

This concept is best illustrated by an example. If Joe wants to keep My Documents folders on his various computers in sync, Joe defines a community folder, for example JoesDocuments. Joe then configures the mapping between the virtual JoesDocuments folder and the local My Documents folder on every computer. From this point on, when Joe's computers are synchronized with each other, they talk about documents in JoesDocuments, not their local items. In this way, all Joe's computers understand each other without knowing who the other computers are, and community folders become the common language of the sync community.

The configuration of the synchronization service involves three steps: (1) defining the mapping between local and community folders, (2) what is synchronized (e.g. with whom, which subset should be sent and received). Defining a synchronization profile to determine, and (3) defining a schedule at which different synchronization profiles should be executed or a schedule to execute them manually.

(1) community folder-mapping

Community folder mappings are stored as XML configuration files on individual machines. Each mapping has the following schema:

/ mappings / communityFolder

This element specifies the name of the community folder that this mapping targets. The name follows the syntax rules of the folder.

/ mappings / localFolder

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

/ mappings / transformations

This element defines how to convert items from a community folder to a local folder and vice versa. If it does not exist or is empty, no conversion is done. Specifically, this means that no ID is mapped. This configuration is mainly useful for creating a cache of folders.

/ mappings / transformation / mapIDs

This element does not require that community IDs be used again, but requires that newly created local IDs be assigned for all items mapped from the community folder. Synchronization execution time maintains ID mapping to convert items back and forth.

/ 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 under whose authority the requests for this mapping are handled. If not present, the sender is assumed.

/ mappings / runAs / sender

The presence of this element indicates that the sender of the message for this mapping is implemented so that requests must be processed under its credentials.

(2) profile

The synchronization profile is a comprehensive set of parameters needed to initiate synchronization. This is provided by the SCA as a synchronization run time to initiate synchronization. The synchronization profile for storage platform to storage platform synchronization includes the following information.

Local folders that serve as the source and target for changes

Remote folder name to be synchronized-This folder must be made public from the remote partner via the mapping defined above.

Direction-synchronization service supports transmission only, reception only, and transmission-receive synchronization.

Local Filter-Select which local information is to be sent to the remote partner. Expressed as a storage platform query for a local folder.

Remote Filter-Select which remote information will be retrieved from the remote partner. Expressed as a storage platform query for community folders.

• Define how to convert items for the conversion-local format.

Local Security-Specify whether changes retrieved from a remote endpoint should be applied under the permission of the remote endpoint (personified) or under the permission of the user initiating local synchronization.

Conflict Resolution Policy-Specify whether conflicts should be rejected, logged or automatically resolved. In the latter case, you specify which conflict resolver to use as well as its configuration parameters.

The synchronization service provides a runtime CLR class that allows simple construction of synchronization profiles. Profiles can also be serialized to XML files (often with a schedule) for easy storage. However, there is no standard place in the storage platform where all profiles are stored, and the SCA may build the profile on the spot without continuing to maintain the profile. Note that it is not necessary to have a local mapping to initiate synchronization. All synchronization information can be specified in the profile. However, mapping is needed to respond to synchronization requests initiated by the remote side.

(3) Schedule

In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it relies on other components to perform this task: the window scheduler available in the Microsoft Windows operating system. The synchronization service includes a command line utility that acts as an SCA and triggers synchronization based on a synchronization profile stored in an XML file. This utility facilitates configuring the window scheduler to perform synchronization on a schedule or in response to events such as user logon or logoff.

d) conflict handling

The collision processing in the synchronization service includes three steps, namely (1) a collision detection step occurring at the time of change application, which determines whether the change can be safely applied; (2) Automatic conflict resolution and logging phase-During this phase (which occurs immediately after a collision is detected), an automatic conflict resolver is consulted to see if the conflict can be resolved, and if it cannot be resolved, the conflict may optionally Is logged; And (3) Conflict checking and resolution step—This step occurs when a predetermined conflict is logged and occurs without regard to a synchronization session, where the logged conflicts can be resolved and removed from the log.

(1) collision detection

In this embodiment, the synchronization service detects two kinds of collisions: knowledge based collisions and restriction based collisions.

(a) knowledge base conflict

Knowledge base conflicts arise when two copies make independent changes to the same unit of change. The two changes are said to be independent if they are made without knowledge of each other, ie the version of the first change is not covered by the knowledge of the second change and vice versa. The synchronization service automatically detects all conflicts based on the knowledge of the copy as described above.

Often, it can be helpful to regard a collision as a fork in the version history of the change unit. If no conflict occurs in the life of the change unit, its version history is a simple chain, ie each change occurs after a previous change. In the case of knowledge base collisions, the two changes occur at the same time, causing the chain to be split into version trees.

(b) restriction-based conflicts

When independent changes are applied together, there is a violation of conservation restrictions. For example, two replicas that create a file with the same name in the same directory can cause this conflict.

Constraints-based collisions involve two independent changes (just like knowledge-based collisions), but they do not affect the same unit of change. Rather, they affect change units that differ but have limitations in between.

The synchronization service automatically detects limit violations when applying changes and automatically generates limit-based conflicts. Resolving restriction-based conflicts usually requires a customer mode that modifies the change in a way that does not violate the restriction. The synchronization service does not provide a general purpose mechanism for doing this.

(2) conflict handling

When a conflict is detected, the synchronization service either selects one of three actions (selected by the synchronization initiator in the synchronization profile): reject the change and return it back to the sender, (2) log the conflict in the conflict log, (3) An action can be taken to automatically resolve the conflict.

If the change is rejected, the synchronization service behaves as if the change did not reach the copy. A negative response is sent to the sender. This resolution policy is primarily useful for headless copies (e.g. file servers) for which logging of conflicts is not possible. Instead, these copies allow other copies to handle the conflict by rejecting the conflict.

Sync initiators configure conflict resolution in their synchronization profile. The synchronization service specifies the list of conflict resolvers to be tried one by one until it succeeds, and then associates the conflict resolvers with the conflict types, ie sending update-update knowledge base conflicts to one resolver. Sending all other conflicts to the log supports combining multiple conflict resolvers into a single profile.

(a) Automatic conflict resolution

The synchronization service provides a number of default conflict resolvers. This list includes:

Local win: In case of a conflict with local stored data, the incoming changes are ignored.

Remote Win: In case of a conflict with an incoming change, ignore local data.

Final author win: Selects a local win or a remote win per change unit based on the time stamp of the change (generally, the synchronization service does not depend on the clock value, this conflict resolver is the only exception to this rule). .

Deterministic: Select Winner in a way that ensures that it is otherwise meaningless on all copies, and in one embodiment of the synchronization service implements this functionality using preedit comparisons of partner IDs.

An ISV can also implement and install its own conflict resolver. Customer conflict resolvers can accept configuration parameters, which must be specified by the SCA in the conflict resolution section of the synchronization profile.

The conflict resolver returns to runtime a list of actions that should be performed (instead of conflict changes) when handling the conflict. The synchronization service then applies these operations with the remote knowledge properly tuned to include what the conflict handler is considering.

Other conflicts may be detected while applying the solution. In this case, the new conflict must be resolved before resuming the original process.

When considering a conflict as a branch in an item's version history, conflict resolution can be seen as a join that combines two branches to form a single point. Thus, conflict resolution changes the version history to DAG.

(b) conflict logging

One very unusual kind of conflict resolver is a collision logger. The synchronization service logs the conflict as an item of type ConflictRecord. This record is associated with the conflicting items again (if the items themselves are not deleted). Each conflict record contains knowledge of the incoming change that caused the conflict, the type of conflict, that is, update-update, update-delete, delete-update, insert-insert, or limit, and the version of the incoming change and the copy that sent it. Include. Logged conflicts can be used for inspection and resolution as described below.

(c) collision detection and resolution

The synchronization service provides an API to the application to examine the crash log and suggest resolving conflicts in it. The API allows an application to enumerate all conflicts, or conflicts about a given item. The API also allows these applications to do three things: (1) remote wins that accept logged changes and overwrite conflicting local changes, (2) local wins that ignore conflicting portions of logged changes, and (3) applications. This allows him to resolve logged conflicts with one of the new change proposals that suggest merging to resolve conflicts. When the conflict is resolved by the application, the synchronization service is removed from the log.

(d) dissemination of copies and dissemination of conflict resolution;

In complex synchronization scenarios, the same conflict may be detected in multiple copies. When this happens, several things can happen: (1) the conflict is resolved on one copy, this resolution is sent to another copy, (2) the conflict is automatically resolved on both copies, or (3) the conflict In both copies, this can be resolved manually (via the collision detection API).

To ensure convergence, the synchronization service sends conflict resolution to another copy. When a conflict-resolving change reaches the copy, the synchronization service finds any conflicting records in the log that are resolved by this update and removes them. In this sense, conflict resolution in one copy is combined in all other copies.

If different winners are selected by different copies for the same conflict, the synchronization service chooses to automatically win one of the two resolutions by applying the principle of combining conflict resolutions. Winners are selected in a deterministic manner that ensures to always produce the same result (one embodiment uses copy ID preedit comparisons).

If different "new changes" are proposed by different copies for the same conflict, the synchronization service treats this new conflict as a special conflict and uses a collision logger to prevent this new conflict from propagating to other copies. do. This situation usually arises from manual conflict resolution.

2. Synchronize for non-storage platform data store

According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for an ISV to implement a synchronization adapter that allows the storage platform to synchronize to legacy systems such as Microsoft Exchange, AD, Hotmail, and the like. Synchronous adapters benefit from many of the synchronization services provided by the synchronization service, as described below.

Despite its name, the synchronization adapter does not need to be implemented as a plug-in into any storage platform architecture. If desired, a "sync adapter" may be any application that simply obtains services such as change enumeration and application using the synchronization service runtime interface.

To make it simpler for others to configure and implement synchronization for a given backend, the sync adapter author is recommended to expose a standard sync adapter interface that performs synchronization when given a synchronization profile as described above. Profiles provide configuration information to the adapter, which passes some of it at runtime to control runtime services (eg, folder synchronization).

a) synchronization service

The synchronization service provides a number of synchronization services to the adapter creator. In the remainder of this section, it is convenient to refer to the machine with which the storage platform is synchronizing as "client" and the non-storage platform backend with which the adapter is talking as "server."

(1) change enumeration

Based on the change tracking data maintained by the synchronization service, change enumeration allows the sync adapter to easily enumerate changes that have occurred since the last synchronization with this partner for the data store folder.

Changes are listed based on the concept of "anchor", an opaque structure that represents information about final synchronization. The anchor takes the form of storage platform knowledge as described in the previous section. Synchronous adapters using the change enumeration service fall into two broad categories: adapters using "stored anchors" and adapters using "provided anchors".

The difference is based on whether information about the final synchronization is stored on the client or on the server. Often, it is easier for the adapter to store this information on the client, and the backend often cannot store this information conveniently. On the other hand, if multiple clients are synchronizing to the same backend, storing this information on the client is inefficient, and in some cases incorrect, which prevents one client from knowing the changes that another client has already pushed to the server. . If the adapter wants to use an anchor stored on the server, the adapter needs to provide this anchor to the storage platform at enumeration of changes.

In order for the storage platform to maintain anchors (for local or remote storage), the storage platform needs to know the changes that have been successfully applied at the server. Only these changes can be included in the anchor. During change enumeration, the synchronization adapter uses an acknowledgment interface to report which changes were applied successfully. At the end of synchronization, adapters using the provided anchor must read the new anchor (including all successfully applied changes) and send it to their backend.

Often, adapters need to store adapter specific data along with the items they insert into the storage platform data store. General examples of such data are remote ID and remote version (time stamp). The synchronization service provides a mechanism for storing this data, and change enumeration provides a mechanism for receiving this extra data with the returned change. This eliminates the need for adapters to materialize in the database in most cases.

(2) apply changes

Change application allows synchronization adapters to apply changes received from their backend to the local storage platform. Adapters are expected to convert changes to the storage platform schema. 24 illustrates a process in which storage platform API classes are generated from a storage platform schema.

The main function of applying changes is to automatically detect collisions. As in the case of storage platform-storage platform synchronization, a collision is defined as two duplicate changes being made without knowledge of each other. When adapters use change application, they must specify the anchor to be involved in performing collision detection. Change application causes a crash if a duplicate local change is detected that is not covered by the knowledge of the adapter. Similar to change enumeration, adapters can use a stored or provided anchor. Change adaptation supports efficient storage of adapter specific metadata. Such data may be attached to changes being applied by the adapter and may be stored by the synchronization service. The data can be returned on the next change enumeration.

(3) conflict resolution

The aforementioned conflict resolution mechanism (logging and auto resolution option) is also available to synchronization adapters. Synchronization adapters can specify a policy for conflict resolution when applying changes. If specified, conflicts can be passed to the designated conflict handler (if possible) and resolved. Conflicts can also be logged. The adapter may detect a conflict when attempting to apply local changes to the backend. In this case, the adapter can still propagate the conflict at synchronization runtime to resolve according to the policy. In addition, synchronization adapters may require that any conflicts detected by the synchronization service be sent to them for processing. This is particularly convenient if the backend can save or resolve the collision.

b) adapter implementation

Some adapters are just applications that use a runtime interface, but adapters are recommended to implement a standard adapter interface. These interfaces allow synchronization control applications to require the adapter to perform synchronization in accordance with a given synchronization profile, cancel ongoing synchronization, and receive progress reports on ongoing synchronization.

3. Security

The synchronization service seeks to introduce as little as possible into the security model implemented by the storage platform. Use existing rights rather than defining new rights for synchronization. Specifically, it is as follows.

• Anyone who can read a data store item can enumerate changes to that item.

• Anyone who can write to a data store item can apply changes to that item.

Anyone who can extend a data store item can associate synchronization metadata with that item.

The synchronization service does not maintain secure author information. When a change is made to copy A by user U and sent to copy B, the fact that the change was first made at A (or by U) is lost. If B sends this change to copy C, it is under B's authority, not A's authority. This causes the following limitations: If a copy does not have the authority to make its own changes to an item, this copy cannot transfer changes made by other copies.

When the synchronization service is started, this is done by the synchronization control application. The synchronization service personifies an identifier of the SCA and performs all operations (both local and remote) under this identifier. For example, note that user U cannot cause the local synchronization service to retrieve changes from the remote storage platform for items that user U does not have read access to.

4. Manageability

Monitoring the distributed community of manuscripts is a complex problem. The synchronization service may use a "sweep" algorithm to collect and distribute information about the status of the copies. The properties of the sweep algorithm ensure that information about all configured copies is eventually collected and that failed (unresponsive) copies are detected.

This community-wide monitoring information will be available in all copies. Monitoring tools can be run on any selected copy to examine this monitoring information and make administrative decisions. Any configuration change should be made directly in the affected copies.

B. Synchronization API Overview

In an increasingly distributed digital world, individuals and work groups often store information and data on a variety of different devices and locations. This has supported the development of data synchronization services that can maintain information with minimal user intervention in separate, often different and always synchronized data stores.

The synchronization platform of the present invention, which is part of the rich storage platform (a.k.a, " WinFS) described in section II of this specification, deals with the following three main objects.

Allow applications and services to synchronize data between different "WinFS" repositories.

Enable developers to build rich solutions for synchronizing data between "WinFS" and non- "WinFS" repositories.

• Provide developers with a suitable interface for customizing a synchronized user experience.

1. General Terminology

Some of the more refined definitions and key concepts related to the description in Section III.B below are as follows.

Synchronized copy: Most applications are only concerned with tracking, enumerating, and synchronizing changes to a given subset of items in the WinFS repository. The set of items participating in the synchronization operation is called a synchronization copy. A copy is defined as items contained within a given WinFS containment hierarchy (usually rooted at folder items). All synchronization services are performed in relation to a given copy. WinFS synchronization provides a mechanism for defining, managing, and removing copies. Every copy has a GUID identifier that uniquely identifies it within a given WinFS repository.

Synchronization Partners: Synchronization partners are defined as entities that can affect changes in WinFS items, extensions, and relationships. Thus, all WinFS repositories are synchronous partners. When synchronized with non-WinFS storage, external data storage (EDS) is also a synchronous partner. Every partner has a GUID identifier that uniquely identifies it.

Synchronization Community: A synchronization community is defined as a collection of copies that are maintained during synchronization by peer-to-peer synchronization operations. These copies can all be in the list itself, which is virtual copies on the same WinFS repository, different WinFS stores, or even non-WinFS stores. WinFS synchronization does not prescribe or specify any particular topology for the community, especially if only synchronization operations within the community are through the WinFS synchronization service (WinFS adapter). Synchronization adapters (defined below) may introduce their own topology constraints.

Change Tracking, Change Units and Versions: All WinFS repositories track changes to all local WinFS entries, extensions, and relationships. Changes are tracked at the level of change unit granularity defined in the schema. Top level fields of any item, extension, and relationship type can be broken down into units of change by the schema designer, with a minimum granularity of one top level field. For change tracking, every change unit is assigned a version, which is a pair of synchronization partner id and version number (the version number is the partner specific monotonic increment number). The versions are updated when the change occurs locally in the repository or when the change is obtained from another copy.

Synchronization knowledge: Knowledge represents the state of a given synchronization copy at any time, ie, encapsulates metadata for all changes that a given copy recognizes locally or from other copies. WinFS synchronization maintains and updates knowledge of synchronization copies in synchronization operations. An important note is that knowledge representations are allowed to be interpreted in relation to the entire community, not to the specific copy in which the knowledge is stored.

Synchronization adapter: The synchronization adapter is a managed code application that accesses the WinFS synchronization service through the synchronization runtime API and enables synchronization of non-WinFS data stores of WinFS data. Depending on the requirements of the scenario, it is up to the adapter developer which subset of the WinFS data and which WinFS data types should be synchronized. The adapter is responsible for communicating with the EDS, converting the WinFS schema to and from the EDS supported schema, and managing its own configuration and metadata. Adapters are strongly encouraged to implement the WinFS Synchronization Adapter API to use a generic configuration to control the infrastructure for adapters provided by the WinFS synchronization team. See the WinFS Synchronization Adapter API [SADP] specification and the WinFS Synchronization Controller API [SCTRL] specification for more details.

For adapters that synchronize WinFS data to an external non-WinFS repository and cannot generate or maintain knowledge of the WinFS format, WinFS synchronization provides a service for gaining remote knowledge that can be used for subsequent change enumeration or apply operations. Depending on the capabilities of the back end repository, the adapter may want to store remote knowledge on the back end or on a local WinFS repository.

For simplicity, a synchronization "copy" is a structure that represents a set of data in a "WinFS" store that exists in a single logical location, while data on a non- "WinFS" store is called a "data source" and is typically an adapter. Requires the use of

Remote knowledge: When a given synchronized copy wants to get changes from another copy, this copy provides its own knowledge as a baseline where the other copy lists the changes. Similarly, when a given copy wants to transfer changes to another copy, this copy provides its own knowledge as a baseline that can be used by another copy to detect conflicts. Knowledge of these other copies provided during synchronous change enumeration and application is referred to as remote knowledge.

2. Synchronization API Principle

In certain embodiments, the synchronization API is divided into two parts, the synchronization configuration API and the synchronization controller API. The Synchronization Configuration API allows an application to configure synchronization and specify parameters for a particular synchronization session between two copies. 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 store, and conflict resolution policy. The synchronization controller API initiates a synchronization session, cancels the synchronization, and receives progress and error information about the ongoing synchronization. Moreover, in certain embodiments where synchronization needs to be performed according to a predetermined schedule, such a system may include a scheduling mechanism to customize the scheduling.

Various embodiments of the present invention use a synchronization adapter to synchronize information between "WinFS" and non- "WinFS" data sources. Examples of adapters include adapters that synchronize address book information between "WinFS" contact folders and non-WinFS mailboxes. In this example, an adapter developer may use the "WinFS" described herein to access the services provided by the "WinFS" synchronization platform to develop schema conversion code between a "WinFS" schema and a non- "WinFS" data source schema. "You can use the Synchronization Core Services API. Adapter developers also provide protocol support for communicating changes with non-WinFS data sources. The synchronization adapter is called and controlled using the synchronization controller API, which reports progress and errors.

However, in some embodiments of the present invention, when synchronizing a WinFS data store to another WinFS data store, a synchronization adapter may not be required if the WinFS to WinFS synchronization service is integrated into a hardware / software interface system. In either case, these various embodiments provide a set of synchronization services for both WinFS to WinFS and synchronization adapter solutions, including the following.

Tracking changes to WinFS entries, extensions, and relationships

Support for efficient incremental change enumeration since a given past state

Applying External Changes to WinFS

Conflict handling during change application.

Reference is made to FIG. 36, which shows three instances of a common data store and components for synchronizing them. The first system 3602 includes a WinFS data store including a core synchronization service 3624 that exposes (3646) the use of the synchronization API 3652 for WinFS to WinFS synchronization service 3622 and WinFS to non-WinFS synchronization. Has (3612). Similar to the first system 3602, the second system 3604 exposes (3646) core synchronization to use the Synchronization API (3652) for WinFS to WinFS synchronization service (3632) and WinFS to non-WinFS synchronization (3646). It has a WinFS data store 3614 which includes a service 3634. First system 3602 and second system 3604 are synchronized (3642) via their respective WinFS to WinFS synchronization services 3622 and 3632. A third system 3606 that is not a WinFS system has an application 3666 that uses WinFS synchronization to maintain a data source within a synchronization community with WinFS copies. This application works directly with the WinFS data store 3612 via WinFS to WinFS synchronization service 3622 (if it can virtualize itself as a WinFS data store) or through a synchronization adapter 3662 that interfaces with the synchronization API 3652. An interface 3644 may utilize the WinFS synchronization configuration / control service 3664.

As shown in this figure, the first system 3602 recognizes and directly synchronizes both the second system 3604 and the third system 3606. However, both the second system 3604 and the third system 3606 do not know each other and thus do not directly synchronize their changes with each other, but instead the changes that occur in one system are passed through the first system 3602. It must be spread.

C. Sync API Service

Various embodiments of the present invention relate to a synchronization service comprising two basic services, namely change enumeration and change application.

1. Change enumeration

As mentioned above, change enumeration allows the synchronization adapter to easily enumerate changes that have occurred since the last synchronization with this partner for the data store folder based on the change tracking data maintained by the synchronization service. Regarding change enumeration, several embodiments of the present invention relate to the following.

Efficient enumeration of changes to items, extensions, and relationships within a given copy, for a given knowledge instance

Enumeration of changes at the level of change unit granularity specified in the WinFS schema.

Grouping of changes listed with respect to compound items. A composite item consists of an item, all of its expansions, all of the maintenance relationships for the item, and all of the compound items corresponding to their insertion items. Changes to reference relationships between items are listed separately.

Placement at change enumeration. The granularity of the batch is a compound item or relationship change (for a reference relationship).

Specifying filters for items in the copy during change enumeration. For example, a copy consists of all items in a given folder, but for a specific change enumeration, the application wants to list only changes for all contact items whose first name begins with 'A' (this support is a milestone B). Is added after).

Remote knowledge of the listed changes, with the ability to record individual change units (or entire items, extensions or relationships) as failed to synchronize within the knowledge, so that they can be enumerated again next time. do.

Use of enhanced adapters to understand WinFS synchronization metadata by returning metadata with changes during change enumeration

2. Apply changes

As mentioned above, change adaptation allows synchronous adapters to apply changes received from their backend to the local storage platform because they are expected to convert the changes to the storage platform schema. Regarding the application of modifications, various embodiments of the present invention relate to the following.

Apply incremental changes to WinFS change metadata from other copies (or non-WinFS repositories) with corresponding updates.

Detection of collisions when applying changes in granularity of change units

• Report successes, failures and conflicts at the level of individual change units when applying changes. Accordingly, applications (including adapters and synchronization control applications) can use this information for progress, error and status reporting, and if any, to update their backend status.

Update of remote knowledge during change application to prevent "reflection" of application-provided changes during the next change enumeration operation.

• Use of improved adapters to understand and provide WinFS synchronization metadata with changes.

3 sample code

Here is a code sample of how the FOO sync adapter interacts with the synchronization runtime (where FOO is prefixed with all adapter-specific functions):

4. Method of API Synchronization

In one embodiment of the present invention, synchronization between a WinFS repository and a non-WinFS repository may be accomplished through a synchronization API exposed by a WinFS-based hardware / software interface system.

In one embodiment, all synchronization adapters are required to 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 provides the following:

Standard mechanism for registering adapters to hardware / software interface system synchronization framework

A standard mechanism by which adapters can declare their capabilities and the type of configuration information needed to initialize the adapter.

Standard mechanism for passing initialization information to the adapter

Mechanisms for reporting progress to applications in which adapters invoke synchronization

Mechanism for reporting any errors that occur during synchronization

A mechanism for requiring a minimum of ongoing synchronization operations

There are two potential process models for adapters depending on the requirements of the scenario. The adapter can run alone in the same process space as the application that calls it or in a separate process. To run in its own separate process, the adapter defines its own factory class that is used to instantiate itself. The factory can return an instance of the adapter in the same process as the calling application, or a remote instance of the adapter in another Microsoft common language runtime application domain or process. A default factory implementation is provided that instantiates the adapter in the same process. In fact, many adapters run in the same process as the calling application. Out of the process model is usually needed for one or two reasons:

Security purpose. The adapter must run in the process space of a given process or service.

The adapter must handle requests from other sources, for example incoming network requests, in addition to handling requests from the calling application.

Referring to FIG. 37, one embodiment of the present invention assumes a simple adapter that does not know how the state is calculated or how metadata associated with it is exchanged. In this embodiment, the synchronization is achieved by copying, in relation to the data source that the copy wants to synchronize, by first detecting in step 3702 what changes occurred after the copy was last synchronized with the data source. The copy sends incremental changes that occurred after the last synchronization based on its current state information, which is then sent to the data source through the adapter. In step 3704, the adapter makes as many changes to the data source as possible when it receives change data from the copy in the previous step, tracks which changes were successful and which changes failed, and reports the success and failure information (the copy of the copy). ) Transfer to WinFS. The copy's hardware / software interface system (WinFS), in step 3706, receives the success and failure information from the copy, calculates new status information for the data source, and stores this information for future use by its copy. This new state information is then sent to the data source, i.e. to the adapter for storage and subsequent use by the adapter.

D. Additional Aspects of the Synchronization Schema

The following are additional (or more specific) aspects of the synchronization schema in various embodiments of the present invention.

Each copy is a synchronization subset of data defined from the whole of the data store, ie a data slice with multiple instances.

The conflict resolution policy is handled separately by each copy (and adapter / data source combination), ie each copy can resolve conflicts based on its own criteria and conflict resolution schema. Moreover, differences in each instance of the data store can cause additional future conflicts, but incremental and sequential enumeration of conflicts as reflected in updated status information is not visible to other copies receiving the update status information. .

The root of the synchronization schema contains a base type that defines a root folder (virtually a root item) with a unique ID, an ID for the synchronization community as a member, and a copy with all the filters and other elements needed or desirable for that particular copy. exist.

The mapping of each copy is kept in the copy, so that the mapping for any particular copy is limited to other copies that this copy does not know. Such a mapping may include only a subset of the entire synchronization community, but changes to the copy may still be made via the shared copies (though not knowing what other copies are shared with the copy that any particular copy does not know). Is propagated to.

The synchronization schema includes the capabilities of a user / developer defined customer conflict handler as well as a plurality of predefined conflict handlers available to all copies. The schema also contains three special "collision resolvers": (a) how to handle when (i) the same unit of change has changed in two places, (ii) the unit of change has been changed in one place, but deleted elsewhere. A collision "filter" that resolves different conflicts in different ways based on the method of handling when, and (iii) a process when two different units of change have the same name in two different places, (b) a collision "resolver List "—each element of this list specifies a sequence of actions to be attempted sequentially until the conflict is successfully resolved, and (c) a" no action "that tracks the conflict but takes no further action without user intervention. (do-nothing) "logs.

Synchronization scheme and use of copies enables a truly distributed peer to peer multimaster synchronization community. Moreover, although there is no synchronization community type, the synchronization community exists only as a value in the community field of the copies themselves.

Every copy has its own metadata for tracking incremental change enumerations and storing state information for other copies known in the synchronization community.

The version of change units comprising a partner key plus partner change number; Item / extension / relational version for each change unit; Knowledge of the changes the copy has seen or received from the synchronization community; GUID and local ID configuration; And their own metadata, including the GUID stored on the reference relationship for deletion.

IV. conclusion

As mentioned above, the present invention relates to a storage platform for the organization, retrieval and sharing of data. The storage platform of the present invention extends and broadens the concept of data storage beyond existing file systems and database systems, and is called semi-structured data such as structured, unstructured, or relational (table) data, XML, and items. It is designed to be a repository for all types of data, including new types of data. The storage platform of the present invention enables more efficient application development for consumers, knowledge workers and businesses through its general storage foundation and schematized data. The storage platform not only makes use of capabilities unique to its data model, but also provides a rich and extensible application programming interface that accommodates and extends existing file system and database access methods. It is to be understood that changes may be made to the above-described embodiments without departing from the broad inventive concept of the invention. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed, but to cover all modifications that fall within the spirit and scope of the invention as defined by the appended claims.

As will be apparent from the above description, all or some of the various systems, methods, and aspects of the present invention may be implemented in the form of program code (ie, instructions). The program code is computer readable, such as, but not limited to, magnetic, electrical or optical storage media including floppy diskettes, CD-ROMs, CD-RWs, DVD-ROMs, DVD-RAMs, magnetic tapes, flash memory, hard disk drives. The computer may be stored in a medium or any other machine readable storage medium, and when the program code is loaded and executed on a machine such as a computer or a server, the machine becomes an apparatus for practicing the present invention. The invention may also be embodied in the form of program code transmitted over any transmission medium, such as electrical wiring or wired, optical fiber, a network comprising the Internet or an intranet, or any other form of transmission, wherein the program code is associated with a computer. When received, loaded and executed by the same machine, the machine becomes an apparatus for practicing the present invention. Program code, when implemented in a general-purpose processor, provides a unique device that, when combined with a processor, operates similarly to specific logic circuits.

Claims (30)

As a storage platform system for a hardware / software interface system (e.g. WinFS), Multiple instances of a storage platform; And Native to the hardware / software interface system, a synchronization subsystem that enables the system to synchronize multiple instances of the storage platform. Storage platform system comprising a. The storage platform system of claim 1, wherein the synchronization subsystem synchronizes only a subset of data among all data in the data store during a synchronization operation. The system of claim 1, wherein the first instance of the storage platform is a copy running on a hardware / software interface system (eg, WinFS) with the synchronization subsystem, and the second instance of the storage platform is the synchronization sub. A storage platform system that is a data source running on a hardware / software interface system (eg non-WinFs) that does not have a system. 4. The storage platform system of claim 3, wherein synchronization between the copy 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 copy's hardware / software interface system. The storage platform system of claim 1, wherein the first instance pair synchronizes changes independently of the second instance pair, and wherein both the first instance pair and the second instance pair are part of a common sync community. The storage platform system of claim 1, wherein collisions in synchronization are automatically detected and resolved based on certain determineable criteria. 7. The storage platform system of claim 6, wherein some of the conflicts are resolved by logging for manual resolution by an end user. The storage platform system of claim 1, wherein the synchronization subsystem tracks the status of previous synchronizations with a synchronization partner, synchronizing only with the change units (ie, "pure changes") that have changed since the last synchronization. A method of synchronizing multiple instances of a storage platform to a hardware / software interface system (e.g., WinFS), Dividing the storage platform into basic units of granularity (eg, change units); Enumerating changes sequentially and tracking the changes per change unit; For each instance, tracking the status of changes to the instance as well as the status of changes to a plurality of other known instances in the synchronization community (synchronization partners); And For synchronization, identifying new changes by comparing the changes listed for a particular instance with the state of the changes for this instance How to include. 10. The hardware / software interface of claim 9, wherein the first instance, which is a copy, is instantiated on a hardware / software interface system (WinFS) that directly supports item-based synchronization, and the second instance, which is a data source, does not directly support item-based synchronization. Instantiated on a system (non-WinFS), the method further comprising using an adapter to virtualize the non-WinFS instance via a synchronous application programming interface. 12. The method of claim 10, further comprising detecting a synchronization conflict at the level of change unit granularity. The method of claim 10, When the change is applied, the instance (synchronization data) reports success, failure and / or conflict at the individual change unit level; And The use of the synchronization data by an application (including but not limited to an adapter and other synchronization control applications) to update the backend state How to include more. Copy and data source (each synchronization partner)-Both the copy and data source have change status information maintained by each synchronization partner, and the data source (non-WinFS) uses an adapter to provide hardware / A method for synchronizing with the software interface system (WinFS). An updated state for the copy that reflects changes made since the last synchronization reflected in the last state information for the data source (“new changes”) based on the last state information for the data source. Transmitting information to the adapter; And The adapter receiving the updated status information and the new changes to the copy, making as many changes to the data source as possible, and tracking success or failure for each change on the change unit per change unit. How to include. The method of claim 13, The adapter calculates a new state of the data source based on the success or failure of each change on a change unit for each change unit, stores the new state information, and stores the new state information in the copy's hardware / software interface. Transmitting to a system (WinFS); And The hardware / software interface system (WinFS) of the copy storing the new state information for the data source for future use by the copy. How to include more. The method of claim 13, Sending, by the adapter, the success or failure of each change on a change unit for each change unit to a hardware / software interface system (WinFS) of the copy; Calculating, by the hardware / software interface system (WinFS) of the copy, new state information for the data source based on the success or failure of each change to the data source on a change unit per change unit; The hardware / software interface system (WinFS) of the copy transmitting the new state information to the adapter and storing the new state information for future use by the copy; And The adapter receiving and storing the new state information How to include more. A computer readable medium containing computer readable instructions for a storage platform system on a hardware / software interface system (eg WinFS), The storage platform system includes instructions for synchronizing a local instance among a plurality of instances of a storage platform. 17. The computer readable medium of claim 16, wherein the synchronization subsystem synchronizes only a subset of the data among all of the data in the data store during the synchronization operation. 17. The system of claim 16, wherein the first instance of the storage platform is a copy running on a hardware / software interface system (e.g., WinFS) having a synchronization subsystem, and the second instance of the storage platform is a synchronization subsystem. A computer readable medium that is a data source running on a hardware / software interface system (eg, non-WinFs) that is not equipped. 19. The computer of claim 18 wherein synchronization between the copy and the data source is facilitated by 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. Readable Media. 17. The computer readable medium of claim 16, wherein the first instance pair synchronizes changes independently of the second instance pair, and both the first instance pair and the second instance pair are both part of a common synchronization community.  17. The computer readable medium of claim 16, wherein collisions in synchronization are automatically detected and resolved based on predetermined determineable criteria. 22. The computer readable medium of claim 21, wherein some of the conflicts are resolved by logging for manual resolution by an end user. 17. The computer readable medium of claim 16, wherein the synchronization subsystem tracks the status of previous synchronizations with the synchronization partner, synchronizing only with the change units (ie, "pure changes") that have changed since the last synchronization. A computer readable medium comprising computer readable instructions for synchronizing a plurality of instances of a storage platform for a hardware / software interface system (eg, WinFS), The computer readable instructions, Dividing the storage platform into basic granularity units (eg, change units); Enumerating changes sequentially and tracking the changes per change unit; For each instance, instructions to track the status of changes to the instances, as well as the status of changes to a plurality of other known instances within a synchronization community (synchronization partners); And For synchronization, instructions that identify new changes by comparing the changes listed for a particular instance with the state of the changes for that instance Computer-readable medium comprising a. The computer-readable medium of claim 24, wherein the computer readable instructions comprise: Hardware / software interface system (non-WinFS) whose copy is the first instance instantiated on hardware / software interface system (WinFS) that directly supports item-based synchronization and data source second instance does not directly support item-based synchronization. And instructions to be instantiated on a computer, the method further comprising virtualizing the non-WinFS instance via a synchronous application programming interface using an adapter. 27. The computer readable medium of claim 25, wherein the computer readable instructions further comprise instructions for detecting a synchronization conflict at a level of change unit granularity. The computer-readable medium of claim 25, wherein the computer readable instructions comprise: Instances (synchronization data) reporting success, failure and / or conflict at the individual change unit level when applying the change; And Applications that use synchronization data to update the backend state, including but not limited to adapters and other synchronization control applications. Computer-readable medium further comprising. Copy and data source (each synchronization partner)-Both the copy and data source have change status information maintained by each synchronization partner, and the data source (non-WinFS) uses an adapter to provide hardware / A computer readable medium comprising computer readable instructions for synchronizing with a software interface system (WinFS). The computer readable instructions, An updated state for the copy that reflects changes made since the last synchronization reflected in the last state information for the data source based on the last state information for the data source (“new changes”) By sending information to the adapter, the adapter receives the updated status information and the new changes to the copy, makes as many changes to the data source as possible, and for each change on a change unit per change unit. Computer-readable media containing instructions for enabling the tracking of success or failure for a computer. The computer-readable medium of claim 28, wherein the computer readable instructions comprise: The adapter calculates a new state of the data source based on the success or failure of each change on the change unit per change unit, has the new state information, and sends the new state information to the copy of the hardware / software interface system ( And a copy by the hardware / software interface system (WinFS) of the copy to store the new state information for a data store for future use by the copy. The computer-readable medium of claim 28, wherein the computer readable instructions comprise: The adapter sends the success or failure of each change on the change unit to the copy's hardware / software interface system (WinFS) for each change unit, Causing the copy of hardware / software interface system (WinFS) to calculate new state information for the data source based on the success or failure of each change to the data source per change unit; And The adapter's hardware / software interface system (WinFS) sends the new state information to the adapter and stores the new state information for future use by the copy so that the adapter receives and stores the new state information. The computer readable medium further comprising instructions for enabling the use of a computer.

Images