KR101149959B1 - System and methods for synchronizing computer systems through an intermediary file system share or device - Google Patents

Abstract

The present invention is based on the finding that two clients using a common storage platform (e.g., a new storage platform of the related invention) (e.g., instead of using a legacy storage platform that does not support synchronization for a new storage platform) And more particularly to a synchronization system and method for synchronizing through an intermediary that does not use a storage platform. The data is synchronized using existing mediator capabilities, where the data structure of the client is preserved. An " adapter " is used to allow a client to interact with an intermediary by rewarding an intermediary that is not capable of preserving a data structure element unique to the client's storage platform. Particular embodiments relate to either or both of upload synchronization data from the client to the intermediary and / or download synchronization data from the intermediary to the client. Certain additional embodiments also relate to data compression on the intermediary.

An intermediary, an STI adapter, a storage platform, a synchronization file, a transmission synchronization operation, a reception synchronization operation, a compression operation

Description

SYSTEM AND METHODS FOR SYNCHRONIZING COMPUTER SYSTEMS THROUGH INTERMEDIATE FILE SYSTEM SHARKS OR DEVICES BACKGROUND OF THE INVENTION 1. Field of the Invention < RTI ID = 0.0 >

<Cross reference>

This application is related to U.S. Patent Application (number not yet assigned) entitled " System and Method for Synchronizing Computer Systems via Intermediate File System Sharing or Device, " filed July 12, 2004, Attorney Docket MSFT- 4484) and claims priority to U.S. Provisional Application No. 60 / 567,141 (Attorney Docket MSFT-3939 / 306727.01), filed April 30, 2003; A United States patent application entitled " System and Method for Providing Conflicting Processing for Peer-to-Peer Synchronization by the Hardware / Software Interface System with Information Manageable Units ", filed June 30, 2004 No. 10 / 883,621 (Attorney Docket MSFT-2854), filed on October 24, 2003, entitled " Providing Relationship to Information Manageable Units and Hierarchical Synchronization Services by a Hardware / Software Interface System System and Method, " entitled " Storage Platform for Systematization, Retrieval and Sharing of Data Filed August 21, 2003, Attorney Docket No. MSFT-2845, Quot; United States Patent Application 10 / 646,646 (Attorney Docket MSFT-2734); Priority is also claimed to international application PCT / US03 / 27419 (Attorney Docket MSFT-2778) filed on August 21, 2003, the disclosures of which are incorporated herein by reference.

This application is related to the inventions set forth in the following commonly assigned applications, the contents of which are incorporated herein by reference in their entirety (and are summarized for convenience only): August 21, 2003 U.S. Patent Application No. 10 / 647,058 entitled " System and Method for Representing Units of Information Independent of Physical Representation, Manageable by a Hardware / Software Interface System, " U.S. Patent Application 10 / 646,941 entitled "System and Method for Separating Units of Information Manageable by a Hardware / Software Interface System from Their Physical Representation" filed on August 21, 2003; U.S. Patent Application No. 10 / 646,940 entitled " System and Method for Implementing a Basic Scheme for Organizing Units of Information Manageable by a Hardware / Software Interface System ", filed on August 21, 2003; Entitled " SYSTEM AND METHOD FOR IMPLEMENTING A Core Schema That Provides a Top-Level Structure for Organizing Units of Information Manageable by a Hardware / Software Interface System ", filed on August 21, 2003, / 646,632; U.S. Patent Application No. 10 / 646,645 entitled "System and Method for Representing Relationships Between Units of Information Manageable by a Hardware / Software Interface System" filed on August 21, 2003; U.S. Patent Application No. 10 / 646,575 entitled "SYSTEM AND METHOD FOR INTERFACING APPLICATION PROGRAMS WITH ITEMS BASED STORAGE PLATFORM" filed on August 21, 2003; U.S. Patent Application No. 10 / 646,580 entitled "System and Method for Data Modeling in Item Based Storage Platforms," filed on August 21, 2003; U.S. Patent Application No. 10 / 692,779 entitled " System and Method for Implementing a Digital Picture Scheme Organizing Units of Information Manageable by a Hardware / Software Interface System " filed October 24, 2003; U.S. Patent Application No. 10 / 692,515 entitled "Systems and Methods for Providing Relationships and Hierarchical Synchronization Services to Units of Information Manageable by a Hardware / Software Interface System", filed October 24, 2003; U.S. Patent Application No. 10 / 693,362 entitled "System and Method for Implementing a Synchronization Scheme for Units of Information Manageable by a Hardware / Software Interface System", filed October 24, 2003; And U.S. Patent Application No. 10 / 693,575 entitled " System and Method for Extending and Inheriting Units of Information Manageable by a Hardware / Software Interface System ", filed October 24, 2003.

The present invention relates generally to synchronization and, more particularly, to a method and system for synchronizing files using a common storage platform (e.g., WinFS), but using other intermediate file system application programming interface (API) (Including, but not limited to, roaming through an API-accessible Win32 file share or other storage device), synchronizing data-sharing, end-user roaming (end-user profiles and their equivalents) And the synchronization between two or more computers that support it.

Individual disk capacity has increased by about 70% annually over the past decade. Moore's Law correctly predicted a remarkable improvement in CPU performance over the years. Wireline and wireless technologies provided tremendous connectivity and bandwidth. Assuming the current trend continues, in a few years the average laptop computer will have a storage capacity of about one terabyte (TB), will contain millions of files, and a 500 gigabyte (GB) drive will be common .

Consumers use their computers to organize personal information, largely independent of communication and the media, such as traditional personal information manager (PIM) style data, digital music or photos. The amount of digital content and the ability to store raw bytes has grown tremendously, but the methods consumers can use to organize and integrate data have not kept pace. Knowledge workers spend enormous amounts of time managing and sharing information, and some studies suggest that knowledge workers spend 15-25% of their time on unproductive information-related activities. According to other studies, general knowledge workers are estimated to spend about 2.5 hours a day searching for information.

Developers and information technology (IT) sectors invest a considerable amount of time and money in building their own data repositories for common storage abstraction to represent things such as people, places, times, and events. This not only causes redundant operations, but also creates islands of common data that do not have a 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 e-mail clients and personal accounting programs, maintain separate address books, and there is little sharing of applications for 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 recipient with the address stored in the e-mail contact folder (e.g., a folder in Microsoft Outlook). In fact, many users have a variety of devices, logically synchronize their personal data with themselves, and with a variety of additional sources, including cell phones, to use services such as MSN and AOL, Is sufficiently accomplished by attaching documents to an e-mail message, i.e., manually and inefficiently.

One reason for this lack of cooperation is that the traditional approach to organizing information in computer systems is to organize multiple files into a directory hierarchy of folders based on the abstraction of the physical organization of the storage medium used to store the files We have focused on the use of file-folder-directory-based systems (the "file system"). The Multics operating system developed in the 1960s can be considered to pioneer the use of files, folders and directories to manage the units of data that can be stored at the operating system level. Specifically, Multix has used symbol addresses within the hierarchy of files (thus introducing the idea of a file path), and the physical address of the files was not transparent to the user (application and end user). These file systems were not interested in the file format of any individual file, and the relationships among the files were considered to be irrelevant at the operating system level (i.e. not the location of the files in the hierarchy). After the emergence of Multics, storable data was organized into files, folders and directories at the operating system level. These files contain the file hierarchy itself (the "directory") inserted into special files, which are typically maintained by the file system. This directory also maintains a list of entries corresponding to all other files in the directory, and the node location of these files in the hierarchy (referred to herein as folders). This was the state of this technology for about 40 years.

However, although the file system provides a rational representation of the information residing in the physical storage system of the computer, it is nevertheless an abstraction of the physical storage system, and thus the use of the files is a function of the user manipulating (the relationship to the context, ) And the operating system (files, folders and directories). As a result, users (applications and / or end users) can only choose to make the units of information into a file system structure, even if doing so is inefficient, inconsistent or undesirable. Moreover, existing file systems have little knowledge of the structure of the data stored in individual files, so that much of the information remains trapped in files that can only be accessed (and understood) by the applications that created them. As a result, an outline description of this information and a lack of information management mechanisms result in the creation of data stores with little data sharing between the individual repositories. For example, many PC users may have access to more than five different repositories, such as Outlook contacts, online account addresses, Windows address books, Quicken Payees, etc., that contain information about the people they interact with at a given level, And an instant messaging (IM) buddy list, because the organization of files presents a serious problem for PC users. Most existing file systems use a nested folder metaphor to organize files and folders, so the effort required to maintain a flexible and efficient organization scheme as the number of files grows greatly. In this situation, it would be very useful to have different classifications for a single file, but using hard or soft links in existing file systems is cumbersome and difficult to manage.

Several unsuccessful attempts have been made in the past to address the shortcomings of the file system. Some of these previous attempts include the use of a 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 to be unsuccessful, as large-scale use in devices such as physical storage media has proved to be unsuccessful, while content addressable memory has proven useful for small-scale use by devices such as cache and memory management units Because it is not yet possible, and therefore there is no such solution. Other attempts have been made with an object-oriented database (OODB) system, but these attempts feature strong database characteristics and good non-file representations, but were not effective at handling file representations, And the speed, efficiency, and simplicity of the folder-based hierarchy. 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 exploit relationships existing between various data files Thus proving that overall system efficiency can not be accommodated. Another attempt to use BeOS (and other such operating system studies) is not appropriate for the processing of non-file representations, although it may adequately represent the file while providing some required database functionality Disadvantages) have been proven.

Database technology is another area of technology where similar problems exist. For example, the relational database model has achieved great commercial success, but indeed individual software vendors (ISVs) generally use a small portion of the functionality available in relational database software products (e.g., 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 (for example, a platform or database is agnostic), but one important reason that is often not noticed is that the database does not necessarily provide the exact abstraction that a major business application vendor actually needs. For example, the real world has the concept of "items" (such as "customer" or "order") (with the inserted "line item" of the order as its items and its items) . As a result, an application may want to have aspects of consistency, locking, security, and / or triggers at the item level (in some cases, for example), but the database typically provides this functionality only at the table / row level. This may work well if each item is mapped to a single row in a given table in the database, but for orders with multiple line items there may be reasons why the item is actually mapped to multiple tables, , A simple relational database system does not provide any correct abstraction at all. As a result, the application must build logic on top of the database to provide this basic abstraction. That is, the underlying relational model does not provide a sufficient platform for data storage where higher-level applications can be easily developed because the underlying relational model requires an indirect level between the application and the storage system, The semantic structure of the data is visible only to the application in the given instance). While some database vendors are building higher-level functionality within their products (eg, providing object-relational capabilities, new organizational models, etc.), none have yet provided the kind of comprehensive solution they need, In solution is a solution that provides both useful data model abstractions (e.g., "items", "extensions", "relationships", etc.) and useful domain abstractions (eg, "person", "location", "event"

In view of the aforementioned deficiencies of existing data storage and database technology, there is a new storage platform that provides enhanced capabilities to organize, search, and share all types of data in a computer system, Beyond that, there is a need for a storage platform that is designed to expand and extend the data platform and be a repository for all types of data. The present invention disclosed in U.S. Patent Application No. 10 / 646,646 (Attorney Docket No. MSTF-2734) entitled " Storage Platform for Data Structuring, Search and Sharing ", filed on August 21, 2003, meets this need. U.S. Patent Application Serial No. 10 / 646,646 entitled " System and Method for Providing Relationships and Hierarchical Synchronization Services to Information Manegable Units by a Hardware / Software Interface System " filed on October 24, 2003 No. MSFT-2745), filed June 30, 2004, entitled " System and Method for Providing Conflicting Processing for Peer-to-Peer Synchronization to Information Capable Units by a Hardware / Software Interface System " Synchronization services for this storage platform (conflict resolution method) are also provided in the present invention, which is disclosed by the US patent application titled (number not yet available) (Attorney Docket MSFT-2854 / 306955.01).

Of course, with the initial use of the new storage platform disclosed in this related patent application, an enterprise with a synchronization network comprising various individual computer systems continues to use legacy storage platforms while other individual computer systems continue to use legacy storage platforms, Will be mixed with using a new storage platform. Thus, for two computer systems using a new storage platform (" client "), it may be necessary to synchronize through a computer system using a legacy storage platform (" intermediary "). For example, some clients may be registered with a legacy roaming service using software such as Folder Redirection with a roaming user profile (RUP) or client side caching (CSC). Because legacy roaming software for these legacy storage platforms does not support roaming data for new storage platforms, new roaming services for new storage platforms are needed. Various embodiments of the present invention are directed to a system and method for client synchronization via an intermediary.

