CN1871598A - System and method for extension and inheritance of information units manageable by a hardware/software interface system - Google Patents

Abstract

By modeling real-world application objects with complex structures, behaviors, and operations described by the schema implemented by the hardware/software interface system, various embodiments of the present invention provide rich subtyping functionality by extending items (and item types) using "extensions" that provide additional data structures (properties, relationships, etc.) to already existing item type structures. Extensions are strongly typed instances that cannot exist independently of and must be attached to an item or nested element. Extensions also address the "multi-typing" problem by allowing overlapping of type instances (e.g., a document may be a "legal document," or may be a "secure document").

Description

System and method for extension and inheritance of information units manageable by a hardware/software interface system

Cross References to Related Applications

This application claims priority to the following patent application: U.S. Patent Application Serial No. 10/693,574 (Attorney Docket MSFT-2847), filed October 24, 2003, and entitled "SYSTEMS AND METHODS FOREXTENSIONS AND INHEITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE /SOFTWARE INTERFACE SYSTEM (System and Method for Extension and Inheritance of Information Units Manageable by a Hardware/Software Interface System)"; U.S. Patent Application No. 10/646,580, filed August 21, 2003 (Attorney Docket No. MSFT-2735 ), entitled "SYSTEMSAND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGEPLATFORM"; and International Application No. PCT/ US 03/26144 (Attorney Docket No. MSFT-2779), entitled "SYSTEM AND METHODS FOR DATA MODELING IN AN ITEM-BASEDSTORAGE PLATFORM"; by reference Include their content here.

This application is related in subject matter to the invention disclosed in the following generally designated application, the contents of which are hereby incorporated by reference in their entirety (and partially summarized here for convenience): Filed August 21, 2003 U.S. Patent Application No. 10/647,058 (Attorney Docket No. MSFT-1748), entitled "SYSTEMSAND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUTINDEPENDENT OF PHYSICAL REPRESENTATION" UNITS OF INFORMATION MANAGEABLE BY AHARDWARE, U.S. Patent Application No. 10/646,941, filed Aug. 21, 2003 (Attorney Docket MSFT-1749), entitled "SYSTEMS ANDMETHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY AHARDWARE /SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICALORGANIZATION (System and Method for Separating Information Units Manageable by a Hardware/Software Interface System by Their Physical Organization)"; U.S. Patent Application No. 10/646,940, filed August 21, 2003 (Attorney General Docket No. MSFT-1750), entitled "SYSTEMS AND METHODS FOR THEIMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING FOR UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM Systems and Methods)"; U.S. Patent Application No. 10/646,632, filed August 21, 2003 (Attorney Docket MSFT-1751), entitled "SYSTEMS AND METHODS FOR THE IMPLEMATION OF ACORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FORORGANIZING UNITS OF INFORMATION MANAGEABLE BY AHARDWARE/SOFTWARE INTERFACE SYSTEM (system and method for implementing a core schema that provides a top-level structure for organizing information units that can be managed by a hardware/software interface system)"; U.S. Patent Application filed August 21, 2003 No. 10/646,645 (Attorney Docket No. MSFT-1752), entitled "SYSTEMSAND METHODS FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM and methods)"; U.S. Patent Application No. 10/646,575 (Attorney Docket MSFT-2733), filed August 21, 2003, and entitled "SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM (for making application System and Method for Programmatically Interfacing Item-Based Storage Platforms)"; U.S. Patent Application Serial No. 10/646,646 (Attorney Docket MSFT-2734), filed August 21, 2003, and entitled "STORAGE PLATFORM FORORGANIZING, SEARCHING, AND SHARING DATA (Storage Platform for Organizing, Searching, and Sharing Data)"; U.S. Patent Application Serial No. 10/692,779, filed August 21, 2003 (Attorney Docket MSFT-2829), entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM (System and Method for Implementing a Digital Image Schema for Organizing Information Units Manageable by a Hardware/Software Interface System)"; U.S. Patent Application filed August 21, 2003 No. 10/692,515 (Attorney Docket No. MSFT-2844), entitled "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM SYSTEM AND METHOD FOR PROVIDING RELATIONAL ANDHIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/ SOFTWARE INTERFACE SYSTEM (System and Method for Providing Relational and Hierarchical Synchronization Services for Information Units Manageable by a Hardware/Software Interface System)"; and U.S. Patent Application No. 10/693,362, filed October 24, 2003 ( Attorney Docket No. MSFT-2846), entitled "SYSTEMS AND METHODS FOR THEIMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM method)".

technical field

The present invention relates generally to the field of information storage and retrieval, and more particularly to a storage platform for organizing, searching and sharing activities of different types of data in a computerized system. Various embodiments of the invention are directed to using the extension and inheritance methods used by the hardware/software interface system to manage data.

background

During the last ten years, the capacity of a single disk has increased by approximately seventy percent (70%) per year. Moore's Law has accurately predicted the incredible growth in central processing unit (CPU) power over the past few years. Wired and wireless technologies have provided massive amounts of connectivity and bandwidth. Assuming current trends continue, within a few years the typical laptop computer will have about a terabyte (TB) of storage and contain millions of files, with 500 gigabyte (500GB) drives becoming common.

Consumers use their computers primarily to communicate and organize personal information, whether they be traditional Personal Information Manager (PIM) style data or media such as digital music or photos. The volume of digital content and the ability to store raw bytes has grown enormously; however, the methods available to consumers to organize and unify this data have not kept pace. Knowledge workers spend a significant amount of time managing and sharing information, with some studies estimating that knowledge workers spend 15-25% of their time on activities related to invalid information. Another study estimates that the typical knowledge worker spends approximately 2.5 hours per day searching for information.

Developers and information technology (IT) departments invest significant time and money building their own data stores for utility storage abstractions to represent things like people, places, times, and events. Not only does this result in duplication of effort, but it also creates silos of common data, with no mechanism for collectively searching or sharing that data. Just consider how many address books there are on computers running the Microsoft Windows operating system today. Many applications, such as email clients and personal finance programs, maintain their own address books, and there is little sharing between the address book applications that each such program maintains separately. Thus, financial programs such as Microsoft Money do not share payer addresses with addresses maintained in email contact folders such as those in Microsoft Outlook. Indeed, many users have multiple devices between which their personal data should be logically synchronized and between various additional sources including mobile phone numbers to commercial services such as MSN and AOL; however collaboration on shared documents Most do so by attaching documents to email messages—which is manual and inefficient.

One reason for the lack of collaboration is that traditional approaches to organizing information in computer systems have focused on using a file-folder-directory-based system ("file system") to divide more files organized into a directory hierarchy of folders. The Multics operating system, developed in the 1960s, is considered a pioneer in the use of files, folders, and directories to manage storable data units at the operating system level. Specifically, Multics uses symbolic addresses in the hierarchical structure of files (thus introducing the concept of file paths), where the physical address of a file is opaque to users (applications and end users). This file system takes no account of the file format of any individual file at all, and the relationships within and between files are considered independent at the operating system level (ie, distinct from the location of the files in the hierarchy). Thanks to Multics, storable data at the operating system level is organized into files, folders, and directories. These files typically include the file hierarchy itself ("directory") placed within a specific file maintained by the file system. This directory in turn maintains a list of items corresponding to all other files in the directory and the node positions of those files in the hierarchy (here referred to as folders). This has been the state of the art for nearly 40 years.

However, while providing a reasonable representation of information residing in a computer's physical storage system, the file system is an abstraction of the physical storage system, and thus utilization of a file requires the user to process what (with context, characteristics, and relationships to other units) A layer of indirection (interpretation) between what the operating system provides (files, folders, and directories). As a result, users (applications and/or end users) have to force information units into file system structures, even if doing so is inefficient, inconsistent, or undesirable. Furthermore, existing file systems know very little about the structure of the data stored in individual files, and thus, most information remains closed within the files, only accessible (and understandable) by the applications that wrote those data. Consequently, the lack of a schema description of information and a mechanism to manage it leads to the formation of data silos, with little data shared across silos. For example, many personal computer (PC) users have more than five disparate stores that contain information about the people they interact with at some level—such as Outlook contacts, online account addresses, Windows address book, Quicken payees and Instant Messaging (IM) buddy lists—because organizing files presents important challenges to these PC users. Since most existing file systems utilize a nested folder metaphor to organize files and folders, the effort necessary to maintain a flexible and efficient organizational model becomes overwhelming as the number of files increases. In these cases, having multiple catalogs for a single file is very useful; however using hard and soft links in existing file systems is cumbersome and difficult to maintain.

Several unsuccessful attempts have been made in the past to overcome the shortcomings of file systems. Some of these previous attempts have involved the use of content-addressable memory to provide mechanisms by which data can be accessed by content rather than by physical address. However, these efforts proved unsuccessful, and while content-addressable memory proved useful for small-scale use by devices such as cache memory and memory management units, it was not effective for large-scale Using is not yet possible for various reasons, so a solution like that simply doesn't exist. Other attempts have been made using object-oriented database (OODB) systems, but these attempts, while strongly database-like, and good non-file representations, are not efficient at handling file representations and cannot be reproduced on hardware/ Speed, efficiency, and simplicity of software interfaces to hierarchically structured files and folders at the system level. Other attempts, such as the attempt to use SmallTalk (and other derivatives), proved to be quite effective in dealing with file and non-file representations, but lacked the database features necessary to effectively organize and exploit the relationships that existed between the various data files, so The overall effectiveness of that system is unacceptable. Yet another attempt to use BeOS (and others such as Operating System Research), while capable of adequately representing files while providing some of the necessary database features, proved inadequate in dealing with non-file representations, which are traditional file The same core shortcomings of the system.

Database technology is another area of expertise that presents similar challenges. For example, although the relational database model has achieved great commercial success, in practice Independent Software Vendors (ISVs) typically utilize a small fraction of the functionality available in relational database software products such as Microsoft SQL Server. Instead, most of an application's interaction with such a product is in the form of simple "gets" and "puts". While there are several obvious reasons for this (such as being platform or database agnostic), a key reason that is often overlooked is that databases do not necessarily provide the precise abstraction that major business application distributors really need. For example, while the real world has concepts of "items" like "customers" or "orders" (and orders' embedded "row items" as items within them and the items themselves), relational databases only aspect to discuss. As a result, while applications may wish to have aspects of consistency, locking, security, and/or triggers at the item level (to name a few), typically databases only provide these features at the table/row level. While it would work fine if each item mapped to a single row of a table in the database, in the case of orders with multiple row items, there is a reason for an item to actually map to multiple tables, and In this case, a single relational database system cannot exactly provide the correct abstraction. Therefore, applications must build logic on top of the database to provide these basic abstractions. In other words, the basic relational model does not provide a sufficient platform for storing data on which advanced applications are easily developed, because the basic relational model requires a layer of indirection between the application and the storage system, which is only possible in certain cases of the application See the semantic structure of the data. Although some database vendors are building advanced functionality into their products (such as providing object-relational capabilities, new organizational models, etc.), none have yet provided the comprehensive solution needed, and where a truly comprehensive solution is useful for The domain abstractions (such as "person", "location", "event", etc.) provide solutions for useful data model abstractions (such as "item", "extension", "relationship", etc.).

In view of the aforementioned shortcomings in existing data storage and database technologies, there is a need for a new storage platform that provides an improved ability to organize, search, and share all types of data in computer systems—a storage platform that It extends and augments the data platform beyond existing file systems and database systems, and is designed to store all types of data. The present invention, and related inventions previously incorporated herein by reference, fulfill this need. In particular, the present invention provides methods for extension and inheritance of objects handled by the hardware/software interface system.

overview

The following summary provides a summary of various aspects of the invention described in the context of a related invention previously incorporated by reference ("the related invention"). This summary is not intended to provide an exhaustive description of all important aspects of the invention, nor to delineate the scope of the invention. Rather, this summary is intended as an introduction to the detailed description and drawings that follow.

Related inventions collectively relate to storage platforms for organizing, searching, and sharing data that expand and expand the concept of data storage beyond existing file systems and database systems. This storage platform is designed to store all types of data, including structured, unstructured, or semi-structured data.

The storage platform includes data storage implemented on a database engine. The database engine includes a relational database engine with object-related extensions. The data store implements a data model that supports organization, search, sharing, synchronization and security of data. Concrete types of data are declared in various schemas, and the platform provides a mechanism that extends the schema's settings in order to define new data types (mainly, subtypes of the base types provided by said schema) . A synchronization feature helps to share data between users or systems. Filesystem-like functionality is provided that allows interoperability of the data store with existing filesystems without the limitations of such traditional filesystems. A change tracking mechanism provides the ability to track changes to the data store. The storage platform also includes a set of application program interfaces, which enable applications to access all the above-mentioned functions of the storage platform, and to access data declared in schemas.

The data model implemented by the data store defines the units of the data store in terms of items, elements and relationships. An item is a unit of data that is storable in a data store and can include one or more elements and relationships. An element is an instance of a type that includes one or more fields (also referred to here as attributes). A relationship is a connection between two items. (As used herein, these and other specific terms may be capitalized to separate them from other terms used nearby, however, no distinction is made between capitalized terms such as "Item" and non-capitalized terms same term, such as "item", and no such distinction should be assumed or implied.)

The computer system also includes a plurality of items, each of which includes a discrete storable unit of information operable by a hardware/software interface system; a plurality of item folders forming an organizational structure for the items; and A hardware/software interface system that operates a plurality of projects, and wherein each project belongs to at least one project folder, and may belong to more than one project folder.

As opposed to exporting from persistent storage, items or some item property values can be dynamically calculated. In other words, the hardware/software interface system does not require items to be stored, and supports certain operations, such as functions to enumerate the current settings of an item, or to give an identifier for an item on a storage platform (described in the API or API section is described more fully) and the ability to retrieve items—for example, an item could be the current location of a cell phone, or the temperature read from a temperature sensor. The hardware/software interface system can handle multiple items, and can also include multiple relationally interconnected items manageable by the hardware/software interface system.

The hardware/software interface system for the computer system also includes a kernel schema to define a set of kernel items that said hardware/software interface system understands and can directly process in a predetermined and predictable manner. In order to handle multiple items, the computer system interconnects items with multiple relationships and manages the relationships at the hardware/software interface system level.

The storage platform's API provides data classes for each item, item extension, and relationship defined in the storage platform schema group. In addition, the application programming interface provides a set of framework classes that define a set of common behaviors for the data classes and, together with the data classes, provide the basic programming model for the storage platform API. The storage platform API provides a simplified query model that enables application programmers to formulate queries based on various attributes of items in the data store in a manner that isolates the application programmer from the details of the query language of the underlying database engine . The storage platform API also collects changes made to items by applications and then organizes them into the correct updates required by the database engine (or any kind of storage engine) implementing the data store. This enables application programmers to make changes to items in memory, while leaving the complex details of data store updates to the API.

Through its common storage base and schematized data, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It provides a rich and extensible application programming interface that not only makes available the functionality inherent in its data model, but also includes and extends existing file system and database access methods.

In view of the overall structure of the related invention (described in detail in Section II of the Detailed Description), the present invention is specifically directed to the use of extensions to extend the functionality of item and attribute types, and the use of inheritance to facilitate communication between related items Efficient search and organization of (detailed in Section III of the detailed description). Other other features and advantages of the present invention will become apparent from the following detailed description of the invention and accompanying drawings.

Brief description of the drawings

The foregoing Summary, together with the following Detailed Description of the Invention, may be better understood when read in conjunction with the accompanying drawings. For purposes of illustrating the invention, exemplary embodiments of various aspects of the invention are shown in the drawings; however, the invention is not limited to the precise methods and instrumentalities disclosed. In the attached picture:

Figure 1 is a block diagram representing a computer system in which aspects of the present invention may be incorporated;

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

Figure 2A shows a conventional tree-based hierarchical structure for files grouped into folders within directories in a file-based operating system;

Figure 3 is a block diagram illustrating a storage platform;

Figure 4 shows the structured relationship between projects, project folders and categories;

FIG. 5A is a block diagram showing the structure of a project;

Figure 5B is a block diagram illustrating complex attribute types for the item of Figure 5A;

Fig. 5C is a block diagram showing a "Location (position)" item, wherein the complex type of the "Location" item is further specified (explicitly listed);

Figure 6A shows an item that is a subtype of an item in the base schema;

Fig. 6B is a block diagram showing the subtype item of Fig. 6A, which explicitly lists its inherited types (in addition to its immediate attributes);

Figure 7 is a block diagram showing the base schema, including its two top-level class types, the item and attribute bases, and the additional base schema types derived therefrom;

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

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

Fig. 9 is a block diagram showing a project folder, its member projects and the interconnection relationship between the project folder and its member projects;

Fig. 10 is a block diagram showing a category (which itself is also an item), its member items, and the interconnection relationship between the category and its member items;

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

Figure 12 is a diagram showing how relationships are classified;

FIG. 13 is a diagram illustrating a notification mechanism;

Figure 14 is a diagram showing an example, where both transactions insert new records into the same B-tree;

Figure 15 shows a data change detection process;

Figure 16 shows an exemplary directory tree;

Figure 17 shows an example where folders of an existing directory-based file system are moved into said storage platform data store;

Figure 18 shows the concept of holding folders;

Figure 19 shows the basic architecture of the storage platform API;

Figure 20 schematically represents the various components of the storage platform API stack;

Figure 21A is a graphical representation of an example contact item schema;

Figure 21B is a graphical representation of elements of the example Contact Items schema of Figure 21A;

Figure 22 shows the runtime framework of the storage platform API;

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

Figure 24 shows the process by which the storage platform API classes are generated from the storage platform schema;

Figure 25 shows such a schema, on which the File (File) API is based;

Figure 26 is a schematic diagram showing the format of an access mask for data security purposes;

Figure 27 (parts a, b, c) shows a new identically protected security area divided from the existing security area;

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

FIG. 29 is a schematic diagram illustrating an example project hierarchy;

Figure 30A shows the interface "Interface 1" as the conduit through which the first and second encoding segments communicate;

Fig. 30B shows an interface, this interface comprises interface object I1 and I2, and it enables the first and second coding segment of the system to communicate through the medium M;

Figure 31A shows how the functionality provided by the interface "Interface 1" can be divided so that the communication of the interface is converted to a plurality of interfaces "Interface 1A", "Interface 1B", "Interface 1C";

Figure 31B shows how the functionality provided by I1 can be divided into multiple interfaces I1A, I1B, I1C;

Figure 32A shows a situation where the meaningless parameter precision can be ignored or replaced with an arbitrary parameter;

Figure 32B shows a situation where an interface is replaced by a substitute interface specified for ignoring or adding parameters to the interface;

Figure 33A shows a situation where the first and second encoded segments are merged into a module containing both of them;

Figure 33B illustrates a situation where part or all of an interface can be embedded written into another interface to form a merged interface;

Figure 34A shows how one or more blocks of an intermediary device can transform communications on a first interface so that they conform to one or more different interfaces;

Figure 34B shows how coded segments can be introduced with interfaces to receive communications from one interface and transfer said functionality to a second and third interface;

Figure 35A shows how a just-in-time compiler (JIT) can convert communications from one code segment to another;

Figure 35B shows a JIT method for dynamically rewriting one or more interfaces, which can be applied to dynamically factor or otherwise change the interfaces;

Figure 36 shows a subset of a series of related items and their relationships;

Figure 37A illustrates the disadvantages of standard subclassing of items for application-specific purposes;

Figure 37B shows a partial solution to the standard subclassing problem; and

Figure 37C shows an embodiment of the invention that extends an item with an extension that is different from and independent of the contact itself, thus allowing multi-type functionality.

A detailed description

Table of contents

I. Introduction ................................................................................................... 14

A. Exemplary Computing Environment  ……………………………………… 14

B. Traditional File-Based Storage ................................................................... 17

II. The WINFS Storage Platform for Organizing, Searching, and Sharing Data ... 18

C. Glossary……………………………………………………… 18

D. Overview of Storage Platforms……………………………………… 18

E. Data model ................................................................................................... 20

1. Project…………………………………………………………… 21

2. Project identification ………………………………………………… 23

3. Project folders and categories  …………………………………… 24

4. Mode………………………………………………………… 26