SUMMARY OF THE INVENTION [

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 be exhaustive or to define the scope of the invention, which is intended to cover all of the significant aspects of the invention. Rather, this summary is intended to serve as an introduction to the following detailed description and drawings.

The invention as a matter of course relates, in general, to a storage platform for organizing, searching for 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 .

The storage platform of the present invention includes a data store implemented on a database engine. The database engine includes relational database engines with object relationship extensions. The data store implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data. Certain types of data are described in the schema, and the platform provides a mechanism to extend the schema set to define new types of data (essentially subtypes of the base types provided by the schema). The synchronization capability facilitates sharing of data between users or systems. A file system-like capability is provided that allows interoperation of such conventional file systems and data stores 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 the application to access all of the aforementioned capabilities of the storage platform and access the data described in the schema.

The data model implemented by the data repository defines 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 contains one or more fields (also referred to herein as attributes). A relationship is a link between two items. (These and other specific terms as used herein may be capitalized to separate them from other terms that are used in close proximity, but it is also possible to use capitalized terms such as " Item " item ", and no differences should be assumed or implied.)

The computer system also includes a plurality of items, each item comprising a separately storable information unit that can be manipulated by a hardware / software interface system; An item folder 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 more than one items folder.

Some of the property values of an item or item may be computed dynamically, as opposed to being derived from a persistent store. That is, the hardware / software interface system does not require the item to be stored, and does not require the ability to enumerate a set of current items, or the ability to retrieve an item when given its identifier for the storage platform Or an API), for example, the item may be the current location of the cell phone or the temperature read to the temperature sensor. A hardware / software interface system may further manipulate a plurality of items and may further include items interconnected by a plurality of relationships managed by a 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 understands and can directly process in a predictable manner. To manipulate multiple items, the computer system interconnects the items with multiple relationships and manages the relationships at the hardware / software interface system level.

The storage platform API provides data classes for each item, item extension, and relationship defined in the storage platform schema set. The API also provides a set of framework classes that define a set of common behaviors for data classes and provide a base programming model for the storage platform API along 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 the query language details of the underlying database engine . The storage platform API also gathers changes to items made by the application program and then organizes them into the correct 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 allows the complexity of datastore updates to be passed to the API.

The storage platform of the present invention enables the development of more efficient applications to consumers, knowledge workers and corporations through its common storage foundation and schemaized data. It provides a rich and extensible API for accepting and extending existing file system and database access methods, as well as making it possible to take advantage of the capabilities inherent in its data model.

As part of the prioritized structure of these interrelated inventions (described in detail in Section II of the Detailed Description), certain related inventions relate specifically to the Synchronization API (detailed in Section III of the Detailed Description) . It is anticipated that some embodiments of the present invention may be integrated with this synchronization capability to handle conflicts that occur during peer-to-peer synchronization. The ability to correctly handle collisions efficiently minimizes data loss while retaining good usability and reduces the need for user intervention during synchronization. Because of this, Section III of the Detailed Description also discloses various implementations of the related invention relating to a system and method for handling conflicts within a peer-to-peer synchronization system including, but not limited to, the synchronization system or storage platform of the related invention. Includes a detailed description of the example.

In view of the foregoing, various embodiments of the present invention may be implemented using a common storage platform (e.g., a new storage platform of the related invention) (e.g., a legacy storage that itself does not support synchronization for a new storage platform And more particularly to systems and methods for synchronization of both clients synchronizing through an intermediary that does not use the same common storage platform. In summary, various embodiments of the present invention employ a method in which data is synchronized using existing capabilities of the intermediary, but the data structure of the client is preserved. Various embodiments utilize an " adapter " to enable a client to interact with an intermediary, where the adapter effectively compensates for intermediary capabilities to preserve data structure elements unique to the client's new storage platform. Various embodiments of the present invention relate to one or both of upload-synchronous data from the client to the intermediary, as well as download-synchronous data from the intermediary to the client. A particular embodiment also relates to the compression of data on the intermediary.

Certain features and advantages of the present invention, along with the related 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 present invention, various embodiments of the present invention are shown in the drawings, but the present invention is not limited to the specific methods and means 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: a hardware component, a hardware / software interface system component, and an application program component.

2A illustrates a conventional tree-based hierarchy for files grouped into folders in a directory in a file-based operating system;

3 is a block diagram illustrating a storage platform;

4 is a diagram showing the structure relationships between items, item folders and categories;

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

Figure 5B is a block diagram illustrating a composite attribute type of the item of Figure 5A;

Figure 5C is a block diagram illustrating a " location " item where the complex types are further described (explicitly listed).

6A shows an item as a subtype of the item found in the base schema; Fig.

6B is a block diagram illustrating the subtype items of FIG. 6A in which the inheritance types are explicitly listed (in addition to the direct attribute); FIG.

Figure 7 is a block diagram illustrating two base-level class types, namely a base schema containing 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;

Figure 9 is a block diagram illustrating an item folder, its membership items, and the interconnections between item folders and their membership items;

10 is a block diagram illustrating a category (again, the item itself), its membership items, and the interconnections between categories and their membership items.

11 shows a reference type hierarchy of a data model of a storage platform;

Figure 12 is a diagram illustrating how relationships are classified.

13 shows a notification mechanism;

14 shows an example in which two transactions insert a new record in the same B-tree;

15 shows a data change detection process;

16 shows an exemplary directory tree;

Figure 17 illustrates an example of an existing folder in a directory-based file system moving into a storage platform data store;

18 is a diagram showing the concept of an inclusion folder;

19 shows a basic structure of a storage platform API;

20 schematically depicts various components of a storage platform API stack;

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

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

22 shows a runtime framework of a storage platform API;

23 shows the execution of the " FindAll "operation;

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

25 is a diagram showing a schema on which a file API is based;

26 shows an access mask format used for data security;

Fig. 27 (a, b and c) shows that a new protected area that is equally protected is separated from the existing secured area.

28 is a diagram showing the concept of an item search view;

29 illustrates an exemplary item hierarchy;

30A shows interface Interface 1 as a conduit in which first and second code segments communicate;

30B is an illustration showing that the interface includes interface objects I1 and I2 that enable the first and second code segments of the system to communicate through the medium M;

31A shows how a function provided by an interface Interface1 is subdivided into a plurality of interfaces Interface 1A, Interface1B, and Interface1C to convert the communication of the interface.

31B is a diagram showing how the functions provided by the interface I1 are subdivided into a plurality of interfaces I1a, I1b and I1c.

32A is a diagram illustrating a scenario in which meaningless parameter precision can be ignored or replaced with arbitrary parameters;

32B is a diagram illustrating a scenario in which an interface is replaced by an alternate interface that is defined to ignore or add parameters to the interface;

Figure 33A illustrates a scenario in which the first and second code segments are merged into a module that includes both of them.

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

34A is a diagram illustrating how one or more portions of middleware can transform communications on a first interface to adapt to one or more different interfaces.

34B is a diagram illustrating how a code segment receives communications from one interface but can be introduced with an interface to transmit functionality to the second and third interfaces.

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

35B illustrates that a JIT method that dynamically rewrites one or more interfaces can be applied to dynamically factorize or change the interface.

36 illustrates three instances of a common data store and the components that synchronize them;

Figure 37 illustrates an embodiment of the invention that assumes a simple adapter that does not know how the state is computed or the metadata associated with it is exchanged;

Figures 38A-D show how changes are tracked, enumerated, and synchronized using a sequential change enumeration method to highlight exceptions and solutions for changes.

39A illustrates a conflict processing pipeline.

Figure 39B is a flow chart illustrating the logical traversal of the pipeline shown in Figure 39A;

40 is a block diagram showing an example in which an item of conflict is logged as a copy of a target item;

41 is a block diagram illustrating a scenario in which two clients must synchronize through an intermediary;

42 is a flowchart showing a step ("transmission synchronization" operation) in which a client transmits change data to an intermediary via an STI adapter;

43 is a flowchart showing a step ("reception synchronization" operation) in which a client receives change data from an intermediary via an STI adapter;

44 is a flow chart showing a step ("compression" operation) in which an STI adapter (that is, an STI adapter associated with a client capable of both transmit and receive motions) performs a compression operation on data in a community folder on the intermediary.

I. Introduction

The contents of the present invention are specifically described to satisfy legal requirements. However, the description itself is not intended to limit the scope of the invention. Rather, the inventor has contemplated that the claimed subject matter may alternatively be implemented in other ways to include other steps, or a combination of similar steps, than those described herein with other present or future techniques. Furthermore, although the term " step " may be used herein to mean different elements of the methods of use, it will be understood that the term &quot; It should not be interpreted to mean order.

A. Exemplary Computing Environment

Various embodiments of the invention may be practiced on a computer. 1 and the following description are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, various aspects of the invention may be described in general in connection with 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 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.

1, an exemplary general purpose computing system includes a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21 And the like, and the like. The system bus 23 may be one of several types of bus architectures, including a memory bus or local bus using a memory controller, a peripheral bus, and various bus architectures. The system memory includes a ROM 24 and a RAM 25. The BIOS 26, which contains the basic routines that help to transfer information between elements within the personal computer 20, for example, during start-up, is stored in the ROM 24. 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 an optical disk drive 30 for reading and writing to a removable optical disk 31 such as a CD-ROM or other optical media. The hard disk drive 27, the magnetic disk drive 28 and the optical disk drive 30 are connected to the system bus (not shown) by a hard disk drive interface 32, a magnetic disk drive interface 33 and an optical disk drive interface 34, respectively. 23. The drives and their associated computer readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for the personal computer 20. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 21, it is also possible to use a computer such as a magnetic cassette, flash memory card, DVD, Bernoulli cartridge, RAM, It should be understood by those skilled in the art that other types of computer readable media that can store data that can be accessed by a computer system may also be used in an exemplary computing environment. Likewise, the exemplary environment may include many types of monitoring devices, such as thermal sensors and security or fire alarm systems, and other information sources.

A plurality of program modules including an operating system 35, one or more application programs 36, other program modules 37 and program data 38 may be stored on a hard disk, magnetic disk 29, optical disk 31, ROM (24) or RAM (25). A user may enter commands and information into the personal computer 20 via input devices such as a keyboard 40 and a 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 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 the same interface as the video adapter 48. In addition to the monitor 47, the personal computer typically includes other peripheral output devices (not shown) such as speakers and a printer. The exemplary system of FIG. 1 also includes an external storage device 62 connected to the host adapter 55, the SCSI bus 56, and the SCSI bus 56.

The personal computer 20 may operate in a network environment using logical connections to one or more remote computers, such as a remote computer 49. [ The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, although only the memory storage device 50 is shown in FIG. 1, Includes most or all of the elements described above in connection with the present invention. The logical connections depicted in FIG. 1 include a LAN 51 and a WAN 52. These networking environments are commonplace in offices, enterprise 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. The personal computer 20 typically includes a modem or other means for establishing communications over the WAN 52, such as the Internet, when used in a WAN networking environment. A modem 54, which may be internal or external, is connected to the system bus 23 via a serial port interface 46. In a networked environment, program modules or portions thereof described in connection with the 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 communication link between the computers may be used.

As shown in the block diagram of Figure 2, the computer system 200 comprises three groups of components: a hardware component 202, a hardware / software interface system component 204, and an application program component 206 Quot; user component " or " software component " in some circumstances).

1, hardware component 202 includes a CPU 21, memory (ROM 24 and RAM 25), BIOS 26, and, in particular, Output (I / O) devices such as a keyboard 40, a mouse 42, a monitor 47 and / or a printer (not shown). The hardware component 202 includes a basic physical infrastructure for the computer system 200.

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 to solve problems, provide solutions, and use computer resources to process data for various users (machines, other computer systems and / or end users).

The hardware / software interface system component 204 includes, in most cases, an operating system (OS) that itself includes a shell and a kernel (and, in some embodiments, only 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 may also be implemented on behalf of a virtual machine manager (VMM), a common language runtime (CLR) or a functional equivalent thereof, a Java virtual machine (JVM) or a functional equivalent thereof, As well as other such software components. The purpose of a 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 make the computer system usable as well as to use the computer hardware in an efficient manner.

A hardware / software interface system is typically loaded on a computer system at startup and then manages all application systems in the computer system. The application program interacts with the hardware / software interface system by requesting the service through the API. Some application programs enable an end user to interact with a hardware / software interface system via a user interface, such as a command language or a GUI.

A hardware / software interface system typically performs various services for an application. In a multitasking hardware / software interface system in which multiple programs can be executed simultaneously, the hardware / software interface system determines how many applications must be executed in what order, and how many for each application before switching to another application for the alternate To 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 the respective application (and, in some cases, the end user) regarding the status of the operation and any errors that may have occurred. The hardware / software interface system may also offload the management of the batch job (e.g., print) so that the start application is free from this job to resume other processes and / or operations. On a computer that can provide parallel processing, the hardware / software interface system also manages the partitioning of the program so that the program runs concurrently on two or more processors.

The hardware / software interface system shell (here simply referred to as " shell ") is an interactive end user interface for a hardware / software interface system. (The shell may also be referred to as a " command interpreter ", or an " operating system shell " in an 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. Shell and month, the kernel is the inner layer of the hardware / software interface system that interacts directly with the hardware components.

While various embodiments of the present invention are believed to be particularly suitable for computerized systems, nothing is contemplated herein to limit the invention to such embodiments. Alternatively, the term " computer system " as used herein is intended to encompass all types of computer systems, including, but not limited to, devices capable of storing and processing information, Is intended to encompass any device and any device capable of controlling its performance.

B. Normal file-based storage

In most modern computer systems today, a " file " is a unit of storable information that can include an application program, a data set, as well as a hardware / software interface system. In all modern hardware / software interface systems (Windows, Unix, Linux, MacOS, virtual machine systems, etc.), files are the basic individual of information (e.g., data, programs, etc.) (Storeable and searchable) units. File groups are typically organized into 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. These folders are also organized in a tree-based hierarchy called a directory (to be described later). In some other hardware / software interface systems, such as DOS, z / OS and most Unix-based operating systems, the terms "directory" and / or "folder" are used interchangeably, (E.g., Apple IIe) used the term " catalog " instead of a directory, but as used herein, all of these terms are considered synonymous and interchangeable and include hierarchical information storage structures and their folders and files It is intended to include all other equivalent terms and references to components.

Typically, a directory (a directory of folders) is a tree-based hierarchical structure in which files are grouped within a folder, and also folders are arranged according to the relative node location including the directory tree. For example, as shown in Figure 2A, a 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 Quot; subfolder ") 216, each of which may also include an additional folder 218 (which may be infinitely repeated). Each of these folders may have more than one file 220, although individual files within the folder at the hardware / software interface system level may have no commonality beyond their location in the tree hierarchy. Not surprisingly, this approach of organizing files within a folder hierarchy indirectly reflects the physical organization of common storage media (e.g., 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, i.e. each folder owns its subfolders and files. For example, when a folder is deleted by a hardware / software interface system, the subfolders and files of that folder are also deleted (in the case of each subfolder, it further includes its own subfolders and files). Likewise, each file is typically owned by only one folder, the files can be copied, and the replicas can be located in different folders, but the replicas themselves of the files are different without having a direct connection with the original (For example, changes to the original file are not reflected in the replica file at the hardware / software interface system level). In accordance with this relationship, files and folders are by nature " physical " because folders are treated like physical containers, and 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 related inventions reflected by reference as initially described herein. The storage platform of the present invention is designed to be a repository for all data types, including new data types, such as items, extending and extending the data platform beyond the types of existing file systems and database systems described above.

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 a hardware / software interface system, and is commonly supported across all objects exposed to the end user by a hardware / software interface system shell, unlike a simple file. Object with a set of default attributes. Items also have attributes and relationships that are commonly supported across all item types, including features that allow new attributes and relationships to be introduced (discussed below).

An " operating system (OS) " is a special program that acts as an intermediary between an application program and computer hardware. The OS includes the shell and kernel in most cases.

A " hardware / software interface system " is software or a combination of hardware and software that serves as an interface between the underlying hardware components of the computer system and the applications running on the computer system. A hardware / software interface system generally includes an operating system (and, in some embodiments, is comprised solely of an operating system). The hardware / software interface system may also be implemented on behalf of a virtual machine manager (VMM), a common language runtime (CLR) or a functional equivalent thereof, a Java virtual machine (JVM) or a functional equivalent thereof, Component. The purpose of a 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 make the computer system usable as well as to use the computer hardware in an efficient manner.

B. Overview of Storage Platform

Referring to FIG. 3, the storage platform 300 includes a data store 302 implemented on a database engine 314. In one embodiment, the database engine includes a relational database engine with object relationship 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. A particular type of data is described in a schema, such as schema 340, and storage platform 300 provides tools 346 for extending this schema, as well as deploying such 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. The data store 302 also provides security capabilities 308 and promotion / demotion capabilities 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 application programs (e.g., application programs 350a, 350b, 350c) that utilize other storage platform components and storage platforms do. The storage platform of the present invention further includes an API 322 that enables an application program, such as application programs 350a, 350b, 350c, to access all of the capabilities of the storage platform described above and to access the data described in the schema . The storage platform API 322 may be used by an application program with other APIs such as the OLE DB API 324 and the Microsoft Windows Win32 API 326. [

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

In at least some embodiments, the storage platform is implemented within, or forms an integral part of, a hardware / software interface system of a computer system. For example and without limitation, the storage platform of the present invention may be implemented within an operating system, virtual machine manager (VMM), CLR or functional equivalent thereof, or JVM or functional equivalent thereof, or may form an integral part 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 schemaized data. The storage platform provides a rich and extensible programming surface area that accommodates and extends the existing file system and database access methods as well as making available the capabilities inherent in its data model.

In the following description, and in various figures, the storage platform 300 of the present invention may be referred to as " WinFS ". However, the use of a designation to refer to such a storage platform is merely for convenience of description, 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 repository. 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 item and item extensions, establishing relationships to items, and organizing items within item folders and categories, as described below.

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

A relationship can be declared between sets of two types of instances and represents a mapping between them. For example, a relationship between a person type and a location type called LivesAt, which defines where a person lives, can be declared. The relationship has a name, two endpoints, a source endpoint and a target endpoint. The relationship may also have a set of ordered properties. Both the source and target endpoints have a name and a type. For example, the LivesAt relationship has a target called residence of the source and location type called resident of the person type, and also has a StartDate and EndDate attribute indicating the residence time in the residence. Since people can live in multiple settlements over time, and settlements can have multiple residents, the place to put the most StartDate and EndDate information is the relationship itself.

A relationship defines a mapping between instances restricted by a given type as an endpoint type. For example, the LivesAt relationship can not be that the car is a resident, 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 relation, is defined in such a way that if there is a case in which all instances of B are also instances of A if type A is a BaseType for type B. Another way to express this is that all instances of B must follow A as well. For example, if A has a string type attribute Name and B has an attribute Age of type Int16, then any instance of B must have both Name and Age. The type hierarchy can be thought of as a tree with a single supertype at the root. Branches from the root provide first level subtypes, branches of this level providing second level subtypes, etc., which continue to terminal subtypes that themselves do not have any subtypes. The tree is not limited to having a uniform depth, but it can not include any circulation. A given type may have zero or many subtypes and zero or one supertype. A given instance can have at most one type and a supertype of this type. As an alternative, for any given instance of a level in the tree, this instance may follow at most one subtype at that level. A type is said to be abstract if instances of that type must also be instances of a subtype of that type.

1. Item

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

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

An item represents an easily understandable unit of the real world of data such as contacts, people, services, locations, documents (all various types), 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 the item is "Core.Location" which indicates that the structure of this item is defined as an item of a specific type in the core schema. (Core schema will be described later.)

The location entry has a number of attributes including EAddress, MetropolitanRegion, Neighborhood, and PostalAddress. The specific type of attribute for each is displayed immediately after the attribute name, separated from the attribute name by a colon (":"). To the right of the type name, the number of values allowed for that attribute type is displayed between square brackets ("[]"), where an asterisk ("*") on the right side of the colon indicates an unspecified and / ). A " 1 " on the right side of the colon indicates that there can be at most one value. A zero ("0") on the left of the colon indicates that the attribute is optional (no value may be present). A "1" on the left of the colon indicates that at least one value should be present (an attribute is required). Neighborhood and MetropolitanRegion are both "nvarchar" (or equivalent) types that are either predefined data types or "simple types" (and are shown here without capitalization). However, EAddress and PostalAddress are attributes of a defined type of EAddress and PostalAddress type, respectively, or of a " complex type " (indicated by capitalization). 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 "nested element", which is nested within the item directly to define its properties, and information about the complex type is combined with the item with these attributes (Within the boundary of the item as described later). The concept of such typing is well known and readily understood by those skilled in the art.

FIG. 5B is a block diagram showing composite attribute types PostalAddress and EAddress. The PostalAddress attribute type may be expected to have a City value of the PostalAddress attribute type of 0 or 1, a CountryCode value of 0 or 1, a MailStop value of 0 or 1, and a PostalAddressType of any number (0 to many). In this way, the shape of the data for a particular attribute in the item is defined accordingly. The EAddress attribute type is defined similarly as shown. Although alternatively used herein, another way to represent a complex type in a location item is to draw the item with the individual properties of each complex type listed therein. Figure 5C is a block diagram illustrating a location item where composite types are further described. It should be understood, however, that this alternative representation of the location item of Figure 5C is for exactly the same item as that shown in Figure 5A. The storage platform of the present invention also allows subtyping, whereby one attribute type can be a subtype of another attribute type (one attribute type inherits properties of other parent attribute types).

Similar to attributes and their attribute types, but differently, items uniquely represent their own item types, which may be subjects of subtyping. That is, the storage platform in various embodiments of the 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 invention, all items are subtypes of the " Item " item type, which is the primary and base item type found in the base schema. (The default schema is also discussed below). 6A shows an item that is a subtype of the Item item type found in the base schema, and a position item in the instance. In this figure, an arrow indicates that the position item is a subtype of the Item item type (as with all other items). The Item item type, which is the default item from which all other items are derived, has a number of important attributes, such as ItemId and various time stamps, thereby defining the standard attributes of all items in the operating system. In this figure, the attributes of this Item item type are inherited by the position, thereby becoming the attribute of the position.

Another way to represent the attributes of a position item that is inherited from an Item type is to draw the position with the individual attributes of each attribute type from the parent items listed in it. FIG. 6B is a block diagram showing a location item in which inherited types are described in addition to the direct attribute. In this figure, the position is shown with both its attributes, i.e., the direct attributes shown both in this figure and in Figure 5A, and in this figure, but not in Figure 5A (whereas in Figure 5A, (These attributes are referred to by indicating with arrows that they are subtypes), but it should be understood that this location item is the same item as shown in Figure 5A.

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

The "boundary" of an item is represented by its attributes (including complex attribute types, extensions, etc.). The boundaries of an item also represent the limitations of the action performed on the item, such as copy, delete, move, create, and so on. For example, in various embodiments of the present invention, when an item is copied, everything within the bounds of the item is also copied. For each item, the boundary includes:

- the item type of the item, and any applicable subtype information (such as in the case of various embodiments of the invention in which all items are derived from a single item and an item type in the base schema) Information about the parent item type). If the original item being copied is a subtype of another item, the replicator 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 attributes of the complex type (primitive or extended), the replicators may also have the same complex type.

- A list of the item's "ownership", that is, a list of items that indicate which other items (owned items) own this item (owned item). This is particularly relevant to item folders as described below, and the rule indicates that all items below should belong to at least one item folder. Moreover, with respect to an insertion item to be described later, an insertion item is regarded as a part of an item in which the insertion item is inserted for an operation such as copying, deletion, and the like.

2. Item Identification

The item is uniquely identified in the global item space by the ItemID. The 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 locating 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 parses the ItemReference and returns an item. This method is ignored by the concrete subtypes of ItemReference that implement the function to retrieve an item when a reference is given. 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 (i.e., identifies) the item domain. This is handled by a locator parsing method that can parse the value of the Locator for the item domain. The ItemID field is of type ItemID.

ItemPathReference is a special type of ItemReference that defines the Locator and Path fields. The Locator field identifies the item domain. This is handled by a locator parsing method that can parse the value of the Locator for the item domain. The Path field contains the (relative) path in the storage platform namespace rooted in the item domain provided by the Locator.

This type of reference can not be used in a set operation. References should generally be analyzed through the path analysis process. The Resolve method of the storage platform API 322 provides this functionality.

The above-mentioned reference form is represented by the reference type hierarchy shown in Fig. Additional reference types inherited from these types can be defined in the schema. They can be used as the type of the target field in the relationship declaration.

3. Item folders and categories

As will be described below, item groups are organized within special items called item folders (not 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, the modified item can be accessed directly from the other items folder. Essentially, access to an item can be made 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, and therefore deletion of item folders does not necessarily result in deletion of items. Nevertheless, in various embodiments of the invention, the item must belong to at least one item folder, so if the only item folder for a particular item is deleted, then in some embodiments the item may be deleted automatically, Is automatically a member of a default item folder (e.g., a " Trash Can " item folder conceptually similar to similar name folders used in various file-folder based systems).

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

A category is conceptually different from an item folder, which means that item folders may include items that are not related to each other (i.e., have no common technical characteristics), while each item in a category may have a common type, attribute, or value (Commonality), and it is this commonality that forms the basis for other items in a category, and the relationships between them. Moreover, while members of items within a particular folder are not necessarily forcibly based on any particular aspect of the item, all items with a commonality that is absolutely related to the category in some embodiments are automatically assigned to that category at the hardware / software interface system level Of the United States. Conceptually, a category may also be regarded as a virtual item folder with members based on the results of a particular query (e.g., in relation to the database), and thus the conditions of this query (defined by the commonality of the categories) Items that satisfy include members of the category.

Figure 4 shows the structure relationships between items, item folders and categories. The plurality of items 402, 404, 406, 408, 410, 412, 414, 416, 418, 420 are members of the various item folders 422, 424, 426, 428, 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, such as items 414, 416, 418, (However, this is rarely possible in certain embodiments in which the possession of any attribute automatically implies a member in a category, and therefore an item must not be fully characterized in order not to become a member of any category ). Unlike the hierarchical structure of folders, both categories and item folders have a structure that is more similar to the orientation graph as shown. In any event, items, item folders, and categories are all items (item types are different).

Unlike files, folders and directories, the 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 can exist in more than one location. The ability of items to reside in more than one item folder location and be organized within a category can be enhanced at the hardware / software interface system level and provides rich data manipulation and storage structure capabilities beyond what is currently available in this field.

4. Schema

a) Default schema

In order to provide a universal basis for the creation and use of an item, various embodiments of the storage platform of the present invention include a base schema that establishes a conceptual framework for creating and organizing items and attributes. The base schema defines the small specific types of items and attributes, and the characteristics of these special basic types from which more subtypes can be derived. The use of this base schema allows the programmer to conceptually distinguish between items (and their respective types) and attributes (and their respective types). Furthermore, the base schema describes a basic set of attributes that all items can possess when all items (and corresponding item types) are derived from the base items in the base schema (and corresponding item types).

As shown in FIG. 7 and in conjunction with 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. Alternatively, the top level attribute type " PropertyBase " does not have a predefined attribute, only all the other attribute types are derived, and all derived attribute types are mutually related (derived jointly from a single attribute type) . An extension type attribute defines an identifier that can distinguish one extension from another extension when an item can have multiple extensions, as well as which item the extension extends.

The ItemFolder is a subtype of the Item item type that characterizes the relationship to establish a link to its members (if any) in addition to the attributes inherited from the item, and 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. FIG. 8A is a block diagram showing an item in the core schema, and FIG. 8B is a block diagram showing an attribute type in the core schema. Differences between files with different extensions (* .com, * .exe, * .bat, * .sys, etc.) and files with different criteria in a file-folder based system are similar to those of core schema. In an item-based hardware / software interface system, the core schema can be directly understood (by item type) or indirectly (by item subtype) and can be handled in a predictable manner Defines a set of core item types that characterize all items with one or more core schema item types. The predefined item types reflect the most common items in the item-based hardware / software interface system, and thus some level of efficiency is achieved by the item-based hardware / software interface system that understands predefined item types that include the core schema .

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

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

Categories: The items of this item type (and subtype derived therefrom) represent the valid categories in the item based hardware / software interface system.

- Commodities: Items that can identify values

- Devices: Items with a logic structure that supports information processing capabilities.

Documents: Items with content that is not interpreted by the item-based hardware / software interface system but instead is interpreted by the application program corresponding to the document type

- Events: Items that record a predetermined occurrence in the environment

- Locations: Items representing physical locations (e.g., geographical locations)

- Messages: Communication items between two or more principles (defined below)

Principals: Items with at least one identifier (eg, an identifier of a person, organization, group, generation, author, service, etc.)

- Statements: Items with special information on the environment, including without limitation, policies, subscriptions, qualifications, etc.

Likewise, and referring to FIG. 8B, certain attribute types supported by the core schema may include one or more of the following.

Certificates (derived from the default PropertyBase type in the base schema)

- Principal Identity Keys (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 types in default schema)

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

- IdentitySecurityPackage (derived from relationship type in default schema)

- RoleOccupancy (derived from relationship type in default schema)

- BasicPresence (derived from relationship type in base schema)

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

5. Relationship

A relationship is a binary relationship where one item is specified as the source and the other as the target. The source item and the target item are related by a relationship. The source item generally controls the lifetime of the relationship. That is, when the source item is deleted, the relationship between the items is also deleted.

Relationships are classified into inclusion and reference relationships. The containment relationship controls the lifetime of the target item, while the reference relationship does not provide any lifetime management semantics. Figure 12 shows how relationships are classified.

Included relationship types are further classified into maintenance and insertion relationships. When all maintenance relationships to an item are removed, the item is deleted. The maintenance relationship controls the lifetime of the target through a reference counting mechanism. Insertion relationships enable modeling of compound items and can be regarded as exclusive maintenance relationships. An item can be a target of one or more maintenance relationships, but an item can be the target of only one insertion relationship. An item that is a target of an insertion relationship can not be a target of any other maintenance or insertion relationship.

The reference relationship does not control the lifetime of the target item. The reference relationship can be hovering, that is, the target item may not exist. A reference relationship can be used to model a reference to an item anywhere within the global item namespace (i.e., including a remote data store).

The withdrawal of an item does not automatically withdraw his relationship. The application must explicitly require the relationship of items. In addition, modification of the relationship does not modify the source or target item, and similarly, the addition of the relationship does not affect the source / target item.

a) Relationship Declaration

An explicit relationship type is defined with the following elements:

The relationship name is specified in the name attribute.

- The relationship type is one of the following: keep, insert, reference. This is specified in the type attribute.

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

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

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

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

The relationship instance is stored in the global relation table.

- All relationship instances are uniquely identified by a combination (source ItemID, relation ID). Relationship IDs are unique within the given source ItemID for all relationships with a source to a given item, regardless of their type.

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

The following is an example of a relationship declaration:

This is an example of a reference relationship. The relationship can not 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 organizational item is deleted, the relationship is not deleted but becomes suspended.

b) Holding Relationships

The maintenance relationship is used to model the reference count based lifecycle management of the target item.

An item may be a source endpoint of zero or more relationships to an item. An item that is not an inserted item may be the target 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 fulfills the lifetime 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 targeting the same item may be created. If the last maintenance relationship instance with the given item as the target endpoint is deleted, the target item is also deleted.

The type of endpoint item specified in the relationship declaration is generally enforced when an instance of the relationship is created. The type of endpoint item can not be changed after the relationship is established.

Maintenance relationships play an important role in the formation of the item name space. They contain a " Name " attribute defining the name of the target item for the source item. This relative name is unique for all maintenance relationships that are sourced from a given item. An ordered list of relative names from the root entry to the given entry forms the complete name for the entry.

The maintenance relationship forms a directional acyclic graph (DAG). When a maintenance relationship is created, the system ensures that the item name space forms a DAG by ensuring that no cycles are 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 of the item that owns the target item through the maintenance relationship. Copy, move, backup, and other actions on an item that is the source of a maintenance relationship do not affect items that are targets of the same relationship. For example, a backup of a folder item may include all items in a folder (targets of a FolderMember relationship) Can not be backed up automatically.

The following are examples of maintenance relationships.

FolderMember relationships enable the concept of folders as a collection of common items.

c) Embedding Relationships

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

The creation of an insert relationship instance and the item it targets is minimal. 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 the target of the insertion relationship can not be the target of the maintenance relationship.

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

The type of endpoint item specified in the relationship declaration is generally enforced when an instance of the relationship is created. The type of endpoint item can not be changed after the relationship is established.

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

The following is an example of a declaration.

d) Reference Relationships

The reference relationship does not control the lifetime of the item it refers to. Even the 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 in a suspended state. A reference relationship can also refer to an item in another data store. A reference relationship can be considered a concept similar to a link within a web page.

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 may be of any item type.

A reference relationship is used to model most non-life management relationships between items. Since the presence of the target is not enforced, the reference relationship is convenient for modeling a loosely coupled relationship. The reference relationship 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 (one insertion relationship) or (one or more maintenance relationships). One exception is the root entry. An item can be a target of zero or more reference relationships.

- An item that is the target of the insertion relationship can not be the source of the maintenance relationship. This may be the source of the reference relationship.

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

- An item promoted from a file can not be the target of an insertion relationship.

f) Ordering of Relationships

In at least one embodiment, the storage platform of the present invention supports ordering of relationships. Ordering is accomplished through an attribute named "Order" in the basic relationship definition. There is no uniqueness limitation on the sequence field. The order of relations 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 relation with a higher "order" field value.

An application can obtain a relationship in default order by ordering on a 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 (e.g., FolderMembers) of a given type are an ordered subset of the set of relationships for a given item.

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

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

- RelLast is the final relation within the ordered set with ordinal value OrdLast.

- RelX is the predetermined relationship in the set with ordinal value OrdX.

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

-RelNext is the closest relation to RelX in a set with ordinal value OrdNext greater than OrdX.

Actions include, but are not limited to:

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

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

- InsertAt (SourceItemID, ord, Relationship) inserts a relation with the specified value for the sequence attribute.

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

- InsertAfter (SourceItemID, ord, Relationship) inserts the relationship after the relationship with the given order value. The new relation can be assigned a sequence value between ord and OrdNext (these values are not included).

- MoveBefore (SourceItemID, ord, Relationship) moves the relation with the given relation ID to the relation with the specified order value. Relationships can be assigned new order values between OrdPrev and ord (these values are not included).

- MoveAfter (SourceItemID, ord, Relationship) moves the relation with the given relation ID back to the relation with the specified order value. Relationships can be assigned new order values between ord and OrdNext (these values are not included).

As described above, all items must be members of item folders. By relationship, all items must have a relationship with item folders. In various embodiments of the present invention, certain relationships are represented by relationships existing between items.

As implemented in various embodiments of the present invention, a relationship provides a directional binary relationship that extends to another item (target) by one item (source). The relationship is owned by the source item (the item that extended the relationship), so if the source is removed, the relationship is removed (e.g., the relationship is deleted when the source item is deleted). Furthermore, in some examples, the relationship may share (owning) the ownership of the target item, and this owning may be within the IsOwned attribute of the relationship (or its equivalent) (as shown in Figure 7 for the relationship attribute type) Can be reflected. In these embodiments, the creation of a new IsOwned relationship automatically increases the number of references to the target item, and the deletion of such a relationship can reduce the number of references to the target item. In this particular embodiment, the entries continue to exist if they have a reference number greater than zero, and are automatically deleted if the number of references becomes zero. Also, an item folder is an item that has (or may have) a set of relationships to other items, these other items including members of item folders. Implementations of other practical relationships are possible and are anticipated 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, as well as more than one category of items, and whether these items, folders and categories are public or private, refers to the meaning given to the presence (or absence) . These logical relationships are meanings assigned to a set of relations that are used specifically to achieve the functions described herein regardless of the physical implementation. A logical relationship is established between an item and its item folder (s) or categories (and vice versa), because it is essentially a special type of item folder and category, respectively. As a result, item folders and categories can be operated in the same manner as any other item, without limitation, such as being copied, added to an email message, inserted into a document, etc., and item folders and categories have the same mechanism And can be serialized and deserialized (fetched and fetched). (For example, in XML all items can have a serialization format, which applies equally to item folders, categories, and items.)

The above relationship, which represents the relationship between an item and its item folder, can be logically extended from item to item folder, from item folder to item, or both. A relationship that extends from an item to an item folder indicates that the item folder is open to the item and shares the item with its member information, but conversely, the lack of a logical relationship from item to item folder indicates that the item folder is private to the item , Indicating that the item and its member information are not shared. Similarly, a relationship logically extending from an item folder to an item indicates that the item is public and can be shared with the item folder, whereas a lack of logical relationship from item folder to item indicates that the item is private and can not be shared . 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 an item retrieves other shareable items in its item folder, &Quot; public " item folders that provide information about the &quot; public &quot;

Figure 9 is a block diagram illustrating the relationship between the item folder (which is also the item itself), its membership items, and the item folder and its membership items. Item folder 900 has a plurality of items 902, 904, and 906. The item folder 900 has a relationship 912 from itself to an item 902 that is open to the item folder 900 and its members 904 and 906, May be shared with any other item folders, categories, or items (not shown) that can access the content 900. However, there is no relationship to item folder 900 in item 902, which indicates that item folder 900 is private to item 902 and does not share its membership information with item 902. Item 904, on the other hand, has a relationship to item folder 900 itself, indicating that item folder 900 is public and that it shares its membership information with item 904. However, if item 904 is private and not shared with item folder, category or item (not shown) that is accessible to item folder 900, its other members 902, 906, and item folder 900 There is no relationship from the item folder 900 to the item 904 indicating that the item is not displayed. Unlike the relationship (or lack of relationship) to the items 902 and 904 in the item folder, the item folder 900 has a relationship 916 from itself to item 906, The relationship 906 is public and is accessible to the item folder 900, to its members 902, 904, and to the item folder 900 Category item or item (not shown), and item folder 900 is open and shares its membership information with item 906. In addition,

As described above, items in an item folder do not need to share a shareability, because the item folder is " not described ". On the other hand, a category is described by a commonality common to all of its membership items. As a result, the members of the category are uniquely limited to items with the commonality described, and in some embodiments all items that satisfy the description of the category are automatically members of the category. Thus, an item folder allows members of a common type to be represented by their members, while a category allows members based on a defined commonality.

Of course, the category description is in fact logical, so a category can be described by any logical representation of types, attributes and / or values. For example, the logical representation of a category may be one of its members, including items with one or both of the two attributes. If these attributes described for the category are "A" and "B", then the category member has items with attribute A but no B, items with attribute B with B, and attributes A and B &Lt; / RTI &gt; The logical representation of these properties is described by the logical operator " OR ", wherein the set of members described by category are items with the attribute AORB. Similar logical operators (including "AND", "XOR", and "NOT" alone or in combination, without limitation) may also be used to describe the category as those skilled in the art will understand.

Despite the differences between the item folders (not described) and the categories (described), the relationship of the categories to the items and the relationship of the items to the categories is essentially that of the item folders It has the same method as that disclosed in the above.

10 is a block diagram showing the category (item itself), its membership items, and the interconnections between categories and their membership items. The category 1000 has a number of items 1002, 1004 and 1006 as members, all of which share a certain combination of common attributes, values or types 1008 as described by the category 1000 do. The category 1000 itself has a relationship 1012 from the item 1002 to the item 1002 where the item 1002 is public and includes the category 1000, its members 1004 and 1006, and the category 1000 Item folders or items (not shown) that are accessible to the user. However, there is no relationship from item 1002 to category 1000, indicating that category 1000 is private to item 1002 and that it does not share its membership information with item 1002. Item 1004, on the other hand, has a relationship 1024 to category 1000 itself, indicating that category 1000 is public and that it shares its membership information with item 1004. However, if the item 1004 is private and has no category, item folder or item (not shown) that can access the category 1000, its other members 1002, 1006, and the category 1000 There is no relationship extending from category 1000 to item 1004 indicating that it can not be shared. Unlike the relationship (or lack thereof) with the items 1002 and 1004 of the category, the category 1000 itself has a relationship to the item 1006 and the item 1006 has a relationship to the category 1000 Which together indicate that the item 1006 is public and includes a category 1000, its item members 1002 and 1004, and any other category, item folder or item that can access the category 1000 And that the category 1000 is public and shares its membership information with the item 1006. In addition,

Finally, since the category and item folders themselves are items, in some other embodiments the items may have a relationship to each other, a category may have a relationship to an item folder, an item folder may have a relationship to a category And categories, item folders and items may have relationships to other categories, item folders, and items. However, in various embodiments, item folder structure and / or category structure is prohibited from including cycles at the hardware / software interface system level. Where item folders and category structures are similar to direction graphs, embodiments that inhibit cycling are similar to directional acyclic graphs (DAGs), which are directional graphs that do not start or end any path at the same vertex by the mathematical definition 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 new schemas 344 (i.e., new items and nested element types). This section deals with a mechanism for generating such schemas 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 set of nested element types are limited as follows.

- ISVs are allowed to introduce a new item type, ie subtype Base.Item.

- ISVs are allowed to introduce a new nested element type, subtype Base.NestedElement.

- ISVs are allowed to introduce a new extension, the subtype Base.NestedElement.

However, an ISV can not subtype any type (item, nested element, or extension type) defined by the initial set 340 of storage platform schemas.

The item type or nested element type defined in the initial set of storage platform schema may not exactly meet the needs of the ISV application, so it is necessary to allow the ISV to customize the type. This is allowed as a concept of expansion. An extension is a strongly typed extension, but (a) it can not exist independently, and (b) it must be attached to an item or a nested element.

In addition to addressing the need for schema extensibility, extensions also deal with the problem of "multi-typing". In some embodiments, the application may use the extension as a method for modeling a nested type instance (e.g., the document may be a legal document as well as a security document Document).

a) Item Expansion

To provide item extensibility, the data model also defines an abstract type named Base.Extension. This is the root type for the hierarchy of extended types. An application can subtype Base.Extension to create a specific extension type.

The Base.Extension type is defined in Base.Extension as follows.

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

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

- The extension type has fields.

The field may be a base or nested element type.

- Extended types can be subtyped.

Other restrictions apply to extension types.

- The extension can not be the source and target of the relationship.

- An extension type instance can not exist separately from an item.

- Extended types can not 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.