a) Basic mode.................................................................................................... 26

b) Kernel mode................................................................................................... 26

5. Relationships………………………………………………………… 28

a) Statement of relationship ................................................................................................... 28

b) hold a relationship ................................................................................... 29

c) Embedded relationship..................................................................................................... 30

d) Citation relationship..................................................................................... 31

e) Rules and Constraints ................................................................... 32

f) Sorting of relationships.................................................................................................... 32

6. Scalability………………………………………………36

a) Project Expansion ................................................................................... 37

b) Extended NestedElement type ………………………… 40

F. Database Engine………………………………………………41

1. Implementation of data storage using UDT ……………………………42

2. Project Mapping……………………………………………42

3. Extended Mapping………………………………………………43

4. Nested element mapping  ………………………………… 44

5. Object identity...................................................................................................44

6. Naming of SQL objects ………………………………………44

7. Column Naming ................................................................................... 45

8. Search view...................................................................................................45

a) Project………………………………………………46

(1) Main project search view  …………………………………46

(2) Type-by-type project search view... 46

b) Project expansion ……………………………………………47

(1) Main Extended Search View  ………………………………… 47

(2) Expanded search view by type... 47

c) Nested elements …………………………………………48

d) Relationship ………………………………………………………48

(1) Main relational search view  ……………………………… 48

(2) Relational instance search view... 48

e) ……………………………………………………………49

9. Update ………………………………………………………… 49

10. Change Tracking and Tombstones... 50

a) Change Tracking …………………………………………… 50

(1) Change Tracking in the “Main” Search View  …………………… 50

(2) Change Tracking in "Categorized" Search Views 51

b) Tombstone ………………………………………………… 52

(1) Tombstone of the project ……………………………………………52

(2) Extended Tombstone ………………………………………… 52

(3) Tombstone of relationship ………………………………………… 53

(4) Tombstone removal ………………………………………… 53

11. Helper API and functions ……………………………………… 54

a) Function [System.Storage].GetItem ………………………54

b) Function [System.Storage].GetExtension…………………54

c) Function [System.Storage].GetRelationship ………………54

12. Metadata …………………………………………………… 54

a) Schema Metadata ................................................................................... 54

b) Instance metadata ……………………………………… 54

G. Security ………………………………………………… 54

H. Notifications and Change Tracking  …………………………………… 55

I. Synchronization …………………………………………………… 55

1. Synchronization from storage platform to storage platform …………………………56

a) Synchronization (Sync) control application program .................................................................... 56

b) Schema Comments  ……………………………………… 57

c) Synchronous configuration ................................................................................... 58

(1) Community Folder—Mapping………………………………58

(2) Overview…………………………………………………59

(3) Schedule …………………………………………… 60

d) Conflict handling ................................................................................................... 60

(1) Conflict detection ………………………………………60

(a) Conflict based on knowledge ................................................................... 60

(b) Constraint-based conflicts...................................................................61

(2) Conflict handling ………………………………………61

(a) Automatic conflict resolution  ………………………… 61

(b) Conflict Logging  ……………………………… 62

(c) Conflict review and resolution  ……………………… 62

(d) Convergence of Replicas and Propagation of Conflict Resolution... 62

2. Synchronization of data storage on non-storage platforms... 63

a) Synchronization service...................................................................................63

(1) Change the enumeration ...................................................................................63

(2) Change the application …………………………………………64

(3) Conflict resolution ………………………………………65

b) Adapter implementation ................................................................................... 65

3. Security …………………………………………………… 65

4. Manageability…………………………………………… 66

J. Legacy Document Interoperability  ……………………………… 66

K. Storage Platform API …………………………………………66

III. Extension and Inheritance .................................................................................... 71

A. Type system...................................................................................................72

B. Type Families ................................................................................... 77

1. Nested element type...................................................................................77

2. Project type…………………………………………… 77

3. Relationship type...................................................................................78

a) Relational Semantics……………………………………… 79

b) Relational Rules and Constraints………………………………… 80

4. Extension type..................................................................................... 81

C. Enhanced Functions ……………………………………………… 82

1. Inheritance…………………………………………………… 82

2. Expansion …………………………………………………… 83

IV. Conclusions …………………………………………………… 84

I. Introduction

The subject matter of the invention is described in detail to satisfy statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors contemplate that the claimed subject matter can be implemented in other ways as well, to include different steps or combinations of steps similar to those described in this specification, in conjunction with other present and future technologies. Furthermore, while the term "step" may be used herein to refer to various elements of the method employed, the term should not be construed to imply a particular order between the steps disclosed herein unless an explicit description of the various steps is explicitly described. order.

A. Exemplary Computing Environment

Many embodiments of the invention can be implemented on computers. Figure 1 and the following discussion are intended to provide a brief description of a suitable computing environment in which the invention may be implemented. Although not required, aspects of the invention can be described in the general context of computer-executable instructions, such as program modules, being executed on 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. In addition, the invention may be practiced with other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in local or remote memory storage devices.

As shown in FIG. 1 , an exemplary general purpose computing system includes a conventional personal computer 20 or the like including a processing unit 21 , a system memory 22 and a system bus 23 coupling various system components including the system memory to the processing unit 21 . System bus 23 may be any of several bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory includes read only memory (ROM) 24 and random access memory (RAM) 25 . A basic input/output system 26 (BIOS), containing the basic routines that help transfer information between elements of the personal computer 20, such as at start-up, is stored in ROM 24. The personal computer 20 may also include a hard disk drive 27 for reading and writing a hard disk (not shown), a magnetic disk drive 28 for reading and writing a removable magnetic disk 29, and an optical disk drive 30 for reading and writing a removable optical disk 29 such as a CDROM 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 23 through the hard disk drive interface 32 , the magnetic disk drive interface 33 and the optical drive interface 34 respectively. 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 hard disks, removable magnetic disks 29, and removable optical disks 31, those skilled in the art understand that other types of computer-readable media that can store data that can be accessed by a computer can also be used in the exemplary operating environment. , such as cassette tapes, flash memory cards, digital video disks, Bernoulli cassettes, random access memory (RAM), read only memory (ROM), etc. Similarly, the example environment may also include many types of monitoring equipment, such as thermal and security or fire alarm systems, and other sources of information.

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

Personal computer 20 may operate in a network environment using logical connections to one or more remote computers, such as remote computer 49 . Remote computer 49 may be another personal computer, server, router, network PC, peer-to-peer device, or other public network node, and typically includes many or all of the elements described above for personal computer 20, although only shown in FIG. memory storage device 50 . The logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52 . Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN network environment, the personal computer 20 is connected to the LAN 51 through a network interface or adapter 53 . When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over a wide area network 52, such as the Internet. A built-in or external modem 54 is connected to the system bus 23 through the serial port interface 46 . In a network environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

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

1, in various embodiments of a computer system, hardware components 202 may include a central processing unit (CPU) 21, memory (ROM 24 and RAM 25), a basic input/output system (BIOS) 26, and various Input/output (I/O) devices, such as keyboard 40, mouse 42, monitor 47, and/or printer (not shown), etc. Hardware components 202 comprise the basic physical infrastructure of computer system 200 .

Application program components 206 include various software programs including, but not limited to, compilers, database systems, file processing programs, business programs, video games, and the like. Applications provide the means by which computer resources are used to solve problems, provide solutions, and manipulate data for various users (machines, other computer systems, and/or end users).

The hardware/software interface system component 204 includes (in some embodiments it may include only) the operating system, which in most cases itself includes a shell and a kernel. An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component 204 may also include a virtual machine manager (VMM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent, or in a computer system other software components on or outside of the operating system. The purpose of a hardware/software interface system is to provide an environment in which a user can execute an application. The goal of any hardware/software interface system is to facilitate the use of a computer system and to utilize computer hardware in an efficient manner.

A hardware/software interface system is typically loaded into a computer system at startup and then manages all application programs in the computer system. Applications interact with the hardware/software interface system by requesting services through an application programming interface (API). Certain applications enable the end user to interact with the hardware/software interface system through, for example, a command language or a graphical user interface (GUI).

Hardware/software interface systems traditionally perform various services for applications. In a multitasking hardware/software interface system where multiple programs run simultaneously, the hardware/software interface system determines which applications run in what order and how much time is allowed for each application in turn before switching to another application . The hardware/software interface system also manages the sharing of internal memory among multiple applications and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends messages to each application (and in some cases to the end user) about the status of the operation and any errors that may have occurred. The hardware/software interface system can also offload the management of batch jobs (such as printing), so that the launched application can get rid of the job and resume other processing and/or operations. On computers capable of parallel processing, the hardware/software interface system also manages partitioning the program so that it runs on multiple processors simultaneously.

The hardware/software interface system shell (referred to herein as "the shell") is the interactive end-user interface to the hardware/software interface system. (The shell is also known as the "command interpreter" or, within an operating system, the "operating system shell"). A shell is the outer layer of a hardware/software interface system that is directly accessible by applications and/or end users. In contrast to the shell, the kernel is the innermost layer of the hardware/software interface system that directly interacts with hardware components.

While many embodiments of the invention are envisioned to be particularly applicable to computerized systems, nothing in this description is meant to limit the invention to those embodiments. Rather, the term "computer system" as used herein is intended to include any and all devices capable of storing and processing information and/or using stored information to control the behavior or performance of the device itself, whether or not those devices are electronic in nature, mechanical, logical, or virtual.

B. Traditional file-based storage

In most computer systems today, a "file" is a unit of storable information, which may include hardware/software interface systems and applications, data sets, etc. In all modern hardware/software interface systems (Windows, Unix, Linux, MacOS, virtual machine systems, etc.), a file is the fundamental discrete (storable and retrievable) unit of information that can be processed by the hardware/software interface system. Groups of files are usually 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 in turn organized into a tree-based hierarchical arrangement called "directories" (discussed in more detail below). In 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, and early Apple computer systems (such as the Apple IIe ) uses the term "category" in place of a directory; however all these terms are considered synonymous and used interchangeably when used here, and are intended to also include all references to hierarchical information storage structures and their folder and file components References to other equivalent terms.

Traditionally, directories (aka directories of folders) are tree-based hierarchies, where files are grouped into folders, which in turn are arranged in relative node positions that make up the directory tree. For example, as shown in FIG. 2B, a base folder (or "root") 212 of a DOS-based file system may include a plurality of folders 214, each of which may also include additional folders (such as the "root directory" for a particular folder). subfolders") 216, and each of these includes additional folders 218, up to infinity. Each of these folders may have one or more files 220, although at the hardware/software interface system level, the individual files in the folder have little in common other than their location in the tree hierarchy. Not surprisingly, the method of organizing files into a file hierarchy indirectly mirrors the physical organization of typical storage media (eg, hard disks, floppy disks, CD-ROMs, etc.) used to store these files.

In addition to the above, each folder is a container for its subfolders and its directories—that is, each folder owns its subfolders and files. For example, when a folder is deleted by the hardware/software interface system, the folder's subfolders and files are also deleted (and in the case of each subfolder recursively including its own subfolders and files). Also, each file is generally owned by only one folder, and while a file can be copied and the copies are located in different folders, the copies of the file are themselves distinct and independent units that have no direct connection to the original file (e.g. Changes at the hardware/software interface system level are not reflected in the copy file). Files and folders are therefore "physical" in nature in this respect, in that folders are treated like physical containers, whereas files are treated as distinct and separate physical elements within those containers.

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

The present invention, in conjunction with the invention incorporated herein by reference, is directed to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and broadens the data platform beyond the file systems and database systems discussed above, and is designed to store all types of data, including data in a new format called items.

C. Glossary

The terms used here and in the claims have the following meanings:

• An "item" is a unit that can store information accessible to the hardware/software interface system, unlike a simple file, it is an object with a basic set of attributes commonly supported by all objects presented to the end user by the hardware/software interface system shell. Items also have attributes and relationships supported common to all item types, including features that allow the introduction of new attributes and relationships (discussed in detail below).

• An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. In most cases, an operating system consists of a shell and a kernel.

• A "hardware/software interface system" is software, or a combination of hardware and software, that functions as an interface between the underlying hardware components of a computer system and the application programs executing on the computer system. A hardware/software interface system typically includes (and in some embodiments only) an operating system. The hardware/software interface system can also include a virtual machine manager (VMM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent, or an operating system on a computer system or other software components other than the operating system. The purpose of a hardware/software interface system is to provide an environment in which users can execute applications. The goal of any hardware/software interface system is to make the computer system easy to use and utilize the computer hardware in an efficient manner.

D. Storage Platform Overview

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

A change tracking mechanism 306 implemented in the data store 302 provides the ability to track changes to the data store. Data storage 302 also provides security capabilities 308 and upgrade/downgrade capabilities 310, both of which are described in detail later. Data store 302 also provides a set of application program interfaces 312 to expose the capabilities of data store 302 to other storage platform components and applications utilizing the storage platform, such as applications 350a, 350b, and 350c. The storage platform of the present invention also includes an application programming interface (API) 322 that enables applications such as applications 350a, 350b, and 350c to access all of the above-mentioned functions of the storage platform and to access data described in the schema. Applications can use the storage platform API 322 in conjunction with other APIs such as OLE OB API 324 and Microsoft Windows Win 32 API 326.

The storage platform 300 of the present invention can provide various services to applications, including a synchronization service 330 that facilitates sharing data between users or systems. For example, synchronization service 330 allows interoperability with other data stores 340 having the same format as data store 302 and accesses data stores 342 having other formats. Storage platform 300 also provides file system capabilities that allow data store 302 to interoperate with existing file systems such as Windows NTFS file system 318. In at least some embodiments, storage platform 320 can also provide applications with additional capabilities to allow acting on data and to allow interaction with other systems. These capabilities may be embodied in the form of additional services 328 such as Info Agent service 334 and notification service 332, as well as in the form of other utilities 336.

In at least some embodiments, the storage platform is implemented in, 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 can use an operating system, a virtual machine manager (VMM), a common language runtime (CLR) or its functional equivalent, or a Java virtual machine (JVM) or its functional equivalent to carry out, or form an integral part of. Through its common storage base and schematized data, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It provides a rich and extensible programming surface area not only for the capabilities inherent in its data model, but also for including and extending existing file system and database access methods.

In the above description and in various drawings, the storage platform 300 of the present invention may be referred to as "WinFs". However, the use of this name to refer to the storage platform is for descriptive convenience only and is not intended to be so limiting.

E. Data Model

The data store 302 of the storage platform 300 of the present invention implements a data model that supports organization, search, sharing, synchronization and security of data residing in the data store. In the data model of the present invention, "item" is the basic unit of storing information. The data model provides a mechanism for declaring projects and extensions of projects, for establishing relationships between projects, and for organizing projects into project folders and categories, as described more fully below.

This data model relies on two primitive mechanisms: types and relations. Types are structures that provide a format that governs the form of instances of a type. Formats are expressed as ordered groups of attributes. A property is the name of a value or set of values of a given type. For example, the USPostalAddress (United States postal address) type has attributes Street (street), City (city), Zip (zip code), State (state), where Street, City, and State are of type String, and Zip is of type Int32. Street can be multivalued (ie, a set of values), allowing addresses to have more than one value for the Street property. The system defines certain primitive types that can be used in the construction of other types, including String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal, and GUID. Properties of a type may be defined using any primitive type (with some restrictions noted below) or any constructed type. For example, the Location (location) type can be defined to have attributes Coordinate (coordinates) and Address (address), wherein the Address attribute is the above-mentioned type USPostalAddress. Properties can also be required or optional.

A relationship can be declared and represents a mapping between two sets of instances of a type. For example, there could be a relationship declared between a Person type and a Location type, called LivesAt, which determines who lives at what location. A relationship has a name and two endpoints, a source endpoint and a target endpoint. Relationships can also have ordered sets of attributes. Both source and destination endpoints have a name and a type. For example, a LivesAt relationship has a source called Occupant of type Person and a target called Dwelling of type Location, and furthermore has attributes StartDate and EndDate representing the resident's life time period in the housing. Note that individuals can live in multiple homes over time, and that homes can have multiple residents, so the most likely place to put the StartDate and EndDate information is at the relationship itself.

A relationship defines a mapping between instances constrained by a type given as an endpoint type. For example a LivesAt relationship cannot be one in which Automobile (car) is Occupant (resident) because Automobile is not Person.

Data models allow the definition of subtype-supertype relationships between types. Also known as a subtype of a base-type relationship—a super-type relationship is defined in such a way that, if a type A is a base type of a type B, it must be the case that every instance of B is also an instance of A. Another way to express it is that every instance that conforms to B must conform to A. For example, if A has an attribute Name (name) of type String, and B has an attribute Age (age) of type Int16, it follows that any instance of B must have both Name and Age. A hierarchy of types can be thought of as a tree with a single supertype at the root. Branches at the root provide first-level subtypes, which provide second-level subtypes, and so on, up to leaf-most subtypes that no longer have any subtypes themselves. Trees are not limited to uniform depth, but cannot contain any cycles. A given type may have zero or many subtypes and zero or one supertype. A given instance may conform to at most one type and that type's supertypes. In other words, for a given instance at any level in the tree, the instance can conform to at most one subtype at that level. A type is said to be abstract if instances of that type must also be instances of subtypes of that type.

1. Project

An item is a storable unit of information, unlike a simple file, it is an object with a basic set of properties common to all objects presented by the storage platform to an end user or application. Items also have attributes and relationships supported common to all item types, including features described below that allow the introduction of new attributes and relationships.

Items are objects for common operations such as copy, delete, move, open, print, backup, restore, duplicate, and so on. Items are units that can be stored and retrieved, and all forms of storable information handled by the storage platform exist as items, attributes of items, or relationships between items, each of which is discussed in more detail below.

Projects are designed to represent realistic and easily understandable data units, such as Contacts, People, Services, Locations, Documents (of various types), etc. FIG. 5A is a block diagram showing the structure of an item. The unqualified name for this item is "Location". The qualified name of the project is "Core.Location", which indicates that the project structure is defined as a specific type of project in the Core schema (the Core schema is discussed in detail below).

The Location item has several attributes, including EAddress (email address), MetropolitanRegion (metropolitan region), Neighborhood (neighborhood), and PostalAddress (postal address). Each item's type-specific properties are denoted immediately following the property name, separated from the property name by a colon (":"). To the right of the type name, the number of values allowed for that attribute type is indicated between square brackets ("[]"), where an asterisk ("*") to the right of a colon (":") indicates unspecified and/ or an unlimited number ("many"). A "1" to the right of the colon indicates at most one value. A zero ("0") to the left of the colon indicates that the attribute is optional (may have no value at all). A "1" to the left of the colon indicates that there must be at least one value (the attribute is required). Both Neighborhood and MetropolitanRegin are of type "nvarchar" (or equivalent), which is a predefined data type or "simple type" (represented here by the lack of capitalization). However EAddress and PostalAddress are properties of defined types or "complex types" (marked here in capitals) of types EAddress and PostalAddress respectively. A complex type is a type that is derived from one or more simple data types and/or from other complex types. Complex types that are properties of an item also constitute "nested elements", because the details of the complex type are nested in the immediate item to define its properties, and the information pertaining to these complex types is maintained with items that have these properties (in the item within the boundaries, as discussed later). These concepts of type are well known and readily understood by those skilled in the art.

Figure 5B is a block diagram illustrating complex attribute types PostalAddress and EAddress. PostalAddress attribute type definition, an item of attribute type PostalAddress can expect zero or one City (city) value, zero or one Country Code (country code) value, zero or one MailStop (country code) value, and any number ( zero to many) PostalAddress type and so on. In this way, the shape of the data for a particular attribute in an item is defined. The EAddress property type is similarly defined as shown. Although optionally used here in this application, another way to represent complex types in the Location item is to derive the item with the individual properties of each complex type listed therein. Figure 5C is a block diagram showing the Location item, in which its complex type is further described. It should be understood, however, that an alternative representation of the Location item in FIG. 5C is for exactly the same item shown in FIG. 5A. The storage platform of the present invention also allows subtyping so that one property class can be a subtype of another (where one property class inherits properties from another parent property type).

Similar to, but distinct from, properties and their property types, Items inherit their own Item type, which is also the subject of subcategories. In other words, the storage platform in several embodiments of the invention allows an item to be a subtype of another item (so that an item inherits the properties of another parent item). Additionally, for various embodiments of the present invention, each item is a subtype of the "Item" item type, which is the first and fundamental item type found in the base schema (the base schema is also discussed in detail below). Figure 6A shows that an item (in this example the Location item) is a subtype of the Item item type found in the base schema. In this figure, the arrows indicate that the Location item (like all other items) is a subtype of the Item item type. The Item item type, which is the base item from which all other items are derived, has several important properties like ItemId and various time stamps, thereby defining standard properties for all items in the operating system. In this figure, these properties of the Item item type are inherited by Location and thus become properties of Location.

Another way to represent properties in a Location item that inherits from the Item item type is to derive a Location with individual properties from each property type of the parent item listed therein. Fig. 6B is a block diagram showing the Location item, in which its inherited types are described in addition to its immediate attributes. It should be noted and understood that this item is the same item shown in Figure 5A, although in this figure, Location is shown with all its attributes, including direct attributes (shown in this figure and in Figure 5A) and inherited attributes (in Shown in this figure but not in Figure 5A) (whereas in Figure 5A these attributes are referenced by arrows showing that the Location item is a subtype of the Item item type).

Items are self-contained objects, so deleting an item also deletes all of the item's direct and inherited properties. Similarly, when retrieving an item, it is the item and all of its direct and inherited attributes (including information pertaining to its complex attribute types) that are retrieved. Certain embodiments of the present invention may enable one to request a subset of attributes when retrieving a particular item; however the default for many such embodiments is to provide an item with all of its direct and inherited attributes when retrieving. In addition, the properties of an item can also be extended by adding new properties to the existing properties of the item's type. These "extensions" are followed by the actual properties of the item, and subtypes of the item type may automatically include extended properties.

The "boundary" of an item is represented by its attributes (including complex attribute types, extensions, etc.). The boundaries of an item also represent the limits of operations performed on the item, including copying, deleting, moving, creating, and so on. For example, in several embodiments of the invention, when an item is copied, all content within the boundaries of the item is also copied. For each project, the boundary includes the following:

The item type of an item, and if the item is a subtype of another item (as in the case of several embodiments of the invention where all items are derived from a single item and item type of the base schema), any applicable subtype Information (that is, information belonging to the parent item type). The original item being copied is a subtype of another item, and the copy can also be a subtype of that same item.

· Item's complex type properties and extensions (if any). If the original item has properties of a complex type (original or extended), the copy can also have the same complex type.

• A record of items on an "ownership relationship", ie, an item-owned list of what other items ("catalogue items") owns what this item ("owning item") owns. This specifically relates to the project folders discussed fully below and the rule that all projects must belong to at least one project folder. Furthermore, with respect to embedded items (discussed more fully below), an embedded item is considered to be the part of the item in which operations such as copy, delete, etc. are embedded.

2. Project identification

ItemID is used to uniquely identify items in the global item space. The Base.Item type defines a field ItemID of type GUID that stores the identity of the item. An item must have exactly one identity in the data store.

Item references are data structures that contain information to locate and identify items. In this data model, define an abstract type named ItemReference from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves the ItemReference and returns an item. This method is overridden by a concrete subtype of ItemReference that implements functionality for retrieving an item given a reference. Call the Resolve method as part of the Storage Platform API 322.

ItemIDReference (item ID reference) is a subtype of ItemReference. It defines the Locator (locator) and ItemID fields. The Locator field names (that is, identifies) the domain of the item. It is handled by the locator resolve method that resolves the value of the Locator to the project field. The ItemID field is of type ItemID.

ItemPathReference (item path reference) is a specialization of ItemReference that defines the Locator and Path fields. The Locator field identifies an item field. It is handled by the locator resolve method that resolves the value of the Locator to the project field. The Path field contains a (relative) path in the storage platform namespace rooted at the project domain provided by the Locator.

Such references cannot be used in set operations. References generally must be resolved through the path resolution process. The Resolve method of the Storage Platform API 322 provides this functionality.

The citation forms discussed above are represented by the citation type hierarchy shown in FIG. 11 . Additional reference types that inherit from these types can be defined in the schema. They can be used as the type of the target field in the relation declaration.

3. Project folders and categories

As will be discussed more fully below, groups of projects can be organized into special projects called project folders (not to be confused with folders of files). Unlike most file systems, however, a project can belong to multiple project folders, so that when a project is accessed and revised in one project folder, the revised project can then be accessed directly from another project folder. Essentially, although access to a project can occur from different project folders, what is actually being accessed is the same project. However, a project folder does not have to own all of its member projects, or simply own projects in conjunction with other folders, so that deletion of a project folder does not necessarily result in the deletion of projects. In several embodiments of the invention, however, a project must belong to at least one project folder, so that if the unique folder for a particular project is deleted, then for some embodiments the project is automatically deleted, or in other embodiments , the project automatically becomes a member of the default project folder (the "TrashCan" folder is conceptually similar to similarly named folders used in various file and folder-based systems.)

As discussed more fully below, items may also belong to categories based on commonly described characteristics such as: (a) item type (or types), (b) specific direct or inherited attributes (or attributes), or (c ) corresponds to a specific value (or values) of an item property. For example, items that include a specific attribute of personal contact information may automatically belong to the Contact category, as will any item that has the attribute of contact information. Likewise, any item that has a location attribute with a value of "New York City" can automatically belong to the category NewYorkCity.

Categories are conceptually different from project folders in that project folders may contain items that are unrelated to each other (i.e., have no common descriptive characteristics), whereas each item in a category has a common type, attribute, or value ("commonality"), it is this commonality that forms the basis for its relationship to other items or items in the class. Furthermore, while membership of an item in a particular folder is not mandatory based on any particular aspect of the item, for some embodiments, all items having a taxonomically common Membership of this class is automatic at the system level. Conceptually, categories can also be seen as virtual project folders, whose membership is based on the results of a specific query (such as in the context of a database), and projects that satisfy the conditions of this query (determined by the commonality of the category) should form the category membership.

Figure 4 shows the structural relationship between projects, project folders and categories. A plurality of projects 402 , 404 , 406 , 408 , 410 , 412 , 414 , 418 , and 420 are members of respective project folders 422 , 424 , 426 , 428 , and 430 . Certain projects belong to more than one project folder, such as project 402 belonging to project folders 422 and 424 . Certain items, such as items 402, 404, 406, 408, 410, and 412 are also members of one or more categories 432, 434, and 436, while other items, such as items 44, 416, 418, and 420, may not belong to any category ( This is mostly not like in some embodiments though, where having any attribute automatically implies membership in a class, so in that embodiment an item should be completely featureless in order to not be a member of any class). In contrast to the hierarchical structure of folders, both category and project folders have a structure more like a directed graph as shown. In any case, projects, project folders, and categories are projects (albeit different project types).

Contrary to files, folders and directories, the project, project folder and category features of the present invention are not "physical" in nature, because they have no conceptual equivalent of physical containers, so projects can exist in a the position above. The ability for projects to exist in more than one project file location and be organized into categories provides an enhanced and rich degree of data processing and storage structure capabilities at the hardware/software interface level beyond what is currently available in the art.

4. Mode

a) Basic pattern

To provide a common basis for creating and using items, embodiments of the storage platform of the present invention include a Base schema that establishes a conceptual framework for creating and organizing items and properties. The base schema defines the items and properties of some specific types, and the characteristics of these specific base types from which subtypes are further derived. Using this basic pattern enables programmers to conceptually distinguish items (and their respective types) from attributes (and their respective types). Additionally, the base schema lists the base set of properties that all items can have, since all items (and their corresponding item types) are derived from this base item (and their corresponding item types) of the base schema.

As shown in FIG. 7, for several embodiments of the present invention, the basic schema defines three top-level types: Item (item), Extension (extension) and PropertyBase (property base). As shown, the item type is defined through the properties of this base "Item" item type. In contrast, the top-level property type "PropertyBase" has no predefined properties, but is only an anchor from which all other properties are derived, and through which all derived property types are interconnected (collectively derived from a single property type). The Extension type attribute defines which project the extension extends, and defines the identity that distinguishes one extension from another project, since a project can have multiple extensions.

ItemFolder (item folder) is a subtype of the Item item type. In addition to the properties inherited from Item, it characterizes the relationship used to establish its members (if any), although Identitykey (identity key) and Property (attribute ) are subtypes of PropertyBase. CategoryRef (category reference) is in turn a subtype of IdentityKey.

b) Kernel mode

Various embodiments of the storage platform of the present invention also include a Core schema that provides a conceptual framework for the top-level project type structure. FIG. 8A is a block diagram showing items in the core schema, and FIG. 8B is a block diagram showing attribute types in the core schema. The distinction made between files with different extensions (*.com, *.exe, *.bat, *.sys, etc.) and other criteria in the file- and folder-based system is a kernel-mode-like function. In an item-based hardware/software interface system, the core schema defines a core set of item types that directly (by item type) or indirectly (by item subtype) characterize all items into an item-based hardware/software interface system One or more core schema item types that are understood and can be directly addressed in a predetermined or predictable manner. The predefined item types reflect the items most commonly used in the item-based hardware/software interface system, and thus the level of effectiveness is obtained by understanding these predefined item types including the core schema.

In some embodiments, the core schema is not extensible, ie, no additional types can be subclassed directly from item types in the base schema, except for specific predefined derived item types that are part of the core schema. By prohibiting extensions to the core schema (ie, by prohibiting the addition of new items to the core schema), the storage platform hosts the use of the core schema item type, since each subsequent item type must be a subtype of the core schema item type. This structure allows a reasonable degree of flexibility in defining additional item types while maintaining the benefits of having a predetermined set of core item types.

Referring to FIG. 8A, for various embodiments of the present invention, specific item types supported by the core schema may include one or more of the following:

• Category: Items of this item type (and subtypes derived from it) represent valid categories in an item-based hardware/software interface system.

• Commodity: An item that is an identifiable thing as a value.

• Device: An item having a logical structure supporting information processing capabilities.

• Document: An item with content that cannot be interpreted by an item-based hardware/software interface system but instead by an application corresponding to the document type.

· Event (event): records some events in the environment of the project.

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

• Message: An item for communication between two or more principals (defined below).

• Principal: An Item that has at least one positively verifiable identity (eg, identification of a person, organization, group, family, author, service, etc.) other than the ItemId.

• Statement: An item with specific information about an environment, including but not limited to: policies, subscriptions, credentials, etc.

Referring similarly to FIG. 8B , specific attribute types supported by the core schema may include one or more of the following:

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

PrincipalIdentityKey (subject identity key) (derived from the IdentityKey type in the underlying schema)

· PostalAddress (postal address) (derived from the Property type in the basic mode)

RichText (rich text) (derived from the Property type in the basic mode)

EAddress (email geology) (derived from the Property type in the base schema)

· IdentitySecnrityPackage (identity security package) (exported from the Relationship type in the basic model)

·RoleOccupancy (resident role) (derived from the Relationship type in the basic model)

• BasicPresence (derived from the Relationship type in the Basic Schema) These items and attributes are further described by the respective attributes listed in Figures 8A and 8B.

5. Relationship

Relationships are binary, where one item is designated as the source and the other as the target. Source and target items are related by a relationship. The source project generally controls the life cycle of the relationship. That is, when the source item is deleted, the relationship between the items is also deleted.

Relationships are classified into: Containment and Reference relationships. Contains relationships control the lifecycle of the target item, while references relationships do not provide any lifecycle management semantics. Fig. 12 shows how relationships are classified.

The containment relationship is further classified into holding (Holding) and embedding (Embedding) relationships. When all holdings to an item are removed, the item is deleted. The holding relationship controls the target through a reference counting mechanism. Embedding relationships can model composite items and can be viewed as exclusive holding relationships. An item can be the target of one or more holding relationships; but an item can only be the target of one embedded relationship. An item that is the target of an embedded relationship cannot be the target of any other holding or embedded relationship.

Reference relationships do not control the lifecycle of the target project. They can be dangling - the target item can be absent. Reference relationships can be used to model references to projects anywhere in the global project namespace (ie, including remote data stores).

Obtaining an item does not automatically acquire a relationship, the application must explicitly request the item's relationship. Also, modifying a relationship does not modify the source or target items; similarly, adding a relationship does not affect the source/target items.

a) Relationship statement

Explicit relation types are defined with the following elements;

Specify the relationship name in the Name attribute

• A relationship type of one of the following: holds, embeds, references. This is specified in the Type attribute.

• Source and destination endpoints. Each endpoint specifies the name and type of the item being referenced.

• The source endpoint field is typically of type ItemID (not declared), but must refer to an item in the same data store as the relation instance.

• For hold and embed relationships, the target endpoint field must be of type ItemIDReference and it must refer to an item in the same store as the relationship instance. For reference relationships, the target endpoint can be of any ItemReference type and can reference items in other storage platform data stores.

• One or more fields of scalar or PropertyBase type can optionally be declared. These fields can contain data associated with the relationship.

• Relationship instances are stored in the global relationship table.

• Each relation instance is uniquely identified by the combination (source ItemID, relation ID). Relation IDs are unique within a given source ItemID for all relations originating from a given Item, regardless of their type.

The source project is the owner of the relationship. While the project designated as the owner controls the lifecycle of the relationship, the relationships themselves are separate from the projects they are related to. The storage platform API 322 provides mechanisms for exposing the relationships associated with items.

Here is an example of a relationship declaration.

<Relationship Name="Employment"BaseType="Reference">

<Source Name="Employee" ItemType="Contact.Person"/>

<Target Name="Employer" ItemType="Contact.Organization"

     ReferenceType = "ItemIDReference" />

<Property Name="StartDate"Type="the storage

platformTypes.DateTime″/>

<Property Name="EndDate"Type="the storage

platformTypes.DateTime″/>

<Property Name="Office"Type="the storage

platformTypes.DateTime″/>

</Relationship>

This is an example of a reference relationship. This relationship cannot be created if the personal item referenced by the source reference does not exist. And if the individual item is deleted, the relationship instance between the individual and the organization is also deleted. However if the organization item is deleted, the relationship is not deleted and it is swinging.

b) holds a relationship

Holding relationships are used to model reference counting based on the lifecycle management of the target project.

An item can be the source endpoint for zero or more relationships to items. Items that are not embedded items may be target items in one or more holding relationships.

The target endpoint reference type must be ItemIDReference, and it must refer to an item in the same store as the relation instance.

Holding relationships enforces lifecycle management of target endpoints. The creation of the holding relation instance and the item as the target is an atomic operation. Additional holding relationship instances can be created that target the same project. When the last holding relationship instance with the given item as target endpoint is deleted, the target item is also deleted.

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

Holding relationships play a key role in forming a project's namespace. They contain a "Name" attribute, which defines the name of the target project relative to the source project. Relative names are unique across all holding relationships originating from a given project. An ordered list of classes starting from the root project to the relative names of a given project forms the full name of that project.

The holding relationships form a directed acyclic graph (DAG). When creating holding relationships, the system ensures that no loops are created, thereby ensuring that the project's namespace forms a DAG.

Although the hold relationship controls the lifecycle of the target item, it does not control the consistency of operation of the target endpoint item. The target item is operationally independent of the item that owns it through the holding relationship. Copy, move, backup, and other operations on items that are the source of a holding relationship do not affect items that are the target of the same relationship—for example, backing up a folder item does not automatically back up all items in that folder (FolderMember(folder member) target in a relationship).

Here is an example of a hold relationship:

<Relationship Name="FolderMembers"BaseType="Holding">

<Source Name="Folder" ItemType="Base.Folder"/>

<Target Name="Item"ItemType="Base.Item"

        ReferenceType = "ItemIDReference" />

</Relationship>

The FolderMember relationship makes the concept of a folder a generic collection of items.

c) Embedding relationships

The embedding relationship models the concept of exclusive control of the life cycle of the target item. They allow the notion of compositing items.

The creation of an embedded relation instance and an item as a target is an atomic operation. An item can be the source of zero or more embedded relations. However an item can be the object of one and only one embedded relation. An item that is the target of an embedded relationship cannot be the target of a holding relationship.

The target endpoint reference type must be ItemIDReference, and it must refer to an item in the same data store as the relation instance.

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

The embedding relationship controls the operational consistency of that target endpoint. For example, the operation of serializing an item may include serializing all embedded relationships originating from the item and all of its targets; copying an item also copies all of its embedded items.

Here is an example declaration:

<Relationship Name="ArchiveMembers"BaseType="Embedding">

<Source Name="Archive" ItemType="Zip.Archive"/>

<Target Name="Member" ItemType="Base.Item"

       ReferenceType="ItemIDReference"/>

<Property Name="ZipSize"Type="the storage

platformTypes.bigint″/>

<Property Name="SizeReduction"Type="the storage

platformTypes.float″/>

</Relationship>

d) Reference relationship

A reference relationship does not control the lifecycle of the item it references. In particular, a referencing relationship does not guarantee the existence of the target, nor does it guarantee that the target is of the type as specified in the relationship declaration. This means that citation relationships can be volatile. And reference relationships can reference items in other data stores. A citation relationship can be viewed as a concept similar to a link on a web page.

The following is an example of a reference relationship specification:

<Relationship Name="DocumentAuthor"BaseType="Reference">

<Sourc ItemType="Document"

      ItemType = "Base.Document"/>

<Target ItemType="Author" ItemType="Base.Author"

       ReferenceType="ItemIDReference"/>

<Property Type="Role"Type="Core.CategoryRef/>

<Property Type="DisplayName"Type="the storage

platformTypes.nvarchar(256)″/>

</Relationship>

Any reference type is allowed on the target's endpoint. Items participating in a reference relationship can be of any item type.

Reference relationships are used to model most non-lifecycle management relationships between items. Reference relationships are convenient for modeling loosely coupled relationships because the existence of the target is not enforced. Reference relationships can be used for target items in other stores, including stores on other computers.

e) Rules and constraints

The following additional rules and constraints apply to relationships:

• An item must be the target of (only one embedding relationship) or (one or more holding relationships). One exception is the root project. An item can be the target of zero or more reference relationships.

• An item that is the target of an embedded relationship cannot be the source of the holding relationship. It can be the source of a reference relationship.

· An item cannot be the source of a hold relationship if it is promoted from a file. It can be the source of embedding and referencing relationships.

• An item upgraded from a file cannot be the target of an embedded relationship.

f) Ordering of relations

In at least one embodiment, the storage platform of the present invention supports ordering of relationships. Sorting is done through an attribute called "Order" in the base relation definition. There is no uniqueness constraint in the Order field. The order of relations with the same "Order" property value is not guaranteed, however, they are sorted after relations with lower "Order" values and before relations with higher "Order" field values.

The application gets the default order of relationships by sorting on the combination (SourceItem ID, RelationshipID, Order). All relationship instances originating from a given item are sorted into a single collection, regardless of the type of relationship in the collection. This guarantees, however, that all relationships of a given type (eg, FolderMembers) are an ordered subset of a given item's relationship collection.

The data store API 312 for working with relations implements a set of operations that support ordering of relations. The following terms are introduced to help explain those operations:

RelFirst is the first relation in the ordered set with the order value OrdFirst;

RelLast is the last relation of the ordered set with the order value OrdLast;

RelX is a given relation in a set with an order value OrdX;

RelPrev is the closest relation in the set to RelX with an order value OrdPrev less than OrdX; and

• RelNext is the closest relation in the set to RelX with an order value OrdNext greater than OrdX.

Actions include but are not limited to:

• InsertBeforeFirst(SourceItemID, Relationship) inserts a relationship as the first relationship in the collection. The value of the "Order" attribute of the new relationship can be less than OrdFirst.

• InsertAfterLast(SourceItemID, Relationship) inserts a relationship as the last relationship in the collection. The "Order" property of the new relationship can have a value greater than OrdLast.

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

- InsertBefore(SourceItemID, ord, Relationship) inserts the relationship before the relationship with the given order value. New relations may be assigned the "Order" value, which is between, but not including, OrdPrev and ord.

• InsertAfter(SourceItemID, ord, Relationship) inserts the relationship after the relationship with the given order value. New relations may be assigned the "Order" value, which is between but not including ord and OrdNext.