Extended instances are stored and accessed individually from items. 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 is associated with it. The storage platform API provides a programming model for storing, retrieving, and modifying extensions to items.

The extension type may be a subtype type using a storage platform single inheritance model. Derivation from an extension type creates a new extension type. The structure or behavior of the extension can not ignore or replace the structure or behavior of the item type hierarchy. Similar to an item type, an extension type instance can be accessed directly through a view associated with the extension type. The ItemID of the extension indicates to which item they belong, and can be used to retrieve the corresponding item object from the global item view. Expansion is considered part of the item for consistency of operation. The copy / move, backup / restore and other common operations defined by the storage platform can operate on extensions as part of the item.

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

The CRM application developer wants to attach the CRM application extension to the contacts stored on the storage platform. Application developers define CRM extensions that contain additional data structures that an application can manipulate.

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

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

In the above example, the fields and methods of the CRMExtension type can not ignore the fields or methods of the contact hierarchy. Note that an instance of type CRMExtension can be attached to an item type, not a contact.

When a contact is searched, its item extension is not automatically searched. 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 item they belong to. All item extensions share the same item ID. In the above example, 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 Element

Item Item Expansion Nested element Item ID And has its own item ID. Item IDs of items are shared. It does not have its own item ID. A nested element is part of an item. Save The item hierarchy is stored in its own table. The item expansion hierarchy is stored in its own table. Are stored together with the item. Query / Search You can query the item table. You can query the item expansion table. Generally it can only be queried within the context of the containing item. Query / search scope All instances of the item type can be retrieved. All instances of the item extension type can be retrieved. In general, you can only search within a nested element type instance of a single (contains) item. Relational semantics You can have a relationship to the items. No relation to item expansion. No relation to nested elements Relevance to item Maintenance, insertion, and soft relationships. It is generally only relevant through extensions. The extension semantics are similar to the inserted item semantics. Associated with the item through the field, the nested element is part of the item.

b) Expansion of nested elements

The nested element type does not extend to the same mechanism as the item type. The extension of the nested element is stored and accessed with the same mechanism as the field of the nested element type.

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

Nested element types are inherited from this type. The NestElement element type additionally defines a field that is a multi-set of elements.

Nested element extensions differ from item extensions in the following ways:

- Nested element extension is not an extension type. It does not belong to the extension type hierarchy rooted in the Base.Extension type.

- Nested element extensions are stored with the other fields of the entry, global access is not possible, and queries can not be constructed to retrieve all instances of a given extension type.

- These extensions are stored in the same way that other nested elements (of items) are stored. Like other nested sets, nested element extensions are stored in the UDT. They can be accessed via an extension field of the nested element type.

The aggregate interface used to access multi-attribute properties is also used for accessing and repeating the set of type extensions.

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

Expanding items Expanding nested elements

Item Expansion Expand nested elements Save The item extension hierarchy is stored in its own table. It is stored as a nested element. Query / Search You can query the item expansion table. Generally, it can only be queried within the context of the contained item. Query / search scope All instances of the item extension type can be retrieved. In general, you can only search within a nested element type instance of a single (contains) item. Programmability Special queries on special extension APIs and extension tables are required. The nested element extension is similar to any other nested element of the nested element, and the normal nested element type API is used. motion The behavior can be related. Behavior is not allowed (?) Relational semantics No relation to item expansion No relation to nested element expansion Item ID Item IDs of items are shared. It does not have its own item ID. Nested element extensions are part of the item.

D. Database Engine

As described above, the data store is implemented on the database engine. In the present 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 mapping to the relational store of the data model that implements the data store in accordance with the present embodiment and provides information about the logical API 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 a storage platform conceptual data model on a relational database engine, it may also be implemented on other types of databases, such as object-oriented and XML databases.

An object-oriented (OO) database system provides persistence and transactions for programming language objects (e.g., C ++, Java). The storage platform concept of the " item " is well mapped to an " object " in the object oriented system, although the inserted sets must be added to the object. Other storage platform type concepts such as inheritance and nested element types are also mapped to object oriented type systems. Object-oriented systems typically already support object identifiers, so an item identifier can be mapped to an object identifier. 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. In order 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, an XML database based on XSD (XML Schema Definition) supports a single inheritance based type system. The item type system of the present invention can be mapped to an XSD type model. XSD also does not provide support for behavior. The XSD for the item should be augmented against the item behavior. The XML database handles a single XSD document, lacks the systematization and extensive search capabilities. Other concepts, such as relationships and folders, need to be included in such an XML database in order to support the data model described herein, such as in an object-oriented database, and mechanisms such as synchronization, notification and security need to be implemented.

With respect to the following subsections, some explanations are provided which facilitate the general information disclosed, wherein Fig. 13 is a diagram illustrating the notification mechanism. 14 is a diagram showing an example in which two transactions insert a new record into the same B-tree. 15 shows a data change detection process. 16 shows an exemplary directory tree. Figure 17 shows an example where an existing folder in a directory based file system is moved to a storage platform data store.

1. Data store implementation using UDT

In this embodiment, 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 a user can not define his own type, and is simple in the sense that it can not encapsulate a complex structure. User Defined Types (UDTs) provide a mechanism for type extensibility above and beyond native scalar type systems by allowing users to extend type systems by defining complex and structured types. If a UDT is defined by the user, this UDT 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 a UDT class derived from the Base.Item type. As with the entry, the extension maps to the UDT class and uses inheritance. The root extension type is Base.Extension from which all extension types are derived.

A UDT is a CLR class, which has a state (i. E., A data field) and behavior (i. E., A routine). The UDT is defined using one of the managed languages, C #, VB.NET, and the like. UDT methods and operators can be called from T-SQL for instances of that type. The UDT may be a type of column in a row, a type of parameter of a routine in T-SQL, or a type of variable in T-SQL.

The mapping of the storage platform schema to the UDT class is very simple at a high level. Typically, the storage platform schema maps to the CLR namespace. The storage platform type maps to the CLR class. CLR class inheritance mirrors storage platform type inheritance, and storage platform attributes are mapped to CLR class attributes.

2. Item mapping

Where 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 store is to store all items in a single table with a column of type Base.Item . With type substitution, all types of items can be stored and retrieval can be filtered by item type and subtype using Yukon's "is of (type)" operator.

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

A " shadow " table is used to store replicas of 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 a type family table, this global entry table contains only the top-level scalar attributes of the entry, not the complete UDT entry object. The global entry table allows navigation to item objects stored in a type family table by exposing ItemID and TypeID. The ItemID typically uniquely identifies an item in the data store. The TypeID may be mapped to a view including a type name and an item using metadata not described here. Regarding the global entry table and in relation to other situations, it may be a common operation to look up an item by its ItemID, so if an ItemID of the item is given, a GetItem () function is provided to retrieve the item object.

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

3. Expansion Mapping

Extensions are very similar to items and have some of the same requirements. As another type of root that supports inheritance, extensions are subject to many of the same considerations in storage and tradeoffs. Because of this, similar type family mappings are applied to extensions, not single-table approaches. Of course, in other embodiments a single table approach may be used. In the present embodiment, the extension is associated with exactly one item by the ItemID, and includes an ExtensionID unique to the item. As in the entry, a function may be provided to retrieve extensions when given an extension identifier consisting of an ItemID and ExtensionID pair. Similar to the item type view, a view is created for each extension type.

4. Mapping Nested Elements

Nested elements are types that can be inserted into items, extensions, relationships, or other nested elements that form a deeply nested structure. Like items and extensions, nested elements are implemented as UDTs, but are stored in items and extensions. Thus, the nested elements have no storage mapping beyond their entry and mapping of the extension container. That is, there is no table in the system for directly storing an instance of a nested element type, and there is no view specifically dedicated to the nested element.

5. Object Identification

Each entity, i. E., Item, extension, and relationship in the data model has a unique key value. The item is uniquely identified by its ItemID. The extension is uniquely identified by a composite key of (ItemID, ExtensionID). The relationship is identified by a composite key (ItemID, RelationID). ItemID, ExtensionID, and RelationID are GUID values.

6. SQL Object Naming

All objects created in the data store can be stored in the SQL schema name derived from the storage platform schema name. For example, a storage platform default schema (sometimes referred to as a "Base") can generate types such as "[System.Storage] .Item" in a "[System.Storage]" SQL schema. The generated name is prefixed with a qualifier to eliminate naming conflicts. If 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 convention used for objects in the data store. Each of the schema elements (items, extensions, relationships, and views) is listed along with the naming conventions used to access the instances in the data store.

Object Name decoration Explanation Yes Master Item Search Views Master! Item Provides a summary of the items in the current item domain. [System.Storage].
[Master! Item]
Typed Item Search Views ItemType And all attribute data from the item and any parent type (s). [AcmeCorp.Doc].
[OfficeDoc]
Master broad match view Master! Extension Provides a summary of all extensions within the current item domain. [System.Storage].
[Master! Extension]
Typed expanded lookup Extension! ExtensionType Provides all 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 Provides all data related to a given relationship. [AcmeCorp.Doc].
[Relationship! AuthorsFro
mDocument]
View View! ViewName Provides a column / type 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 a naming conflict arises from the additional information stored with the application object. To avoid naming conflicts, all non-type specific columns (those that do not map directly to the naming attribute 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. Also, in order to unify the naming between the CLR and the data repository, all attributes of the storage platform type or schema element (relationship, etc.) must have the first letter capitalized.

8. Search Views

The view is provided by the storage platform to retrieve the stored content. An SQL view is provided for each item and extension type. Views are also 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, the data may be stored or changed using the Update () method of the storage platform API.

Each view that is explicitly defined within the storage platform schema (as defined by the schema designer, not automatically generated by the storage platform) has a named SQL view [<schema-name>]. [View! ]. For example, a view named "BookSales" within the schema "AcmePublisher.Books" can be accessed using the name "[AcmePublisher.Books]. [View! BookSales]". The output format of the view is aligned on a per-view basis (defined by any query provided by the person defining the view), so the columns are mapped directly based on the schema view definition.

All SQL search views in the storage platform data store use the following thermal ordering conventions:

- Logical "key" column of the view result, such as ItemId, ElementId, RelationshipId,

- metadata information about the type of the result, such as TypeId

- Change tracking columns such as CreateVersion, UpdateVersion, and so on.

- Type-specific columns (properties of declared type)

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

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

a) Item

Each item lookup view contains a row for each instance of an item of a particular type or its subtype. For example, a view to 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 entry 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 that describes the type of item, and several columns that are used to provide change tracking and synchronization information. The master item view is identified in the data store using the name "[System.Storage]. [Master! Item]".

Ten type Explanation ItemId ItemId Storage platform identifier for the item _TypeId TypeId The TypeId of the item identifies the exact type of item and can be used to retrieve information about the type using the metadata catalog. _RootItemId ItemId ItemId of the first non-inserted ancestor that controls the lifetime of this item <global change tracking> ... About global change tracking <Item props> n / a One column per item type attribute

(2) typed item search view

Each item type also has a lookup view. While similar to the root item view, this view also provides access to item objects through the "_Item" column. Each typed item lookup view is identified in the data store using the name [schemaName]. [ItemTypeName]. For example, [AcmeCorp.Doc] [OfficeDoc].

Ten type Explanation ItemId ItemId Storage platform identifier for the item type change tracking> ... About type change tracking parent props> <property specific> One column per parent attribute item props> <property specific> One column per exclusive property of this type Item CLR type of item CLR object - type of declaration item

9.

a) Item Expansion

All item extensions in the WinFS repository are also searchable using the search view.

(1) master extended search view

Each instance of the datastore 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 extended 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] ".

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

10.

(1) typed expanded search view

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

Ten type Explanation ItemId ItemId The storage platform identifier of the item with which this extension is associated. ExtensionId ExtensionId (GUID) The ID of this extension instance. <type change tracking> ... About type change tracking <parent props> <property specific> One column per parent attribute <ext props> <property specific> One column per exclusive property of this type _Extension CLR type of extended instance CLR object - type of declaration extension

b) 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 relational search view.

c) Relationship

As described above, the relationship forms the basic unit of connection between items in the 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 in the data store. The master relationship view is identified in the data store using the name "[System.Storage]. [Master! Relationship]".

Ten type Explanation ItemId IemId The identifier of the source endpoint (ItemId) RelationshipId RelationshipId (GUID) The ID of the relationship instance. _RelTypeId RelationshipTypeId The RelTypeId of the relationship identifies the type of relationship instance using the metadata catalog. <global change tracking> ... About global change tracking 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 a 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].

Ten type Explanation ItemId ItemId The identifier of the source endpoint (ItemId) RelationshipId RelationshipId (GUID) The ID of the relationship instance. <type change tracking> ... About type change tracking TargetItemReference ItemReference Identifier of the target endpoint <source name> ItemId Named attribute of the source endpoint identifier (alias of ItemId) <target name> ItemReference or derived class Named attribute of target endpoint identifier (alias and cast to TargetItemReference) <rel property> <property specific> One column per attribute in the relationship definition _Relationship CLR type of relationship instance CLR object - type of declaration relationship

d)

11. Update

All views in the storage platform data store are read-only. To create a new instance of a data model element (item, extension, or relationship), or to update an existing instance, the ProcessOperation or ProcessUpdategram method of the storage platform API should be used. The ProcessOperation method is a single storage procedure defined by a data store that consumes an "action" detailing the action to be performed. The ProcessUpdategram method is a stored procedure that takes an ordered set of actions known collectively as an " updategram " that describes a set of actions to be performed.

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

1. Item Action

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

b. UpdateItem (Update existing item)

2. Relational 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

12. Change tracking and gravestones

Change tracking and gravestone services are provided by the data repository 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 repository includes columns used to provide change tracking information, which are common across all items, extensions, and relationship views. Storage platform schema views that are explicitly defined by the schema designer do not automatically provide change tracking information, and this information is provided indirectly through the search view through 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, the 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) Track changes in master search view

The change tracking information in the master search view provides information about the generated and updated version of the element, the information that is the subject of the element that the synchronous partner created and last updated, and the version number from each partner for creation and update. The partners in the synchronization relationship (described below) are defined by the partner key. A single UDT object of the type [_ChangeTrackingInfo] of type [System.Storage.Store] .ChangeTrackingInfo contains all this information. The type is 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:

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

(2) Track changes in typed search views

Each typed search view provides additional information that records the synchronization state of each element in the synchronous topology, in addition to providing the same information as the global search view.

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

b) Tombstone

The data store provides tombstone information for items, extensions, and relationships. The tombstone view provides information on both entities and entities (items, extensions, and relationships) that have a living entity and a tombstone in one place. The item and extended tombstone views do not provide access to the corresponding objects, while the relationship tombstones provide access to the relationship objects (the relationship object is blank for relationships with tombstones).

(1) Item gravestone

The item gravestones are retrieved from the system via the view [System.Storage]. [Tombstone! Item].

Ten type Explanation ItemId ItemId The identifier of the item _TypedID TypedID Type of item <Item properties> ... Attributes defined for all items _RootItemId ItemId ItemId of the first non-insertion item containing this item _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this item _IsDeleted BIT This is a flag that is 0 for live items and 1 for items with tombstones. _DeletionWallclock UTCDATETIME The UTC wall clock date time according to the partner that deleted the item. This is blank if the item is alive.

(2) Extension tombstone

The extension gravestone is retrieved from the system using the view [System.Storage]. [Tombstone! Extension]. Extended change tracking information is similar to that provided for the item with the ExtensionId attribute added.

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

(3) Relationship tombstone

Relationship tombstones are retrieved from the system via view [System.Storage]. [Tombstone! Relationship]. The relationship grave information is similar to that provided for the extension. However, additional information is provided for the target ItemRef of the relationship instance. In addition, the relationship object is also selected.

Ten type Explanation ItemId ITemId The identifier of the item that owns the relationship (the identifier of the relationship source endpoint) RelationshipId RelationshipId RelationshipId of Relationship _TypedID TypedID Type of relationship _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this relationship _IsDeleted BIT This is a flag that is 0 for alive items and 1 for items with tombstones. _DeletionWallclock UTCDATETIME The UTC wall clock date and time that follows the partner that deleted the relationship. This is blank if the relationship is alive. _Relationship CLR instance of relationship This is a relationship object to a living relationship. This is a blank space 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 a grave removal task. This task determines when tombstone information can be discarded. The task shortens the tombstone information by calculating the bounds for the locally created / updated versions and then discarding all the initial tombstone versions.

13. Helper APIs and Functions

The default mapping also provides a number of helper functions. These functions are provided to aid general operations through the data model.

a) Function [System.Storage] .GetItem

b) Function [System.Storage] .GetExtension

c) Function [System.Storage] .GetRelationship

14. 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

The instance metadata is used by the application to query for the type of item and looks for extensions associated with the item. Given an ItemId for an item, the application can query the global item view, return the item type, and use this value to query the metatype view to return information about the declared type of the item. The following is an example.

E. Security

Generally, all security-enabled objects arrange their access rights using the access mask format shown in FIG. In this format, the lower order 16 bits are for object specific access rights, the next 7 bits are for standard access rights that apply to most object types, and the higher order 4 bits indicate that each object type is a standard and object It is used to specify general access rights that can be mapped to a set of specific 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 specifying right is placed in the object specifying right section (low-order 16 bits). In this embodiment, the storage platform exposes two sets of APIs for security management, namely Win32 and storage platform API, so that the 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 incorporated herein by reference in its entirety. In this regard, FIG. 27 (a, b, c) shows that a new security area, which is equally protected according to an embodiment of the security model, is separated from the existing security area.

F. Notification and Change Tracking

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

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

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

G. Common File System Interoperability

As described above, the storage platform of the present invention is implemented as an integral part of a hardware / software interface system of a 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 an operating system API that allows application programs to interact with the operating system. Thus, the storage platform is the means by which the application programs store information in the operating system, and thus the item-based data model of the storage platform replaces the conventional file system of the operating system. For example, as implemented in the Microsoft Windows operating system family, the storage platform may replace the NTFS file system implemented in this operating system. Currently, application programs access the services of the NTFS file system through the Win32 API 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 re-coding of existing Win32-based application programs and such re-coding may be undesirable, It would be advantageous to provide some interoperability with the same existing file system. Thus, in one embodiment of the 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 normal NTFS file system. Because of this, the storage platform uses a naming convention that is a superset of the Win32 naming convention to facilitate interworking. The storage platform also supports accessing files and directories stored on the storage platform volume via the Win32 API.

Further details on this function can be found in the related applications incorporated herein by reference.

H. Storage Platform API

The storage platform includes an API that enables application programs to access the functions and capabilities of the storage platform described above and access items stored in the data store. This section describes one embodiment of a storage platform API of the storage platform of the present invention. Details of this function can be found in related applications incorporated herein by reference, and for the sake of convenience, some of this information is summarized below.

Referring to FIG. 18, an Included Folder is an item that includes a maintenance relationship to another item, and is equivalent to the general concept of a file system folder. Each item is contained in at least one containing folder.

19 shows a basic architecture of a storage platform API according to the present invention. The storage platform API interacts with the local data store 302 using the SQLClient 1900 and can also interact with the remote data store (e.g., the data store 340) using the SQLClient 1900. Local store 302 may also use a distributed query processor (DQP) or may communicate with remote data store 340 via a storage platform synchronization service (" Sync " The storage platform API 322 functions as a bridge API for data store notification that conveys the subscription of the application to the notification engine 332 as described above and routes the notification to the application (e.g., application 350a, 350b or 350c). In one embodiment, the storage platform API 322 may also define a limited " provider " architecture to allow access to data within 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 that represents storage platform elements and item types; (2) a runtime framework 2004 that manages persistence of objects and provides support classes 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 the types in that schema. For example, consider item types defined in a contact schema such as that shown in Figures 21A and 21B.

22 shows the operation of the runtime framework. The runtime framework operates as follows.

1. Applications 350a, 350b or 350c are coupled to items in the 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 collection of items, and the returned set is conceptually (due to relationships) the object graph 2204.

4. The application changes, deletes and inserts data.

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

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

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

Figure 25 shows a schema based on the File API. The storage platform API includes a namespace for processing 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 repository, and this information can either be promoted from a filesystem object or be created uniquely using the Win32 API. The System.Storage.Files namespace has two classes: FileItem and DirectoryItem. The 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 fix these, you have to use Win32 API or classes in System.IO.

With respect to the API, a programming interface (or more simply an interface) may be shown as any mechanism, process, or protocol that enables one or more code segments to communicate with or access functions provided by one or more other code segments . Alternatively, a programming interface may be viewed as one or more mechanisms, methods, function calls, modules, objects, etc. of components of the system that can communicate with one or more mechanisms, methods, function calls, modules, etc. of other components. The term " code segment " in the preceding sentence is intended to encompass more than one command or line of code, regardless of the terminology applied, or whether the code segments are individually compiled, or whether the code segments are source, Regardless of whether the code segments are used in a run-time system or process, they may be distributed on the same or different machines or distributed across multiple machines, or the functions represented by code segments may be implemented entirely in software, For example, code modules, objects, subroutines, functions, etc., whether implemented entirely in hardware, or in a combination of hardware and software.

Conceptually, the programming interface can be generally viewed as shown in FIG. 30A or 30B. 30A shows interface Interface 1 as a conduit which is the means by which the first and second code segments communicate. 30B is a diagrammatic representation of one embodiment of the invention that includes interface objects I1 and I2 (which may or may not be part of the first and second code segments) that enable the first and second code segments of the system to communicate through the medium M Interface. Referring to FIG. 30B, the interface objects I1 and I2 can be regarded as individual interfaces of the same system, and the objects I1 and I2 plus medium M can be regarded as including an interface. 30A and 30B illustrate bidirectional flows and interfaces on each side of the flow, some implementations may have an information flow in one direction (or no information flow as described below) Lt; / RTI &gt; For example, terms such as APIs, entry points, methods, functions, subroutines, remote procedure calls, and COM interfaces are included within the definition of a programming interface, but are not limited thereto.

Aspects of such a programming interface include methods that allow a first code segment to transmit information to a second code segment (where " information " is used in a broad sense and includes data, instructions, requests, etc.); A method for allowing a second code segment to receive information; And information structure, sequence, syntax, organization, schema, timing, and content. In this regard, the underlying transmission medium itself may not be critical to the operation of the interface, regardless of whether the medium is wired or wireless, or a combination thereof, as long as the information is transmitted in a manner defined by the interface. In some situations, information transmission may take place via other mechanisms (e.g., information located in a buffer, file, or the like may be information between code segments), such as when a code segment simply accesses a function performed by a second code segment The information may not be transmitted in one direction or in both directions in the usual sense. 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 tightly coupled configuration, and thus the list is exemplary only Should be considered as non-limiting.

The concept of such programming interfaces is well 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 the programming interface, and these are also intended to be included in the claims set forth at the end of this specification, unless expressly excluded. Such other methods may appear to be more complex than the simple drawings of Figures 30A and 30B, but nevertheless perform similar functions 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 the communication into a number of separate communications. This is schematically illustrated in Figures 31A and 31B. As shown, some interfaces may be described by a set of partitionable functions. Thus, the interface functions of Figs. 30A and 30B can be factorized to achieve the same result, as can mathematically provide 24 or 2 x 2 x 3 x 2. Hence, as shown in FIG. 31A, the function provided by the interface Interface1 can be subdivided into a plurality of interfaces Interface1A, Interface1B, Interface1C, etc. to convert the communication of the interface while achieving the same result. As shown in FIG. 31B, the function provided by the interface I1 may be subdivided into a plurality of interfaces I1a, I1b, I1c, etc. while achieving the same result. Similarly, the interface I2 of the second code segment receiving information from the first code segment may be factorized into a plurality of interfaces I2a, I2b, I2c, and so on. 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 either of the cases of Figures 31A and 31B, the functional mapping of the interfaces Interface 1 and I1 remains the same as Figures 30A and 30B, respectively. Factorization of interfaces can also follow combinations, exchanges, and other mathematical properties, so factoring can be hard to recognize. For example, the ordering of operations may not be important, and consequently the functions performed by one interface may be performed by other code or interfaces before reaching this interface, or may be performed by individual components of the system . Moreover, those skilled in the programming arts will appreciate that there are various ways of calling different functions to achieve the same result.

Redefinition : In some cases, certain aspects (e.g., parameters) of the programming interface may still be ignored, added or redefined while still achieving the intended result. This is illustrated in Figures 32A and 32B. For example, assuming that the interface Interface1 of FIG. 30A includes a function call Square (input, precision, output) that includes three parameters: input, precision and output, and a call issued to the second code segment in the first code segment do. As shown in FIG. 32A, if the accuracy, which is an intermediate parameter, is not significant in a given scenario, this parameter may be ignored or replaced with a meaningless parameter (in this situation). In addition, additional non-critical parameters may be added. In either case, the function of the square can be achieved as long as the output is returned after the input is squared by the second code segment. The accuracy may very well be a meaningful parameter to a given downstream or other portion of the computing system, but if the accuracy is perceived as not being needed for the narrow purpose of calculating the square, the accuracy may be replaced or ignored. For example, instead of conveying a valid accuracy value, a meaningless value such as a birthday can be delivered without adversely affecting the result. Likewise, as shown in FIG. 32B, interface I1 is replaced with interface I1 ', which is redefined to ignore or add parameters to the interface. Interface I2 may likewise be redefined as an interface I2 'which is redefined to ignore unnecessary parameters or parameters that may be processed 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 and therefore they may be ignored or redefined or otherwise processed elsewhere for other purposes.

Inline coding : It is possible to merge some or all of the functions of two separate code modules so that the interface between them changes form. For example, the functions of FIGS. 30A and 30B may be converted to the functions of FIGS. 33A and 33B, respectively. In Figure 33A, the previous first and second code segments of Figure 30A are merged into a module containing both of them. In this case, the code segments can still communicate with each other, but the interface can be adapted to a single module in a more appropriate form. Thus, for example, a formal call and return statement may no longer be needed, but a similar process or response according to interface Interface1 may still be executed. Similarly, as shown in FIG. 33B, part (or all) of interface I2 from FIG. 30B may be created in-line in interface I1 to form interface I1 '. As shown, interface I2 is divided into I2a and I2b, and interface portion I2a is in-line coded with interface I1 to form interface I1 &quot;. As a specific example, the interface I1 from Fig. 30B is a function call that is received by interface I2 and processes the value passed as input by the second code segment (squares the input value) and passes the squared result to the output It is assumed that square (input, output) is performed. In this case, the processing performed by the second code segment (input squared) can be performed by the first code segment without a call to the interface.

Separation : Communication from one code segment to another can be accomplished indirectly by splitting the communication into a number of separate communications. This is schematically shown in Figures 34A and 34B. As shown in FIG. 34A, one or more middleware (a separate interface, which separates functional and / or interface functions from the original interface), converts communications on the first interface Interface 1 so that they can communicate with different interfaces, in this case interfaces Interface 2A, Interface 2B and Interface 2C To be followed. This can 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 different interfaces, in this case interfaces Interface 2A, Interface 2B and Interface 2C. The point is that the original interface used by the second code segment has changed so that it is no longer compatible with the interface used by the first code segment and thus 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 having a separation interface DI1 for receiving communications from interface I1 and a separation interface DI2 for transmitting interface functions, for example, to interfaces I2a and I2b, I2a and I2b are redesigned to work with DI2 but provide the same functional results. Likewise, DI1 and DI2 can work together to communicate the functionality of interfaces I1 and I2 of Figure 30B to the new operating system, 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 represented in an intermediate language is provided as a Just-in-Time (JIT) compiler or interpreter in an execution environment (e.g., provided by a Net Framework, Java Runtime Environment or other similar runtime type environment) May exist. The JIT compiler is configured to dynamically convert communications from the first code segment to the second code segment, that is, to follow these different communications as may be required by the second code segment (the original or another second code segment) Lt; / RTI &gt; This is shown in Figures 35A and 35B. As shown in Figure 35A, this approach is similar to the separation scenario described above. This may 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-fly from installation-based applications to the new interface of the operating system. As shown in FIG. 35B, this approach of dynamically rewriting the interface may be applied to dynamically factorize or change the interface.

It should be noted that the above-described scenarios that achieve the same or similar results with the interface through alternative embodiments may also be combined in various ways, in series and / or in parallel, or with other arbitration codes. Thus, the alternate embodiments described above are not exclusive to each other, and may be mixed, matched, and combined to create scenarios that are the same as or equivalent to the generic scenario provided in Figures 30A and 30B. It should also be noted that, as in most programming architectures, there are other similar methods for achieving the same or similar functionality of the interface represented by the spirit and scope of the present invention, which may not be described here, In part, the functionality represented by the interface upon which the value of the interface is based, and the beneficial results enabled by the interface.

III. Sync API

Several approaches to synchronization are possible in item-based hardware / software interface systems.

A. Synchronization Overview

In various embodiments of the present invention, and in conjunction with FIG. 3, the storage platform includes (i) a plurality of instances of the storage platform (each having its own data store 302) (Ii) provides a synchronization service 330 that provides an infrastructure for a third party to synchronize the data store of the storage platform of the present invention with other data sources implementing proprietary protocols.

Storage platform-to-storage platform synchronization occurs between groups of participating " replicas ". For example, referring to FIG. 3, it is contemplated to provide synchronization between a data store 302 of a storage platform 300 and another remote data store 338, possibly under the control of another instance of a storage platform running on another computer system May be preferred. All members of this group need not know any given replicators at any given time.

Other replicas can make changes independently (i.e., simultaneously). The synchronization process is defined as making all the replicators aware of the changes made by the other replicators. The synchronization capability is essentially multi-master.

The synchronization capability of the present invention is such that the replica

- determine if any other replicators are aware of any changes,

- Ask for information about the changes this replicator is not aware of,

- communicate information about changes that other replicas are not aware of,

- determine when the two changes conflict with each other,

- Apply changes locally,

- pass collision resolution to other replicators to ensure convergence,

- Allows to resolve conflicts based on a specified policy for conflict resolution.

1. Storage platform to storage platform synchronization

A key application of the synchronization service 330 of the storage platform of the present invention is to synchronize multiple instances of the storage platform (each having its own data store). The synchronization service operates at the storage platform schema level (not the base table of 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 write and transmit individual operations (e.g., transactional replication) but sends the end result of these operations, thus often incorporating 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 atomically applied to all other replicas, that is, one change may appear without any other changes. The exception to this principle is that, if two changes are made to the same item in the same transaction, these changes are guaranteed to be sent and applied to other replicas at a minimum level. Therefore, the items are consistency units of the synchronization service.

a) Sync control application

Any application may be connected to the synchronization service to initiate a synchronization operation. These applications provide 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 informs the local synchronization service to synchronize with the remote partner. On the other side, the synchronization service is initiated by a message sent by the synchronization service from the initiator. The synchronization service responds based on persistent configuration information (see mapping below) that exists on the arriving machine. The synchronization service may be executed according to a schedule or in response to an event. In these cases, the synchronization service that implements the schedule becomes the SCA.

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

b) Commenting schemas

The basic concept of the synchronization service is the concept of a change unit. Change units are the smallest part of the schema that is tracked individually by the storage platform. For all change units, the synchronization service can determine whether the change unit has changed since the last synchronization.

Displaying a change unit in a schema has several purposes. First, it determines how complicated 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 replicators because the synchronization service does not know which part of the change unit has changed. Second, it determines the granularity of collision detection. When two concurrent changes (the term is defined in detail in the following section) are made for the same change unit, the synchronization service causes a conflict, whereas if a concurrent change is made to different change units, no conflict occurs , The changes are merged automatically. Third, it has a strong impact on the amount of metadata maintained by the system. Much of the synchronization service metadata is maintained for the change unit, thus the change units have less overhead of synchronization.

The definition of a change unit requires the discovery of the correct trade-off. Because of this, the synchronization service allows the schema designer to participate in the process.

In one embodiment, the synchronization service does not support a change unit larger than an element. However, the synchronization service supports the ability for the schema designer to specify a change unit smaller than an element, i.e. the ability to group multiple attributes of an element into separate change units. In this embodiment, this is accomplished using the following syntax.

c) Synchronization Configuration

A group of storage platform partners that want to maintain a predetermined portion of their data in synchronization is referred to as a synchronization community. While members of the community want to stay in sync, they do not need to display the data in exactly the same way, i.e. the synchronization partners can convert the data they are synchronizing.

In a peer-to-peer scenario, it is impractical for peers to maintain transformation mappings for all of their partners. Instead, the synchronization service takes an approach that defines a "community folder". A community folder is an abstraction that represents a virtual "shared folder" in which all community members are synchronized.

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

The configuration of the synchronization service includes three steps: (1) defining a mapping between the local folder and the community folder, (2) determining what is synchronized (e.g., with whom, with which subset should be transmitted and received) (3) defining a schedule on which different synchronization profiles are to be executed or a schedule for manually executing them.

(1) Community Folder - Mapping

The community folder mapping is stored as an XML configuration file on individual machines. Each mapping has the following schema.

/ mappings / communityFolder

This element names the community folder that is the object of this mapping. The name follows the syntax rules of the folder.

/ mappings / localFolder

This element names the local folder to which the mapping is converted. This name follows the syntax rules of 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 translate items from community folders to local folders 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 primarily useful for creating a cache of folders.

/ mappings / transformation / mapIDs

This element requires that community IDs are not reused, but that newly created local IDs are assigned to all mapped items from the community folder. Synchronization execution time maintains the ID mapping to translate 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 whose requests this mapping is handled under whose authority. If not, the sender is assumed.

/ mappings / runAs / sender

The presence of this element indicates that the sender of the message for this mapping should be implemented and that requests should be processed under his trust.

(2) Profile

A synchronization profile is a comprehensive set of parameters needed to initiate synchronization. This is provided by the SCA for synchronization initiation 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

- The name of the remote folder to be synchronized. - This folder must be opened from the remote partner through the mapping defined above.

- Direction - The synchronization service supports transmission only, receive only, and transmit-receive synchronization.

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

- Remote filter - Select which remote information is to be retrieved from the remote partner. It is expressed as a storage platform query for the community folder.

- Conversion - Defines how to convert items to local format.

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

- Conflict Resolution Policy - Specifies whether the conflict should be denied, logged, or automatically resolved. In the latter case, specify which configuration parameters to use as well as which conflict resolver to use.

The synchronization service provides a runtime CLR class that allows simple construction of synchronization profiles. Profiles can also be serialized (often with schedules) to XML files 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 local mapping to initiate synchronization. All synchronization information can be specified in the profile. However, mapping is required to respond to the synchronization request initiated by the remote side.

(3) Schedule

In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it depends on the other components that will perform this task, namely the Windows 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 a window scheduler that performs synchronization in response to an event, such as a schedule, or a user logon or logoff.

d) Conflict handling

The conflict processing in the synchronization service is performed in three steps: (1) a conflict detection step occurring at a change application time-this step determines whether the change can be safely applied; (2) Automatic conflict resolution and logging phase - During this phase (occurring immediately after the conflict is detected), the automatic conflict resolver is consulted to see if the conflict can be resolved, and if it can not be resolved, Logged -; And (3) Collision checking and resolution step - This step occurs when a certain conflict is logged and occurs without regard to the synchronization session, at which time the logged conflicts can be resolved and removed from the log. Various embodiments of the present invention relating to conflict handling are described in further detail in Section III below.

2. Synchronization to the non-storage platform data store

According to another aspect of the storage platform of the present invention (and in connection with various embodiments of the invention disclosed in Section IV below), the storage platform may be a storage platform that synchronizes to a legacy system such as Microsoft Exchange, AD, Hotmail, It provides an architecture for ISVs to implement a synchronization adapter that allows for The synchronization adapter benefits from a number of synchronization services provided by the synchronization service, as described below.

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

To make it simpler for others to configure and run synchronization for a given backend, the Sync Adapter creator is encouraged to expose a standard Sync Adapter interface that implements synchronization when a synchronization profile is given, as described above. The profile provides configuration information to the adapter, which passes some of it at runtime to control runtime services (e.g., folder synchronization).

a) Synchronization Services

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

(1) Change enumeration

Based on the change tracking data maintained by the synchronization service, the change enumeration allows the sync adapter to easily enumerate changes made to the data store folder after the last synchronization with this partner is attempted.

The changes are enumerated based on the concept of an " anchor " which is an opaque structure representing information about the final synchronization. The anchor has the form of storage platform knowledge as described in the previous section. Synchronous adapters using change enumeration services are classified 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 can not conveniently store this information. On the other hand, when multiple clients synchronize to the same backend, storing this information on the client is inefficient and in some cases incorrect, which prevents one client from noticing 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 change enumeration.

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 a change enumeration, the Sync Adapter uses a confirmation interface to report which changes were successfully applied. At the end of synchronization, adapters using the provided anchor must read the new anchor (including all of the successfully applied changes) and send it to their backend.