• MoveBefore(SourceItemID, ord, Relationship) moves the relationship with the given relationship ID before the relationship with the specified "Order" value. Relationships can be assigned a new "Order" value, which is between, but not including, OrdPrev and ord.

• MoveAfter(SourceItemID, ord, Relationship) moves the relationship with the given relationship ID after the relationship with the specified "Order" value. The relationship can be assigned a new order value, which is between but not including ord and OrdNext.

As mentioned earlier, each project must be a member of the project folder. In terms of relationships, each project must have a relationship with a project folder. In several embodiments of the invention, certain relationships are represented by relationships that exist between items.

As implemented for various embodiments of the present invention, a relationship provides a directed binary relationship extending from one item (source) to another item (target). A relationship is owned by the source item (the item that extends it), so the relationship is removed if the source is removed (eg, the relationship is deleted when the source item is deleted). Also in some cases, relationships can share (co-owned) ownership of the target item, and that ownership can only be reflected in the relationship's IsOwned property (or its equivalent) (see Figure 7 shown for relational attribute types). In these embodiments, creating a new IsOwned relationship automatically increments the reference count on the target, while deleting such a relationship decrements the reference count on the target item. For these particular embodiments, an item persists if it has a reference count greater than zero, and is automatically deleted if the item count reaches zero. Again, a project folder is a project that has (or can have) a set of relationships with other projects, including membership of the project folder. Other practical implementations of relationships are possible and contemplated by the present invention to achieve the functionality described herein.

Regardless of the actual implementation, a relationship is an optional connection from one object to another. The ability for a project to belong to more than one project folder and one or more categories, whether those projects, folders and categories are public or private, is determined by the meaning given to the presence (or lack thereof) in project-based structures . These logical relationships are the meanings assigned to a set of relationships, regardless of its physical implementation designed to perform the functions described herein. Logical relationships are established between projects and their folders or categories (or vice versa), because essentially project folders and categories are each a specific type of project. Thus, project folders and categories can be acted on like other projects (copied, added to email messages, embedded in documents, etc., without limitation), and project folders and categories can be used like other projects using the same Mechanisms for serialization and deserialization (import and export). (eg in XML all items can have a serialized format and this grid applies equally to item folders, categories and items).

The above-described relationships representing relationships between projects and their project folders can logically extend from projects to project folders, from project folders to projects, or both. A relationship that logically extends from a project to a project folder indicates that the project folder is public to the project and shares its membership information with the project; conversely, the lack of a logical relationship from a project to a project folder indicates that the project file Folders are private to the project and do not share their membership information with the project. Similarly, a relationship that logically extends from a project folder to a project indicates that the project is public and can be shared with the project folder, whereas the lack of a relationship that extends logically from the project folder to the project indicates that the project is private and cannot shared. Therefore, when exporting a project folder to another system, it is "public" to the project, it is shared in the new environment, and it is "public" when the project searches its project folder for other shareable projects A project folder that provides the project with information about shareable projects that belong to it.

FIG. 9 is a block diagram showing a project folder (which is itself a project), its member projects, and the interconnection relationship between the project folder and its member projects. Project folder 900 has a number of projects 902, 904, and 906 as its members. Project folder 900 has a relationship 912 from itself to project 902, which indicates that project 902 is public and can be shared with project folder 900, its members 904 and 906, and any other project files that can access project folder 900 Folders, categories, or items (not shown) are shared. However, there is no relationship from project 902 to project folder project 900 , indicating that project folder 900 is private to project 902 and does not share its membership information with project 902 . On the other hand, project 904 does have a relationship 924 from itself to project folder 900 , which indicates that project folder 900 is public and shares its membership information with project 904 . However there is no relationship from project folder 900 to project 904, which indicates that project 904 is private and not related to project folder 900, its other members 902, 906, and any other project folder that can access project folder 900 , category, or project (not shown) sharing. In contrast to its relationships (or lack thereof) to projects 902 and 904, project folder 900 has a relationship 916 from itself to project 906, and project 906 has a relationship 926 back to project folder 900, together indicating that project 906 is public, and can be shared with folder 900, its members 902 and 904, and any other project folder, category, or project (not shown) that can access project folder 900, and project folder 900 is public, And share its membership information with Project 906.

As discussed previously, projects within project folders need not share commonality because project folders are not "described". A category, on the other hand, is described by a commonality common to all its member projects. Thus, membership of a class is inherently limited to items that have a described commonality, and in some embodiments, all items that satisfy a class's description automatically become members of that class. Thus, while project folders allow unimportant type structures to be represented by their membership, categories allow membership based on defined commonality.

Of course, class descriptions are logical in nature, so classes can be described by any logical representation of types, attributes and/or values. For example, a logical representation of a category may be its membership to include items with one or both of two attributes. If the attributes described for a class are "A" and "B," membership in that class can include items with attribute A but not B, items with attribute B but not A, and items with both attributes A and B project. The logical representation of the attribute is described by the logical operator "OR", where the member group described by the category is an item with attribute A OR B. As will be appreciated by those skilled in the art, similar logical operators (including but not limited to "AND (and)", "XOR (exclusive or)" and "NOT (not)" alone or in combination thereof can also be used to Describe the category.

Although there is a distinction between project folders (not described) and categories (described), in many embodiments of the invention, in principle, category relationships to projects and project relationships to categories above face project folders and Items are revealed in the same way.

Fig. 10 is a block diagram showing a category (which is itself an item), its member items, and the interconnection between the category and its member items. Class 1000 has a number of items 1002, 1004, and 1006 as members, all of which share some combination of common attributes, values, and types 1008 (commonality description 1008') described by class 1000. Class 1000 has a relationship from itself to project 1002, which indicates that project 1002 is public and can be shared with class 1000, its members 1004 and 1006, and any other class, project folder, or project that has access to class 1000 (not shown) shared. However, there is no relationship from project 1002 to category 1000 , indicating that category 1000 is private to project 1002 and does not share membership information with project 1002 . On the other hand, item 1004 does have a relationship 1024 from itself to category 1000 , which indicates that category 1000 is public and shares its membership information with item 1004 . However, there is no relationship extending from class 1000 to item 1004, indicating that item 1004 is private and cannot be shared with class 1000, its other members 1002 and 1006, and any other class, item folder, Or project (not shown) sharing. In contrast to its relationship (or lack thereof) to items 1002 and 1004, class 1000 has a relationship 1016 from itself to item 1006, and item 1006 has a relationship 1026 back to class 1000, which together indicate that item 1006 is public , and can be shared with class 1000, its project members 1002 and 1004, and any other class, project folder, or project (not shown) that can access class 1000, and class 1000 is public and shares its Membership information.

Finally, since categories and project folders are themselves projects, and projects can relate to each other, categories can relate to project folders and vice versa, and in some further embodiments, categories, project folders and projects can each relate to Other categories, project folders and projects. In various embodiments, however, the project folder structure and/or class structure prohibits containment loops at the hardware/software interface system level. While the project folder and category structure resembles a directed graph, an embodiment that prohibits loops resembles a directed acyclic graph (DAG), which, according to the mathematical definition in the field of graph theory, is one in which no path begins and ends at the same vertex directed graph.

6. Scalability

As noted above, the present storage platform is intended to provide an initial set of schemas 340 . However, at least in some embodiments, the storage platform also allows customers, including independent software vendors (ISVs), to create new schemas 344 (ie, new items and nested element types). This section discusses the mechanism for creating this schema by extending the item types and nested element types (or simply "element" types) defined in the initial schema group 340 .

Preferably, the expansion of the initial set of item and nested element types is constrained as follows:

Allow ISVs to introduce a new item type, the subtype Base.Item;

Allows ISVs to introduce a new nested element type, the subtype Base.NestedElement;

Allows ISVs to introduce new extensions, namely the subtype Base.NestedElement; but

• An ISV cannot subclass any type (item, embedded element, or extension type) defined by the storage platform's initial set of schemas 340 .

Since the item type or embedded element type defined by the storage platform's initial schema set may not exactly match the needs of the ISV application, the ISV must be allowed to customize the type. This takes into account the concept of extension. Extensions are strongly typed instances, but (a) they cannot stand alone, and (b) they must be attached to an item or nested element.

In addition to addressing the need for schema extensibility, the extension also aims to address the "multi-classification" problem. In some embodiments, because storage platforms may not support multiple inheritance or overlapping subtypes, applications may use extensions as a way to model instances of overlapping types (eg, a document that is both a legal document and a secure document).

a) Project extension

To provide extensibility of the project, the data model also defines an abstract type called Base.Extension. This is the root type of the hierarchy of extension types. Applications can subclass Base.Extension to create specific extension types.

Define the Base.Extension type in the base schema as follows:

<Type Name="Base.Extension" IsAbstract="True">

<Propety Name="ItemID"

      Type = "the storage platformTypes.uniqueidentified"

                                      

MultiValued="false"/>

<Property Name="ExtensionID"

      Type = "the storage platformTypes.uniqueidentified"

Nullable = "false"

MultiValued="false"/>

</Type>

The ItemID field contains the ItemID of the item associated with this extension. An item with this ItemID must exist. If an item with the given ItemID does not exist, the extension cannot be created. When an item is deleted, all extensions with the same ItemID are deleted. The 2-tuple (ItemID, ExtensionID) uniquely identifies the extension instance.

The structure of an extension type is similar to that of an item type:

The extension type has fields;

Fields can be primitive or nested element types; and

• Extension types can be subcategorized.

The following restrictions apply to extension types

An extension cannot be the source and target of a relationship;

An instance of an extension type cannot exist independently of the item; and

Extended types cannot be used as field types in storage platform type definitions

There are no constraints on the types of extensions that can be associated with a given item type. Any extension type allows extension of any item type. When multiple extension instances are attached to a project, they are independent of each other in structure and behavior.

Extension instances are stored separately and accessed from projects. All extension type instances are accessible from the global extension view. An efficient query can be composed that returns all instances of extensions of a given type, regardless of what type of item they are associated with. The Storage Platform API provides a programming model for storing, retrieving and modifying project extensions.

An extended type may be a type that is subclassed using the storage platform's single inheritance model. Creates a new extension type derived from an extension type. An extended structure or behavior cannot override or replace the structure or behavior of the item type hierarchy. Similar to item types, extension type instances can be accessed directly through the views associated with that extension type. Extended ItemIDs indicate which item they belong to and can be used to retrieve the corresponding item object from the global item view. For operational consistency purposes, extensions are considered part of the project. Copy/move, backup/restore, and other common operations defined by the storage platform can operate on extensions that are part of the project.

Consider the following example. Define the Contact type in the Windows type group.

<Type Name="Contact"BaseType="Base.Item">

<Property Name="Name"

Type = "String"

Nullable = "false"

MultiValued="false"/>

<Property Name="Address"

Type="Address"

Nullable="true"

MultiValued="false"/>

</Type>

CRM (Customer Relationship Management) application developers like to attach CRM application extensions to contacts stored in storage platforms. Application developers define CRM/extensions that contain additional data structures that the application can handle.

<Type Name="CRMExtension"BaseType="Base.Extension">

<Property Name="CustomerID"

Type = "String"

                                       

MultiValued="false"/>

...

</Type>

HR application developers wish to attach additional data to contacts as well. This data is separate from CRM application data. Application developers can also create—extended

<Type Name="HRExtension"EBaseType="Base.Extension">

<Property Name="EmployeeID"

Type = "String"

Nullable = "false"

MultiValued="false"/>

...

</Type>

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

In the above example, the fields and methods of the CRMExtension type cannot override the fields and methods of the contact hierarchy. It should be noted that instances of the CRMExtension type can be attached to item types other than Contacts.

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

All CRMExtension extensions in the system, regardless of the project they belong to, can be accessed through the CRMExtension type view. All project extensions of a project share the same project 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 the Item (item), Extension (extension) and NestedElement (nested element) types:

Item, ItemExtension and NestedElement Item ItemExtension NestedElement Item ID store query/search query/search scope relational semantics and association of items Has its own item id The item's hierarchy is stored in its own table Can query the items table Can search for all instances of an item type Can have relationships to items Can be related to other items by holding embedded and soft relationships The project id of a shared project The project extension hierarchy is stored in its own table The project extensions table can be queried All instances of a project extension type can be searched Not related to project extensions Usually only related by extensions. Extended semantics are similar to embedded item semantics Does not have its own project id. A nested element is a part of an item Stored within an item Usually only queried within the context of the containing item Usually only searchable within nested element type instances of a single (containing) item No relationship to nested elements Related to items by fields relevant. Nested elements are part of an item

b) Extend the NestedElement type

Nested element types are not extended by the same mechanism as item types. Extensions of nested elements are stored and accessed using the same mechanisms as fields of nested element types.

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

<Type Name="Element"

IsAbstract="True">

<Property Name="ElementID"

Type = "the storage platformTypes.uniqueidentifier"

Nullable = "false"

MultiValued="false"/>

</Type>

The NestedElement type inherits from this type. The NestedElement element type additionally defines—fields, which are groups of elements.

<Type Name="NestedElement"BaseType="Base.Element"

IsAbstract="True">

<Property Name="Extensions"

Type = "Base.Element"

Nullable = "false"

MultiValued="true"/>

</Type>

NestedElement extensions differ from item extensions in the following ways:

· Nested element extension is not an extension type. They do not belong to the extension type hierarchy rooted at the Base.Extension type.

• Nested element extensions are stored with the item's other fields and are not globally accessible—queries that retrieve all instances of a given extension type cannot be composed.

• Store these extensions like other nested elements (or items). Like other nested groups, NestedElement extensions are stored in UDTs. They are accessible through the Extension field of the nested element type.

• The collection interface used to access multivalued properties is also used for access and iteration over groups of type extensions.

The following table summarizes and compares Item extensions and NestedElement extensions.

Item extension and NestedElement extension project extension NestedElement extension storage The project extension hierarchy is stored in its own table store like nested elements Query/Search Query/Search Scope Programmability Behavior Relational Semantics Item ID Can query project extension tables Can query all instances of a project extension type Requires special extension API and special queries on extension tables Can associate behaviors that have nothing to do with project extensions Shared project project ids NestedElement can generally only be queried within the context of the containing item. NestedElement can generally only be searched within a single (containing) item's nested element type instance Any other multivalued field that extends like a nested element; not allowed using the normal nested element type API The behavior(?) has nothing to do with the NestedElement extension not having it's own item id. The NestedElement extension is part of the project

F. Database engine

As mentioned above, data storage is implemented on the database engine. In this embodiment, the database engine includes a relational database engine such as a Microsoft SQL Server engine that implements SQL query language and has object-relational extensions. According to this embodiment, this section describes the mapping from the data model implemented by the data storage to the relational storage, and provides the information used by the client of the storage platform on the logic API. It will be appreciated, however, that different mappings may be used when different database engines are used. Indeed, in addition to implementing the storage platform conceptual data model on the relational database engine, it can also be implemented on other types of databases, such as object-oriented and XML databases.

Object-oriented (OO) database systems provide persistence and transactions for programming language objects (eg, C++, Java). The storage platform concept of "items" maps well to objects in object-oriented systems, although embedded collections must be added to objects. Other storage platform type concepts like inheritance and nested element types also map to the object-oriented type system. Object-oriented systems typically already support object identities; thus, item identities can be mapped to object identities. The behavior (operations) of items map nicely to object methods. However, object-oriented systems often lack organizational capabilities and are poor at searching. Also, object-oriented systems do not provide support for unstructured and semi-structured data. To support the full storage platform data model described here, concepts like relationships, folders, and extensions need to be added to the object data model. Additionally, mechanisms such as upgrades, synchronization, notifications, and security need to be implemented.

Similar to object-oriented systems, XML databases based on XSD (XML Schema Definition) support systems based on single-inheritance types. The item type system of the present invention is mappable to an XSD type model. XSD does not provide support for behaviors either. The project's XSD must add the project's behavior. XML databases deal with a single XSD document and lack organization and broad search capabilities. As with object-oriented databases, to support the data model described here, other concepts such as relationships and folders need to be incorporated into the XML database; and mechanisms such as synchronization, notification and security need to be implemented.

Regarding the following subsections, a few diagrams are provided to facilitate general information disclosure: Figure 13 is a diagram showing the notification mechanism. Figure 14 is a diagram showing an example where two transactions both insert new records into the same B-tree. Figure 15 shows the data change detection process. Figure 16 shows an exemplary directory tree. Figure 17 shows where an existing folder of a directory based file system is moved into a storage platform data store.

1. Data storage implementation using UDT

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

According to one aspect of the invention, storage platform schemas are mapped to UDT classes in database engine storage. Data store items are mapped to UDT classes derived from the Base.Item type. Similar to projects, extensions can also be mapped to UDT classes and use inheritance. The root extension type is Base.Extension, from which all extension types are derived.

A UDT is a CLR class that has state (ie data fields) and behavior (ie routines). Define UDTs using any managed language (c#, VB.NET, etc.). UDT methods and operators can be invoked on instances of this type in Transact-SQL. A UDT can be: the type of a column in a row, the type of a parameter of a routine in T-SQL, or the type of a variable in T-SQL.

The mapping of storage platform schemas to UDT classes is completely straightforward at a high level. In general, storage platform schemas are mapped to CLR namespaces. Storage platform types are mapped to CLR classes. CLR class inheritance mirrors storage platform type inheritance, and storage platform attributes are mapped to CLR class attributes.

2. Project Mapping

In order to hope that items can be searched globally, and support inheritance and type substitutability in the relational data of this embodiment, a possible implementation of item storage in database storage is in a class with type Base.Item Store all items in a single table of columns. Using type substitutability, items of all types can be stored, and searches can be filtered by subtypes of item types using Yukon's "is of(type)" operator.

However, due to the overhead involved in this embodiment associated with this approach, the items are divided by the top-level type, so that items for each "family" of types are stored into separate tables. In this partitioning schema, a table is created for each item type that directly inherits from Base.Item. As noted above, types inheriting from the following use type substitutability stored in the appropriate type family table. Only first-level inheritance from Base.Item is handled exclusively.

A "shadow" table is used to store a copy of all items' globally searchable attributes. This table can be maintained by the Update() method of the storage platform API, through which all data changes are made. Unlike the type family table, the global item table only contains the item's top-level scalar attributes, rather than the full UDT item object. The Global Items table allows navigation to Item objects stored in the Type Family table by exposing ItemID and TypeID. ItemID typically uniquely identifies an item in the data store. Metadata not described here can be used to map a TypeID to a type name and a view containing the item. Since finding an item by its ItemID is a common operation in the context of the global item table as well as in other cases, a GetItem() function is provided to retrieve an item object given an item's ItemId.

For ease of access and to hide implementation details as much as possible, all queries of a project can be made against views built on the tables of said project. Specifically, for each item type, create a view on the family table of the appropriate type. These type views select the associated type, including all items of subtypes. For convenience, in addition to UDT objects, views can display columns for all top-level fields of that type including inherited fields.

3. Extended mapping

Extensions are very similar to projects and have some of the same requirements. As another root type that supports inheritance, extensions are subject to many of the same considerations and trade-offs compared to storage. For this, a similar type family mapping is applied to extensions, rather than a single table approach. Of course, in other embodiments, a single table approach could be used. In this embodiment, an extension is associated with only one item through an ItemID, and contains an ExtensionID that is unique within the context of the item. As with Items, given an Identity comprising ItemID and ExtensionID pairs, a function may be provided for retrieving Extensions. Similar to item type views, views can be created for each extension type.

4. Nested element mapping

Nested elements are types that can be embedded into items, extensions, relationships, or other nested elements to form deeply nested structures. Similar to items and extensions, nested elements are implemented as UDTs, but they are stored in items and extensions. Thus, nested elements do not have a storage map beyond the map of their items and extending containers. In other words, there are no tables in the system that directly store instances of the NestedElement type, and no views dedicated to nested elements.

5. Object Identity

Every entity in the data model, ie every item, extension and relationship has a unique key value. An item is uniquely identified by its ItemId. Extensions are uniquely identified by composite keys (ItemId, ExtensionId). Relations are identified by composite keys (ItemId, RelationId). ItemId, ExtensionId and RelationshipId are all GUID values.

6.SQL object naming

All objects created in the data store can be stored in a SQL schema name derived from the storage platform schema name. For example, the storage platform base schema (often referred to as "basic") can generate types in the "[System.Storage]" SQL schema, such as "[System.Storage].Item". The generated names can be prefixed with a qualifier to eliminate naming conflicts. Where appropriate, use exclamation points (!) as delimiters for each logical part of the name. The table below summarizes the naming conventions used for objects in the data store. Each schema element (items, extensions, relationships, and views) is listed along with the decorated naming conventions used to access instances in the data store. object name modification describe example Main Project Search View Master! Item Provides an overview of projects in the current project domain [System. Storage]. [Master! Item] Typed item search view ItemType Provides all property data from the item and any parent types [AcmeCorp.Doc].[OfficeDoc] Main Extended Search View Master! Extension Provides an overview of all extensions in the current project domain [System. Storage]. [Master! Extension] Expanded search view by category Extension! extensionType Provides all property data to the extension [AcmeCorp.Doc].[Extension! SlickyNote] master relationship view Master! Relationship Provides an overview of all relationships in the current project domain [System. Storage]. [Master! Relationship] relationship view Relationship! relationshipName Provides all data associated with the given relation [AcmeCorp.Doc].[Relationship! AuthorsFromDocument] view View! viewName Provide columns/types based on schema view definition [AcmeCorp.Doc].[View! DocumentTitles]

7. Column naming

When mapping either object model to storage, naming conflicts may occur due to the additional information stored with application objects. To avoid naming conflicts, all non-type-specific columns (columns that do not map directly to named properties in the type declaration) are prefixed with an underscore character (_). In this embodiment, the underscore character (_) is not allowed as the beginning character of any identifier attribute. Furthermore, to unify naming between the CLR and the datastore, all attributes (relations, etc.) of a storage platform type or schema element shall have an uppercase first character.

8. Search View

Views are provided by the storage platform for searching stored content. SQL views are provided for each project and extension type. Additionally, views are provided to support relationships and views (defined by the data model). All SQL views and underlying tables in the storage platform are read-only. As described more fully below, data may be stored or changed using the Update( ) method of the storage platform API.

Every view defined directly in the storage platform schema (defined by the schema designer, not automatically generated by the storage platform) can be named by the SQL view [<schema-name>].[View! <view-name>] access. For example, a view named "BookSales" in the schema "AcmePublisher.Books" can be accessed using the name "[AcmePublisher.Books].[View!BookSales]. Because the view's output format is customized on a per-view basis (determined by any query provided by the party defining the view), columns are mapped directly based on the schema view definition.

All SQL search views in the storage platform data store use the following sorting conventions for columns:

Logical "keyword" columns for view results such as ItemId, ElementId, RelationshipId, etc.

• Metadata information about the result type such as TypeId.

Change tracking columns such as CreateVersion (create version), UpdateVersion (update version) etc.

Type-specific columns (properties of the declared type)

· Type-specific views (family views) also contain object columns for returned objects

Members of each type family are searchable using a series of item views, one view for each item type in the data store. FIG. 28 is a diagram showing the concept of an item search view.

a) project