Often, adapters need to store adapter specific data with the items they insert into the storage platform data store. Common examples of such data are remote IDs and remote versions (timestamps). The synchronization service provides a mechanism for storing such data, and change enumeration provides a mechanism for receiving such extra data with the changes being returned. This eliminates the need for adapters to materialize the database in most cases.

(2) Application of change

The change application allows the sync adapters to apply changes received from their backend to the local storage platform. Adapters are expected to convert the changes into a storage platform schema. 24 shows a process in which storage platform API classes are generated from a storage platform schema.

The main function of the change application is to automatically detect conflicts. As in the case of storage platform-storage platform synchronization, conflicts are defined as two duplicate changes being made without knowledge of each other. When adapters use change application, they must specify an anchor to be associated with performing collision detection. A change application causes a conflict if a duplicate local change is detected that is not covered by the knowledge of the adapter. Similar to change enumeration, adapters can use stored or supplied anchors. The change application supports efficient storage of adapter-specific metadata. This data can be attached to changes being applied by the adapter and can be stored by the synchronization service. The data can be returned at the next change enumeration.

(3) Conflict resolution

The conflict resolution mechanisms described above (logging and automatic resolution options) are also available to synchronization adapters. Synchronization adapters can specify policies for resolving conflicts when applying changes. If specified, conflicts can be passed (if possible) to the specified conflict handler. Collisions can also be logged. The adapter can detect a conflict when it tries to apply a local change to the backend. In this case, the adapter can still deliver a conflict to the synchronization run time so that it is resolved according to policy. In addition, the synchronization adapters may require that any conflicts detected by the synchronization service be forwarded to them for processing. This is especially useful if the backend can store or resolve conflicts.

b) Adapter implementation

Some adapters are applications that only use run-time interfaces, but adapters are encouraged to implement standard adapter interfaces. These interfaces allow the synchronization control applications to require the adapter to perform synchronization according to a given synchronization profile, to cancel the ongoing synchronization, and to receive progress reports on the ongoing synchronization.

3. Security

The synchronization service tries to minimize as much as possible the security model implemented by the storage platform. Use existing rights rather than defining new rights to synchronization. Specifically, it is as follows.

- Anyone who can read the data store entry can enumerate changes to that item.

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

Anyone who can extend the data store entry can associate synchronization metadata with the item.

The synchronization service does not maintain secure author information. When a change is made to replicator A by user U and is sent to replicator B, the fact that the change was made first in A (or by U) is eliminated. If B sends this change to replicator C, this is done under B's authority, not A's authority. This causes the following restrictions, that is, if the replicator is not authorized to make its own changes to the entry, then this replicator can not transmit changes made by other replicas.

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

4. Manageability

Monitoring of the distributed community of replicas is a complex problem. The synchronization service can use a "sweep" algorithm to collect and distribute information about the state of the replicators. The attributes of the sweep algorithm ensure that information about all replicas configured is eventually collected and that a failed (non-replied) replicas are detected.

This community-wide monitoring information becomes available to all replicas. The monitoring tool can be run on any selected replicator to inspect this monitoring information and make management decisions. Any configuration changes must be made directly from the affected replicators.

B. Sync API Overview

In the increasingly dispersed digital world, individuals and workgroups often store information and data in a variety of different devices and locations. This has assisted in the development of a data synchronization service that can keep the information at minimum user intervention in separate, often different, and always synchronized data stores.

The synchronization platform of the present invention, which is part of the abundant storage platform (so-called " WinFS ") described in Section II of this specification, deals with three main subjects:

- Allows applications and services to synchronize data between different " WinFS " stores.

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

- Provide developers with an appropriate interface to customize the synchronization user experience.

1. General terminology

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

Synchronization replicas: Most applications are only concerned with tracking, enumerating, and synchronizing changes to a given subset of items in a WinFS repository. A set of items participating in a synchronization operation is called a synchronization replica. The replicas are defined as items contained within a given WinFS inclusion hierarchy (usually the root of a folder item). All synchronization services are performed with respect to a given replicator. WinFS synchronization provides a mechanism for defining, managing, and removing replicas. Every replicator has a GUID identifier that uniquely identifies itself within a given WinFS repository.

Synchronization partners: Synchronization partners are defined as entities that can influence changes in WinFS items, extensions, and relationships. Therefore, all WinFS repositories are synonymous partners. When synchronized with a non-WinFS repository, an external data store (EDS) can be considered a synchronization partner. Every partner has a GUID identifier that uniquely identifies itself.

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

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 granularity defined in the schema. The top level fields of any item, extension, and relationship type can be subdivided by the schema designer in change units, with the minimum granularity being one top level field. For change tracking, all change units are assigned a version, and the version is a pair of sync partner id and version number (the version number is the partner specific monotonic increase number). Versions are updated when the change occurs locally in the repository or when the change is obtained from a different replicator.

Synchronization knowledge: The knowledge represents the state of a synchronization replica given at any time, that is, it encapsulates the metadata for every change that a given replicator perceives locally or from another replica. WinFS synchronization maintains and updates knowledge of synchronization replicas in synchronization operations. An important note is that the knowledge representation allows interpretation of the entire community, not the specific replicas where 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 the WinFS data to the non-WinFS data store. Depending on the requirements of the scenario, which subset of WinFS data and which WinFS data types should be synchronized is left to the adapter developer. The adapter is responsible for communicating with the EDS, converting the WinFS schema into / from the EDS support schema, and managing its own configuration and metadata. Adapters are strongly encouraged to use the generic configuration to implement the WinFS Synchronization Adapter API to control the infrastructure for the adapters provided by the WinFS synchronization team. For more information, see the WinFS Sync Adapter API [SADP] specification and the WinFS Sync Controller API [SCTRL] specification.

For adapters that can not synchronize WinFS data to external non-WinFS storage and can not create or maintain knowledge of WinFS format, WinFS synchronization provides a service to obtain remote knowledge that can be used for subsequent change enumeration or apply operations. Depending on the capabilities of the backend store, the adapter may want to store the remote knowledge on the backend or on the local WinFS store.

For simplicity, a synchronization "replicator" is a structure that represents a set of data in a "WinFS" repository that resides in a single logical location, while data on a non-"WinFS" repository is called a "data source" Requires the use of adapters.

Remote knowledge: When a given synchronization replicator wants to get a change from another replicator, this replicator provides its own knowledge as a baseline for the other replicators to enumerate the changes. Likewise, when a given replicator wants to send a change to another replicator, it provides its own knowledge as a baseline that can be used by other replicators to detect the collision. Knowledge of these other replicas provided during synchronization change enumeration and application is called remote knowledge.

2. Sync API principles

In some embodiments, the synchronization API is split into two parts: a synchronization configuration API and a synchronization controller API. The Synchronization Configuration API allows an application to configure synchronization and specify parameters for a specific synchronization session between two replicas. For a given synchronization session, the configuration parameters include a set of items to be synchronized, 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 synchronization, and receives progress and error information for 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 for customizing scheduling.

Various embodiments of the present invention use synchronization adapters to synchronize information between " WinFS " and non- " WinFS " data sources. An example of an adapter includes an adapter that synchronizes address book information between a " WinFS " contact folder and a non-WinFS mailbox. In this example, the adapter developer is referred to as " WinFS " as described herein to access the services provided by the " WinFS " synchronization platform to develop schema conversion code between the & "You can use the Sync Core Services API. Adapter developers also provide protocol support for communicating changes to non-WinFS data sources. The synchronization adapter is invoked and controlled using the synchronization controller API, and uses this API to report progress and errors.

However, in certain embodiments of the invention, when synchronizing a WinFS data store to another WinFS data store, the synchronization adapter may not be needed if the WinFS-to-WinFS synchronization service is integrated within the hardware / software interface system. In any case, these various embodiments provide a set of synchronization services for both WinFS-to-WinFS and synchronization adapter solutions, including:

Tracking changes to WinFS entries, extensions, and relationships

- Support for efficient incremental change enumeration after a given past state

- Applying external changes to WinFS

- Collision handling during change application.

Reference is made to Fig. 36, which shows three instances of a common data store and the components for synchronizing them. The first system 3602 includes a core synchronization service 3624 that exposes (3646) the use of the WinFS-to-WinFS synchronization service 3622 and the synchronization API 3652 for WinFS to non- (3612). Similar to the first system 3602, the second system 3604 exposes (3646) the WinFS-to-WinFS synchronization service 3632 and the sync API 3652 for WinFS-to-non- And a WinFS data store 3614 that includes a service 3634. The first system 3602 and the second system 3604 are synchronized 3642 through their respective WinFS-to-WinFS synchronization services 3622, 3632. The third system 3606, which is not a WinFS system, has an application 3666 that uses WinFS synchronization to keep a data source in a synchronization community with a WinFS replica. The application is directly connected to the WinFS data store 3612 via a synchronization adapter 3662 that interfaces with the WinFS-to-WinFS synchronization service 3622 (if it can virtualize itself as a WinFS data store) (3644) &lt; / RTI &gt;

As shown in this figure, the first system 3602 recognizes both the second system 3604 and the third system 3606 and is directly synchronized. However, both the second system 3604 and the third system 3606 do not know each other and thus do not synchronize their changes directly with each other, but instead changes that occur in one system are sent through the first system 3602 Be propagated.

C. Sync API Services

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

1. Change enumeration

As noted above, the change enumeration allows the synchronization adapter to easily enumerate changes that occur since the last synchronization attempt with this partner to the data store folder, based on change tracking data maintained by the synchronization service. With respect to change enumeration, various embodiments of the present invention relate to the following.

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

- enumeration of changes at the level of granularity granularity specified in the WinFS schema

- grouping of the enumerated changes for multiple items. A compound item consists of an item, all its extensions, all the maintenance relationships to the item, and all compound items corresponding to its insertion items. Changes to the reference relationships between items are listed separately.

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

- Specify the filter for entries in the replicator during change enumeration. For example, a replicator may consist of all items in a given folder, but for a particular change enumeration, the application wants to enumerate only changes to all contact items whose first name begins with 'A' Added after the milestone).

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

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

2. Apply changes

As noted above, the change application allows the sync adapters to apply changes received from their backend to the local storage platform, as adapters are expected to convert the changes to a storage platform schema. With regard to the modification application, several embodiments of the present invention relate to the following.

- Application of incremental changes to WinFS change metadata from other replicas (or non-WinFS repositories) with corresponding updates

- Detection of collision when applying change in changing unit granularity

- Reporting of successes, failures and conflicts at the individual change unit level 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 the remote knowledge during the change application to prevent " reflection " of application-supplied changes during the next change enumeration operation

- Improved use of 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 run time (where all adapter specific functions are prefixed with FOO):

4. How API synchronization works

In one embodiment of the invention, synchronization between a WinFS repository and a non-WinFS repository can be achieved 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 consistently deployed, initialized, and controlled. The adapter API provides:

- Standard mechanism for registering adapters in the 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

- a standard mechanism for passing initialization information to the adapter

- mechanisms for adapters to report progress to applications that invoke synchronization

- a mechanism to report any errors that occur during synchronization

- Mechanism to require a minimum of ongoing synchronization operations

There are two potential process models for adapters according to the requirements of the scenario. The adapter can be run in the same process space as the application calling it or alone 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 return 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 practice, many adapters run in the same process as the calling application. The process model out is usually required for one or both of the following reasons.

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

In addition to handling requests from the calling application, the adapter must handle requests from other sources, such as incoming network requests.

37, an embodiment of the present invention assumes a simple adapter that does not know how states are computed, or how metadata associated with it is exchanged. In this embodiment, synchronization is achieved by the replicators, in relation to the data source that the replicators want to synchronize, by first detecting in step 3702 what change has occurred since the replica was last synchronized with the data source And the replicator then sends an incremental change that occurred after the last synchronization based on its current state information, which current state information and incremental changes are sent to the data source via the adapter. At step 3704, the adapter makes as many changes to the data source as possible when it receives change data from the replicators in the previous step, tracks which changes are successful and which changes have failed, Flicker) to WinFS. The replica's hardware / software interface system (WinFS), in step 3706, calculates the new status information for the data source after receiving the success and failure information from the replicator, and forwards this information to its replicators for future use And sends this new state information to the data source, i. E., For storage by the adapter and subsequent use.

D. Synchronization Hierarchy

As described above, each replicator (and data source and / or adapter) maintains incremental and sequential enumeration of its changes, each of which is assigned a corresponding incremental and sequential change number 1 change is 1, the second change is 2, the third change is 3, and so on). Moreover, each replicator maintains state information for these other replicas to track which changes have been received from other known replicas (synchronization partners) in its synchronization community. By knowing the change number of the last change from the second replica applied to the first replica, the first replicator can later use this number to request, receive or process only those changes that are greater than the number of the last applied change . Figures 38A-D illustrate how changes are tracked, enumerated, and synchronized using this sequential change enumeration method.

In Figure 38A, the synchronization adapters A and B are replicas in the common synchronization community, and since no changes have yet been made, they are equally the same with a change number of 0 for each replica, e.g., A0 and A0 for each replica, Lt; RTI ID = 0.0 &gt; B0. &Lt; / RTI &gt; (In this embodiment, the unique change number is used to reflect the initial state.) Each replicator knows its state and tracks the state of its synchronization partner, and stores this information in its vector (As shown, listing the status of the replicator itself first, listing the last known state of each of its partners based on final synchronization, or in this case based on initialization). The initial vector for replicator A is "[A0, B0]", the initial vector for replicator B is "[B0, A0]", and the two replicas are now fully synchronized.

In Figure 38B, replicator A makes a change and assigns a unique incremental change number A1 to this change (the change number is the unique incremental number " 1 " for the change of the replicar as well as the unique identifier &Quot;). On the other hand, replicator B makes two changes and assigns unique incremental change numbers of B1 and B2 to these changes, respectively. At this point, prior to the next synchronization, the replicators now deviate from synchronization, the vector for replica A is now [A1, B0], and the vector for replica B is [B2, A0] Reflected).

  In Figure 38C, replicator A is synchronized with replica B by sending its current vector to replicator B to request a change (step 1). Replica B receives the vector of replica A and computes that changes B1 and B2 need to be sent to replica A and thus does so (step 2). Replicator A receives changes (i.e., change units) of replicator B identified as B1 and B2 and applies them to update its own vector to [A1, B2] (step 3).

In an alternative embodiment shown in Figure 38D, replicator B computes and sends the correct changes to replicator A (step 2) and also replies to replica A, which replicator B does not have, based on the vector of replicator A And therefore replica B also sends its own vector and change request to replica A (step 2 '). Later, when replicator A receives the changes in replicator B and applies them to update its vector to [A1, B2] (during step 3), replicator A also determines which of its modifications To replicator B, and also transmits them (step 3 '). When the replicator B receives this information, it makes a change and updates its vector to [B2, A1] (step 4).

With respect to the above example, conflicts can occur in various environments. For example, A1 and B2 may be changes made to the same change unit, or A1 may be a deletion to the same change unit that B2 is modifying. While some of these conflicts can be resolved using the conflict resolution options described above, certain conflicts present a very difficult problem, and these problems and their solutions are described below in light of this example.

Proactive Synchronization of Out-of-Range Changes

In certain embodiments of the invention, the range of replicas may not be static. As a result, replicator A can effectively increase its range with changes that create new relationships between items within its range and items outside its range. However, if it is assumed that the change units for out-of-range items are not synchronized between replicators A and B (because this is out of sync with the replicators), a synchronization mismatch May occur. The solution to this problem is that replicator A sends to replicator B all changes made to the out-of-range item with a specific change in replica A that creates a relationship between the in-scope and out-of-scope items.

2. Parent-child disorder synchronization

In some embodiments of the invention, for synchronization, it is a general principle that the parent item is always sent before the child item (e.g., if the child K is inserted into the parent J, It can not be transmitted before it is transmitted). However, for replicator A, child items K have a lower classification number than parent item J (e.g., based on the sequential superiority of its identification number), while items J and K are changed between syncs, Therefore, it can be transmitted normally first. One solution to this problem of synchronization in various embodiments of the present invention is to classify the changes into two groups: a group that only reflects changes made to item K, and a group that only reflects changes made to item J (I.e., send a change group for parent entry J and then a change group for child entry K).

3. Tombstone propagation

As described above, a tombstone is used to indicate deleted change units for synchronization. However, since synchronization is asynchronous to multiple vectors in the synchronization community, these tombstones must be propagated to the entire data platform. It is a problem that replicator A can create an item without responsibility for tombstone propagation and can transmit this item to replicator B during synchronization with replicator B. Replicator A can then delete this entry and, during synchronization with replicator C, will not be able to send anything for the entry for the item (since the item has been deleted) because there is no transmission. Thereafter, when the replicators B and the replicators C attempt to synchronize, the replicators C receive the items from the replicators B, and the items remain on the B's.

In various embodiments of the present invention, the solution to this problem is that replicator A marks the deletion item as a gravestone. Later, when replicator A deletes an item, replicator A transfers the gravestone to replicator B during synchronization with replicator C. Thereafter, when replicators B and replicators C attempt synchronization, replicerator B also receives gravestones, and items are now completely removed from the synchronization community.

4. Route tombstone propagation

In P1, if item X has a plurality of inserts A, B, C, D and E, then an interesting scenario is that between P1 and P2, when P1 deletes the child items first and then deletes the parent item X The same pure result is obtained when P1 simply deletes the parent X (one change) (in this case, the inserted items &lt; RTI ID = 0.0 &gt; Is also automatically deleted). In this regard, several embodiments of the present invention relate to the fact that the deletion of X at the time of synchronization is really equivalent to six individual delete events, so that P1 only transmits the change unit corresponding to the deletion of X to P2, Thereby allowing them to propagate naturally.

5. Name Swapping

As described above, the relations have names, so it is possible for one replicator P1 to swap the names for the two relations R1 and R2 using the temporary name element X, i.e. the name of R1 Is copied to X, then the name of R2 is copied to R1, then X is copied to R2, and finally X is deleted. However, since the partner replica P2 is unaware of the temporary name element X, an error occurs during synchronization, which is when R1 recognizes that it has a new name, that P2 attempts to change this name to R1 and Lt; RTI ID = 0.0 &gt; R2. &Lt; / RTI &gt; One solution to this problem in various embodiments of the present invention is that P2 assumes possible name swap scenarios upon receipt or recognition of this same naming error and automatically generates its own temporary name element Y, If the change actually involves renaming R2 to a name in X, it is to complete swapping (otherwise, the scenario is created as a regular conflict event).