A per-item search view contains one row for each instance of an item of a particular type or a subtype thereof. For example, a document view can return Document (document), LegalDocument (legal document), and ReviewDocument (review document) instances. Given this example, the project view can be conceptualized as in FIG. 29 .

(1) Main Item Search View

Each instance of a storage platform data store defines a special item view called the Master Item View. This view provides overview information about each item in the data store. The view provides one column for each item type attribute, one describing the type of item, and several columns providing change tracking and synchronization information. Use the name "[System.Storage].[Master!Item]" in the data store to identify the master item view. List type describe ItemId ItemId The project's storage platform identity _TypeId TypeId TypeId of the item - identifies the exact type of the item and can be used to retrieve information about the type using the metadata category _RootItemId ItemId the ItemId of the first non-embedded ancestor that controls the lifetime of this item <global change tracking> … global change tracking information <project properties> n/a There is a column for each item type attribute

(2) Item search view by type

Each item type also has a search view. Similar to the root item view, this view also provides access to item objects through the "_Item" column. Use the name [schemaName].[itemTypeName] in the data store to identify each type of item search view. For example [AcmeCorp. Dod]. [OfficeDoc]. List type describe ItemId ItemId The project's storage platform identity <type change tracking> … type change tracking information <parent attribute> <property only> one column for each parent attribute <project properties> <property only> One column for each exclusive attribute of this type _Item The CLR type of the project The type of item declared by the CLR object

b) Project extension

All project extensions in WinFs storage can also be accessed using the search view.

(1) Main Extended Search View

Each instance of the data store defines a special extension view called the master extension view (Master Extension View). This view provides overview information about each extent in the datastore. The view has one column for each extension attribute, one describing the type of extension, and several columns providing change tracking and synchronization information. Use the name "[System.Storage].[Master!Extension]" to identify the master extension view in the data store. List type describe ItemId ItemId The storage platform identity of the project associated with this extension ExtensionId ExtensionId (GUID) the id of this extension instance _TypeId TypeId TypeId of the extension - identifies the exact type of the extension and can be used to retrieve information about the extension using the metadata category <global change tracking> … global change tracking information <extended attribute> <property only> One column for each extension type attribute

(2) Expanded search view by type

Each extension type also has a search view. Similar to the main extension view, this view also provides access to project objects through the _Extension column. Use the name [SchemaName].[Extension! extensionTypeName] identifies the extension search view for each subtype. For example [AcmeCorp.Doc].[Extension! OfficeDocExt]. List type describe ItemId ItemId The storage platform identity of the project associated with this extension ExtensionId ExtensionId (GUID) The Id of this extension instance <type change tracking> … type change tracking information <parent attribute> <property only> one column for each parent attribute <extended attribute> <property only> One column for each exclusive attribute of this type _Extension The CLR type of the extension instance CLR object—the type of the declared extension

c) nested elements

All nested elements are stored in Item, Extension or Relationship instances. Therefore, they can be accessed by querying the appropriate project, extension or relational search view.

d) relationship

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

(1) Main relation search view

Each datastore provides a master-relational view. This view provides information about all relational instances in the datastore. Use the name "[System.Storage].[Master!Relationship]" in the data store to identify the master relational view. List type describe ItemId ItemId The identity of the source endpoint (ItemId) RelationshipId RelationshipId (GUID) the id of the relation instance _RelTypeId RelationshipsPTypeId RelTypeId for this relation - uses metadata category to identify the type of this relation instance <global change tracking> … global change tracking information TargetItemReference ItemReference The identity of the target endpoint _Relationship Relationship an instance of the Relationship object for this instance

(2) Relation instance search view

Each declared relationship also has a search view that returns all instances of that particular relationship. Similar to the main relational view, this view provides named columns for each attribute of the relational data. Use the name [schemaName].[Relationship! relationshipName] to identify each relationship instance search view. For example [AcmeCorp.Doc].[Relationship! DocumentAuthor]. List type describe ItemId ItemId The identity of the source endpoint (ItemId) RelationshipId RelationshipId (GUID) the id of the relation instance <type change tracking> … type change tracking information TargetItemReference ItemReference The identity of the target endpoint <source name> ItemId Named property of source endpoint identity (alias for ItemId) <target name> ItemReference or exported class Named property of target endpoint identity (alias and model(cast) of TargetItemReference) <relationship attribute> <property only> There is a column for each attribute defined by the relationship _Relationship The CLR type of the relation instance CLR object—declares the type of relationship

e)

9. Update

All views in the storage platform data store are read-only. To create new instances of data model elements (items, extensions, or relationships), or to update existing instances, the ProcessOperation or ProcessUpdategram methods of the storage platform API must be used. A ProcessOperation method is a single stored procedure defined by a data store that consumes an "operation" that refines the action to be performed. The ProcessUpdategram method is a stored procedure that takes an ordered set of operations called "updategrams" that together refine the set of actions to be performed.

The operation format is extensible and provides various operations on schema elements. Some common operations include:

1. Project operation:

a.CreateItem (create a new item in the context of embedding or holding a relationship)

b.UpdateItem (update an existing item)

2. Relational operations:

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

b.UpdateRelationship (update a relationship instance)

c.DeleteRelationship (remove a relationship instance)

3. Extended operation

a.CreateExtension (add an extension to an existing project)

b.UpdateExtension (update an existing extension)

c.DeleteExtension (delete an extension)

10. Change tracking and tombstones

As discussed more fully below, change tracking and tombstone services are provided by the data store. This section provides an overview of the change tracking information presented in the data store

a) change tracking

Each search view provided by the data store contains columns for providing change tracking information; those columns are common to all project, extension and relational views. A storage platform schema view explicitly defined by the schema designer does not automatically provide change tracking information - this information is provided indirectly through the search view upon which the view itself is built.

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

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

The change tracking information in the main search view provides information about the created and updated versions of an element, information about which sync partner created the element, information about which sync partner last updated the element, and information from each partner for creating and the updated version number. A partner in a synchronization relationship is identified with the partner keyword (described below). A single UDT object named _ChangeTrackingInfo of type [System.Storge.Store].ChangeTrackingInfo contains all this information. Define types in the System.Storage schema. _ChangeTrackingInfo is available in all global search views for projects, extensions, and relationships. The type definition of _ChangeTrackingInfo is: <Type Name="ChangeTrackingInfo"BaseType="Base.NestedElement"> <FieldProperty Name="CreationLocalTS" Type="SqlTypes.SqlInt64"Nullable="False"/><FieldProperty Name="CreatingPartnerKey" Type ="SqlTypes.SqlInt32"

Nullable="False"/><FieldProperty Name="CreatingPartnerTS" Type="SqlTypes.SqlInt64"

Nullable="False"/><FieldProperty Name="LastUpdateLocalTS" Type="SqlTypes.SqlInt64"

Nullable="False"/><FieldProperty Name="LastUpdatingPartnerKey"Type="SqlTypes.SqlInt32"

Nullable="False"/><FieldProperty Name="LastUpdatingPartnerTS" Type="SqlTypes.SqlInt64"

Nullable="False"/></Type>

These properties contain the following information: List describe _CreationLocalTS The local machine's creation time stamp _CreatingPartnerKey PartnerKey of the partner who created this entity. If the entity was created locally, this is the PartnerKey of the local machine _CreatingPartnerTS A timestamp of when this entity was created at the partner corresponding to _CreatingPartnerKey _LastUpdateLocalTS A local timestamp corresponding to the update time of the local machine _LastUpdatePartnerKey The PartnerKey of the partner who last updated this entity. This is the PartnerKey of the local machine if the last update to this entity was done locally. _LastUpdatePartnerTS A timestamp of when this entity was updated at the partner corresponding to _LastUpdatingPartnerKey.

(2) Change Tracking in "Categorized" Search Views

In addition to providing the same information as the global search view, each subtype of search view provides additional information about the synchronization status of each element recorded in the synchronization topology. List type describe <global change tracking> … Information from global change tracking _ChangeUnitVersions MultiSet<change unit version> A description of the version number of the unit of change in a particular element _ElementSyncMetadata ElementSyncMetadata Additional version-independent metadata about items that are only interested in synchronizing the runtime _VersionSyncMetadata VersionSyncMetadata Additional version-specific metadata about versions that are only interested in synchronizing the runtime

b) tombstone

Datastores provide tombstone information for projects, extensions, and relationships. The tombstone view provides information about both activities and tombstone entities (items, extensions and relationships) in one place. Project and extended tombstone views do not mention access to corresponding objects, while relational tombstone views provide access to relational objects (relational objects are null in case of tombstoned relations).

(1) Project Tombstone

Via view[System.Storage].[Tombstone! item] Retrieves the item tombstone from the system. List type describe ItemId ItemId project identity _TypeID TypeId type of item <project properties> … Properties defined for all items _RootItemId ItemId ItemId of the first non-embedded item containing this item _ChangeTrackingInfo A CLR instance of type ChangeTrackingInfo Change tracking information for this item _IsDeleted BIT This is the flag, 0 is the active item, 1 is the tombstone item _DeletionWallclock UTCDATETIME The UTC wall clock datetime of the partner of the deleted item, or empty if the item is active

(2) Extended Tombstone

Use the view [System.Storage].[Tombstone! Extension] Retrieves the extension tombstone from the system. Extension change tracking information is similar to that provided for projects with the addition of the ExtensionId property. List type describe ItemId ItemId The identity of the project that owns the extension ExtensionId ExtensionId ExtensionId of the extension _TypeID TypeId the type of extension _ChangeTrackingInfo A CLR instance of type ChangeTrackingInfo Change tracking information for this extension _IsDeleted BIT This is the flag, 0 is the active item and 1 is the tombstone extension _DeletionWallclock UTCDATETIME Press to remove the extension's partner's UTC wall clock day period. It is empty if the extension is active

(3) Relationship Tombstone

Via view[System.Storage].[Tombstone! Relationship] Retrieves relationship tombstones from the system. Relationship tombstone information is similar to the information provided for extensions. However, additional information is provided on the target ItemRef of the relation instance. Also, select the relationship object. List type describe ItemId ItemId The identity of the project that owns the relationship (the identity of the source endpoint of the relationship) RelationshipId RelationshipId the RelationshipId of the relationship _TypeID TypeId type of relationship _ChangeTrackingInfo A CLR instance of type ChangeTrackingInfo Change tracking information for this relationship _IsDeleted BIT This is the flag, 0 is the active item and 1 is the tombstone extension _DeletionWallclock UTCDATETIME By the UTC wall clock datetime of the partner who deleted the relationship. It is null if the relationship is active _Relationship CLR instance of relation This is the relationship object for active relationships, it is null for tombstone relationships TargetItemReference ItemReference The identity of the target endpoint

(4) Tombstone removal

To prevent unlimited growth of tombstone information, the data store provides a tombstone removal task. This task determines when tombstone information can be discarded. This task computes the bounds of locally created/updated versions and then truncates the tombstone information by discarding all earlier tombstone versions.

11. Helper API and functions

The base map also provides several helper functions. These functions are provided to facilitate common operations on this data model.

a) Function [System.Storage].GetItem

//Given ItemId returns an item object

Item Getltem(Itemld Itemld)

b) Function [System.Storage].GetExtension

//Given ItemId and ExtensionId return an extension object

Extension GetExtension(Itemld Itemld, Extensionld Extensionld)

c) Function [System.Storage].GetRelationship

//Given ItemId and RelationshipId return - relationship object

Relationship GetRelationship(Itemld Itemld, Relationshipld Relationshipld)

12. Metadata

There are two types of metadata represented in the store: 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

Applications use instance metadata to query an item's type and to find extensions associated with the item. Given an item's ItemId, an application can query the global item view to return the item's type, and use this value to query the Meta.Type view to return information about the item's declared type. For example,

// Returns the metadata item object for the given item instance

SELECT m._Item AS metadataInfoObj

FROM[System.Storage].[Item]i INNER JOIN[Meta].[Type]m ON i._Typeld＝m.Itemld

WHERE i.Itemld = @Itemld

G. Security

In general, all protectable objects use the access mask format shown in Figure 26 to arrange access rights. In this format, the lower 16 bits are used for object-specific access rights, the next 7 bits are used for standard access rights that apply to most object types, and the upper 4 bits are used to specify generic access rights, which are assigned to each object type. Maps to a standard set of object-specific permissions. The ACCESS_SYSTEM_SECURITY bit corresponds to the permission to access the object's SACL.

In the access mask structure of FIG. 26, item-specific permissions are placed in the object-specific permissions field (lower 16 bits). Since in this embodiment, the storage platform presents two sets of APIs to administrator security: Win32 and storage platform API, to facilitate the design of storage platform object-specific permissions, file system object-specific permissions must be considered.

The security model for the storage platform of the present invention is fully described in the related patents incorporated herein by reference. In this regard, Figure 27 (parts a, b, and c) depicts an embodiment in terms of a security model as new equally protected security areas carved out of existing security areas.

H. Notifications and Change Tracking

According to another aspect of the invention, the storage platform provides notification capabilities that allow applications to track data changes. This trait is primarily intended for use by applications that maintain volatile state or perform business logic on data change events. Applications register for notifications on items, item extensions, and item relationships. Data change notifications are delivered asynchronously upon commit. Applications can filter notifications by project, extension and relationship type, and action type.

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

Additional details regarding this functionality can be found in the related patents previously incorporated herein by reference.

I. Synchronization

According to another aspect of the invention, the storage platform provides a synchronization service 330 which (i) allows multiple instances of the storage platform (each with its own data store 302) to synchronize parts of their contents according to a flexible set of rules, and (ii) Provide an infrastructure for third parties to synchronize data storage of the storage platform of the present invention with other data sources implementing proprietary protocols.

Storage platform-to-storage platform synchronization occurs between a set of participating replicas. For example, referring to FIG. 3, it may be desirable to provide synchronization between data store 302 of storage platform 300 and another remote data store 338 (perhaps running on a different computer system) under the control of another instance of the storage platform. The full membership of this group need not be known for any given replica at any given time.

Different replicas can make changes independently (ie, simultaneously). The process of synchronization is defined so that each replica is aware of changes made by other replicas. This synchronization capability is inherently multi-master.

The synchronization capabilities of the present invention allow replicas to:

Determine which changes the other replica knows about;

Request information about changes that the replica is not aware of;

· transmit information about changes that the other replica is not aware of;

Determine when two changes conflict with each other;

Apply changes locally;

· Send conflict resolution solutions to other replicas to ensure convergence; and

• Decomposes conflicts based on specified policies of the conflict resolution scheme.

1. Synchronization from storage platform to storage platform

The basic application of the synchronization service 300 of the storage platform of the present invention is to synchronize multiple instances of a storage platform (each with its own data store). The synchronization service operates at the storage platform schema level (rather than in the underlying tables of the database engine 314). Thus, for example "Scope" is used to define the synchronization groups discussed below.

Synchronization services operate on the principle of "net change". Instead of recording and sending individual operations (such as transactional replication), a synchronization service sends the final results of those operations, thus often combining the results of multiple operations into a single final result.

Synchronization services generally do not respect transaction boundaries. In other words, if two changes are made to a storage platform data store in a single transaction, there is no guarantee that these changes are applied atomically to all other replicas—one change can be shown without the other. The exception to this principle is that if two changes are made to the same item in the same transaction, those changes are guaranteed to be sent and applied to the other replicas atomically. Thus, a project is a unit of consistency for the synchronization service.

a) Sync control application

Any application can connect to the synchronization service and initiate a sync operation. That application provides all the parameters needed to perform a synchronization (see Synchronization Overview below). Such applications are referred to herein as Synchronous Control Applications (SCA).

When synchronizing two storage platform instances, the synchronization is initiated by SCA on one side. The SCA notifies the local synchronization service to synchronize with the remote partner. On the other side, the sync service is woken up by a message sent by the sync service from the originating machine. It responds based on persistent configuration information (see mapping below) that exists on the target machine. Synchronization services can run on a schedule or in response to events. In these cases, the synchronization service that implements the schedule becomes the SCA.

To enable synchronization, two steps need to be taken. First, schema designers must annotate storage platform schemas with appropriate synchronization semantics (specifying change units as described below). Second, synchronization must be properly configured on all machines with instances of the storage platform participating in the synchronization (described below).

b) schema annotation

The basic concept of synchronization service is the concept of change unit (Change Unit). A unit of change is the smallest schema fragment tracked individually by the storage platform. For each unit of change, the synchronization service can determine whether it has changed or remained unchanged since the last synchronization.

Changing elements in the specified schema serves several purposes. First, it establishes how wordy the online sync service is. When a change is made within a change unit, the entire change unit is sent to the other replicas because the synchronization service does not know which part of the change unit was changed. Second, it determines the granularity of collision detection. When two concurrent changes are made to the same change unit (these terms are defined in detail in subsequent chapters), the synchronization service causes a conflict; on the other hand, if concurrent changes are made to different change units, no conflict occurs and the changes are automatically merge. Third, it severely affects the amount of metadata maintained by the system. A lot of sync service metadata is maintained for each unit of change; therefore, making the unit of change smaller increases the overhead of synchronization.

Defining the changing unit requires finding the right tradeoff. To this end, Synchronization Services allows schema designers to participate in the process.

In one embodiment, the synchronization service does not support change units larger than one element. However, it supports the ability for schema designers to specify units of change smaller than an element—that is, to combine multiple attributes of an element into a single unit of change. In this embodiment, this is accomplished using the following syntax: <Type Name="Appointment" MajorVersion="1" MinorVersion="0"ExtendsType="Base.Item"

ExtendsVersion="1">

<Field Name="MeetingStatus"Type="the storage platformTypes.uniqueidentifierNullable="False"/>

<Fileld Name="OrganizerName"Type="the storage platformTypes.nvarchar(512)"Nullable="False"/>

<Filed Name="OrganizerEmail"Type="the storage platform Types.nvarchar(512)"TypeMajorVersion="1" MultiValued="True"/>

…

<ChangeUnit Name="CU_Status"><Field Name="MeetingStatus"/>

</ChangeUnit>

<ChangeUnit Name="CU_Organizer"/><Field Name="OrganizerName"/><Field Name="OrganizerEmail"/>

</ChangeUnit>

...</Type>

c) Synchronization configuration

A group of storage platform partners who wish to keep some parts of their data in sync is called a sync community. Although members of the community wish to remain in sync, they do not need to represent the data in exactly the same way; in other words, sync partners can transform the data they are synchronizing.

In a peer-to-peer situation, it is impractical for peers to maintain translation maps for all their partners. Instead, the synchronization service takes the approach of defining "community folders". A community folder is an abstraction that represents a hypothetical "shared folder" that all community members are syncing with.

This concept is best illustrated with an example. If Joe wants to keep the My Documents (My Documents) folders of several of his computers synchronized, Joe defines a community folder, such as called JoeDocuments. Then on each computer, Joe configures a mapping between the hypothetical JoeDocuments folder and the local My Documents folder. From this point on, when Joe's computers synchronize with each other, they talk by means of documents in JoeDocuments rather than their local projects. In this way, all Joe's computers understand each other without having to know who the others are - the community folder becomes the lingua franca of the sync community.

Configuring the synchronization service consists of three steps: (1) defining the mapping between local folders and community folders; (2) defining the synchronization profiles that determine which gets synchronized (such as who to synchronize with, and which subset should be sent, which is received); and (3) define a schedule on which the different synchronization profiles should run, or run them manually.

(1) Community Folder - Mapping

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

This element names the mapped community folder. The names follow the syntax of folders. /mappings/localFolder

This element names the local folder to which the mapping is translated. This name follows the syntax rules for folders. For the mapping to work, the folder must already exist. Items in this folder are considered for each synchronization of this mapping. /mappings/transformations

This element defines how to convert projects from community folders to local folders and vice versa. If missing or empty, no conversion is performed. Specifically, this means that no IDs are mapped. This configuration is mainly used to create a cache of folders. /mappings/transformations/mapIDs

This element requests that a newly generated local ID be given to all projects mapped from the community folder, rather than reusing the community ID. The sync runtime maintains ID mappings to convert items back and forth. /mappings/transformations/localRoot

This element requests all root items in the community folder to be children of the specified root. /mappings/runAs

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

The presence of this element indicates that the sender of messages to this mapping must be impersonal and process requests under his credentials.

(2) Overview

A synchronization profile is the overall set of parameters required for a separate synchronization. It is provided by SCA to the sync runtime to start the sync. The synchronization profile for storage platform-to-storage platform synchronization contains the following information:

· Local folders, used as source and target for changes;

Name of remote folder to synchronize with - this folder must be published from the remote partner via the mapping defined above;

·Direction-synchronization service supports sending only, receiving only and sending-receiving synchronization;

• Local Filters - select what local information is sent to the remote partner. Expressed as a storage platform query on a local folder;

Remote Filters - select what remote information to receive from remote partners - expressed as storage platform queries on community folders;

Conversion - define how to convert between the project and the native format;

· Local Security—specifies whether changes retrieved from the remote endpoint are applied with the permission of the remote endpoint (personalization), or whether the user initiates the synchronization locally; and

• Conflict resolution policy—specifies whether conflicts should be rejected, logged, or resolved automatically—in the latter case, which conflict resolver to use and its configuration parameters.

The synchronization service provides runtime CLR classes that allow easy construction of synchronization profiles. Profiles can be serialized to and from XML files for easy storage (often along with timetables). However, there is no standard place to store all profiles in a storage platform; SCA is welcome to build profiles at points that do not have to be persistent. Note that it is not necessary to have a local mapping to initiate a sync. All synchronization information can be specified in the profile. However, to respond to a synchronization request initiated by a remote party, a mapping is required.

(3) Schedule

In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it relies on another component to accomplish this task—WindowsScheduler, available in the Microsoft Windows operating system. The sync service includes a command line utility that acts as an SCA and triggers syncs based on sync profiles saved in XML files. This utility makes it easy to configure Windows Scheduler on a schedule or in response to events such as user logon or logout.

d) Conflict handling

Conflict handling in the synchronization service is divided into three phases: (1) Conflict detection occurs when changes are applied—this step determines whether the changes can be safely applied; (2) Automatic conflict resolution and logging—In this step ( Occurs immediately after conflict detection) informational automatic conflict resolver to see if conflicts can be resolved - if not, conflicts can optionally be logged; and (3) conflict checking and resolution - if some conflicts have been resolved This step is taken if a conflict is logged and occurred outside of a sync session - at this point, the logged conflict can be resolved and removed from the log.

(1) Conflict detection

In this embodiment, the synchronization service detects two types of conflicts: knowledge-based and constraint-based.

(a) Knowledge-Based Conflict

Knowledge-based conflicts occur when two replicas make independent changes to the same unit of change. Two changes are said to be independent if they were made without mutual knowledge—in other words, the version of the first is not overwritten by knowledge of the second, and vice versa. The synchronization service automatically detects all those conflicts based on the knowledge of the above replicas.

It is sometimes helpful to think of conflicts as forks in the version history of changing units. Provided no conflicts occur during the life of a change unit, its version history is a simple chain—each occurrence after the previous one. In the case of a knowledge-based conflict, two changes happen in parallel, causing the chain to split into a version tree.

(b) Constraint-based conflicts

There are cases where independent changes, when applied together, violate integrity constraints. For example, creating two copies of a file with the same name in the same directory can cause that conflict to occur.

Constraint-based conflicts involve two independent changes (like knowledge-based conflicts), but they do not affect the same unit of change. Instead, they affect different change units, but there are constraints between them.

The synchronization service detects constraint violations when changing applications and automatically causes constraint-based conflicts. Resolving constraint-based conflicts usually requires custom code that modifies those changes in a way that does not break the constraints; the synchronization service does not provide a general mechanism for doing so.

(2) Conflict handling

Upon detecting a conflict, the sync service can take one of three actions (chosen by the sync initiator in the sync profile): (1) reject the change, returning it to the sender; (2) log the conflict in the conflicts log; or (3) automatically resolve conflicts.

If the change is rejected, the synchronization service acts as if the change did not reach the replica. A negative acknowledgment is sent back to the initiator. This split policy is primarily useful on leaderless replicas, such as file servers, where logging conflicts is not feasible. Instead, those replicas force other replicas to deal with those conflicts by rejecting them.

Synchronization initiators configure conflict resolution in their synchronization profiles. The synchronization service supports combining multiple conflict resolvers in a single profile in the following manner—first, by specifying a list of conflict resolvers, trying to resolve one after the other until one succeeds; second, by associating a conflict resolver with a conflict type Links, such as Guided Update—update knowledge-based conflicts to a resolver, but log all other conflicts.

(a) Automatic Conflict Resolution

The synchronization service provides several default conflict resolvers. Its list includes:

·Local win: If it conflicts with locally stored data, the incoming change will not be processed;

·Remote win: local data will not be processed if it conflicts with incoming changes;

Last write wins: picks local wins or remote wins for each unit of change based on the timestamp of the change (note that sync services generally do not depend on clock values; this conflict resolver is the only exception to this rule);

• Deterministic: Pick a winner in a way that is guaranteed to be identical across all replicas, but otherwise meaningless—one embodiment of the synchronization service implements this feature using a dictionary-like comparison of partner IDs.

Furthermore, ISVs can implement and install their own conflict resolvers. Custom conflict resolvers can accept configuration parameters; those parameters must be specified by SCA in the conflict resolution section of the synchronization profile

When the conflict resolver resolves a conflict, it returns to the runtime a list of operations (replacing conflicting changes) that need to be performed. The sync service then applies these operations with properly adjusted remote indications to include everything considered by the conflict handler.

Additional conflicts may be detected while the decomposition is being applied. In that case, the new conflict must be resolved before the original process can be restarted.

When considering conflicts as branches in a project's version history, conflict resolution can be thought of as a merge—combining two branches to form a single point. Therefore, conflict resolution transfers the version history to the DAG.

(b) Conflict logging

A very specific type of conflict resolver is a conflict logger. The synchronization service logs conflicts as ConflictRecord items. These records are in turn related to the project in conflict (unless the project itself has been deleted). Each conflict record includes: the incoming change that caused the conflict; the type of conflict; update-update, update-delete, delete-update, insert-insert, or constraint; and knowledge of the version of the incoming change and the replica that sent it. Logged conflicts are available for inspection and resolution as described below.

(c) Conflict review and resolution

The sync service provides an API to applications to examine the conflict log and suggest conflict resolutions therein. This API allows an application to enumerate all conflicts, or those related to a given item. Those applications are also allowed to resolve logged conflicts in one of three ways: (1) remote win - accept logged changes and overwrite conflicting local changes; (2) local win - ignore logged The conflicting part of the change; and (3) Propose a new change - where the application proposes a merge that, in its view, resolves the conflict. Once the conflicts are resolved by the application, the synchronization service removes them from the log.

(d) Convergence of replicas and propagation of conflict resolution

In the case of complex synchronization, the same conflict can be detected in multiple replicas. When this happens, several things happen: (1) the conflict can be resolved on one replica and the resolution sent to the other; (2) the conflict is automatically resolved on both replicas; and (3) Manually resolve conflicts on each replica (via the resolve check API).

To guarantee convergence, the synchronization service forwards conflict resolution to other replicas. When changes resolving conflicts arrive at replicas, the sync service automatically looks in the log for any conflicts resolved by this update, and resolves them. In this case, conflict resolution on one replica is bound to all other replicas.

If different replicas choose different winners for the same conflict, the synchronization service applies the principles of bound conflict resolution and automatically picks one of the two resolutions over the other. The winner is picked in a deterministic manner to ensure the same result at all times (one embodiment uses replica ID dictionary comparison).

If different replicas suggest different "new changes" for the same conflict, the sync service treats this new conflict as a special conflict and uses the conflict logger to prevent it from propagating to other replicas. That often happens during manual conflict resolution.

2. Synchronization of non-storage platform data storage

According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for the ISV to implement a sync adapter that enables the storage platform to synchronize with legacy systems such as Microsoft Exchange, AD, Hotmail, etc. A sync adapter benefits from a number of synchronization services provided by the synchronization services described below.

Despite its name, a sync adapter does not need to be implemented as a plug-in to a storage platform architecture. A "sync adapter" can simply be any application that utilizes the sync service runtime interface to obtain services such as change enumeration and application when needed.

To make it easier for others to configure and run synchronization to a given backend, writers of sync adapters are encouraged to expose a standard sync adapter interface that runs synchronization given the synchronization profile described above. Profiles provide configuration information to adapters that some adapters pass to the sync runtime to control runtime services (eg, folders to sync).

a) Synchronization service

Synchronization Services Provides several synchronization services to adapter writers. In the remainder of this section, it is convenient to refer to the machine on which the storage platform is doing the synchronization as the "client", and the non-storage platform backend that the adapter is talking to as the "server".

(1) Change the enumeration

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

Changes are enumerated based on the concept of an "anchor"—an opaque structure that represents information about the last synchronization. As mentioned in previous chapters, anchors take the form of stored platform knowledge. Synchronization adapters that utilize changing enumeration services fall into two broad categories: adapters that use "stored anchors" and adapters that use "provided anchors".

The distinction is based on where the information about the last sync is stored—on the client or on the server. Adapters often store this information easily on the client - the backend often cannot. On the other hand, if multiple clients are synchronizing with the same backend, it is inefficient and in some cases incorrect to store this information on the client—this leaves one client unaware that other clients have pushed to Server changes. If the adapter wants to use the anchor stored by the server, the adapter needs to send it back to the storage platform when changing the enumeration.

In order for the storage platform to maintain the anchor (for local or remote storage), the storage platform needs to know about the changes successfully applied on the server. These and only these changes can be included in the anchor. During change enumeration, the sync adapter uses the Acknowledgment interface to report which changes have been successfully applied. At the end of the sync, adapters using the provided anchor must read the new anchor (which aggregates all successfully applied changes) and send it to their backends.

Each adapter often needs to store adapter specific data as well as items that are inserted into the storage platform data store. Common examples of this data store are remote IDs and remote versions (time stamps). The sync service provides the mechanism for storing this data, while the change enumeration provides the mechanism for receiving this additional data and the changes to return. In most cases, this eliminates the need for the adapter to re-query the database.

(2) Change application

Change Apply allows sync adapters to apply changes received from their backend to the local storage platform. The adapter is expected to transition the change to storage platform mode. Figure 24 shows the process of generating storage platform API classes from the storage platform schema.

The main function of the change application is to automatically detect conflicts. As in the case of storage platform-to-storage platform synchronization, a conflict is defined as two overlapping changes made without mutual knowledge. When adapters use changes to apply, they must specify the anchor on which to perform conflict detection. If overlapping local changes not covered by the adapter's knowledge are detected, the change application causes a conflict. Similar to changing enums, adapters can use stored or provided anchors. Changes the effective storage of application-supported adapter-specific metadata. Such data can be appended by the adapter to the changes to be applied, and can be stored by the synchronization service. Data can be returned the next time the enumeration is changed.

(3) Conflict resolution

The conflict resolution mechanisms described below in IV (including logging and auto-resolution options) are also available for sync adapters. A sync adapter can specify policies for conflict resolution when an application changes. If specified, conflicts are passed to the specified conflict handler and resolved (if possible). Conflicts can also be logged. It is possible for the adapter to detect conflicts when attempting to apply local changes to the backend. In that case, the adapter can still pass conflicts to the sync runtime for resolution by policy. Additionally, sync adapters can request that any conflicts detected by sync services be sent back to them for processing. This is especially handy in cases where the backend can store or resolve conflicts.

b) Adapter implementation

While some "adapters" are simply applications that utilize the runtime interface, adapters are encouraged to implement the standard adapter interface. These interfaces allow a synchronization control application to: request that the adapter perform a synchronization for a given synchronization profile; cancel an ongoing synchronization; and receive a progress report (percent complete) on the ongoing synchronization.

3. Security

The synchronization service strives to introduce as little synchronization as possible into the security model implemented by the storage platform. Instead of defining new permissions for synchronization, existing permissions are used. specifically,

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

Anyone who can write to a datastore item can apply changes to that item; and

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

The synchronization service does not maintain security authorization information. When a change is made by user U at replica A, and forwarded to replica B, the fact that the change was originally made at A (by U) is lost. If B forwards this change to replica C, this is done under B's authority, not A's. This leads to the restriction that if a replica is not trusted to make its own changes to an item, it cannot forward changes made by other replicas.

This is done by the sync control application when the sync service is started. The synchronization service personifies the identity of the SCA and completes all operations (local and remote) under that identity. As an illustration, observe that user U cannot cause the local synchronization service to retrieve changes to items for which user U does not have read access from the remote storage platform.

4. Manageability

Monitoring a distributed community of replicas is a complex problem. The synchronization service may use a "sweep" algorithm to collect and distribute information about the state of the replica. The properties of the scanning algorithm ensure that information about all configured replicas is eventually collected and the failed (non-responsive) replica is detected.

Community-wide surveillance information is available on each replica. Monitoring tools can be run on any chosen replica to examine this monitoring information and make management decisions. Configuration changes must be made directly on the affected replica.

J. Legacy Document Interoperability

As mentioned above, at least in some embodiments, the storage platform of the present invention is intended to be implemented as an integral part of the hardware/software interface system of a computer system. For example, the storage platform of the present invention may be implemented as an integral part of, for example, the Microsoft Windows family of operating systems. In this respect, the storage platform API becomes part of the operating system API through which applications interact with the operating system. Thus, the storage platform becomes the device by which applications store information on the operating system, and thus the item-based data model of the storage platform replaces the traditional file system of this operating system. For example, when implemented in the Microsoft Windows family of operating systems, the storage platform can replace the NTFS file system implemented in that operating system. Currently, applications access the services of the NTFS file system through the Win32 API exposed by the Windows family of operating systems.

However, it should be recognized that completely replacing the NTFS file system with the storage platform of the present invention requires recoding existing Win32-based applications, and that such recoding may be undesirable, so the storage platform of the present invention provides Some kind of interoperability with existing filesystems would be beneficial. Therefore, in one embodiment of the present invention, the storage platform enables applications relying on the Win32 programming model to simultaneously access the contents of the data storage of the storage platform and the data storage of the traditional NTFS file system. To this end, the storage platform uses naming conventions that are a superset of the Win32 naming conventions to facilitate easy interoperability. In addition, Storage Platform supports accessing files and directories stored in Storage Platform volumes through Win32 API.

Additional details on this functionality can be found in the related patents previously incorporated herein by reference.

K. Storage Platform API

The storage platform includes APIs that enable applications to access the features and capabilities of the storage platform discussed above, and to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform of the present invention. Details regarding this functionality can be found in the related patents incorporated herein by reference, some of this information is summarized below for convenience.

Referring to FIG. 18, a containing folder is an item that contains a holding relationship with other items, and is equivalent to a file system folder of a general concept. Every project is "contained" in at least one containing folder.

FIG. 19 shows the basic architecture of the storage platform API according to this embodiment. The storage platform API uses SQL client 1900 to talk to local data store 302 and also uses SQL client 1900 to talk to remote data stores such as data store 340 . Local storage can also talk to remote data storage 340 using DQP (Distributed Query Processor) or through the storage platform synchronization service ("Sync") described above. The storage platform API 322 also acts as a bridge API for data storage notifications, passing the application's subscript to the notification engine and routing the notifications to the application (such as application 350a, 350b, or 350c) as described above. In one embodiment, the storage platform API 322 also defines a restricted "provider" architecture that enables it to access data in Microsoft Exchange and AD.

Figure 20 schematically represents various components of the storage platform API. The storage platform AP includes the following components: (1) data classes 2002, which represent storage platform elements and item types; (2) runtime framework 2004, which manages object persistence and provides support classes 2006; and (3) tools 2008, It is used to generate CLR classes from stored platform schemas.

The hierarchy of classes derived from a given schema directly reflects the hierarchy of types in that schema. As an example, consider the item types defined in the Contacts schema as shown in Figures 21A and 21B.

Figure 22 shows the runtime architecture in operation. The runtime architecture operates as follows:

1. The application 350a, 350b or 350c is bound to an item of the storage platform.

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

3. The application submits a Find on this ItemContext to get a collection of items; the returned collection is conceptually an object graph 2204 (due to relationships).

4. The application changes, deletes and inserts data.

5. The application saves the changes by calling the Update() method.

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

Figure 24 shows the process of generating storage platform API classes from the storage platform schema.

Figure 25 shows the schema on which the file API is based. The Storage Platform API includes namespaces for working with file objects. The namespace is called System.Storage.Files. The data members of the classes in System.Storage.Files directly reflect the information stored in the storage platform's storage; this information is "upgraded" from the file system object or created natively using the Win32 API. The System.Storage.Files namespace has two classes: FileItem (file item) and DirectoryItem (directory item). Members of these classes and their methods can be predicted by reviewing the schema diagram in Figure 25. FileItem and DirectoryItem are read-only from the storage platform API. To modify them, you must use the Win32 API or classes in System.IO.