6. References

In situations where the suspension relationship (supported by WinFS) is not supported by non-WinFS systems for synchronization between replicator P1 (running on a WinFS system) and data source P2 (running on a non-WinFS system) Lt; / RTI &gt; The problem is that the two items A and B have a relationship R on P1 and that P1 has them as A (as change unit P1-21), R (as change unit P1-22), B (as change unit P1-23) Occurs when generating in sequence. When R is created (P1-22), R is a hanging relationship, so when P2 applies the changes in sequence, an unacceptable suspension relation error occurs. The solution to this problem in various embodiments of the present invention is that all references (e.g., R) are sent after all other changes have been sent from P1 to P2 to generate items A and B first, Reordering the changes so that the problem can be completely prevented by relating them.

E. Synchronization - Conflict handling

As described above, the conflict processing in the synchronization service includes three steps: (1) a conflict detection occurring at a change application time (this step determines whether or not the change can be safely applied); (2) {During this phase (which occurs immediately after a collision is detected), an automatic collision handler is consulted to see if the collision can be resolved. If not, conflicts are optionally logged}; And (3) collision checking and resolution (this step occurs when some conflicts are logged and occurs outside the context of a synchronous session, where logged conflicts can be resolved and removed from the log).

Various embodiments of the present invention are particularly directed to conflict handling for conflicts occurring in a peer-to-peer synchronization system (such as the synchronization system described above). The ability to handle collisions correctly and efficiently minimizes data loss while maintaining good availability and reducing the need for user intervention during synchronization. Some embodiments of the present invention are directed to a conflict handling schema that includes one or more of the following conflict handling elements: The conflict handling element includes (a) a graphical representation of the conflict; (b) detection of collision; (c) a log of collisions into a reparative storage; (d) automatic resolution of collisions according to flexible and configurable conflict resolution strategies; (e) an organizable and scalable conflict handler for filtering and resolving conflicts; (f) automatic detection and removal of degraded collisions; And (g) a programmed conflict resolution. Further, apart from the conflict handling scheme, each of these conflict handling elements themselves represents a further embodiment of the present invention.

1. Collision type

Generally, a conflict occurs whenever data can not be synchronized during a synchronization operation (" change application failure "). This failure can occur for many reasons, but in general, conflicts can be divided into two categories: constraint conflicts and knowledge conflicts.

a) Knowledge-based conflict

Knowledge-based conflicts occur when replicators make independent changes to the same change unit. When two changes are made without knowledge of each other, they are called independent. In other words, the first version is not included by knowledge of the second version, and vice versa. The synchronization service automatically detects all such conflicts based on the knowledge of the replicators described above and handles such conflicts as described below. Some specific types of knowledge conflicts include update-delete, delete-update, and update-update conflicts (where each name implies local action and remote action in order. Due to local updates to the data and remote deletion).

Sometimes it is helpful to consider the conflict as a fork in the version history of the change unit. If no conflicts occur within the lifetime of the change unit, then the version history will be a simple chain (each change occurring after the previous change). In the case of a knowledge-based conflict, two changes occur in parallel, causing the chain to be split into a version tree.

In summary, knowledge conflicts arise as a result of knowledge and version processing. This is generated by WinFS synchronization when changes with conflicting versions of the information stored in the database are applied. Conflicts need to include version information as well as conflicting change information. Most of the requirements for knowledge conflicts are also a requirement for constraint conflicts. However, knowledge conflicts can be detected based only on the synchronous version and knowledge.

b) Constraint-based conflict

When independent changes are applied together, there are cases where the integration constraint is violated. For example, two replicas that generate a file with the same name in the same directory (in a situation where constraints within the system, such as enforcing unique item names within a folder) cause this type of constraint-based conflict , Such a collision can occur.

In general, constraint-based conflicts include two independent changes, as in knowledge-based conflicts. However, constraint-based conflicts do not affect the same change unit, but instead involve changes that affect different change units using constraints existing between them. Constraint-based conflicts can arise from a single change when synchronizing between two different types of systems, one with constraints and the other without. For example, if the system has a constraint that the maximum file name length is eight characters, and the system receives a change to a file from another system that does not have such a constraint, (For a file name whose name is longer than eight characters), resulting in a constraint conflict (resulting from a single change on a single machine).

Specific types of constraint conflicts include, but are not limited to:

? Insertion-insertion conflict: This occurs when two synchronization partners each create an object with the same logical identifier, such as a file with the same name.

? Parent-absent conflict: This happens when the parent of the incoming object to be created does not exist. An example is that a file is received before its parent folder.

? Non-uniform-type conflict: This happens when the schema of the incoming object is not installed, thus preventing the object from being created.

In summary, constraint conflicts are caused by failure to apply changes for a variety of reasons. Such a failure is called a constraint conflict if it can eventually be processed meaningfully in the form of a converging solution, or if it can be logged in the ultimate solution through user interaction. Failures that can not be handled more meaningfully than reported are simply referred to as change application errors. In a particular embodiment, all change application failures are treated as errors. That is, there is no recognized constraint conflict. And, in certain embodiments, when a knowledge collision is expected to be provided again at the next receive sync, all collisions that occur during transmit sync are ignored. Other failures resulting in non-convergence are also ignored.

2. Collision detection

The synchronization service detects constraint violations in the change application time and automatically generates constraint-based conflicts. Solving a constraint-based conflict usually requires an on-demand code that modifies the change in a way that does not violate the constraint, and the synchronization service may or may not provide a universal mechanism for doing so.

In various embodiments of the invention, the conflict is detected on a change-by-change basis by checking whether the local knowledge recognizes the remote version and vice versa. For knowledge-based collisions, here are four collision detection scenarios.

1. Local knowledge recognizing remote bans, remote knowledge not recognizing local versions: This means that the incoming changes are obsolete and are discarded.

2. Local knowledge recognizing the remote version, remote knowledge not recognizing the local version: This means that the incoming change is accepted more recently than the local version.

3. Local knowledge recognizing the remote version, remote knowledge not recognizing the local version: This can happen only if both are identical and the change is not applied.

4. Local knowledge that does not know the remote version, or remote knowledge that does not know the local version: This means that the local and remote versions conflict and conflict occurs.

3. Collision processing

Collisions may occur during transmit or receive synchronization. However, if the two partners are similar in performing a one-way synchronization (such as two similarly configured WinFS repositories), the scenario is symmetric and can synchronously resolve conflicts automatically or log conflicts for synchronous solutions So that it can be most easily processed on the receiving side.

Of course, there are situations in which a transmitting partner may need to handle conflicts, such as, for example, synchronization from WinFS to non-WinFS. In such a case, a non-moveable constraint conflict is returned from the subsequent receive sync to the transmit partner. Also, the receiving partner may not have an attendance log, or may not need the sender's conflict log for ease of management. In such a case, the changes may all be rejected together, causing the sender to resolve the conflict (described below).

The Sync Initiator configures the conflict resolution in its Sync Profile. The synchronization service supports combining multiple conflict handlers into a single profile. Since the conflict handling mechanism is extensible, there are several ways to combine multiple conflict handlers. One particular method involves specifying a list of conflict handlers to be associated in succession until one of them succeeds (as described below). Another method involves associating a conflict handler with a conflict type, such as, for example, sending update-update knowledge-based conflicts to a conflict handler, and sending all other conflicts to the log.

When a collision is detected, the synchronization service has three actions (selected by the synchronization initiator in the synchronization profile): (1) an action to reject the change; (2) an action that automatically resolves the conflict; Or (3) an action that logs the conflict to the conflict log.

a) Change refusal

If the change is rejected, the synchronization service acts as if the change did not reach the replicators, and sends back a negative acknowledgment to the sender. This resolution policy is primarily useful for headless replicas that do not allow logging conflicts (such as file servers). Instead, such replicators allow conflicts to be handled by others by rejecting them.

b) Automatic conflict resolution

Automatic conflict resolution is the process of synchronizing conflicts according to a specific policy. In the WinFS synchronization operation, the policy can be specified independently for the send operation and the receive operation. The automatic conflict resolution policy is specified through the synchronization profile. The resulting conflict is forwarded to the specified top-level conflict handler in the profile. The conflict handler can resolve the conflict, log it, or forward the conflict to another conflict handler for further processing along the conflict handling pipeline.

Figure 39A illustrates a conflict handling pipeline according to some embodiments of the present invention. In the figure, when a conflict occurs, the conflict handler list (or " list ") 3910 receives the conflict item 3902 and, in this case, the first handler 3912 on the first path of the pipeline, Handed. The filter 3912 is a gatekeeper that evaluates the conflict 3902 and sends the conflict back to the next handler 3914 or back to the list 3910 which lists 3912, To the first handler 3922 on the next path in the pipeline. If the collision 3902 is sent by the first filter 3912 to the second handler 3914, which in this case is the resolver, the collision is resolved by the solver 3914 if possible, If not, the conflict is again sent to the first handler 3912 and sent to the list 3910 and then to the resolver 3922 on the next path in the pipeline. The conflict may then be resolved by (a) one of the handlers in the pipeline, or (b) by a particular conflict handler known as a " logger " (C) log out of the pipeline again, and logically by collision log (logger 3944) as logarithm (by way of example) &Lt; / RTI &gt; through the pipeline.

Figure 39B is a flow chart illustrating the logical traversal of the pipeline shown in Figure 39A. 39B, and also in FIG. 39A, the conflict 3902 enters the pipeline in the conflict handler list 3910 (step 3950) and is first sent to the filter 3912 (step 3952). If conflict 3902 passes through this filter 3912 (step 3954), conflict 3902 proceeds to solver 3914 (step 3956) and solver 3914 attempts to resolve conflict 3902 (Step 3958). If successful, the process is returned (step 3998); Otherwise, the conflict proceeds to the solver 3922 (step 3960) and the solver 3922 attempts to resolve the conflict 3902 (step 3962). If successful, the process is returned (step 3998); Otherwise, the conflict proceeds to the list 3932 (step 3964), from there to the filter 3934 (step 3966), and if the conflict 3902 passes the filter 3934 (step 3968) 3902 are logged into the conflict log (not shown) by logger 3936 (step 3970) and the process is returned (step 3998); Otherwise the conflict 3902 is sent to the filter 3938 (step 3972), and if the conflict 3902 passes through this filter 3938 (3974), the conflict 3902 goes to the resolver 3940 ( Step 3976) and the solver 3940 attempts to resolve the conflict 3902 (step 3978). If successful, the process is returned (step 3998); Otherwise, the conflict proceeds to solver 3942 (step 3980) and solver 3942 attempts to resolve conflict 3902 (step 3982). If successful, the process is returned (step 3998); Otherwise, the conflict 3902 is logged into the conflict log (not shown) by the logger 3944 (step 3984) and the process is returned (step 3998).

Although not shown in Figures 39A and 39B, if a conflict can not be resolved by a solver, a path of successive conflict resolutions can also be constructed, and the unresolved conflict is sent to the next solver , The resolver attempts to resolve the conflict, and so on. If the collision remains unresolved, only at the end of one path, the collision is sent back to the list to reverse the path to the next. Likewise, if all the paths in a list have been used up and the collision has not been resolved, the list will traverse the path until the collision reaches the next list, pass the collision, and so on.

Also, the pipeline need not necessarily start from a list; Rather, it is important to know that it can start with some type of conflict handler, for example a filter. Regardless, however, if the conflict is reversed and sent to the first conflict handler in the pipeline, and the conflict handler does not have any more additional paths to try (but all paths are tried for the conflict handler list , Conflicts are logged out of the pipeline and automatically logged into the conflict log by default.

The ConflictHandler type is a conflict handler list, a basic type of conflict handler that includes conflict logs and conflict filters, and other types of conflict handlers. In addition, the synchronization service may also provide a number of default conflict handlers, including but not limited to:

? Local-wins: Data stored locally rather than incoming data

   resolving conflicts by selecting them as winners;

? Remote-wins: The incoming data, rather than the locally stored data,

   Resolving conflicts by selecting them as winners;

? Last-writer-wins: time of change unit

   Select local-win or remote-win per change unit based on stamp

   Services are generally not dependent on clock values; This conflict resolver

   Know that it is the only exception to the rule);

? Deterministic: The same guarantees for all replicas

   Choose a winner in a way that does not mean anything else - one of the motivational services

   Embodiments may use lexicographical comparisons of partner IDs to implement this feature.

   has exist.

For example, the conflict handler can specify that the local win-win resolution applies in case of update-delete conflicts and the final register win-win resolution applies for all other conflicts, as follows:

Of course, if no conflict handler is specified, or if the conflict is not handled by any particular conflict handler, the conflict is placed in the conflict log. In the case of some embodiments, the conflict log is also a conflict handler.

In various embodiments of the invention, ISVs may implement and implement their own conflict handlers. On-demand collision handlers can accept configuration parameters, although the configuration parameters should be specified by the SCA in the conflict resolution section of the Sync Profile.

When the conflict resolver processes the conflict, it returns to the runtime again and returns an action list that needs to be executed (instead of a conflicting change). The synchronization service then applies these operations to have the remote knowledge appropriately adjusted to include what the conflict handler considers.

It is possible for another conflict to be detected while applying the resolution. In such a case, the new conflict must be resolved or logged before the original processing is resumed.

When considering a conflict as a branch in the version history of an item, the conflict resolution can be viewed as joins joining two branches to form a single point. Therefore, conflict resolution converts version history to directed acyclic graphs (DAG).

c) Collision logging

While some reported conflicts can be resolved synchronously using automatic conflict resolution, others can be logged later as programmatic resolution. Collision logging allows the conflict resolution process to proceed asynchronously - that is, it can be logged for future resolution without needing to be resolved when a conflict is detected. For example, a conflict viewer application can allow a user to manually check for conflicts that are logged afterwards.

In some embodiments of the invention, a very special kind of crash handler is a crash logger (or more simply " logger "). The synchronization service logs conflicts in the conflict log as items of type ConflictRecord (or, alternatively, in the alternative embodiment, type Conflict). These records are again associated with the item in the conflict (if the item itself has not been deleted). In some embodiments, each conflict record may include a crash change; Type of conflict (e.g., update-update, update-delete, delete-update, insert-insert, or delete); And the version of the incoming change and the knowledge of the replicators that send it. In certain alternative embodiments of the invention, each such conflict item includes conflicting change data and metadata, conflict description, as well as change application information, incorporation data and other context information such as remote partner name. The change data is also stored in a format that can be used to apply the change. Moreover, in various embodiments of the present invention, each type derived from a conflict may add a new field associated with the conflict type. For example, the InsertInsertConflict type adds the item ID of the item that caused the uniqueness constraint to be violated.

In some embodiments of the invention, the conflict item to be logged may also be a copy of the target item, either as an extension of the conflict item, or merely as a separate item stored in the conflict log in a relationship defined between it and the conflict item itself, Alternatively, it may be included as part of the conflict item itself (such as a set of property-value pairs). This target item to be stored as part of the conflict item in the conflict log (maintained on the persistent data store) or with the conflict item will reflect the particular change that caused the conflict in the first location. 40 is a block diagram illustrating this method of using an exemplary contact item. In this example, the connection item 4002 (" target item ") includes a name field 4004 initially set to " John " This field 4004 is then changed locally to " Bob " by the local system. If, during subsequent synchronization, an attempt to change this same field 4004 to " Jane " results in a conflict because the local system can not figure out what name change "Bob" or "John" The change ("Bob") is maintained and the conflict 4006 is logged in the conflict log 4008 with a copy of the connection item 4002 'that reflects the application of the change ("Jane") that caused the conflict. In this way, the conflict log contains the completed target item that caused the conflict, and this particular target item is updated to reflect the attempted change to be made on the item that caused the conflict.

To add a conflict to the conflict log, the log is first searched to determine if there are other conflicts on the same change unit (s). If there are any existing conflicts on the same change unit, then the conflicts are probed to remove as much as possible. An existing conflict is removed if its change awareness is included by the change awareness of a new conflict. On the other hand, if the change awareness of a new conflict is included by the change awareness of the existing logged conflict, then the new conflict is ignored and vice versa (i.e., And it is useless if the recognition of the collision is included by the recognition of the storage). In the third case where neither of the two change perceptions contains anything else, a new conflict is added to the log, and two conflicts corresponding to the same change unit are in the log until later manually or automatically resolved.

d) Conflict inspection and resolution

The synchronization service provides APIs for applications to examine the conflict log and present conflict resolution within the conflict load. The API allows an application to enumerate all collisions, or collisions pertaining to a given item. It also allows such applications to resolve logged conflicts in one of three ways: (1) remote win-ins overrides conflicting local changes by accepting logged changes; (2) local win - the method of ignoring the conflict part of the logged change; And (3) suggesting a new change if the application proposes merging to resolve conflicts in its own mind. Once the conflict is resolved by the application, the synchronization service removes them from the log.

e) Convergence of replicas and delivery of conflict resolution

In a complex synchronization scenario, the same collision can be detected in multiple replicas. When this happens, several things can happen: (1) the collision can be resolved on one replicator and the solution can be sent elsewhere; (2) collisions automatically resolved on both replicas; Or (3) the conflict is resolved manually on the two replicas (via the conflict checking API).

To ensure convergence, the synchronization service sends conflict resolution to the other replicas. When a change resolving conflict reaches one replica, the synchronization service automatically finds and removes any conflict records in the log that are resolved by this update. In this regard, conflict resolution in one replica is binding on all other replicas.

If different winners are selected by different replicas for the same collision, the synchronization service applies the principle of binding conflict resolution and automatically selects a better solution than the other two solutions. The winner is chosen in a deterministic manner, which is guaranteed to always produce the same result (one embodiment uses the replica ID dictionary comparison).

If different "new changes" are proposed by different replicators for the same collision, the synchronization service will treat this new collision as a specific collision and use the collision logger so that it will not be forwarded to other replicas. Such situations usually result from manual passive resolution.

F. Additional aspects of synchronous schemas and conflict handling schemas

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

? Each replica has a defined synchronization of data from the entire data store

   It is a subset - some of the data have multiple instances.