With respect to an API, a programming interface (or simply an interface) can be thought of as any interface used to enable one or more pieces of code to communicate with or access functionality provided by one or more other pieces of code. Mechanisms, processes, protocols. Alternatively, a programming interface may be considered one or more mechanisms, methods, function calls, modules, objects, etc. of a component of a system capable of communicatively coupling to one or more mechanisms, methods, function calls, modules, etc. of other computers. The term "code segment" in the above statement is intended to include one or more instructions or lines of code, and includes, for example, a code module, object, subroutine, function, etc., regardless of the term applied, or code whether the pieces are compiled separately, or whether the code pieces are provided as source code, intermediate code, or object code, whether the code pieces are used in a runtime system or process, or whether they are located on the same or different machines or distributed across multiple machines, or Whether the function represented by the code segment is realized entirely by software, entirely by hardware, or a combination of hardware and software.

Conceptually, the programming interface can be viewed generically, as shown in Figure 30A or Figure 30B. Figure 30A shows the interface "Interface 1" as a pipe through which the first and second code fragments communicate. FIG. 30B shows that the interface includes interface objects I1 and I2 (which may or may not be part of the first and second code fragments), which enable the first and second code fragments of the system to communicate through the medium M. In FIG. 30B , the interface objects I1 and I2 can be considered as separate interfaces of the same system, and it can also be considered that the objects I1 and I2 plus the medium M constitute an interface. Although Figures 30A and 30B show a bi-directional flow and interfaces on each side of the flow, some implementations may only have information flow in one direction (or no information flow as described below), or have an interface on only one side object. By way of example and not limitation, terms such as application programming or program interface (API), entry point, method, function, subroutine, remote procedure call, and Component Object Model (COM) interface are included within the definition of programming interface.

Aspects of such programming interfaces may include methods by which a first code segment sends information to a second code segment (where "information" is used in its broadest sense and includes data, commands, requests, etc.); the second code segment The method of receiving information; and the structure, sequence, syntax, organization, mode, timing and content of that information. In this regard, the underlying transmission medium itself may be immaterial to the operation of the interface, whether that medium is wired or wireless, or a combination of both, as long as the information is transmitted in the manner defined by the interface. In some cases, information may not be transferred in one or both directions, in the conventional sense, when one piece of code only accesses functionality performed by a second piece of code, because the information transfer may be by or through another mechanism such as , the information is placed in a cache, file, etc. that is separate from the flow of information between code snippets) or does not exist. Any or all of these aspects may be important in a given situation, eg, depending on whether the code snippet is part of a loosely or tightly coupled configured system, and thus this list should be considered illustrative rather than limiting.

This concept of a programming interface is known to those skilled in the art and can be made clear by reading the above detailed description of the present invention. However, there are other ways of implementing the programming interface, and unless expressly excluded, these are also encompassed by the appended claims. These other methods may appear to be more sophisticated or complex than the views of Figures 30A and 30B, but they still perform similar functions to accomplish the same overall result. Some illustrative alternative implementations of the programming interface are now briefly described.

Decomposition: Communication from one piece of code to another can be achieved indirectly by splitting the communication into multiple discrete communications. This is schematically depicted in Figures 31A and 31B. As shown, some interfaces may be described in terms of groupability of functions. Thus, the interface functions of FIGS. 30A and 30B can be broken down to achieve the same result, as can mathematically provide 24, or 2 by 2 by 3 by 2. Therefore, as shown in FIG. 31A, the functions provided by the interface "Interface 1" can be subdivided to transform the communication of this interface into a plurality of interfaces "Interface 1A", "Interface 1B", "Interface 1C", etc. to achieve the same the result of. As shown in FIG. 31B, the functions provided by interface I1 can be subdivided into multiple interfaces I1a, I1b, I1c, etc. to achieve the same result. Similarly, the interface I2 of a second code fragment receiving information from a first code fragment may be decomposed into a plurality of interfaces I2a, I2b, I2c, and so on. When decomposed, the number of interfaces included in the first code fragment need not match the number of interfaces included in the second code fragment. In either case of Figures 31A or 31B, the functional spirit of the interfaces "Interface 1" and I1 remains the same as that of Figures 30A and 30B, respectively. The decomposition of an interface may also obey association, communication, and other mathematical properties, making the decomposition more difficult to identify. For example, command operations may be trivial, and thus the functionality performed by an interface may be better performed by another piece of code or interface before reaching that interface, or performed by a separate component of the system. Furthermore, those of ordinary skill in the programming arts will understand that there are various ways to make different function calls to achieve the same result.

Redefinition: In some cases, it is possible to omit, add, or redefine certain aspects of a programming interface (such as parameters) while still achieving the desired result. This is shown in Figures 32A and 32B. For example, assume that the interface "interface 1" of Figure 30A includes a function call Square(input, precision, output) (square), which includes three parameters, input (input), precision (precision) and output (output), and is determined by the A code snippet is distributed to a second code snippet. If the intermediate parameter precision does not matter in a given situation, as shown in Figure 32A, it can also be ignored or even replaced by a meaningless (in this case) parameter. It is also possible to add insignificant additional (additional) parameters. In either case, the function of square is achieved as long as the output is returned after the input has been squared by the second code snippet. It is also possible that precision is a parameter of great interest to some downstream or other part of the computing system; however, once it is recognized that precision is not necessary for the limited purpose of computing squares, it can be replaced or ignored. For example, instead of passing a valid precision value, pass a meaningless value such as date of birth without adversely affecting the result. Similarly, as shown in Figure 32B, interface I1 is replaced by interface I1', which is redefined to omit or add parameters to the interface. Interface I2 can similarly be redefined as interface I2', which is redefined to omit unnecessary parameters, or parameters that can be handled elsewhere. The point here is that in some cases, a programming interface may include aspects, such as parameters, that are not required for a purpose, so they can be ignored or redefined, or handled elsewhere for other purposes.

Inline code: It is also possible to merge some or all of the functionality of two separate code modules so that the "interface" between them changes form. For example, the functions of Figures 30A and 30B can be transformed to the functions of Figures 33A and 33B, respectively. In FIG. 33A, the previous first and second code fragments of FIG. 30A are merged into a module containing both. In this case, the code fragments can still communicate with each other, but the interface can be adapted to a form more suitable for a single module. Thus, for example, formal call (Call) and return (Return) statements will no longer be necessary, but similar processing or responses according to the interface "Interface 1" are still valid. Similarly, as shown in FIG. 33B, part (or all) of interface I2 of FIG. 30B can be embedded into interface I1 to form interface I1". As shown in the figure, interface I2 is divided into I2a and I2b, and the interface part I2a is embedded in interface I1 to write code to form interface I1″. For a concrete example, consider that interface 1 of Figure 30B executes a function call square(input, output), which is received by interface I2, which is used after the value passed to input is processed (squared) by the second code fragment output passes back the squared result. In this case, the processing performed by the second code fragment (squaring input) can be performed by the first code fragment without calling this interface.

Disengagement: Communication from one piece of code to another can be done indirectly by splitting the communication into multiple discrete communications. This is schematically depicted in Figures 34A and 34B. As shown in Figure 34A, one or more fragments of middleware (Divorce Interface (Divorce Interface), because they are separated from the original interface function and/or interface function) are provided to transform the first interface "Interface 1" so that they comply with different interfaces, in this case "Interface 2A", "Interface 2B" and "Interface 2C". This can be done in a case where, for example, the installed base of applications is designed according to the "Interface 1" protocol to communicate with, for example, the operating system, but then the operating system is changed to use a different interface, in this case the interface " Interface 2A", "Interface 2B" and "Interface 2C". The gist is that the original interface used by the second code fragment is changed such that it is no longer compatible with the interface used by the first code fragment, so an intermediary is used to make the old interface compatible with the new interface. Similarly, as shown in Figure 34B, a third code fragment can be introduced using breakaway interface DI1 to receive information from interface I1, and use breakaway interface DI2 to introduce a third code snippet to send interface functions to, for example, interfaces I2a and I2b, redesigning the interface I2a and I2b use DI2, but provide the same functional results. Similarly, DI1 and DI2 may work together to translate the functionality of interfaces I1 and 12 of FIG. 30B into a new operating system, while providing the same or similar functional results.

Rewriting: Yet another possible variation is to dynamically rewrite the code, replacing the functionality of the interface with something else, while still achieving the same overall result. For example, there may be a system in which a Just-in-Time (JIT) compiler in an execution environment such as that provided by the .Net framework, the Java runtime environment, or other similar runtime-type environment Or an interpreter provides code snippets rendered in an intermediate language such as Microsoft IL, JavaByteCode, etc. A JIT compiler can be written to dynamically translate communications from a first code fragment to a second code fragment, ie to conform them to different interfaces required by the second code fragment (either the original or a different second code fragment). This is depicted in Figures 35A and 35B. As seen in Figure 35A, this approach is similar to the disengagement situation described above. It can be done, for example, where the installed base operating system of an application is designed to communicate in accordance with the "interface 1" protocol, and then the operating system is changed to use a different interface. A JIT compiler can be used to conform the air communication of the installed base application to the new interface of the operating system. As depicted in FIG. 35B, this method of dynamically rewriting an interface can be applied to dynamically decompose, or change the interface.

It should be noted that the above-mentioned situation of achieving the same or similar results as the interface through alternative embodiments can also be serialized, paralleled, or combined with other intervening codes in various ways. Thus, the alternative embodiments presented above are not mutually exhaustive and can be mixed, matched and combined to create the same or equivalent situations as the general situation presented in FIGS. 30A and 30B . It should also be noted that, like most programming constructs, this invention may not describe other similar ways of achieving the same or similar functionality as an interface, but they are nonetheless represented by the spirit and scope of this invention, i.e., it should be noted that it is at least partially is a function represented by, or an advantageous consequence enabled by, an interface upon which its value is based.

III. Extension and Inheritance

A fundamental concept of the present invention is to utilize projects, which model real-world application objects in part with complex structures, behaviors and operations described by schemas and implemented by hardware/software interface systems. To provide rich subtyping capabilities, and in various embodiments of the present invention, a hardware/software interface system (hereinafter referred to simply as "WinFS" for convenience) may provide a mechanism by which "extended " to extend the project (and project type). Extensions provide additional data structures (attributes, relationships, etc.) to an already existing item type structure.

As discussed earlier in this paper (and in particular in Sections II.E.6.(a) and II.F.3), although it is intended to provide an initial set of schemas for storage platforms, at least some implementations The example storage platform allows customers including independent software vendors (ISVs) to create new schemas (ie, new items and nested element types). Since the item types or nested element types defined by the initial set of storage platform schemas do not exactly meet the needs of ISV applications, it is necessary to allow ISVs to customize the types. This is allowed with the concept of extension. Extensions are strongly typed instances but (a) they cannot exist independently and (b) they must be attached to an item or nested element. Moreover, in addition to addressing the need for schema extensibility, extensions also address the "multiple typing" issue. Since the storage platform does not support multiple inheritance or overlapping subtypes in some embodiments, applications can use extensions as a way of modeling instances of overlapping types (for example, a document can be a "legal document" or a "safe document") .

A) type system

In various embodiments of the invention, the WinFS type system provides a mechanism to define the structure of data. A type system is used to represent data stored in WinFS. WinFS types are declared in WinFS schemas. A WinFS schema defines a namespace that serves as a logical grouping for a set of types and other WinFS schema elements. WinFS schemas can be declared using the WinFS Schema Definition Language (SDL), which may use the XML language. The following is an example of a possible schema declaration:

<Schema Namespace="System.Storage">

Type definitions

</Schema>

WinFS schemas are also used as type versioning units. WinFS defines several system modes for booting the system. These are the System.Storage schema namespace, which contains type declarations for the root types in the system, and the System.Storage.WinFS schema namespace, which declares all the basic scalar types in the system.

The WinFS type system declares a simple set of scalar types. These types serve as the most basic building blocks for all other types in the WinFS type system. These types are declared in the schema namespace System.Storage.WinFS. The following table defines the collection of primitive types. WinFS type Managed SQL Types CLR type describe String SqlString String Variable-length Unicode data has a maximum length of 2^31 characters in length. Use "max" (maximum) keyword length can be fixed or unlimited from 1-4000 characters. Binary SqlBinary Byte[] Variable-length binary data has a maximum length of 2^32 bytes in length. Using the "max" (maximum) keyword length can be fixed or unlimited from 1-8000 bytes. Boolean SqlBoolean Boolean Boolean value that can be NULL Byte SqlByte Byte single unsigned byte Int16 SqlInt16 Int16 Integer data from -2^15 (-32, 768) to 2^15-1 (32, 767) Int32 SqlInt32 Int32 Integer (integer) data from -2^31 (-2, 147, 483, 648) to 2^31-1 (2, 147, 483, 647) Int64 SqlInt64 Int64 Integer (integer) data from -2^63 (-9223372036854775808) to 2^63-1 (9223372036854775807) Double SqlDouble Double Floating point precision data from -3.40E+38 to 3.40E+38 Single SqlSingle Single Floating point precision data from -1.79E+308 to 1.79E+308 Decimal SqlDecimal Decimal SQLDecimal has a larger range of values than the CLRDecimal type. Precision is always 28 numbers in memory word and the scale is 0. DateTime SqlDateTime DateTime Date and time, from January 1, 1753 to December 31, 9999, with an accuracy of three hundredths of a second or 3.33 seconds Guid SqlGuid Guid Globally Unique Identifier (GUID) Xml SqlXmlReader XmlReader For Milestone B, WinFS.Xml will be mapped to "String" type. True XML datatype support is expected in milestone C. Stream TBD TBD Binary data type, used for efficient access using file stream-enabled storage. This type will be supported in milestone C.

A WinFS enumeration is a scalar type that declares a named set of constants, called a list of values. Enumerated types can be used anywhere scalar types can be used. Here is an example of an enum declaration:

<Enumeration Name="Gender">

<Value Name="Male"/>

<Value Name="Female"/>

</Enumeration>

Enumeration values are zero-based. In the above example Gender.Male represents a value of 0 and Gender.Female represents a value of 1.

Complex types are defined by a name and a set of properties. Properties are member fields of a type and are defined by name and type. The type of an attribute can be scalar (including enumerated types) or can be other complex types. WinFS types that can be used as types for attributes are called nested types. An instance of a nested type can only exist as an attribute value of an attribute of a complex WinFS type -- the instance is nested within an instance of a complex type. Nested types are declared using the NestedType (nested type) schema element. Here are some examples of valid type declarations:

<NestedType Name="Address"BaseType="System.Storage.NestedObject">

<Property Name="Street"Type="WinFS.String"Size="256"

Nullable="false"/>

<Property Name="City"Type="WinFS.String"Size="256"

Nullable="false"/>

<Property Name="State"Type="WinFS.String"Size="256"

Nullable="false"/>

<Property Name="Country"Type="WinFSString"Size="256"

Nullable="false"/>

</NestedType>

<ItemType Name="Person"BaseType="System.Storage.Item">

<Property Name="Name"Type="WinFS.String"Size="256"

Nullable="false"/>

<Property Name="Age"Type="WinFS.Int32"

Nullable="false"Default="1"/>

<Property Name="Picture"Type="WinFS.Binary"Size="max"/>

<Property Name="Addresses"Type="MultiSet"MultiSetOfType="Address"/>

</ItemType>

For properties of type String and Binary, the Size attribute must be specified. This attribute specifies the maximum size of the value contained in the Property. Properties can optionally declare a nullable constraint using the Nullable attribute. A value of "false" for this attribute indicates that the application must provide a value when creating an instance of this type. Another optional Property attribute is the Default attribute, which specifies the default value for the Property. This value will be assigned to the Property when the instance is created, if the application does not provide it.

In the above example the Addresses property is of type MultiSet. MultiSet (multiple settings) type attributes are also known as multi-valued attributes. In this example the MultiSet contains a set of instances of type Address. A MultiSet is similar to a Set. It can contain zero or more instances of complex types. The type of the instance in the MultiSet must be a complex nested type. The MultiSet type does not support instances of WinFS scalar types (including enumerated types). Properties of type MultiSet cannot be nullable and cannot have a default value.

WinFS supports single inheritance of types. All types in WinFS must inherit from one and only one WinFS type. The inherited type is called a derived type and the type from which this type is derived is called a base type. The base type in the BaseType attribute of the WinFS declaration element. Suppose type A derives from base type B, which in turn derives from type C. Type C is the ancestor type of Type A and Type B. Type A is a descendant of types B and C. Data instances stored in WinFS are always instances of a single type. However, a data instance can be thought of as a set of instances of a type that includes that type and all its ancestor types. For a data instance that is an instance of such a set of types, invoke a type that is not an ancestor of any other type in the set of most-derived types. A single typed data instance is an instance of the last derived type. In general, the last derived type of an individually typed element is referred to as its type. A derived type inherits all properties declared in its base type. Derived types can declare new properties but cannot override properties defined in the base type. Properties declared in derived types must not use the same name as properties of the base type.

The main advantage of inheritance in the data model comes from the substitutability of inherited types. Consider the following example:

<NestedType Name="Name"BaseType="System.Storage.NestedObject">

<Property Name="FirstName"Type="WinFS.String"/>

<Property Name="LastName"Type="WinFS.String"/>

</Nestedype>

<NestedType Name="NameWithMiddleInitial"BaseType="Name">

<Property Name="MiddleInitial"Type="WinFS.String"/>

</NestedType>

<NestedType Name="Person" BaseType="System.Storage.Item">

<Property Name="RealName"Type="Name"/>

<Property Name="OtherNames"Type="MultiSet"MultiSetOfType="Name"/>

</NestedType>

In the example above, the type Person has an attribute RealName of type Name and an attribute OtherNames of type Name as a set. It is usually required that the attribute RealName (real name) has only instances of its type Name (name). However, through inheritance, single-valued instances are allowed to be the value of RealName as long as the Name type is one of the ancestors of the element's last derived type. Thus, an instance of NameWithMiddleInitial (name with middle initial) will allow to be the value of property RealName (real name).

Extend the same rules to set properties. The attribute OtherNames (other names) contains a set of elements. For each individually typed instance that is a member of the set, that instance's last derived type must have Name as one of its ancestors. Thus, some instances in the set OtherNames may be instances of type Name, while others may be instances of type NameWithMiddleInitial (names with middle initials).

Inheritance also supports convenient queries, since it is possible to find all instances of a certain type in the WinFS system. When looking up all instances of a type, the query engine will also return all instances whose last derived type is a descendant of this type. However, only item, extension, and relationship types (not property types) support these operations. For nested types (aka nested element, attribute, or complex attribute types), only instances contained within a single multiset attribute support this operation.

B. Type Families

In summary, the WinFS type system defines four distinct type families:

Nested element types (also known as nested types or attribute types)

·project type

·Relationship type

·Extension type

Each type family has a different set of attributes and usages in the WinFS type system. The System.Storage schema namespace declares four types that serve as the root types for each type family. The following sections describe these type systems in detail.

1. Nested element types

Unlike other families of WinFS types, nested types can be used as types for attributes of complex WinFS types. An instance of a nested type can only be nested inside an instance of another complex type. However, instances of nested types cannot be queried globally—that is, an application cannot write a simple query that returns all instances of a given nested type in WinFS storage.

2. Project type

A WinFS item is an instance of a type whose ancestor is of type System.Storage.Item. This type is the complex type that is the root of the project type family. System.Storage.Item declares a property named ItemID (item ID) of type Guid. This is a special property of an item and is used as the item's primary key. The value of this property is guaranteed to be unique for a given item in WinFS storage. This property cannot be null and must be assigned by the application when creating an instance of the item type. The ItemID (item ID) property is also immutable -- it never changes and must not be reused.

The query engine can return instances of a given item type in WinFS storage. This query returns all instances of this type and all of its descendant types. The central role that items have in the operational semantics of the WinFS system is described later in this document.

3. Relationship type

Relationship types enable relationships to exist between items. WinFS relationship types describe binary relationships where one item is designated as the source and another item is designated as the target. A relationship is an instance of a type whose ancestor is of type System.Storage.Relationship. This type is the root of the relationship type hierarchy. The System.Storage.Relationship type declares the following properties:

· SourceItemID (source item ID) - the ItemID (item ID) of the item that is the source of the relation instance

· RelationshipID (relationship ID) -- relative to the unique identifier of the relationship of the source item; (SourceItemID (source item ID), RelationshipID (relationship ID)) pair forms the primary key of the relationship in WinFS

· TargetItemId (target item ID)--ItemID (item ID) of the target of the relationship

Mode (way) - one of 3 possible relationship instance modes: Holding (holding), Embedding (embedding) or Reference (quoting)

Name (name) - the name of the containing relationship used to hold the relationship

· IsHidden (whether hidden) - Boolean attribute, the application can optionally use it to filter relations that do not need to be displayed

SourceItemID (source item ID), RelationshipID (relationship ID), TargetItemId (target item ID) and Mode (way) property values are immutable. They are assigned at relation instance creation time and cannot be changed.

A relational type is declared as a complex type with the following additional constraints:

· Source and target endpoint specification: each endpoint specifies the name and type of the referenced item

Allowed modes for instances of relation types: relation instances cannot have values for the Mode attribute that are not allowed in relation declarations

Here is an example of a relationship declaration:

<RelationshipType Name="DocumentAuthor"

`` BaseType="System.Storage.Relationship"

AllowsHolding="true"

AllowsEmbedding="false"

  AllowsReference="true">

<Source Name="Document"Type="Core.Document"/>

<Target Name="Author"Type="Core.Contact"/>

<Property Name="Role"Type="WinFS.String"/>

<Property Name="DisplayName"Type="WinFS.String"/>

</RelationshipType>

The DocumentAuthor (document author) relationship is declared with the restriction of the instance to Holding (holding) or Reference (reference). This means that instances of the DocumentAuthor relationship can have instances with values Mode="Reference" or Mode="Holding". Instances with value Mode="Embedding" are not allowed.

A relationship declares a source endpoint named "Document" of item type "Core.Document" and a target endpoint of item type "Core.Contact". The relationship also declares two additional properties. Relationship instances are stored and accessed separately from items. All relationship instances are accessible from the global extension view. A query can be written to return all instances of a given relationship type.

Given an item, all relationships for which that item is a source can be enumerated based on the relationship's SourceItemID property. Likewise, for a given item, all relationships in the same store that target that item can be enumerated using the relationship's TargetItemId property.

a) Relational Semantics

The following sections describe the semantics of the different ways of instantiating relationships:

Holding Relationships: Holding relationships are used to model the reference count-based lifespan management of the target project. A project can have zero or more source endpoints related to the project. An item that is not an embedded item can be the target of one or more holding relationships. The target project must be in the same storage as the relation instance.

Holding a relationship enforces lifetime management of the target endpoint. The creation of the holding relation instance and the item as the target is an atomic operation. Additional holding relationships can be created targeting the same project. When the last holding relationship instance with a given item as target endpoint is deleted, the target item is also deleted.

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

Holding relationships play a key role in forming the WinFS project namespace. All holding relationships participate in namespace declarations. The "Name" attribute in the relationship declaration declares the name of the target project relative to the source project. This relative name is unique for all holding relationships originating from a given project and cannot be null. This ordered list of relative names starts from the root item to a given item forming the full name of the item.

Holding relationships form a directed acyclic graph (DAG). When the holding relationship is created, the system ensures that no loops are generated, thus ensuring that the project namespace forms a DAG. For more information on WinFS namespaces and project paths, refer to the "WinFS Namespaces" specification.

Embedded Relationships: Embedded relationships model the notion of exclusive control over the lifetime of a target item. They support the concept of compound items. The creation of an embedded relation instance and an item as a target is an atomic operation. An item can be the source of zero or more embedded relationships. However, an item can be the target of one and only one embedded relation. An item that is the target of an embedded relationship cannot be the target of a holding relationship. The target project must be in the same storage as the relation instance.

The endpoint item type specified in the relationship declaration will be implemented when an instance of the relationship is created. The type of an endpoint item cannot be changed after the relationship is established. Embedding relationships do not participate in WinFS namespaces. The value of the Name property of an embedded relationship must be null.

Reference relationship: A reference relationship does not control the lifetime of the item it references. A referential relationship does not guarantee the existence of the target, nor the target type as specified in the relationship declaration. This means that reference relationships can be dangling. Also, reference relationships can refer to items in other WinFS storage.

Reference relationships in WinFS will be used to model most non-lifetime managed relationships between items. Reference relationships are convenient for modeling loosely coupled relationships since the existence of the target is not enforced. Reference relationships can be used for target items in other WinFS storage (including storage on other machines). Embedding relationships do not participate in WinFS namespaces. The value of the Name attribute of an embedded relationship must be null.

b) Relational Rules and Constraints

The following additional rules and constraints apply to relationships:

• An item must be the target (with respect to an embedded relationship) or (one or more holding relationships). One exception is the root project. An item can be the target of zero or more reference relationships.

• An item that is the target of an embedded relationship cannot be the source of the holding relationship. It can be the source of a reference relationship.

· An item cannot be the source of a hold relationship if it is promoted from a file. It can be the source of embedded and referenced relationships.

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

When relation type A is derived from base relation type B, the following rules apply:

• Relationship type A can further restrict endpoint types. An endpoint type must be a subtype of the corresponding endpoint type in base relation B. If the endpoint is further restricted, a new name must be declared for the endpoint. The specification of an endpoint is optional if the endpoint is not constrained

• A relation type A can further restrict the allowed instance modes declared in the base relation. The restricted set of instance modes must be a subset of the base types of the allowed instance types.

• Endpoint names are treated as attribute names: they are not the same as the attribute name or the endpoint name or its base type.

The source and target elements are optional if the corresponding endpoint type is not further constrained by the derived relationship

Here is an example of a declaration of a relation type derived from the DocumentAuthor relation defined above in this article:

<RelationshipType Name="LegalDocumentAuthor"

`` BaseType="Core.DocumentAuthor"

AllowsHolding="false"

AllowsEmbedding="false"

  AllowsReference="true">

<Source Name="LegalDocument"Type="Legal.Document"/>

<Property Name="CaseNumber"Type="WinFS.String"/>

</RelationshipType>

The LegalDocumentAuthor relationship also restricts the source endpoint but not the target endpoint. The source endpoint type is Legal.Document, which is derived from Core.Document. The target endpoint is not further restricted in this example, so the target element is omitted. Relationships further restrict the allowed instance modes. It does not allow the Holding method and the only allowed method of holding is a reference.

4. Extension type

A WinFS extension is an instance of a type whose ancestor is the System.Storage.Extension type. This type is the complex type that is the root of the extended type family.

· System.Storage.Extension defines two properties:

ItemID (item ID) - the ItemID (item ID) of the item associated with the extension

· ExtensionID (extension ID) - the unique identifier of the extension relative to the ItemID (item ID). The (ItemID (item ID), ExtensionID (extension ID)) pair uniquely identifies an extension instance.

The following restrictions apply to extension types:

· An instance of an extension type cannot exist independently of an item. An ItemType instance with the same ItemID as the extension ItemID must exist in memory before the extension Type instance is created. If an item with the given ItemID does not exist, the extension cannot be created. When this item is deleted, all extensions with the same ItemID (item ID) are deleted.

• At most one instance of a given last exported extension type may be associated with a single item.

• An extension cannot be the source and target of a relationship.

There are no constraints on the types of extensions that can be associated with a given item type. Any extension type is allowed to extend any item type. When multiple instances of different extension types are attached to a project, they are independent of each other, both structurally and behaviorally. Extension instances are stored and accessed separately from projects. All extension instances are accessible from the global extension view. A query can be written to return all instances of an extension of a given type, no matter what type of item they are associated with. Extended ItemIDs indicate which item they belong to and can be used to retrieve the corresponding item object from the global item view. Also, given an item, all extension instances associated with that item can be enumerated using the extension's ItemID (item ID) property.

C. Enhanced functionality

In several embodiments of the invention, the hardware/software interface system utilizes extension and inheritance to formalize relationships between various items, thereby enhancing the ability to query multiple items.

1. Inheritance

Figure 36 shows a subset of a series of interrelated items and their relationships. Document (document) item 3602 and Contact (contact person) item 3604 are related directly by specified relation 3606, in this example, relation 3606 is " author relation " -- that is, Contact (contact person) 3604 is Document (document). )3602 "Author". In this example, the Picture (photo) item 3622, the Music (music) item 3624, and the Special (special) item 3626 all inherit from the Document (document) item 3604, because the type of each item is a child of the Document (document) item type. type. Likewise, the Person item 3642 and the Organization item 3644 inherit from the Contact item 3604 . In several embodiments of the invention, these inherited items (Person (personal) 3622, Music (music) 3624, Special (special) 3626, Person (personal) 3642 and Organization (organization) 3644) not only inherit the corresponding parent items ( Document (document) 3602 and Contact (contact) 3604), and they also inherit the relationship specified between these two parent items. For example, Person 3622 inherits relationship 3662 to Contact 3664 , relationship 3664 to Person 3642 and relationship 3666 to Organization 3644 . A similar set of relationships is also inherited by every other item shown.

It is important to note, however, that relational inheritance is not automatic and does not occur in every context. For example, properties that describe when a type can be inherited (ie, inheritance controls) are not themselves inheritable. Inherited parameters are saved and adjusted by the hardware/software interface system.

2. Expand

Figure 37A illustrates the disadvantages of standard subtyping of items for application-specific purposes. In this figure, Contact can be accessed by four applications, APP1, APP2, APPX and APPY. APP1 and APP2 access the standard Contact, but APPX and APPY each require an extended Contact object (adding additional fields), thus exporting Contact' and Contact", which each inherit from Contact. However, the problem is that there are now three different instances of the basic Contact item - one in Contact, one in Contact', and one in Contact".

A partial solution to this problem, as shown in Figure 37B, is to extend the Contact attribute to include the fields required for such an application. In this case, Extend Contact to include the additional fields required by APPX. However, directly extending an item such as a Contact field can only be done once, so APPY cannot use this method.

In one embodiment of the present invention, a more comprehensive solution is to extend Contact with a different and separate extension than Contact itself. In this way, APPX can extend Contact (contact) to include its APPX additional field, and APPY can also extend Contact (contact) to include its APPY additional field. These extensions are then searchable and queryable, and thus these extensions support multi-typed forms for hardware/software interface systems.

IV. Conclusion

As previously indicated, the present invention is directed to a storage platform for organizing, searching, and sharing data. The storage platform of the present invention extends and expands the concept of data storage beyond existing file systems and database systems, and is designed for storage of all types of data, including structured, unstructured, or semi-structured standardized data such as relational (tabular) data, XML, and a new form of data called items. Through its shared storage of functions and schematized data, the storage platform of the present invention allows for more efficient application development for customers, knowledge workers, and enterprises. It provides a rich and extensible application programming interface that not only makes use of the capabilities inherent in its data model, but also encompasses and extends existing file system and database access methods. It will be appreciated that changes may be made to the above-described embodiments without departing from the broad inventive concepts thereof. It is therefore intended that this invention not be limited to the particular embodiments disclosed, but it is intended by the appended claims to cover modifications which are within the spirit and scope of the invention.

As becomes apparent from the above, all or a portion of the various systems, methods, and aspects of the present invention may be embodied in the form of program codes (ie, instructions). Such program code may be stored on a computer readable medium such as a magnetic, electronic or optical storage medium including, without limitation, a floppy disk, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, tape, flash memory, hard drive, or other machine-readable storage medium, wherein when the program code is loaded into a machine such as a computer or server and executed by the machine, the machine becomes a means for implementing the present invention . The present invention can also be embodied in the form of program code transmitted over some transmission medium, such as on a wire or cable, through an optical fiber, on a network, including the Internet or an intranet, or through any other form of Transmission wherein, when the program code is received and loaded into and executed by a machine such as a computer, the machine becomes a means for carrying out the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique means of resembling the operation of specific logic circuits.

Claims (42)

1. extension purpose method, but described project consists of the discrete memory cell of the information that can be processed by hardware/software interface system, described method comprises that the example (" expansion ") that utilizes strong typing expands described project, but described expansion consists of the discrete memory cell of the information that can be processed by described hardware/software interface system.

2. the method for claim 1 is characterized in that, described expansion is additional to described project.

3. the method for claim 1 is characterized in that, described expansion can not be independent of described project and exist, if thereby described project stop to exist, then described expansion also stops to exist.

4. the method for claim 1 is characterized in that, described project is expanded by a plurality of expansions.

5. method as claimed in claim 4 is characterized in that, described a plurality of expansions are used for the overlapping type instance of modelling.

6. method that is used for extended attribute, described attribute consists of can be by the complex properties type of hardware/software interface system processing, described method comprises utilizes strong typing example (" expansion ") to expand described attribute, but described expansion consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, and is associated with described attribute.

7. method as claimed in claim 6 is characterized in that, described expansion is additional to described attribute.

8. method as claimed in claim 6 is characterized in that, described expansion can not be independent of described attribute and exist, if thereby described attribute stop to exist, then described expansion also stops to exist.

9. method as claimed in claim 6 is characterized in that, described attribute is expanded by a plurality of expansions.

10. method as claimed in claim 9 is characterized in that, described a plurality of expansions are used for the overlapping type instance of modelling.

11. method that is used for hardware/software interface system organization and a plurality of projects of effective query, but described project consists of the discrete memory cell of the information that can be processed by hardware/software interface system, described a plurality of project comprises the first relation, it is relevant with the second project with the first project, described method comprises, instantiation for the 3rd project, the subtype example that described the 3rd project is described the first project, described the 3rd project are automatically from the relation of described the first project succession with described the second project.

12. method as claimed in claim 11 is characterized in that, for the instantiation of the 4th project, and the subtype example that described the 4th project is described the second project, described the 4th project is automatically from the relation of described the second project succession with described the first project.

13. method as claimed in claim 12 is characterized in that, described the 4th project is also automatically from the relation of described the second project succession with described the 3rd project.

14. method as claimed in claim 11, it is characterized in that, for each of more than first subtype example of described the first project, each of described more than first subtype example is automatically inherited relation with described the second described project from described the first project.

15. method as claimed in claim 14, it is characterized in that, for each of more than second subtype example of described the second project, each of described more than second subtype example is automatically inherited relation with described the first described project from described the second project.

16. method as claimed in claim 15 is characterized in that, each of described more than first subtype example is automatically inherited each relation with described more than second subtype example from described the first project.

17. method as claimed in claim 16 is characterized in that, each of described more than second subtype example is automatically inherited each relation with described more than first subtype example from described the second project.

18. the hardware for the treatment of a plurality of projects/software interface system, wherein, but project consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, described system comprises that one is used for coming extension purpose subsystem with strong typing example (" expansion "), but consist of can be by the memory cell that disperses of the information of described hardware/software interface system processing in described expansion.

19. system as claimed in claim 18 is characterized in that, described expansion is additional to described project.

20. system as claimed in claim 18 is characterized in that, described expansion can not be independent of described project and exist, if thereby described project stop to exist, then described expansion also stops to exist.

21. system as claimed in claim 18 is characterized in that, described project is expanded by a plurality of expansions.

22. the hardware for the treatment of a plurality of attributes/software interface system, described attribute consists of can be by the complex properties type of hardware/software interface system processing, described system comprises that one is used for coming with strong typing example (" expansion ") subsystem of extended attribute, but consist of can be by the memory cell that disperses of the information of described hardware/software interface system processing in described expansion.

23. the system as claimed in claim 22 is characterized in that, described expansion is additional to described attribute.

24. the system as claimed in claim 22 is characterized in that, described expansion can not be independent of described attribute and exist, if thereby described attribute stop to exist, then described expansion also stops to exist.

25. the system as claimed in claim 22 is characterized in that, described attribute is expanded by a plurality of expansions.

26. the hardware for the treatment of a plurality of projects/software interface system, wherein, but project consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, described system comprises that one is used for the subsystem of tissue and the described a plurality of projects of effective query, described a plurality of project comprises the first relation, it is relevant with the second project with the first project, wherein, and described subsystem:

For the instantiation of the 3rd project, the subtype example that described the 3rd project is described the first project is automatically set up the relation between described the 3rd project and described the second project;

For the instantiation of the 4th project, the subtype example that described the 4th project is described the second project is automatically set up the relation between described the 4th project and described the first project; And

Automatically set up the relation between described the 4th project and described the first project.

27. system as claimed in claim 26, for each of more than first subtype example of described the first project, and for each of more than second subtype example of described the second project, described subsystem:

Automatically set up each of described more than first subtype example and the relation of described the second project;

Automatically set up each of described more than second subtype example and the relation of described the first project; And

Automatically set up each relation of each and described more than second subtype example of described more than first subtype example;

28. the hardware for the treatment of a plurality of projects/software interface system, wherein, but project consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, described system comprises that one is used for coming extension purpose subsystem with strong typing example (" expansion "), but consist of can be by the memory cell that disperses of the information of described hardware/software interface system processing in described expansion.

29. system as claimed in claim 28 is characterized in that, described expansion is additional to described project.

30. system as claimed in claim 28 is characterized in that, described expansion can not be independent of described project and exist, if thereby described project stop to exist, then described expansion also stops to exist.

31. system as claimed in claim 28 is characterized in that, described project is expanded by a plurality of expansions.

32. the hardware for the treatment of a plurality of attributes/software interface system, described attribute consists of can be by the complex properties type of hardware/software interface system processing, described system comprises that one is used for coming with strong typing example (" expansion ") subsystem of extended attribute, but consist of can be by the memory cell that disperses of the information of described hardware/software interface system processing in described expansion.

33. system as claimed in claim 32 is characterized in that, described expansion is additional to described attribute.

34. system as claimed in claim 32 is characterized in that, described expansion can not be independent of described attribute and exist, if thereby described attribute stop to exist, then described expansion also stops to exist.

35. system as claimed in claim 32 is characterized in that, described attribute is expanded by a plurality of expansions.

36. the hardware for the treatment of a plurality of projects/software interface system, wherein, but project consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, described system comprises that one is used for the subsystem of tissue and the described a plurality of projects of effective query, described a plurality of project comprises the first relation, it is relevant with the second project with the first project, wherein, and described subsystem:

For the instantiation of the 3rd project, the subtype example that described the 3rd project is described the first project is automatically set up the relation between described the 3rd project and described the second project;

For the instantiation of the 4th project, the subtype example that described the 4th project is described the second project is automatically set up the relation between described the 4th project and described the first project; And

Automatically set up the relation between described the 4th project and described the first project;

37. system as claimed in claim 36 is characterized in that, for each of more than first subtype example of described the first project, and for each of more than second subtype example of described the second project, described subsystem:

Automatically set up each of described more than first subtype example and the relation of described the second project;

Automatically set up each of described more than second subtype example and the relation of described the first project; And

Automatically set up each relation of each and described more than second subtype example of described more than first subtype example;

38. one kind comprises the computer-readable medium for extension purpose computer-readable instruction, but described project consists of the discrete memory cell of the information that can be processed by hardware/software interface system, described computer-readable instruction comprises be used to utilizing strong typing example (" expansion ") to expand the instruction of described project, but described expansion consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, wherein, described expansion is additional to described project, and wherein, described expansion also stops to exist when described project stops to exist.

39. one kind comprises the computer-readable medium for the computer-readable instruction of extended attribute, described attribute consists of can be by the complex properties type of hardware/software interface system processing, described computer-readable instruction comprises be used to utilizing strong typing example (" expansion ") to expand the instruction of described attribute, but described expansion consists of the discrete memory cell of the information that can be processed by described hardware/software interface system, wherein, described expansion is additional to described attribute, and wherein, described expansion also stops to exist when described attribute stops to exist.

40. one kind comprises the computer-readable medium for the computer-readable instruction of tissue and a plurality of projects of effective query, but described project consists of the discrete memory cell of the information that can be processed by hardware/software interface system, described computer-readable instruction comprises instruction, is used for:

Instantiation the first project, the second project and the first relation that the first project is relevant with the second project;

Instantiation the 3rd project, the subtype example that described the 3rd project is described the first project; And

Automatically set up the relation of the succession between described the 3rd project and described the second project.

41. computer-readable medium as claimed in claim 40 is characterized in that, also comprises being used for instruction:

Instantiation the 4th project, the subtype example that described the 4th project is described the second project; And

Automatically set up the relation of the succession between described the 4th project and described the first project.

42. computer-readable medium as claimed in claim 41 is characterized in that, also comprises instruction, is used for automatically setting up the relation of the succession between described the 3rd project and described the 4th project.

Images