? The root of the Sync Schema contains any filter or other for the particular replicator

   Whether or not elements are needed or required,

   A root folder with a unique ID that is an ID for the community (actually,

   There are replicas that have a basic type for defining an item.

? The " mapping " of each replica is maintained in the replica and, by itself,

   The mappings for the static replicas can be mapped to other replicas that such replicators know.

   Is limited. This mapping only includes a subset of the entire synchronous community

   , But the change to the replica (which may be a specific replica,

   I do not know any other replicators that I usually share with replicas of

   It is still common for the entire synchronous community to be shared via shared replicas

   Can be electrolyzed.

? Synchronous schemas, and the use of replicas are true distributed peer-to-

   It enables a tea master synchronous community. In addition,

   , The motivational community is merely a place within the community field of the replicator

   Lt; / RTI &gt;

? All replicas track incremental change enumerations,

   In order to store the state information of the other replicators,

   .

? A change unit has its own metadata, including the following:

   A version containing the partner key in addition to the serial number; For each change unit,

   Item / Extension / Relationship versioning; If the replica is synchronized

   Knowledge of the changes learned / received from the community; GUID and local ID clause

   castle; And GUIDs stored as reference relationships for cleanup.

The following are additional (or more specific) aspects of the conflict handling scheme for various embodiments of the invention.

? Conflict resolution policies are defined for each replica (and adapter / data source combination)

   That is, each replica has its own criterion and collision resolution

   The collision can be solved based on the key. In addition,

   Although instance differences can occur and result in additional future conflicts,

   The incremental and sequential enumeration of the conflicts reflected in the updated state information indicates that the update

   Lt; RTI ID = 0.0 &gt; status information. &Lt; / RTI &gt;

? The synchronous schema is not only a user / developer-defined order conflict handler,

   And includes a number of selected conflict handlers available to replicas. ski

   Ma also has three special "crash handlers": (a) different collisions in different ways

   Conflict "filter, that is, (i) the same change unit has changed in two places

   (Ii) the way in which one change unit is changed in one place, but the other

   , And (iii) a method in which two different change units

   A method for processing when having the same name in two different locations; (b) lease

   Each element of the tree is used to try each

   A conflict "handler list" that specifies a set of actions; And (c) do not track conflicts.

   Do-nothing "that does not take any further action without user intervention,

   nothing "log.

IV. Synchronization through intermediaries

With the initial use of the new storage platform described herein, an enterprise with a synchronous network of different individual computer systems may be able to utilize the existing storage platform while other individual computer systems continue to use the existing storage platform, while some individual computer systems use the new storage platform May have a mixing system. This is particularly important in certain client-server synchronization schemes where the two clients include a new storage platform but the server includes a conventional storage platform. Thus, in such an environment, two computer systems (" clients ") using a new storage platform may need to be synchronized via a computer system (" intermediary ") using a legacy storage platform. For example, some clients may be registered in an existing roaming service using software such as a folder orientation change of client side caching (CSC) or a roaming user profile (RUP). Because existing roaming software on these existing storage platforms does not support roaming data on new storage platforms, new roaming services for new storage platforms are needed. Various embodiments of the present invention may be implemented on a common storage platform (e. G., Via an intermediary that does not use the same common storage platform (e.g., using an existing storage platform that does not support synchronization of the new storage platform, , A new storage platform of the related invention).

A. Data structures for intermediaries

Some embodiments of the invention relate to a " Sync Through Intermediate " (STI) adapter that exists between and operates between a replica client and a non-replica mediator. In these embodiments, the STI adapter is designed to deserialize the results of these changes from the non-replica mediator to the replica client, as well as to serialize the result of the change enumeration from the replica client to the non-replica mediator .

41 is a block diagram illustrating a scenario in which two clients must synchronize through an intermediary; In the figure, the mediator computer system 4102 using an existing storage platform (e.g., Win32) has a new storage platform (e.g., for convenience, the associated inventions described herein, hereinafter referred to as " WinLH & This WinLH is connected to Client A 4112 and Client B 4114 using a WinFS file system, as shown here). Intermediary 4102 may be viewed as a " pass-through " for a synchronized change only from client A 4112 to client B 4114 and vice versa. As such, intermediary 4102 does not "self-synchronize" with client A 4112 or client B 4114 for itself, so intermediary 4102 can receive from client A 4112 or client B 4114 You do not use or change the data directly. For this reason, using the terminology used above, the replica client A 4112 or client B 4114 interacts with the intermediary 4102 as though the intermediary 4102 is a replica through the STI adapter, (4102) is not a replica.

The client A 4112 and the client B 4114 interface with the intermediary 4102 via the STI adapters 4122 and 4124 respectively and the STI adapter communicates with the new storage platform of the clients 4112 and 4114, It is specifically tailored to interface between special existing platforms. Some alternative embodiments of the present invention are directed to special STI adapters corresponding to some existing storage platforms where the intermediary may need to synchronize. This is because the clients 4112 and 4114 (via the STI adapters 4122 and 4144) communicate with the intermediary 4102, as if the intermediary is a real replica, although the STI adapter is an adapter specific to clients that successfully synchronize clients. And still be logically synchronized.

With respect to serializing the result of a change enumeration from a replicative client to a non-replicated mediator, each serialization corresponds to a batch of changes serialized into a file triplet to be written to the intermediary. In some embodiments, these files are written to a special folder (" community folder ") corresponding to a special synchronous community, and different synchronous communities may have different community folders. The above-described file triplet includes a change data file (CDF), a prerequisite knowledge file (PKF), and a learning knowledge file (LKF). The CDF contains information pertaining to special changes to the WinFS entry at the change unit level. The PKF specifies that the synchronization peer should be aware in advance to apply the relevant changes. On the other hand, the LKF specifies that the synchronization peer should learn when applying the relevant changes. For efficiency, as with peer-to-peer synchronization, the STI adapter only serializes the change unit information (the "changed portion" and its associated metadata) and, in some embodiments, The item type, the item version number, the change unit version, and the value of the changed property). In various embodiments, the file triplet is written to the intermediary using a sequential naming convention based on the message serialization order (for reasons described below); For example, the first serialization may include three files stored as 1.PKF (PKF file), 1.CDF (CDF file) and 1.LKF (LKF file) on the intermediary system, and the second serialization May include 2.PKF, 2.CDF and 2.LKF, and so on.

B. STI Adapter Process

In some embodiments of the invention, the STI adapter includes three core operations: transmit sync, receive sync, and data compression.

1. Transmit synchronization operation

42 is a flowchart showing a step ("transmission synchronization" operation) in which the client transmits change data to the intermediary via the STI adapter. At step 4202, the STI adapter first determines if the community folder exists on the intermediary corresponding to the client's synchronous community. If so, at step 4204, the STI adapter scans and deserializes all content of the LKF in the broker's community folder to confirm the current state of the broker's local knowledge (ILK) for that synchronous community. On the other hand, if there is no community folder, then in step 4206, ILK is considered null and a community folder is created on the intermediary.

At step 4208, the STI adapter sends a request to the community of the intermediary (via the intermediary's file system) to preserve data integrity by preventing other clients (or other peers or processes) from reading or writing to the community folder during the transmit synchronous operation &Quot; write mode " process locks on the folder at the same time. At step 4210, the STI adapter then communicates the ILK to the client. Based on the ILK and its client local knowledge (CLK), at step 4212, the client determines if there are any changes that are not covered by the ILK, and if not, the process skips to step 4220. On the other hand, if the client determines that there are uncovered changes by the ILK, then in step 4214 the client passes the enumerated changes not covered by the ILK and passes it to the STI adapter. At step 4216, the STI adapter serializes each batch of change information (change data and knowledge), and at step 4218, the STI adapter then writes the serialized change batches sequentially Fill in the mediator's community folder as an incremental file triplet. Once all serialized change batches have been written to the broker, at step 4220, the STI adapter releases the &quot; write mode &quot; process lock so that another client (or other peer or process) can examine the updated content on the broker Let's do it.

It should be noted that although the transmit synchronous operation has been completed, the STI adapter stores the identifier (or reference number) of the last highest incremental change triplet (HCT) written to the intermediary for future reference. It should also be noted that no conflict processing is performed as part of the transmit synchronization operation. Finally, in a peer-to-peer embodiment in which the client just "pulls" data (thus, the client fails to initiate a transmit synchronous operation), the intermediary does not have the capability to initiate its transmit synchronous operation by itself , Then the STI adapter may voluntarily start with a transmit synchronous action instead of the intermediary.

2. Receive synchronous operation

In the case of synchronization in the other direction, Fig. 43 is a flowchart showing the step ("reception synchronization" operation) in which the client receives change data from the intermediary via the STI adapter. In step 4302, the STI adapter first receives, in some embodiments of the invention, a client local knowledge (CLK) that occurs when a client sends a synchronization request to an intermediary via an STI adapter, Lt; RTI ID = 0.0 &gt; CLK &lt; / RTI &gt; according to a peer-to-peer synchronization scheme. At step 4304, the STI adapter then stores data integrity (such as by preventing other clients (or other peers or processes) from writing to the community folder during the receive sync operation period (Via the intermediary's file system) acquires &quot; read mode &quot; process locks on the intermediary's community folder. In some embodiments, this &quot; read mode &quot; may be optimized to lock each triplet rather than the entire directory for better concurrency.

At step 4306, with respect to the HCT stored by the STI adapter to that intermediary (which may be generated, for example, by the transmit synchronous operation described above), the STI adapter may use the next higher change triplet: (a) (B) the CLK (client local knowledge) is higher than the required knowledge (from the PKF) for that change triplet, and (c) the CLK is lower than the learning knowledge (from the LKF) for the change triplet , And scans the community folder on the mediator to find the change triplet. (Such a change triplet is referred to herein as the "applicable change triplet" or "ACT (applicable change triplet)".) At step 4308, if such a change triplet ACT exists, at step 4310, Deserializes the contents of the change triplet ACT to a replica-understandable enumerated change, and, in step 4312, sends the change to the client for processing. The process then returns to step 4306 for the next ACT and continues the process until there is nothing left and when the STI adapter unlocks the read mode at step 4314, And is terminated.

3. Intermediary file data compression (compression / compaction)

In various embodiments of the present invention, it is necessary to compress the serialization data and the knowledge file created by the STI adapter in a frame-wise manner; Otherwise, an ever increasing number of change triplets will fill all available storage space on the intermediary. In this regard, the purpose of data compression is to ensure that the growth of data and knowledge files is adequately limited on the intermediary. One method used by some embodiments of the invention is to set an " upper threshold " with respect to the number of change packets allowed to exist on the shared file system, and once that threshold is exceeded, The STI adapter is required to compress the shared file system (files in the community folder) on the intermediary through compression operations. The compression operation is performed by (a) compressing the history of changes to individually existing objects, (b) removing the change broadcasts to the deleted objects (either explicitly through conflict resolution or as a result of tombstone cleanup) Thereby reducing the amount of data stored in the shared file system. However, compression is only performed by the STI adapter for clients that can only execute receive motions and can immediately execute a " full " transmit sync (i.e., full change enumeration with zero baseline as if there were no community folders on the broker) . Therefore, the compression can not be executed by the client which carries out only the transmission synchronization with the intermediary or only the reception synchronization.

44 is a flowchart showing a step ("compression" operation) in which an STI adapter (that is, an STI adapter associated with a client capable of both transmission and reception synchronization) executes a compression operation on data in a community folder on the intermediary to be. In the figure, immediately after a successful receive sync operation for the client of the STI adapter in step 4202 (i.e., immediately after step 4312 in Figure 43) and before step 4314 )), At step 4404, the STI adapter checks the community folder on the intermediary to see if the upper threshold has been exceeded; If not, the process is terminated (and the receive synchronization process is terminated, such as by releasing the lock). If, however, the upper threshold has been exceeded, then at step 4406, the STI adapter deletes all change triplet files in the broker's community folder, and then at step 4408, the STI adapter sends the broker's knowledge to the client, (Including write mode process lock) between the client and the intermediary by indicating that the state (which, after deletion, is actually the case). As a result, only a minimal set of triplet files corresponding to the overall state of the client is uploaded to the intermediary and is present on the intermediary.

In these embodiments where the " read mode " is optimized to lock each triplet rather than the entire directory for better concurrency, and other alternative embodiments of the present invention using the standard " (Step 4304 of FIG. 43) before obtaining a " read mode " process lock on the broker's community folder (via the intermediary's file system), the STI adapter checks to see if compression is required, (Non-optimized) " read mode &quot; to preserve data integrity by preventing other clients (or other peers or processes) from writing to the community folder during the receive synchronous action period "Is slightly different.

In some alternative embodiments, the data on the intermediary may be updated after the client has uploaded all the change triplets by overwriting the existing change triplets, starting from the first one, and if all the change triplets have been uploaded (and if the existing ones have been rewritten ), Until all remaining change triplets of a higher sequence number than the last one uploaded during the full read operation are deleted.

Finally, some alternative embodiments also begin to compress after the complete read sync operation is completed (including the read mode process lock). In such an embodiment, the process continues from the acquisition of the write mode process lock and then continues all the above steps.

C. Support for STI and down-level clients

In addition to the above, some additional embodiments of the invention relate to a modification of the synchronization technique through the intermediary described above. Certain embodiments relate to a system further comprising a " legacy client ", which is also executing an existing storage platform that also has access to all data files. It is also anticipated that some existing clients and other applications and processes may access these data files for other uses. For example, there is a case of a legacy client that synchronizes files based on creation data or some other unique file characteristic. Another example is an existing client that directly accesses and copies any or all files (e.g., a * .CDK files). A legacy client can be viewed as a second intermediary that communicates directly with the first intermediary (perhaps using legacy synchronization technology) from the same perspective, and thus is multi-agent synchronous enabled and initiated thereby.

V. Conclusion

As described above, the present invention relates to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and broadens the concept of data storage beyond existing file systems and database systems and can be structured, unstructured, or distributed, such as relationship data, XML, and new types of data, It is designed to be a storage for all types of data, including semi-structured data. Through a common storage base of the storage platform and organized data, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It provides a rich and scalable application programming interface that not only makes the data model's own capabilities available, but also accommodates and extends existing file system and database access methods. It is understood that modifications may be made to the embodiments described above without departing from the broad inventive concept. Accordingly, the invention is not intended to be limited to the particular embodiments disclosed, but is to be accorded the widest scope consistent with the spirit and scope of the invention as defined by the appended claims.

As will become apparent from the foregoing, all, or some, of the various systems, methods and embodiments of the present invention may be embodied in the form of program code (i.e., instructions). The program code may include, but is not limited to, a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine- ), A magnetic, electrical or optical storage medium, where the program code is loaded into and executed by a machine, such as a computer or a server, To be carried out. The invention may also be embodied in the form of program code that is transmitted over a given transmission medium, such as via an electrical wire or cable, through an optical fiber, through a network including the Internet or an intranet, When the program code is received and loaded into a machine such as a computer and executed by the machine, the machine becomes an apparatus embodying the present invention. When implemented on a general purpose processor, the program code combines with the processor to provide a unique device that operates similarly to a particular logic circuit.

Claims (44)

CLAIMS What is claimed is: 1. A method for synchronizing client computer systems via an intermediary computer system, Providing a first and a second client computer system, each of the first and second client computer systems utilizing a first storage platform; Providing an intermediary computer system, the intermediary computer system utilizing a second storage platform different from the first storage platform and having no support for synchronization to the first storage platform; Providing a synchronization adapter to each of the client computer systems for connecting the respective client computer systems to the intermediary computer system; Serializing, by the synchronization adapter of the first client computer system, a change enumeration for the first client computer system to a file stored on the intermediary computer system; And Synchronizing the second client computer system with the first client computer system using the file stored on the intermediary computer system by the synchronization adapter of the second client computer system / RTI &gt; The method according to claim 1, Wherein the synchronization between the client computer systems is used to support a data-sharing operation. The method according to claim 1, Wherein the synchronization between the client computer systems is used to support end-user roaming. The method according to claim 1, Wherein the first storage platform is an item-based storage platform. delete A system for synchronizing client computer systems via an intermediary computer system, First and second client computer systems each having a microprocessor and memory, each of said first and second client computer systems utilizing a first storage platform; And An intermediary computer system having a microprocessor and a memory, the intermediary computer system utilizing a second storage platform different from the first storage platform and having no support for synchronization to the first storage platform, Lt; / RTI &gt; Wherein each client computer system comprises synchronization means for connecting the intermediary computer system to each of the client computer systems, Wherein the synchronization means of the first client computer system serializes a change enumeration for the first client computer system to a file stored on the intermediary computer system, Wherein the synchronization means of the second client computer system synchronizes the second client computer system with the first client computer system using the file stored on the intermediary computer system. The method according to claim 6, Wherein the synchronization between the client computer systems is used to support a data-sharing operation. The method according to claim 6, Wherein the synchronization between the client computer systems is utilized to support end-user roaming. The method according to claim 6, Wherein the first storage platform is an item-based storage platform. delete A hardware control device for synchronizing client computer systems through an intermediary computer system, each of the client computer systems utilizing a first storage platform, the intermediary computer system being different from the first storage platform and synchronizing Lt; RTI ID = 0.0 &gt; a &lt; / RTI &gt; second storage platform, Connect a client computer system of one of the client computer systems to the intermediary computer system; Serialize the change enumeration for the one client computer system to a file stored on the intermediary computer system; Means for synchronizing the one client computer system with another client computer system using serialized change enumeration for another client computer system of the client computer systems stored on the intermediary computer system; &Lt; / RTI &gt; 12. The method of claim 11, Wherein the synchronization between the client computer systems is utilized to support a data-sharing operation. 12. The method of claim 11, Wherein the synchronization between the client computer systems is utilized to support end-user roaming. 12. The method of claim 11, Wherein the first storage platform is an item-based storage platform. A computer-readable medium having computer-executable instructions for synchronizing at least client computer systems through an intermediary computer system, The computer- Providing a first and a second client computer system, each of the first and second client computer systems utilizing a first storage platform; Providing an intermediary computer system, the intermediary computer system utilizing a second storage platform different from the first storage platform and having no support for synchronization to the first storage platform; Providing a synchronization adapter to each of the client computer systems for connecting the respective client computer systems to the intermediary computer system; Serializing, by the synchronization adapter of the first client computer system, a change enumeration for the first client computer system to a file stored on the intermediary computer system; And Synchronizing the second client computer system with the first client computer system using the file stored on the intermediary computer system by the synchronization adapter of the second client computer system The computer program product comprising: a computer readable medium; delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images