KR101024730B1 - Systems and methods for data modeling in an item-based storage platform - Google Patents

Abstract

Various embodiments of the present invention relate to data store 302 in which stored data includes items, elements, and relationships. An item is a unit of data storage within data store 302, and further includes the element and the relationship. An element is an instance of a type that contains one or more fields. A relationship is a link between at least two items. The data store 302 further includes a core schema 304 for defining a core item set that allows the hardware / software interface system to understand the core item set and directly process it in a predetermined and predictable manner. Core items are derived from a common single base item and become the base item in the base schema.

Interface, storage platform, synchronization, application programming interface

Description

SYSTEM AND METHOD FOR MODELING DATA IN AN ITEMS-BASED STORAGE PLATFORM {SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM}

<Cross Reference>

This application is related to the inventions and contents disclosed in the following assigned applications, in addition to: "System and method for expressing units of information manageable by a hardware / software interface system but independent of physical representation. US Patent Application No. (not yet assigned) entitled "Agent Control Number MSFT-1748"; United States Patent Application (not yet assigned) entitled "System and Method for Separating Units of Information Manageable by Hardware / Software Interface System from Their Physical Mechanisms" (Agent Control No. MSFT-1749); US Patent Application No. (not yet assigned) entitled "System and Method for Implementation of a Basic Schema to Organize Units of Information Manageable by a Hardware / Software Interface System" (Agent Control No. MSFT-1750) ); US Patent Application No. (not yet assigned) entitled "System and Method for Implementing Core Schema that Provides Top Level Structure for Organizing Units of Information Manageable by Hardware / Software Interface System" No. MSFT-1751); US Patent Application No. (not yet assigned) entitled "System and Method for Representing Relationships Between Units of Information Manageable by Hardware / Software Interface System" (Agent Control No. MSFT-1752); US Patent Application No. (not yet assigned) entitled "Storage Platform for Systematization, Retrieval and Sharing of Data" (Agent Control No. MSFT-2734); US Patent Application No. (not yet assigned) entitled “Systems and Methods for Data Modeling in Item-Based Storage Platforms” (Agent Control No. MSFT-2735).

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

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

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

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

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

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

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

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

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

The following summary provides an overview of various aspects of the invention. This Summary is not intended to provide an exhaustive description of all of the important aspects of the invention, nor is it intended to limit the scope of the invention. Rather, this summary is intended to serve as an introduction to the following detailed description and drawings.

The present invention relates to a storage platform for organizing, retrieving, and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file systems and database systems, and is designed to be a repository for all types of data including structured data, unstructured data, or semi-structured data. do.

According to one aspect of the present invention, the storage platform of the present invention comprises a data store implemented on a database engine. The database engine includes a relational database engine with object relational extensions. The data store implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data. Specific types of data are described by schemas, and the platform provides a mechanism for extending the schema set to define new types of data (essentially subtypes of the base types provided by the schema). The synchronization capability facilitates data sharing between users or systems. Without limitation to conventional file systems, file system-like capabilities are provided that allow data storage to interoperate with such conventional file systems. The change tracking mechanism provides the ability to track changes to the data store. The storage platform further includes a set of application program interfaces that allow an application to access all of the capabilities of the storage platform described above and to access data described by the schema.

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

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

According to another aspect of the present invention, a computer system includes a plurality of items, each item comprising a separate storeable unit of information that can be manipulated by a hardware / software interface system, wherein the item or some of the attribute values of the item Can be calculated dynamically as opposed to being derived from a persistent store. That is, the hardware / software interface system does not require the item to be stored, but the ability to enumerate the current set of items, or the ability to retrieve the item when given an identifier for its storage platform (application programming interface). Or certain actions (such as described in more detail in the section describing the API), for example, the item may be the current location of the phone or the temperature read from a temperature sensor.

According to another aspect of the present invention, a hardware / software interface system for a computer system that manipulates multiple items further includes items interconnected by a number of relationships managed by the hardware / software interface system. In accordance with another aspect of the present invention, a hardware / software interface system for a computer system manipulates a number of distinct units of information with attributes that are self understandable. In accordance with another aspect of the present invention, a hardware / software interface system for a computer system includes a core schema for defining a set of core items that it can understand and directly process in a predetermined and predictable manner. According to another aspect of the present invention, there are a plurality of distinct within a hardware / software interface system for a computer system, comprising interconnecting the items with multiple relationships and managing the relationships at a hardware / software interface system level. A method for managing information units (“items”) is disclosed.

According to another feature of the invention, the storage platform's API provides a data class for each item, item extension and relationship defined in the storage platform schema set. In addition, the API provides a set of framework classes that define common sets of behaviors for data classes and provide the basic programming model for the storage platform API with the data classes. According to another aspect of the invention, the storage platform API enables application programmers to form queries based on various attributes of items in the data store in a manner that isolates application programmers from the details of the query language of the underlying database engine. Provide a simplified query model. According to another aspect of the storage platform API of the present invention, the API also collects changes to items made by the application program and then corrects the requests requested by the database engine (or any kind of storage engine) in which the data store is implemented. Organize them in updates. This enables application programmers to change items in memory and to pass the complexity of data store updates to the API.

Through its common storage infrastructure and schemad data, the storage platform of the present invention enables the development of more efficient applications for consumers, knowledge workers and enterprises. This not only allows the use of capabilities unique to his data model, but also provides a rich and extensible API to accommodate and extend existing file system and database access methods.

Other features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings.

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

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

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

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

3 is a block diagram illustrating a storage platform according to the present invention.

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

5A is a block diagram illustrating the structure of items of various embodiments of the present invention.

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

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

6A illustrates an item as a subtype of that item found in the base schema.

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

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

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

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

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

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

11 illustrates a reference type hierarchy of a data model of a storage platform, in accordance with the present invention.

12 is a diagram illustrating how relationships are classified, in accordance with an embodiment of the invention.

13 is a diagram illustrating a notification mechanism according to an embodiment of the present invention.

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

15 is a diagram illustrating a data change detection process, according to an embodiment of the present invention.

16 is a diagram illustrating an exemplary directory tree.

17 is a diagram illustrating an example of moving an existing folder of a directory-based file system to a storage platform data store according to another embodiment of the present invention.

18 is a diagram illustrating a concept of an include folder according to an embodiment of the present invention.

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

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

21A and 21B are diagrams of example contact (item and element) schemas.

22 illustrates a runtime framework of a storage platform API, in accordance with aspects of the present invention.

23 illustrates execution of a FindAll operation according to an embodiment of the present invention.

24 is a diagram illustrating a process in which storage platform API classes are generated from a storage platform schema, in accordance with an aspect of the present invention.

25 is a diagram illustrating a schema on which a file API is based, according to another aspect of the present invention.

FIG. 26 is a diagram illustrating an access mask format used for data security, according to an embodiment of the present invention.

27A, B, and C are diagrams illustrating that a new secured area that is equally protected is protected from an existing secured area, according to one embodiment of an aspect of the present invention.

FIG. 28 is a diagram illustrating the concept of an Item search view according to an embodiment of an aspect of the present invention.

29 is a diagram illustrating an exemplary item hierarchy, in accordance with an embodiment of the present invention.

Contents

I. Introduction

A. Example Computing Environment

B. Normal File-Based Storage

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

A. Glossary

B. Overview of Storage Platforms

C. Data Model

1. Item

2. Item Identification

a) See item

(1) ItemIDReference

(2) ItemPathReference

b) reference type hierarchy

3. Item Folders and Categories

4. Schema

a) basic schema

b) core schema

5. Relationship

a) relationship declaration

b) maintenance relationship

c) insertion relationship

d) reference relationships

e) rules and restrictions

f) relationship ordering

6. Scalability

a) item expansion

b) NestedElement type extension

D. Database Engine

1. Implementing a Data Store Using UDTs

2. Item Mapping

3. Extension Mapping

4. Nested Element Mapping

5. Object Identification

6. Naming SQL Objects

7. Column Naming

8. Search View

a) item

(1) Master Item Search View

(2) Typed Item Search View

b) item expansion

(1) master extended search view

(2) typed extended search view

c) nested elements

d) relationships

(1) Master Relationship Search View

(2) relationship instance search view

9. Renewal

10. Change tracking and tombstone

a) change tracking

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

(2) Change tracking in "typed" search views

b) tombstone

(1) item tombstone

(2) tombstone

(3) relationship tombstone

(4) tombstone elimination

11. Helper APIs and Functions

a) function [System.Storage] .GetItem

b) function [System.Storage] .GetExtension

c) function [System.Storage] .GetRelationship

12. Metadata

a) schema metadata

b) instance metadata

E. Security

1. Overview

2. Detailed description of the security model

a) security engineer structure

(1) access mask format

(2) general access rights

(3) standard access rights

b) item-specific rights;

(1) file and directory object specific rights

(2) WinFSItemRead

(3) WinFSItemRead property

(4) WinFSItemWrite property

(5) WinFSItemWrite

(6) WinFSItemAddLink

(7) WinFSItemDeleteLink

(8) Right to Delete Items

(9) Right to copy items

(10) Right to move items

(11) Right to view security policy on items

(12) The right to change the security policy on items.

(13) The right not to have a direct equivalent

3. Implementation

a) create a new item within the container

b) adding explicit ACLs to entries

c) adding maintenance relationships to items

d) delete a maintenance relationship from an item;

e) explicit ACL deletion from entries

f) modify the ACL associated with an entry.

F. Notice and Change Tracking

1. Save change event

a) event

b) monitor

2. Change tracking and notification generation mechanism

a) change tracking

b) timestamp management

c) Data change deletion-Event detection

G. Sync

1. Storage platform vs storage platform synchronization

a) Sync control application

b) schema annotation

c) Sync configuration

(1) community folder-mapping

(2) profile

(3) schedule

d) conflict handling

(1) collision detection

(a) knowledge base conflict

(b) restriction-based conflicts

(2) conflict handling

(a) automated conflict resolution

(b) conflict logging

(c) collision detection and resolution

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

2. Synchronize for non-storage platform data store

a) synchronization service

(1) change enumeration

(2) apply changes

(3) conflict resolution

b) adapter implementation

3. Security

4. Manageability

H. Normal File System Interoperability

1. Model for interoperability

2. Data Store Function

a) not a volume

b) storage structure

c) all files are not migrated

d) NTFS Namespace Access to Storage Platform Files

e) expected namespace / derived character

I. Storage Platform API

1. Overview

2. Naming and scope

3. Storage Platform API Components

4. Data Class

5. Runtime framework

a) runtime framework classes

(1) ItemContext

(2) ItemSearcher

(a) target type

(b) filter

(c) preparing for search

(d) Find options

(3) Item Result Stream ("FindResult")

b) runtime framework of operations;

c) common programming patterns

(1) opening and closing an ItemContext object

(2) object search

(a) search options

(b) FindOne and FindOnly

(c) Shortcut search for ItemContext

(d) Find by ID or path

(e) GetSearcher pattern

(3) update the repository

6. Security

7. Relationship Support

a) basic relationship types

(1) Relationship class

(2) ItemReference class

(3) ItemIdReference class

(4) ItemPathReference class

(5) RelationshipId structure

(6) VirtualRelationshipCollection class

b) the type of relationship created

(1) the created relationship type

(2) RelationshipPrototype class

(3) RelationshipPrototypeCollection class

c) supporting relationships within item classes

(1) Item class

(2) RelationshipCollection class

d) supporting relationships in search expressions;

(1) Traverse from relationship to relationship

(2) Traverse from item to item

(3) relational traversal combination

e) exemplary use of relationship support

(1) search for relationships

(2) navigation from source to target items

(3) navigation from source item to relation

(4) Create relationships (and items)

(5) Delete relationships (and items)

8. Storage Platform API "Extension"

a) domain behavior

b) value-additional behavior

c) value-adding behavior as a service provider;

9. Design time framework

10. Query Format

a) filter base

b) type cast

c) filter syntax

11. Remote

a) local / remote transparency of the API

b) remote storage platform implementation

c) access to non-storage platform repositories

d) relationship with DFS

e) relationship with GXA / indigo

12. Limitations

13. Share

a) shared representation

b) share management

c) shared access

d) discoverability

14. Semantics of Find

15. Storage Platform Contact API

a) Overview of System.Storage.Contact

b) domain behavior

16. Repository platform file API

a) Introduction

(1) reflects NTFS volumes within the storage platform

(2) Create files and directories in the storage platform namespace

b) file schema

c) Overview of System.Storage.Files

d) code example

(1) open file and write to file

(2) using queries

e) domain behavior

J. Conclusion

I. Introduction

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

A. Example Computing Environment

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

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

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

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

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

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

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

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

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

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

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

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

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

B. Normal File-Based Storage

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

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

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

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

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

A. Glossary

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

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

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

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

B. Overview of Storage Platforms

Referring to FIG. 3, storage platform 300 includes a data store 302 implemented on database engine 314. In one embodiment, the database engine includes a relational database engine with object relational extensions. In one embodiment, relational database engine 314 includes a Microsoft SQL Server relational database engine. The data store 302 implements a data model 304 that supports the organization, retrieval, sharing, synchronization, and security of data.

Certain types of data are described in a schema, such as schema 340, and storage platform 300 provides tools 346 for extending such schemas as well as deploying such schemas, as described below.

The change tracking mechanism 306 implemented within the data store 302 provides the ability to track changes to the data store. Data store 302 also provides security capability 308 and enhancement / demotion capability 310, both of which are described below. The data store 302 also provides a set of APIs 312 for exposing the capabilities of the data store 302 to application programs (e.g., application programs 350a, 350b, 350c) that use other storage platform components and storage platforms. to provide.

The storage platform of the present invention further includes an API 322 that allows an application program, such as the application program 350a, 350b, 350c, to access all the capabilities of the storage platform described above and to access data described in the schema. . The storage platform API 322 may be used by the application program in conjunction with other APIs such as the OLE DB API 324 and the Microsoft Windows Win32 API 326.

The storage platform of the present invention can provide a variety of services 328 to application programs, including a synchronization service 330 that facilitates data sharing between users or systems. For example, the synchronization service 330 may enable interworking with other data stores 340 having the same format as the data store 302 as well as access to data stores 342 having other formats. The storage platform 300 also provides file system capabilities that allow for interworking of the data store 302 with existing file systems such as the Windows NTFS file system 318.

In at least some embodiments, storage platform 300 may also provide application programs with additional capabilities to enable data to operate on other systems and to interact with other systems. These capabilities may be implemented in the form of additional services 328, such as information agent service 334 and notification service 332, as well as other utilities 336.

In at least some embodiments, the storage platform is implemented within or forms an integral part of the hardware / software interface system of the computer system. For example, and without limitation, the storage platform of the present invention may be implemented within, or form part of, an operating system, a virtual device manager (VMM), a CLR or a functional equivalent thereof, or a JVM or a functional equivalent thereof.

The storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises through its common storage foundation and schematized data. The storage platform not only makes the capabilities unique to its data model available, but also provides a rich and extensible programming surface area to accommodate and extend existing file system and database access methods.

In the following description, and in the various figures, the storage platform 300 of the present invention may be referred to as "WinFS". However, the use of names to refer to such storage platforms is for convenience of description only and is not intended to be limiting in any way.

C. Data Model

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

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

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

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

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

A type is said to be abstract when instances of that type must also be instances of subtypes of that type.

1. Item

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

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

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

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

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

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

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

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

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

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

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

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

* 2. Item Identification

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

a) See item

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

(1) ItemIDReference

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

(2) ItemPathReference

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

b) reference type hierarchy

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

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

3. Item Folders and Categories

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

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

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

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

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

4. Schema

a) basic schema

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

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

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

b) core schema

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

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

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

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

Commodity: An item whose value can be identified.

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

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

Event: Item that records a certain occurrence in the environment

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

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

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

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

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

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

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

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

Rich Text (derived from attribute type in base schema)

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

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

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

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

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

5. Relationship

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

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

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

Reference relationships do not control the life of the target item. The reference relationship may be in the air, i.e., the target item may not exist. Reference relationships can be used to model references to items anywhere in the global item namespace (ie, including remote data stores).

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

a) relationship declaration

Explicit relationship types are defined with the following elements:

Relationship name is specified within the name attribute.

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

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

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

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

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

Relationship instances are stored in the global relationship table.

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

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

The following is an example of a relationship declaration:

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

b) maintenance relationship

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

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

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

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

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

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

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

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

The following is an example of a maintenance relationship.

*

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

c) insertion relationship

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

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

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

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

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

The following is an example of a declaration.

d) reference relationships

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

The following is an example of a reference relationship declaration.

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

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

e) rules and restrictions

The following additional rules and restrictions apply to relationships.

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

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

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

4. Items promoted from a file cannot be targets of insertion relationships.

f) ordering of relationships

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9 is a block diagram showing the item folder (which is also the item itself), its member items, and the interconnection relationship between the item folder and its member items. The item folder 900 has a number of items 902, 904, 906. Item folder 900 has a relationship 912 from itself to item 902, which item 902 is public and item folder 900, its members 904, 906, and item folder 900 ) Can be shared with any other item folders, categories, or items (not shown) that can access. However, there is no relationship from item 902 to item folder 900, which indicates that item folder 900 is private to item 902 and does not share its member information with item 902. Item 904, on the other hand, has a relationship from itself to item folder 900, indicating that item folder 900 is public and shares its member information with item 904. However, there is no relationship from item folder 900 to item 904, which means that item 904 is private and that item folder 900, its other members 902, 906, and item folder 900 are not present. Not shared with an accessible item folder, category, or item (not shown) Unlike the relationship (or lack of relationship) to items 902 and 904 in the item folder, item folder 900 ) Has a relationship 916 from itself to item 906, which in turn has a relationship 926 to item folder 900, which together makes item 906 public and item folder ( 900, its members 902, 904, and any other item folder, category, or item (not shown) that can access item folder 900, and item folder 900 is public. And share its member information with item 906.

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

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

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

10 is a block diagram illustrating a category (item itself), its member items, and an interconnection relationship between a category and its member items. Category 1000 has a number of items 1002, 1004, 1006 as members, all of which share some combination of common attributes, values, or types 1008 as described by category 1000. do. Category 1000 itself has a relationship 1012 to item 1002, in which item 1002 is public, and in category 1000, its members 1004, 1006, and category 1000. Indicates that it can be shared with any other category, item folder, or item (not shown) that can be accessed. However, there is no relationship from item 1002 to category 1000, which indicates that category 1000 is private to item 1002 and does not share its member information with item 1002. Item 1004, on the other hand, does not itself have a relationship 1024 to category 1000, which indicates that category 1000 is public and shares its member information with item 1004. However, there is no relationship that extends from category 1000 to item 1004, which means that item 1004 is private, and that category 1000, its other members 1002, 1006, and category 1000 do not exist. Indicates that it cannot be shared with any other category, item folder, or item (not shown) accessible to it. Unlike the relationship (or lack thereof) with items 1002 and 1004 of a category, category 1000 has a relationship to item 1006 on its own, and item 1006 is conversely to category 1000. Which together is an item 1006 is public and includes category 1000, its item members 1002 and 1004, and any other category, item folder or item (not shown) that can access category 1000 ) And category 1000 is public and shares item 1006 with its member information.

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

6. Scalability

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

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

ISVs are allowed to introduce a new item type, Base.Item, which is a subtype.

ISVs are allowed to introduce new nested element types, ie subtypes Base.NestedElement.

ISVs are allowed to introduce new extensions, that is, the subtype Base.NestedElement; However, the ISV cannot subtype any type (item, nested element or extended type) defined by the initial set 340 of the storage platform schema.

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

In addition to addressing the need for schema extensibility, extensions also address the "multi-type" problem. In some embodiments, since the storage platform may not support multiple inheritance or nested subtypes, applications may use extensions as a method for modeling overlapped type instances (eg, documents are legitimate). The document is of course a secure document).

a) item expansion

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

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

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

The structure of extended types is similar to that of item types:

Extended types have fields.

The field may be a basic or nested element type.

Extension types may be subtyped.

The following restrictions apply to extended types.

Extensions cannot be sources and targets of relationships.

An extension type instance cannot exist separately from an item.

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

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

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

The extended type may be a subtyped type using the storage platform single inheritance model. Derivation from an extension type creates a new extension type. The structure or behavior of an extension cannot override or replace the structure or behavior of an item type hierarchy.

Similar to item types, extension type instances can be accessed directly through views associated with the extension type. The ItemID of the extension indicates which item they belong to and can be used to retrieve the corresponding item object from the global item view.

Extensions are considered part of the item for consistency of operation. Copy / move, backup / restore, and other general operations defined by the storage platform may operate on extensions as part of the item.

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

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

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

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

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

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

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

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

Item-to-item expansion vs. nested elements

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

b) Nested element type extension

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

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

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

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

Nested element extensions are not extension types. It is not part of the extension type hierarchy rooted in the Base.Extension type.

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

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

The aggregation interface used to access multi-valued attributes is also used for access and iteration over the set of type extensions.

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

Item Expansion vs. Nested Element Expansion

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

D. Database Engine

As mentioned above, the data store is implemented on a database engine. In this embodiment, the database engine includes a relational database engine that implements an SQL query language such as the Microsoft SQL Server engine with object relational extensions. This section describes the mappings to the relational stores of the data model that implements the data store according to this embodiment, and provides information about the logical APIs used by the storage platform client. However, it should be understood that different mappings may be used when different database engines are used. Indeed, in addition to implementing the storage platform conceptual data model on a relational database engine, it can also be implemented on other types of databases such as, for example, object-oriented and XML databases.

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

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

1. Implementing a Data Store Using UDTs

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

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

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

The following example illustrates the basics of a UDT. Suppose MapLib.dll has an assembly called MapLib. In this assembly, there is a class called Point under the namespace BaseType:

The following T-SOL code combines a class Point into a SQL server UDT called Point. The first step is to call "CreateAssembly" which loads the MapLib assembly into the database. The second step calls "CreateType" to create a user defined type "Point" and associates it with the managed type BaseTypes.Point:

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

The item hierarchy illustrated in FIG. 29 is used herein as an example. This represents the Base.Item type, in which all item types are derived along a set of item types (eg, Contact.Person and Contact.Employee) derived by inheritance indicated by arrows.

2. Item Mapping

Preferably, if items are globally searchable, and inheritance and type substitution are supported in the relational database of this embodiment, one possible implementation for storing items in a database repository may list all items in a column of type Base.Item in a single table. Will save. Using type substitution, all types of items could be stored, and the search could be filtered by item type and subtype using Yukon's "is of (Type)" operator.

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

A "shadow" table is used to store a copy of the global searchable attributes for all items. This table can be maintained by the Update () method of the storage platform API, which makes all data changes. Unlike type family tables, this global item table contains only the top-level scalar attributes of the item, not the complete UDT item object.

The structure of the global entry table is as follows:

The global item table allows navigation to item objects stored in the type family table by exposing ItemID and TypeID. The ItemID typically uniquely identifies an item in the data store. TypeID may be mapped to a view containing the type name and item using metadata not described herein.

With regard to the global item table and with respect to other situations, finding an item by its ItemID may be a normal operation, so given the ItemID of the item, a GetItem () function is provided to retrieve the item object. This function has the following declaration:

Base.Item Base.GetItem (uniqueidentifier ItemID)

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

For completeness, a view can also be created for a global item table. This view can initially expose the same columns as the table:

3. Extension Mapping

The extension is very similar to the item and has some of the same requirements. As another root type that supports inheritance, extensions are subject to much of the same considerations and tradeoffs in storage. Because of this, similar type family mappings apply to extensions rather than single table approaches. Of course, in other embodiments a single table approach may be used.

In this embodiment, the extension is associated with exactly one item by ItemID and includes a unique ExtensionID with respect to the item. Extension tables have the following definitions:

As with the item, a function may be provided for retrieving the extension when given an extension identifier consisting of ItemID and ExtensionID pairs. This function has the following declaration:

A view is created for each yield type similar to the item type view. Assume an extension hierarchy that is parallel to an example item hierarchy of the following type: Base.Extension, Contact.PersonExtension, Contact.EmployeeExtention. The following view can be created:

4. Nested Element Mapping

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

5. Object Identification

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

6. Naming SQL Objects

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

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

7. Column Naming

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

8. Search View

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

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

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

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

2. Metadata information about the result type, such as TypeId

3. Change tracking columns such as CreateVersion, UpdateVersion, etc.

4. Type-specific columns (attributes of declared types)

5. Type-specific views (family views) also contain an array of objects that return objects.

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

a) item

Each item search view includes a row for each instance of an item of a particular type or subtype thereof. For example, a view on a document can return instances of Document, LegalDocument, and ReviewDocument. Given this example, the item view can be conceptualized as shown in FIG.

(1) Master Item Search View

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

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

(2) Typed Item Search View

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

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

b) item expansion

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

(1) master extended search view

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

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

(2) typed extended search view

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

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

c) nested elements

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

d) relationships

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

(1) Master Relationship Search View

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

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

(2) relationship instance search view

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

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

9. Renewal

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

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

1. Item Action

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

b. UpdateItem (Update Existing Item)

2. Relationship Behavior

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

b. UpdateRelationship (Update Relationship Instance)

c. DeleteRelationship (remove relationship instance)

3. Extended operation

a. CreateExtension (add extension to existing item)

b. UpdateExtension (Update Existing Extension)

c. DeleteExtension

10. Change tracking and tombstone

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

a) change tracking

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

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

(1) Change tracking in master search view

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

These attributes include the following information:

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

(2) change tracking in typed search views

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

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

b) tombstone

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

(1) item tombstone

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

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

* (2) tombstone

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

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

* (3) relationship tombstone

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

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

(4) tombstone removal

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

11. Helper APIs and Features

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

a) function [System.Storage] .GetItem

b) function [System.Storage] .GetExtension

c) function [System.Storage] .GetRelationship

12. Metadata

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

a) schema metadata

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

b) instance metadata

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

E. Security

This section describes a security model for the storage platform of the present invention according to one embodiment.

1. Overview

According to the present invention, the granularity in which the storage platform's security policy is specified and enforced is at the level of various operations for an item of a given data store, and there is no ability to individually secure parts of the item from the whole. The security module specifies a set of subjects that may be given or denied access to perform these operations on items via an access control list (ACL). Each ACL is an ordered set of access control entries (ACEs).

The security policy for an item can be fully described by the discretionary access control policy and system access control policy. Each of these is a set of ACLs. Whereas a second set of ACLs refers to a system access control list (SACL) that specifies how the auditing system behaves when an object is manipulated in some way, the first set (DACL) refers to the various entities Represents quasi-random access. In addition, each item in the data store is associated with an SID (owner SID) corresponding to the owner of the item.

The primary mechanism for organizing items within the storage platform data store is that of the containment hierarchy. Inclusion hierarchies are realized using maintenance relationships between items. The maintenance relationship between two items A and B, expressed as "A includes B", allows item A to affect the life of item B. In general, an item in a data store cannot exist until there is a maintenance relationship from another item to it. In addition to controlling the life of an item, a maintenance relationship provides the mechanisms needed to propagate the security policy for the item.

The security policy specified for each item consists of two parts, the part explicitly specified for that item and the part inherited from the item's parent in the data store. An explicitly defined security policy for an item consists of two parts: one that controls access to the item under conditions and one that affects the security policy inherited by all its descendants in the containment hierarchy. . The inherited security policy is a function of explicitly defined and inherited policies.

Since security policies can be propagated through maintenance relationships and can be ignored in any item, there is a need to specify how to determine an effective security policy for an item. In this embodiment, an item in the data store containing hierarchy inherits an ACL along all paths from the root of the store to that item.

Within an ACL inherited for any given path, the ordering of the various ACEs in the ACL determines the final security policy enforced. The following description describes the ordering of ACEs in an ACL. The ordering of the ACEs in the ACL inherited by the entry is determined by two rules:

The first rule stratifies ACEs inherited from various items in the path from the root of the containment hierarchy to item I. ACEs inherited from closer containers have precedence over entries inherited from distant containers. Intuitively, this allows the administrator the ability to ignore inherited ACEs from farther in the containment hierarchy. This rule is as follows:

The second rule orders the ACEs that denied access to the items before the ACEs that gave them access.

In the case of a containment hierarchy that is a tree, there is only one path from the root of the tree to the item, and the item has only one inherited ACL. In this situation, the ACL inherited on an entry matches the ACL inherited on a file (entry) within the existing Windows security model in terms of the relative ordering of the ACEs within the ACL.

However, the containment hierarchy in the data store is a directional acyclic graph (DAG) because multiple retention relationships for the item are allowed. Under this condition, there are a number of paths from the root of the containment hierarchy to the item. Because entries inherit ACLs along all paths, each entry is associated with a set of ACLs, as opposed to a single ACL. Note that this is different from the traditional file system model, where only one ACL is associated with a file or folder.

There are two aspects that need to be elaborated when the containment hierarchy is a DAG rather than a tree. When an item inherits more than one ACL from its parent, an explanation is needed about how the effective security policy for that item is calculated, and how they are organized and expressed is directly related to the management of the security model for the storage platform data store. Is related.

The following algorithm evaluates the access rights for a given subject in a given item. Throughout this document, the following describes the ACLs associated with entries.

Inherited_ACLs (ItemId)-The set of ACLs whose item identifier ItemId is inherited from its parent in the repository.

Explicit_ACL (ItemId)-An explicitly defined ACL for an item whose identifier is ItemId.

The routine returns STATES_SUCCESS if the desired access has not been explicitly denied, and pGrantedAccess determines which rights the user desires have been given by the specified ACL. If any of the desired accesses are explicitly denied, the routine returns STATUS_ACCESS_DENIED.

The scope of impact of a security policy defined in any item covers all descendants of the item in the inclusion hierarchy defined on the data store. For all items for which an explicit policy has been defined, a policy inherited to all descendants in the containing hierarchy is in fact defined. A valid ACL inherited to all descendants is obtained by taking each inherited ACL and adding the inheritable ACE into the explicit ACL at the beginning of the ACL. This means a set of inheritable ACLs associated with the item.

If there is no explicit security specification in the containing hierarchy rooted at the folder item, then the security specification of the folder applies to all descendants of that item in the containing hierarchy. Therefore, every item provided with an explicit security policy specification defines an area of equally protected items, and the valid ACL for all items is the set of inheritable ACLs for that item. This will completely define the region in the case of a tree-included hierarchy. If each region is associated with a number, it would be sufficient to simply include the region to which it belongs, along with the item.

However, for a containment hierarchy that is a DAG, the point in the containment hierarchy where the effective security policy changes is determined by two kinds of items. The first is an explicit ACL specified entry. Typically, these are points within an inclusion hierarchy where the administrator explicitly specifies ACLs. The second is an item with two or more parents, which have different security policies associated with them. Typically, they are the confluence of security policies specific to the volume, and are the items that mark the beginning of a new security policy.

By this definition, all items in the data store fall into one of two categories: those that are the root of the same secured area and those that are not. Items that do not define a security zone obviously belong to one security zone. As in the case of a tree, effective security for an item can be specified by specifying the area to which the item belongs along with the item. This leads to a simple model for managing the security of the storage platform data store based on the various areas that are equally protected within the store.

2. Detailed description of the security model

This section provides details on how items are secured by explaining how the individual rights within the included ACLs and security descriptors affect various behaviors.

a) security engineer structure

Before describing the details of the security model, a basic description of the security descriptor is useful. The security descriptor includes security information associated with the securable object. The security descriptor consists of the SECURITY_DESCRIPTOR structure and its associated security information. The security descriptor may include the following security information:

1. The SID of the owner and major group of objects.

2. A specific DACL that grants or denies access to specific users or groups.

3. A SACL that specifies the type of access attempting to create an audit record for the object.

4. A set of control bits that give meaning to a security descriptor or its individual members.

Preferably, the application cannot directly manipulate the security technician's content. There is a facility for setting and retrieving security information in the security descriptor of an object. In addition, there is the ability to create and initialize security descriptors for new objects.

The discretionary access control list (DACL) identifies a trustee that is allowed or denied access to the securable objects. When a process attempts to access a securable object, the system checks the ACE in the object DACL to determine whether to give it access. If the object does not have a DACL, the system gives everyone full access. If the DACL of an object does not have any ACEs, the system rejects all attempts to access the object because the DACL does not grant any access rights. The system finds one or more ACEs that allow all of the requested access rights or checks the series of ACEs until any of the requested access rights are denied.

System access control lists (SACLs) allow administrators to log attempts to access secured objects. Each ACE specifies the type of access attempt using a specific trustee that allows the system to create a record in the security event log. An ACE in a SACL may generate an audit record when an access attempt fails, when it succeeds, or both. The SACL can also sound an alert when an unauthorized user attempts to gain access to an object.

All ACE types contain the following access control information:

1. Security identifier (SID) that identifies the trustee to which the ACE applies.

2. an access mask specifying the access rights controlled by the ACE

3. Flag indicating the type of ACE

4. A set of bit flags that determine whether the child container or object can inherit the ACE from the main object to which the ACL is attached.

The following table lists the three ACE types supported by all securable objects.

type Explanation Access-denied ACE Used to deny access to trustees within the DACL. Access-permitted ACE Used to grant access to trustees within an ACL. System-monitoring ACE Used to generate audit records when trustees attempt to exercise specified access rights within the SACL.

(1) access mask format

All securable objects arrange their access rights using the access mask format shown in FIG. In this format, the 16 low-order bits are for object-specific access rights, the next 7 bits are for standard access rights that apply to most object types, and the 4 high-order bits are for each object type. Used to specify general access rights that can be mapped to a set of standard and object specific rights. The ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the SACL of the object.

(2) general access rights

General rights are specified within four high rank bits in the mask. Each type of secureable object maps these bits to a set of standard and object specific access rights. For example, the file object maps the GENERIC_READ bit to the READ_CONTROL and SYNCRONIZE standard access rights, and the FILE_READ_DATA, FILE_READ_EA, and FILE_READ_ATTRIBUTES object specific access rights. Objects of other types map the GENERIC_READ bit to any set of permissions appropriate to that type of object.

General access rights can be used to specify the type of access required when opening a process for an object. This is typically simpler than specifying both the corresponding standard and the specific rights. The following table shows the constants defined for general access rights.

a constant General meaning GENERIC_ALL Read, write, and execute access GENERIC_EXECUTE Running access GENERIC_READ Read access GENERIC_WRITE Record access

(3) standard access rights

Each type of securable object has a set of access rights that correspond to actions specific to that type of object. In addition to these object specific permissions, there is a set of standard permissions that correspond to actions common to most types of securable objects. The following table shows the constants defined for standard access rights.

a constant meaning DELETE Right to Delete Object READ_CONTROL Right to Read Information in Object Security Identifier Except for Information in SACL SYNCHRONIZE Right to synchronize objects. This allows a thread to wait for an object to be signaled. Some object types do not support this permission. WRITE_DAC Right to Modify DACLs in Object Security Descriptors WRITE_OWER Right to Change Owner in Object Security Descriptor

b) item-specific rights;

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

(1) file and directory object specific rights

Consider the following table:

Directory Directory description file File description value FILE_LIST_DIRECTORY Right to list the contents of the directory FILE_READ_DATA The right to read the corresponding file data 0x0001 FILE_ADD_FILEX Right to create a file in a directory FILE_WRITE_DATA Right to Write Data to File 0x0002 FILE_ADD_SUBDIRECTORY Right to Create Subdirectory FILE_APPEND_DATA Right to Attach Data to File 0x0004 FILE_READ_EA Right to Read Extended File Attributes FILE_READ_EA Right to Read Extended File Attributes 0x0008 FILE_WRITE_EA Right to Record Extended File Attributes FILE_WRITE_EA Right to Record Extended File Attributes 0x0010 FILE_TRAVERSE Right to Traversing Directories FILE_EXECUTE For source code files, the right to run the file 0x0020 FILE_DELETE_CHILD Right to delete directory and all files it contains none none 0x0040 FILE_READ_ATTRIBUTES Right to read directory attributes FILE_READ_ATTRIBUTES Right to read file attributes 0x0080 FILE_WRITE_ATTRIBUTES Right to Record Directory Attributes FILE_WRITE_ATTRIBUTES Right to Record File Attributes 0x0100

With reference to the table above, keep in mind that the file system makes a fundamental distinction between files and directories (why file rights and directory rights overlap on the same bit). The file system defines a very granular right that allows an application to control the behavior of these objects. For example, they allow an application to distinguish between attributes associated with a file (FILE_READ / WRITE_ATTRIBUTES), extended attributes, and DATA streams.

For example, the purpose of the security model of the storage platform of the present invention is to simplify the rights assignment model so that applications that operate on data store items (contacts, email, etc.) generally have attributes, extended attributes, and data streams. There is no need to distinguish. However, for files and folders, by protecting the granular Win32 rights and defining the semantics of access through the storage platform, compatibility with Win32 applications can be provided. This mapping is explained by the respective item rights specified below.

The following item rights are specified by the associated allowable actions. Equivalent Win32 rights are also provided to support each of these item rights.

(2) WinFSItemRead

This right allows read access to all elements of the item, including items linked to the item via an inserted relationship. It also allows enumeration (also known as directory listing) of items linked to this item through a maintenance relationship. This includes the name of the item linked through the reference relationship. This right is mapped to:

file:

(FILE_READ_DATA | SYNCHRONIZE)

folder:

(FILE_LIST_DIRECTORY | SYNCHRONIZE)

Semantic is that a security application can set WinFSItemReadData and specify a rights mask with a combination of the specified file rights.

(3) WinFSItemReadAttributes

This right allows read access to the element's elementary attributes as the file system distinguishes between elementary file attributes and data streams. Preferably, these elementary attributes reside in the elementary item from which all items are derived. This right is mapped to:

file:

(FILE_READ_ATTRIBUTE)

folder:

(FILE_READ_ATTRIBUTE)

(4) WinFSItemWriteAttributes

This right allows write access to the element's elementary attributes as the file system distinguishes between elementary file attributes and data streams. Preferably, this base attribute resides in the base item from which all items are derived. This right is mapped to:

file:

(FILE_WRITE_ATTRIBUTES)

folder:

(FILE_WRITE_ATTRIBUTES)

(5) WinFSItemWrite

This right allows the ability to write to all elements of an item, including items linked through an insert relationship. This right also allows the ability to add or delete insert relationships in other items. This right is mapped to:

file:

(FILE_WRITE_DATA)

folder:

(FILE_ADD_FILE)

In a storage platform data store, there is no difference between an item and a folder because an item may also have a maintenance relationship with other items in the data store. Accordingly, with the right of FILE_ADD_SUBDIRECTORY (or FILE_APPEND_DATA), it is possible to have an item which is the source of a relationship with other items.

(6) WinFSItemAddLink

This right allows the right to add maintenance relationships to items in the repository. The security model for many maintenance relationships changes the security for an item, and if this change comes from a higher point in the hierarchy, it can bypass the WRITE_DAC, so that the destination item can be created in order to create a relationship with it. WRITE_DAC is requested for. This right is mapped to:

file:

(FILE_APPEND_DATA)

folder:

(FILE_ADD_SUBDIRECTORY)

(7) WinFSItemDeleteLink

This right allows the ability to delete the maintenance of an item even if the subject is not given the right to delete the item. This is consistent with the file system model and helps with cleanup. This right is mapped to:

file:

(FILE_DELETE_CHILD)-The file system does not have file equivalents for this right, but we have the concept of an item that has a maintenance relationship with others, so keep in mind that this right is also passed to non-folders.

folder:

(FILE_DELETE_CHILD)

(8) Right to Delete Items

If the last retention relationship to the item disappears, the item is deleted. There is no explicit concept of deleting an item. There is a purge action that deletes all maintenance relationships with items, but it is a high level feature and is not a system default.

Any item specified using a path may be denied if either (1) the parent item along the path does not give write access to the subject, or (2) the standard right for the item satisfies one of two conditions: DELETE. Can be released. When the last relationship is removed, the item disappears from the system. Any item specified using ItemID can be unlinked if the standard right for the item gives a DELETE.

(9) Right to copy items

Given a subject to WinFSItemRead for an item and WinFSItemWrite for a destination folder, the item can be copied from the source to the destination folder.

(10) Right to move items

File movement within the file system requires only a DELETE right for the source file, and a FILE_ADD_FILE for the destination directory, because it protects the ACL for the destination. However, the flag can be specified with a MoveFileEx call (MOVEFILE_COPY_ALLOWED) that specifies that the application can allow CopyFile semantics in the case of cross-volume moves. There are four potential choices about what happens by security descriptors on the move:

1. Move the entire ACL with files-default intra-volume move semantics.

2. Move the entire ACL with the file and mark the ACL as protected.

3. Move only explicit ACEs and inherit again on the destination.

4. Nothing moved, inherited again on the destination-default inter-volume move semantics-same as file copy.

In this security model, if an application specifies the MOVEFILE_COPY_ALLOWED flag, these four choices are performed for both inter and intra volume cases. If the flag is not specified, the second option is performed unless the destination is in the same security realm (ie, the same inheritance semantics). The storage platform level move implements the fourth selection and requests READ_DATA for a source such as a copy.

(11) Right to view security policy on items

If the item gives the subject the standard right READ_CONTROL, the item's security can be seen.

(12) The right to change the security policy on items.

If the item gives the subject the standard right WRITE_DAC, the security of the item can be changed. However, if the data store provides implicit inheritance, this means how security can change in the hierarchy. If the root of the hierarchy gives WRITE_DAC, then the rule is that the security policy changes over the entire hierarchy regardless of whether a particular item in the hierarchy (or DAG) did not give the subject WIRTE_DAC.

(13) not to have direct equivalents

In this embodiment, FILE_EXECITE (FILE_TRAVERSE for a directory) does not have a direct equivalent in the storage platform. The model maintains these for Win32 compatibility, but does not make any access decisions made on items based on these rights. As with FILE_READ / WRITE_EA, the semantics for this bit are not provided because data store items do not have the concept of extended attributes. However, this bit remains for Win32 compatibility.

3. Implementation

All items that define equally protected areas have entries associated with them in the security table. The security table is defined as follows:

Item identifier Item Ordpath Explicit Entry ACL Path ACL Zone ACL

The item identifier entry is the item identifier of the root of the same protected area. The entry order path entry is the order path associated with the root of the security zone that is equally protected. Explicit Entry ACL An entry is a defined explicit ACL for the root of an equally protected security zone. In some cases, this may be NULL, for example when a new security zone is defined, for example because the item has multiple parents belonging to different zones. A path ACL entry is a set of ACLs inherited by an entry, and a zone ACL entry is a set of ACLs defined for an equally protected security zone associated with an entry.

The calculations for effective security for any item in a given repository affect this table. To determine the security policy associated with the item, the security realm associated with the item is obtained and the ACL associated with that realm is retrieved.

The security policy associated with an item is altered either by adding an explicit ACL directly or indirectly by adding a maintenance relationship that generates a formula for the new security zone, so that the security table indicates that the above algorithm for determining effective security of an item is valid. Continually updated to guarantee

Various changes to the repository and accompanying algorithms to maintain security tables are as follows:

a) create a new item within the container

When an item is newly created in a container, it inherits all the ACLs associated with the container. Since a newly created item has only one parent, it belongs to the same area as its parent. Therefore, there is no need to create new entries in the security table.

b) adding explicit ACLs to entries

When an ACL is added to an entry, it defines a new security zone for all its descendants in the containing hierarchy that belong to the same security zone as the given entry. For all items that are descendants of a given item in the containing hierarchy but belonging to another security realm, the security realm remains unchanged, but the effective ACL associated with that realm is changed to reflect the addition of a new ACL.

The introduction of this new security zone can trigger the addition of zone definitions for all items that have multiple maintenance relationships with ancestors straddling the old and newly defined security zones. For all these items, a new security realm needs to be defined and the procedure needs to be repeated.

27A, B, and C illustrate new equally protected security zones that are separated from existing security zones by introducing new explicit ACLs. This is represented by the node indicated by reference number 2. However, because the item has a number of maintenance relationships, the introduction of this new area creates an additional area 3.

The next series of updates to the security table reflects the factorization of equally protected security zones.

c) adding maintenance relationships to items

When a maintenance relationship is added to an item, it raises one of three possibilities. If the target of the maintenance relationship, i.e. the item under the condition, is the root of the security zone, then the effective ACL associated with the zone is changed and no further modifications to the security table are required. If the security zone of the source of the new maintenance relationship is the same as the security zone of the existing parent of the item, no change is requested. However, if an item has a parent belonging to a different security realm, a new security realm with the item given as the root of the security realm is formed. This change is propagated to all items in the containment hierarchy by modifying the security zone associated with the item. All items belonging to the same security domain as the item under the condition and their descendants in the containing hierarchy need to be changed. Once changed, all items with multiple maintenance relationships should be examined to determine if more changes are required. If any of these items have parents of different security zones, further changes may be requested.

d) delete a maintenance relationship from an item

When a retention relationship is deleted from an item, it is likely that one security zone will collapse with its parent zone if certain conditions are met. More precisely, this means that (1) if the removal of a maintenance relationship creates an item with one parent, no explicit ACL is specified for that item, and (2) the removal of the maintenance relationship is within the same security zone. Creating an item can be done under the condition that no explicit ACL is specified for that item. Under these circumstances, the security zone can be marked the same as the parent. This marker needs to be applied to all items corresponding to the zone where the security zone is collapsed.

e) explicit ACL deletion from entries

When an explicit ACL is deleted from an entry, the security zone rooted in that entry can collapse into the security zone of its parent. More precisely, this can be done if the removal of explicit ACLs creates an item whose parents belong to the same security zone in the containing hierarchy. In this environment, the security zone can be marked the same as the parent, and the change can be applied to all items corresponding to the zone where the security zone is collapsed.

f) modify the ACL associated with an entry.

In this scenario, no new additions to the security table are required. Valid ACLs associated with the zone are updated, and new ACL changes are propagated to the affected security zone.

F. Notice and Change Tracking

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

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

1. Save change event

This section provides some examples of how the notification interface provided by storage platform API 322 is used.

a) event

Items, item extensions, and item relationships expose data change events that an application uses to register for data change notifications. The following code sample shows the definition of the ItemModified and ItemRemoved event handlers for the base item class.

All notifications carry enough data to retrieve changed items from the data store. The following code sample shows how to register for events on items, item extensions, and item relationships:

In this embodiment, the storage platform ensures that notifications will be notified to the application if individual items have been modified or deleted since the last delivery, or if a new registration has been made since the last patch from the data store.

b) monitor

In this embodiment, the storage platform defines a watcher class to monitor (1) a folder or folder hierarchy, (2) an item context, or (3) an object associated with a particular item. For each of the three categories, the storage platform provides a specific watcher class that monitors the associated item, item extension, or item relationship, for example, the storage platform provides the FolderItemWatcher, FolderRelationshipWatcher, and FolderExtensionWatcher classes, respectively.

When creating a watcher, an application can request notification of an existing item, that is, an item, extension, or relationship. This option is usually for applications that maintain a private item cache. If not requested, the application receives a notification about all updates that occur after the watcher object is created.

In conveying the notification, the storage platform provides a "WatcherState" object. WatcherState is serialized and stored on disk. The watcher state can then be used to recreate an individual watcher when it reconnects after a failure or after it goes off-line. The newly regenerated supervisor will regenerate the unacknowledged notification. The application represents the delivery of the notification on the individual watcher state that provides a reference to the notification by calling the "Exclude" method.

The storage platform delivers a separate copy of the watcher's state to each event handler. The watcher state received on the next invocation of the same event handler assumes delivery of all previously received notifications.

For example, the following code sample shows the definition of FolderItemWatcher.

The following code sample shows how to create a folder watcher object to monitor the contents of a folder. The watcher generates a notification, that is, an event, when a new music item is added or an existing music item is updated or deleted. Folder Watcher monitors all folders within a particular folder or folder hierarchy.

2. Change tracking and notification generation mechanism

The storage platform provides a simple but valid mechanism for tracking data changes and generating notifications. The client retrieves the notification for the same connection used to retrieve the data. This primarily simplifies security checks, eliminates delays, and limits possible network configurations. The notification is retrieved by issuing a select statement. To prevent polling, the client can use the "waitfor" function provided by the database engine 314. 13 illustrates a basic storage platform notification concept. This waitfor query can be run synchronously when the calling thread is blocked until the result is available, or asynchronously when the thread is not blocked and the result is returned to an individual thread (when available). have.

The combination of " waitfor " and " select " is good for monitoring data changes that fit a particular data range when changes can be monitored by setting a notification lock on a separate data area. This maintains several common storage platform scenarios. Changes to individual items can be efficiently monitored by setting notification locks on individual data areas. Changes to folders and folder trees can be monitored by setting notification locks on the path area. Changes to the type and its subtypes can be monitored by setting a notification lock on the type area.

In general, there are three distinct phases associated with processing notifications: (1) data change or even detection, (2) subscription match, and (3) notification delivery. Apart from synchronous notification delivery, that is, notification delivery as part of a transaction that performs data changes, the storage platform may implement two notification delivery forms:

1) Immediate Event Detection: Event detection and subscription matching is performed as part of the update transaction. The notification is inserted into a table monitored by the subscriber.

2) Deferred Event Detection: Event detection and subscription matching is performed after an update transaction is made. The real subscriber or mediator then detects the event and generates a notification.

Immediate event detection requires additional code to be executed as part of the update operation. This allows capturing all of the related events, including those that indicate a related state change.

Deferred event detection eliminates the need to add additional code to update behavior. Event detection is done by the ultimate subscriber. Deferred event detection naturally batches event detection and event delivery and fits well into the query execution infrastructure of the database engine 314 (eg, SQL server).

Deferred event detection responds to traces left by log or update operations. The storage platform maintains a set of logical timestamps with the tombstones for deleted data items. When scanning the data store for changes, the client provides a time stamp that defines a low watermark for detecting changes, and a set of time stamps to prevent duplicate notifications. The application may receive a notification of all modifications that occur after the time indicated by the low watermark.

Sophisticated applications with access to core views can create private parameter and duplicate filter tables to optimize and reduce the number of SQL statements needed to monitor a potentially large set of items. Applications with special needs, such as those that need to support rich views, can use the change tracking framework available to monitor data changes and restore their private snapshots.

Therefore, in one embodiment, preferably the storage platform implements the deferred event detection approach as described more fully below.

a) change tracking

Every item, extension, and item relationship definition has a unique identifier. Change tracking maintains a set of logical time stamps to record the creation, update, and deletion times for all data items. Tombstone entries are used to indicate deleted data items.

The application uses that information to efficiently monitor whether a particular item, item extension, or item relationship has been newly added, updated, or deleted since the application last accessed the data store. The following example illustrates this mechanism.

All deleted items, item extensions and relationships are recorded in the corresponding gravestone tables. Next, a template is shown.

For efficiency, the storage platform maintains a set of global tables for items, item extensions, relationships, and path names. This global lookup table can be used by the application to efficiently monitor the data area and retrieve the associated time stamp and type information.

b) timestamp management

The logical time stamp is "local" to the database store, i.e. the storage platform volume. The time stamp monotonically increases to a 64-bit value. Holding a single time stamp is often sufficient to detect if data has changed since the last connection to the storage platform volume. However, in most realistic scenarios, several more time stamps are needed to continuously check for duplicates. The reason is explained next.

Relational database tables are logical abstractions built on top of a set of physical data structures (ie, B-trees, heaps, etc.). Assigning a time stamp to a newly created or updated record is not an atomic action. Inserting the record into the underlying data structure can be issued at different times, so the application can know that the record order is out of order.

14 shows two transactions inserting a new record into the same B-tree. Since transaction T3 inserts its record before the insertion of transaction T2 is scheduled, the application scanning the B-tree can see the record inserted by transaction T3 before being inserted by T2. Thus, the reader may incorrectly assume that he has seen all the records created by time "10". To solve this problem, the database engine 314 provides the ability to return a low watermark until all updates are made and inserted into individual underlying data structures. In the above example, assuming that the reader has started before transaction T2 is made, the low watermark returned will be "5". The low watermark provided by the database engine 314 allows the application to efficiently determine which items to ignore when scanning the data area for database or data changes. In general, ACID transactions are assumed to last only for a very short time, and low watermarks are expected to be very close to the most recently distributed time stamp. When there is a long lasting transaction, the application will have to maintain separate time stamps to detect and delete duplicates.

c) Data change detection-event detection

When querying the data store, the application gets a low watermark. The application then uses the watermark to scan the data store to find entries that are larger than the low watermark for which a create, update, or delete time stamp was returned. 15 shows this process.

To prevent duplicate notifications, the application remembers timestamps larger than the low watermark returned and uses them to remove duplicates. The application creates session-local temporary tables to efficiently manage large sets of duplicate time stamps. Before issuing a select statement, as shown below, the application inserts any duplicate time stamps that have already been returned and deletes those older than the last low watermark returned.

E. Synchronization

According to another aspect of the present invention, the storage platform allows (i) multiple instances of the storage platform, each with its own data store 302, to synchronize portions of their content according to a flexible set of rules. And (ii) provide a synchronization service 330 that provides an infrastructure for the third party to synchronize the data repository of the storage platform of the present invention with other data sources implementing proprietary protocols.

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

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

The synchronization capability of the present invention is that

Determine what changes the other copy is aware of,

Request information about changes that this copy does not know;

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

Determine when two changes conflict with each other,

Apply the change locally,

Deliver conflict resolution to other copies to ensure convergence,

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

1. Storage platform vs storage platform synchronization

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

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

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

a) Sync control application

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

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

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

b) annotating the schema

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

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

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

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

c) Configure synchronization

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

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

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

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

(1) community folder-mapping

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

/ mappings / communityFolder

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

/ mappings / localFolder

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

/ mappings / transformations

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

/ mappings / transformation / mapIDs

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

/ mappings / transformations / localRoot

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

/ mappings / runAs

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

/ mappings / runAs / sender

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

(2) profile

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

Local folders that serve as the source and target for changes

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

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

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

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

Conversion-defines how items are converted for the local format.

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

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

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

(3) schedule

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

d) conflict handling

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

(1) collision detection

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

(a) knowledge base conflict

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

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

(b) restriction-based conflicts

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

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

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

(2) conflict handling

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

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

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

(a) Automatic conflict resolution

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

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

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

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

Deterministic: We select Wiener in such a way as to ensure that it is otherwise insignificant on all copies, in one embodiment of the synchronization service using preedit comparisons of partner IDs to implement this functionality.

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

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

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

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

(b) conflict logging

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

(c) collision detection and resolution

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

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

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

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

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

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

2. Synchronize for non-storage platform data store

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

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

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

a) synchronization service

Synchronization services provide a number of synchronization services to adapter writers. In the remainder of this section, it is convenient to refer to the device that the storage platform is synchronizing with as "client" and the non-storage platform backend with which the adapter is talking as "server."

(1) change enumeration

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

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

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

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

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

(2) apply changes

Change application allows synchronization adapters to apply changes received from their backend to the local storage platform. Adapters are expected to convert changes to the storage platform schema.

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

(3) conflict resolution

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

b) adapter implementation

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

3. Security

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

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

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

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

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

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

4. Manageability

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

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

G. Normal File System Interoperability

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

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

1. Model for interoperability

In accordance with this aspect of the present invention and in accordance with the embodiments described above, the storage platform implements a non-file item and one namespace in which file items can be organized. By this model, the following advantages are taken:

1. Folders within a data store can contain both file and non-file items, thus representing a single namespace for files and schematized data. It also provides a uniform security, sharing and management model for all user data.

2. This approach presents a better programming model for application developers to work on again because both file and non-file items are accessible using the storage platform APIs and there are no specific rules enforced on files.

3. All namespaces are passed through the storage platform and are therefore processed synchronously. While deep attribute enhancements (discarding file content) still occur asynchronously, it is important to keep in mind that synchronous operations provide a much more predictable environment for users and applications.

In this embodiment, as a result of this model, search capabilities may not be provided for data sources that are not migrated to the storage platform data repository. This includes files on removable media, remote servers and local disks. A synchronization adapter is provided that represents proxy items (shortcuts + enhanced metadata) within the storage platform for items residing in an external file system. Proxy entries do not attempt to mimic files in terms of data source namespace hierarchy or in terms of security.

The balance made on the programming model and namespace between file content and non-file content provides an application with a better path for migrating content from the file system to more structured items in the storage platform data store over time. By providing a raw file item type in the storage platform data store, the application program can still manipulate the file data via Win32 while transitioning the file data to the storage platform. Eventually, application programs can migrate seamlessly to storage platform APIs and organize their data in terms of storage platform items rather than files.

2. Data storage function

In order to provide the desired level of interoperability, in one embodiment the following storage platform data storage functions are implemented.

a) not a volume

Storage Platform Data storage is not exposed as individual file system volumes. The storage platform is affected by FILESTREAMs hosted directly on NTFS. Thus, the on-disk format is not changed, thereby eliminating the need to expose the storage platform to a new file system at the volume level.

Instead, the data store (name space) is configured to correspond to NTFS volumes. Databases and FILESTREAMs that support part of this namespace are located on the NTFS volume with which the storage platform data store is associated. A data store corresponding to the system volume is also provided.

b) storage structure

The structure of the repository is well illustrated with examples. For example, as illustrated in FIG. 16, consider a directory tree on the system volume of a device named HomeMachine. According to the file system interoperability function of the present invention, there is a storage platform data store corresponding to C: \ drive exposed to the Win32 API, for example via a UNC share called "WinFSOnC". This makes the associated data store accessible through a UNC name of "HomeMachine" and WinFSOnC.

In this embodiment, files and / or folders need to be explicitly migrated from NTFS to the storage platform. Therefore, if the user wants to move the My Document folder to the storage platform data store to use all of the redundant search / categorization functions provided by the storage platform, the hierarchy will appear as shown in FIG. In this example, it is important to keep in mind that these folders are actually moved. Another thing to keep in mind is that the namespace moves to the storage platform, and the actual stream is renamed FILESTREAM with the appropriate pointer hooked up in the storage platform.

c) not all files are migrated

Files that correspond to user data or require search / categorization provided by the storage platform are candidates for migration to the storage platform data repository. Preferably, in order to limit the problem of application program compatibility with the storage platform, from the perspective of the Microsoft Windows operating system, the file set migrated to the storage platform of the present invention may be stored in the MyDocument folder, Internet Explorer (IE) Favorites, IE History. (IE History), and files in the desktop .ini file in the Document and Setting directory. Preferably, migration of Windows system files is not allowed.

d) NTFS Namespace Access to Storage Platform Files

In the embodiment described herein, files migrated to the storage platform are not accessed through the NTFS namespace even though the actual file stream is stored in NTFS. In this way, the complex locks and security that result from a multi-headed implementation need not be considered.

e) extended namespace / drawing characters

Access to files and folders in the storage platform is provided through UNC names of the form 〈< machine name〉 〈< WinfsShareName>. For classes of applications that request a derivation character for an action, the derivation character may be mapped to this UNC name.

I. Storage Platform API

The storage platform includes an API that allows application programs to access the functionality and capabilities of the storage platform described above and to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform of the present invention.

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

1. Overview

The data access mechanism of this embodiment for the storage platform API of the present invention deals with four areas of query, navigation, action, and event.

vaginal

In one embodiment, the storage platform data store is implemented on the relational database engine 314, and as a result, the complete expression of the SQL language is inherited by the storage platform. Higher level query objects provide a simplified model for querying the repository, but cannot encapsulate the complete expressiveness of the store.

navigation

The storage platform data model builds a rich scalable type system for the underlying database abstraction. For the developer, the storage platform data is the item's web. Storage platform APIs enable navigation from item to item through filtering, relationships, folders, and the like. This is a higher level of abstraction than basic SQL queries, and sometimes allows rich filtering and navigation capabilities to be used with the familiar CLR coding pattern.

action

The storage platform API exposes common actions for all items, namely create, delete, update as methods on the object. In addition, domain specific actions such as SendMail, CheckFreeBusy, etc. are also available as methods. The API framework uses well-defined patterns that ISVs can use to add values by defining additional actions.

event

The data in the storage platform is dynamic. To make the application react when data in the repository changes, the API exposes a wealth of eventing, subscription, and notification capabilities to the developer.

2. Naming and scope

This is useful for distinguishing between namespaces and naming. The term namespace refers to all sets of names available in some systems, as is commonly used. This system can be an XML schema, a program, a web, a set of all ftp sites (and their content), and so on. Naming is the process and algorithm used to assign a unique name to the namespace for every entity of interest. Therefore, naming is important because it is desirable to explicitly refer to a given unit within the namespace. Thus, as used herein, the term “name space” refers to the set of all names available within virtually every storage platform instance. An item is a named entity in the storage platform namespace. Using the UNC naming conventions ensures the uniqueness of item naming. Actually all storage platform All entries in the repository are addressable by UNC naming.

The highest systematic level within the storage platform namespace is simply a service that is an instance of the storage platform. The next level of organization is volume. A volume is the largest autonomous container of items. Each storage platform instance includes one or more volumes. The volume has an entry. The item is the smallest unit of data in the storage platform.

Real-world data is almost always organized according to some system that has meaning within a given domain. All of these basic data organization schemas are the concept of dividing all of the data into named groups. As mentioned above, this concept is modeled within the storage platform by the folder concept. Folders are a specific type of item, and there are two folder types: containing folder and virtual folder.

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

A virtual folder is a more dynamic way of organizing a set of items, simply a name given a set of items (the set is either explicitly listed or specified by a query). A virtual folder is itself an item and can be considered to represent a set of (non-holding) relationships with the item set.

Sometimes it is necessary to model a tighter concept of a container, for example, a word document embedded in an e-mail message is more tightly coupled to its container than a file contained within a folder. This concept is represented by the concept of insert items. An insert item has a particular kind of relationship that references another item, and the referenced item can be combined with the containing item or, on the other hand, can only be adjusted in its context.

Finally, the storage platform provides the concept of categories as a means of classifying items and elements. Every item or element in the storage platform may be associated with one or more categories. A category is essentially simply a name tagged to an item / element. This name can be used when searching. The storage platform data model allows for the definition of a hierarchy of categories, thus enabling the classification of data such as trees.

There are three self-explanatory names for items: (<serviceName>, <volumeID>, and <ItemID>). Some items (specifically, folders and virtual folders) are a collection of other items. This provides an alternative way of identifying items (<serviceName>, <volumeID>, <itemPath>).

The storage platform name includes the concept of a service context, which is a name that maps to a pair of (<volumeName>, <path>). This identifies the item or set of items (eg, folder, virtual folder, etc.). By the concept of a service context, the UNC name for any item in the storage platform namespace is: << serviceName> << serviceContext> << itemPath>.

The user can create and delete service contexts. In addition, the root directory in each volume has a predefined context volume-name $.

The ItemContext scopes a query (eg, a find operation) by limiting the results returned to items that live within the specified path.

3. Storage Platform API Components

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

According to one aspect of the present invention, at design time, the schema author submits the schema document 2010 and the code 2012 for the domain method to a set of storage platform API design time tools 2008. These tools generate client-side data classes 2002 and storage schemas 2014 and store class definitions 2016 for those schemas. A "domain" refers to a particular schema, for example domain methods for classes such as contact schemas. This data class 2002 is used at runtime by the application developer (in cooperation with the storage platform API runtime framework class 2006) to manipulate the storage platform data.

To illustrate various aspects of the storage platform API of the present invention, examples based on example contact schemas are presented. Illustrative representations of example schemas are illustrated in FIGS. 21A and 21B.

4. Data Class

According to aspects of the present invention, each item, item extension, and element type, as well as each relationship in the storage platform data store, has a corresponding class in the storage platform API. Roughly, the type field maps to a class field. Each item, item extension, and element in the storage platform is available as an object of the corresponding class in the storage platform API. Developers can query to create, modify, or delete these objects.

The storage platform includes an initial set of schemas. Each schema defines a set of item and element types, and a set of relationships. The following is an embodiment of an algorithm for generating data classes from these schema entities:

For each schema S:

For each item I, a class S.I named System.Storage is created in S. This class has the following members:

An overloaded constructor that includes a constructor that allows the initial folder and name of the new item to be specified.

Attributes for each field in I. If the field has multiple values, the attribute will be a set of corresponding element types.

Overloaded static methods that find multiple items that match the filter (for example, the method named "FindAll").

· Overloaded static methods to find a single item that matches the filter (for example, the method named "FindOne").

· Static method to find the item given its id (for example, the method named "FindByID")

· Static method to find the item given its name relative to the ItemContext (for example, the method named "FindByName").

· A method for saving changes to the item (for example, a method named "Update").

Overloaded static creation method that creates a new instant for an item.

These methods allow the initial folder of an item to be specified in various ways.

For each element E, a class S.E is created in S named System.Storage. This class has the following members:

Attributes for each field in E. If the field is multi-valued, the attribute will be a set of corresponding element types.

For each element E, a class S.E Collection is created in S named System.Storage. This class follows the general .NET framework guidelines for strongly typed aggregate classes. For relation-based element types, this class will also contain the following members:

An overloaded method that finds a number of item objects that match a filter whose collection explicitly includes the item represented by the source role. Overloads include methods that allow filtering based on item subtypes (eg, a method named "FindAllTargetItems").

An overloaded method that finds a single item object that matches a filter whose collection explicitly contains the item represented in the source role. The overload includes methods that allow filters based on item subtypes (eg, a method named "FindOneTargetItems").

Overloaded methods (eg, a method named "FindAllRelationship") that look for objects of nested element types that match a filter whose collection explicitly includes the item indicated in the source role.

An overloaded method that looks for objects of nested element types that match a filter whose collection explicitly includes the item indicated in the source role (for example, the method named "FindAllRelationshipsForTarget").

Overloaded methods (for example, a method named "FindOneRelationship") that look for a single object of nested element type that matches a filter whose collection explicitly contains the item indicated in the source role.

Overloaded methods (for example, a method named "FindOneRelationshipForTarget") that finds a single object of nested element type that matches a filter whose collection explicitly contains the item represented in the source role.

For relationship R, a class S.R named System.Storage is created in S. This class will have one or two subclasses, depending on whether one or two relationship roles specify endpoint fields.

The class is also created in this way for each item extension created.

The data class resides in the System.Storage. <SchemaName> namespace, where <schemaName> is the name of the corresponding schema, such as contacts, files, and so on. For example, all classes corresponding to the contact schema are in the System.Storage.Contact namespace.

For example, referring to FIGS. 21A and 21B, the contact schema creates the following classes included in the System.Storage.Contact namespace:

Item: Folder, WellKnownFolder, LocalMachineDataFolder, UserDataFolder, Principal, Service, GroupService, PersonService, PresenceService, ContactService, ADService, Person, User, Group, Organization, HouseHold.

Elements: NestedElementBase, NestedElement, IdentifyKey, SecurityID, EAddress, ContactEAddress, TelephoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, WindowsPresence, Relationship, TemplateRelationship, LocationRelationship, FamilyEventLocationRelationship, HouseHoldLocationRelationship, RoleOccupancyationRelationship, Employeehipship , HouseHoldMemberData, FamilyData, SpouseData, ChildData.

For example, the detailed structure for the Person type (as defined in the contact schema) is shown in XML below:

This type creates the following class (only public members are shown):

As another example, the detailed structure for the TelephoneNumber type (as defined in the contact schema) is given in XML below:

This type creates the following class (only public members are shown):

The hierarchy of classes created from a given schema directly reflects the hierarchy of the types in that schema. For example, consider the Item type defined within the contact schema (see FIGS. 21A and 21B). The corresponding class hierarchy in the storage platform API would be:

Object

DataClass

ElementBase

RootItemBase

Item

Principal

Group

Household

Organization

Person

User

Service

PresenceService

ContactService

ADService

RootNestedService

... (element classes)

Another schema that allows representing all audio / video media (damaged audio files, audio CDs, DVDs, home videos, etc.) in the system is to store, organize, retrieve, and manipulate different kinds of audio / video media. Make it possible. The base media document schema is general enough to represent any medium, and extensions to this base schema are designed to handle domain specific attributes for audio and video media separately. This schema and many others are thought to operate directly or indirectly under the core schema.

5. Runtime framework

The underlying storage platform API programming model is object persistent. The application program (or “application”) retrieves the repository and retrieves the objects representing the data in the repository. The application modifies the retrieved objects or creates new objects and allows their changes to propagate to the repository. This process is managed by an ItemConext object. The search is performed using the ItemSearcher object, and the search results are accessible through the FindResult object.

a) runtime framework classes

According to another inventive aspect of the storage platform API, the runtime framework implements a number of classes that support the operation of data classes. These framework classes define a common set of behaviors for data classes, and together with the data classes provide a basic programming model for storage platform APIs. Classes in the runtime framework belong to the System.Storage namespace. In this embodiment, the framework class includes the main classes of ItemContext, ItemSearcher and FindResult. Other minor classes, enumeration values, and representatives may also be provided.

(1) ItemContext

The ItemContext object represents (i) the set of item domains that the application program wants to retrieve, (ii) maintains state information for each object representing the state of the data retrieved from the storage platform, and (i) interacts with the storage platform. It manages the transactions used when working, and any file system with which the storage platform can work.

Like the object persistence engine, ItemContext provides the following services:

1. Deserialization of data read from storage into objects.

2. Maintain object identifiers (the same object is used to represent a given item regardless of how many items are included in the query results).

3. Object state tracking.

ItemContext also performs a number of services specific to the storage platform:

1. Create and run a storage platfrom update gram operation required to persist the change.

2. Create connections to multiple data stores needed to enable even navigation of reference relationships and allow retrieved objects to be modified and stored from multi-domain searches.

3. Ensure that file backed items are updated accordingly when changes to the object (s) representing the item are saved.

4. Manage transactions across multiple storage platform connections (when updating data stored in file stream attributes and file supported items) and transacted file systems.

5. Create, copy, move, and delete operations that take into account storage platform relationship semantics, file support items, and stream typed attributes.

Appendix A provides a source code list of the ItemContext class, according to one embodiment.

(2) ItemSearcher

The ItemSearcher class supports simple search that returns an entire item object, a stream of item objects, or a stream of values estimated from an item. ItemSearcher encapsulates core functionality that is common to both the target type and the concept of parameterized filters applied to that target type. ItemSearcher also allows the searcher to be precompiled or prepared as an optimization when the same search is performed for multiple types. Appendix B provides a source code list of the ItemSearcher class and several closely related classes, according to one embodiment.

(a) target type

The search target type is set when you configure the ItemSearcher. The target type is a CLR type that maps to a queryable range by the data store. Specifically, it is a CLR type that maps not only to schemad views but also to items, relationships, and item extension types.

When retrieving a searcher using the ItemContext.GetSearcher method, the searcher's target type is specified as a parameter. When a static GetSearcher method is called for an item, relationship, or item extension type (eg, Person.GetSearcher), the target type is an item, relationship, or item extension type.

The search expression provided to ItemSearcher (eg, search filter and through find option, or estimation definition) is always related to the search target type. Such expressions may specify attributes of the target type (including attributes of nested elements), and alternatively, may specify associations into relationships and item extensions.

The search target type is available via read only properly (e.g., ItemSercher.Type property).

(b) filter

The ItemSearcher contains properties for specifying a filter that defines the filter used for the search (e.g., a property named "Filter" as a collection of SearchExpression objects). All filters in the set are combined using logic and operators when the search is performed. The filter can include parameter references. Parameter values are specified through the Parameters property.

(c) preparing for search

Perhaps with only parameter changes, some performance improvement can be obtained by compiling or preparing a search in the situation where the same search is executed repeatedly. This is a set of prepare methods for ItemSearcher (for example, a method named "PrepareFind" to prepare a Find that returns one or more items, and a method named "PrepareProject" to prepare a Find that returns estimates. ) Yes:

(d) Find options

There are a number of options that can be applied to simple searches. For example, they can be specified by a FindOption object and passed to the Find method. Yes:

For convenience, sorting options can also be passed directly to the Find method:

The DelayLoad option determines whether the value of a large binary attribute is loaded when the search results are retrieved or delayed before loading is referenced. The MaxResults option determines the maximum number of results returned. This is equivalent to specifying a TOP in an SQL query. This is mainly used in connection with sorting.

A series of SortOption objects can be specified (eg, using the FindOptions.SortOptions property). The search results will be sorted as specified by the first SortOption object, then as specified by the second SortOption object, and so on. SortOption specifies a search expression that represents the attribute to be used for sorting. The expression specifies one of the following:

1. scalar attribute in search target type;

2. A scalar attribute in a nested element that can be reached from a search target type by traversing a single valued attribute; or

3. The result of the aggregation function with valid arguments (eg, the maximum value applied to a scalar attribute within a nested element reachable from the search target type by traversing an attribute or relationship that is multivalued).

For example, suppose the search target type is System.Storage.Contact.Person:

1. "Birthdate"-Valid, birthday is a scalar attribute of type Person.

2. "PersonalNames.Surname"-invalid, PersonalNames is a multi-valued property and no aggregation feature is used.

3. "Count (PersonalNames)"-Valid, count of PersonalNames.

4. "Case (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate"-A multi-valued property that has no invalid, no user relations, and no aggregation capabilities.

5. "Max (Cast (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate)"-The start date of the valid, most recent home email address.

(3) Item Result Stream ("FindResult")

An ItemSearcher (eg, via the FindAll method) returns an object (eg, a "FindResult" object) that can be used to access the object returned by the search. Appendix C provides a source code list of the FindResult class and several closely related classes, according to one embodiment.

There are two separate methods for using the read pattern defined by IObjectReader (and IAsyncObjectReader), and the enumerator pattern defined by IEnumerable and IEnumerator, to obtain results from a FindResult object. The enumerator pattern is standard within the CLR and supports language constructs such as C # 's foreach. Yes:

Reader patterns are supported because in some cases deleting data copies allows for more efficient processing of the results. Yes:

In addition, the reader pattern supports asynchronous operation:

In this embodiment, FindResult should be closed when no longer needed. This can be done by calling the Close method or using a language construct such as C # that uses statements. Yes:

b) runtime framework within operations;

22 illustrates an active runtime framework. The runtime framework works as follows:

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

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

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

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

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

c) common programming patterns

This section provides various examples of how storage platform API framework classes can be used to manipulate items in a data store.

(1) opening and closing an ItemContext object

The application obtains an ItemContext object that will be used to interact with the data store, for example, by calling a static ItemContext.Open method and providing a path or paths identifying the item domain to be associated with the ItemContext. The item domain defines the scope of the search performed using the ItemContext, so that only the domain item and the items contained in that item will be searched. An example is as follows:

local On computer Default  Repository storage platform share ItemContext The yeom

ItemContext ic = ItemContext.Open ();

With a given storage platform share ItemContext The yeom

ItemContext ic = ItemContext.Open (@ "＼＼myserver1＼DefaultStore");

As items under storage platform sharing ItemContext The yeom

ItemContext ic = ItemContext.Open (@ "'myserver1'WinFSSpecs'api'm6');

To multiple entry domains ItemContext The yeom

The ItemContext should be closed when no longer needed.

ItemContext Explicitly close

ItemContext With Statement  Close to use

(2) object search

According to another aspect of the present invention, the storage platform API may enable the application programmer to form a query based on various item attributes in the data store in a manner that isolates the application programmer from the details of the query language of the underlying database engine. It provides a simplified query model.

An application can use the ItemSearcher object returned by the ItemContext.GetSearcher method to perform a search for the specified domain when the ItemContext is opened. For example, suppose the following declaration:

The basic search pattern involves using an ItemSearcher object retrieved from an ItemContext by calling the GetSearcher method.

Search all items of a given type

Search for items of a given type that satisfy the filter

Use parameters within search filter strings

Find relationships that satisfy a given type and filter

Search for items of a given type and a relationship that satisfies the filter

Search for item extensions that satisfy the given type and filter

Search for items of the given type and with item extensions that satisfy the filter

(a) search options

Various options can be specified when performing a search, including sorting, lazy loading, and limiting the number of results.

Sort Results

Result count limit

(b) FindOne and FindOnly

Sometimes it is useful to retrieve only the first result, especially when specifying sort criteria. In addition, some searches are expected to return only one object, but not expected to return any object.

Search for one object

Retrieve a single object that is always expected to exist

(c) Shortcut search of ItemContext

There are a number of shortcut methods in the ItemContext that make simple searches as easy as possible.

ItemContext . FindAll Shortcut  Search used

ItemContext . FindOne Shortcut  Search used

Person p = ic.FindOne (typeof (Person), "PersonalNames.Surname = 'Smith'") as Person;

(d) Find by ID or path

In addition, items, relationships, and item extensions can be retrieved by providing their id (s). Items can also be retrieved by path.

get item, relationship and item extension given id (s)

Get item given path

(e) GetSearcher pattern

Within the storage platform API, there are several places where it is desirable to provide helper methods to perform searches in the context of other objects or with specific parameters. The GetSearcher pattern makes these scenarios possible. There are a number of GetSearcher methods in the API. Each returns a preconfigured ItemSearcher to perform a given search. Yes:

You can add additional filters before running the search:

You can choose how you want the result:

(3) update the repository

Once the object is retrieved by the search, it can be modified by the application as needed. New objects can also be created and associated with existing objects. When an application makes all the changes that make up a logical group, the application calls ItemContext.Update to persist those changes to the repository. According to another aspect of the storage platform API of the present invention, the API collects changes to the items made by the application program, and makes them correct as required by the database engine (or any kind of storage engine) in which the data store is implemented. Systematize with update. This allows the application programmer to change items in memory while leaving the complexity of updating the data store for the API.

Save Changes to a Single Item

Save Changes to Multiple Items

Create new item

relation( target  Delete items)

Add item extension

Delete item extension

6. Security

Referring to section II.E (Security) above, in this embodiment of the storage platform API, there are five methods available on the ItemContext to retrieve and modify the security policy related to the item in the repository. They are as follows:

1. GetItemSecurity;

2. SetItemSecurity;

3. GetPathSecurity;

4. SetPathSecurity; And

5. GetEffectiveItemSecurity

GetItemSecurity and SetItemSecurity provide mechanisms for retrieving and modifying explicit ACLs associated with items. This ACL is independent of the paths present in the entry and will be independent of any maintenance relationships that have this entry as a target (while running). This allows the administrator to make logical inferences about item security that is independent of the paths present in the item, if desired.

GetPathSecurity and SetPathSecurity provide a mechanism for retrieving and modifying ACLs on items because of their maintenance relationships from other folders. This ACL consists of the ACLs of the various ancestors of the item along the path, along with the explicit ACL if one was supplied for that path. The difference between this ACL and the ACL in the previous case is that the explicit item ACL is independent of any maintenance relationship to the item, while this ACL remains (running) as long as the corresponding maintenance relationship exists.

ACLs that can be set on items by SetItemSecurity and SetPathSecurity are inheritable and limited to object specific ACEs. They cannot contain ACEs marked as inherited.

GetEffectiveItemSecurity retrieves various path-based ACLs as well as explicit ACLs on items. This actually reflects the authentication policy for a given item.

7. Relationship Support

As mentioned above, the storage platform's data model defines a "relationship" that allows items to be related to others. When a data class for a schema is created, the following classes are created for each relationship type:

1. A class that represents the relationship itself. This class is derived from the Relationship class and contains members specific to the relationship type.

2. A strongly typed "virtual" aggregate class. This class is derived from the VirtualRelationshipCollection, allowing relationship instants to be created and deleted.

This section supports relationships within the storage platform API.

a) the underlying relationship type

The storage platform API provides a number of types within the System.Storage namespace that form the infrastructure of the relational API. These are:

1. Relationship-the base type of all relationship classes

2. VirtualRelationshipCollection-the base type for all relationship sets

3. ItemReference, ItemIDReference, ItemPathReference-indicates an item reference type; The relationship between these types is illustrated in FIG.

(1) Relationship class

The following is the base class for relation classes.

(2) ItemReference class

The following is the base class for item reference types.

An ItemReference object can identify items that exist in a repository other than where the item reference resides. Each derived type specifies how a reference to a remote repository is constructed and used. The implementations of GetItem and IsDomainConnected in the derived class use ItemContext's multi-domain support to load items from the required domain and determine whether a connection to the domain has already been established.

(3) ItemIdReference class

Here is the ItemIdReference class-the item reference identifies the target item using the item id.

GetItem and IsDomainConnected use ItemContext's multi-domain support to load items from the required domain and determine whether a connection to the domain has already been established. This feature is not yet implemented.

(4) ItemPathReference class

The ItemPathReference class is an item reference that uses a path to identify the target item. The code for this class is as follows:

GetItem and IsDomainConnected use ItemContext's multi-domain support to load items from the required domain and determine whether a connection to the domain has already been established.

(5) RelationshipId structure

The RelationshipId structure encapsulates a RelationshipId GUID.

This value type wraps the GUID, allowing the parameters and attributes to be strongly typed into the relationship id. OptionalValue <RelationshipId> should be used when the relationship id can be null. Empty values such as those provided by System.Guid.Empty are not exposed. RelationshipId cannot consist of empty values. When creating a RelationshipId using the default constructor, a new GUID is generated.

(6) VirtualRelationshipCollection class

The VirtualRelationshipCollection class implements a set of relational objects that contain objects from the data store, sums up new objects added to the set, but does not include objects removed from the store. Objects of the specified relationship type with the given source item id are included in the set.

This is the base class for the relationship set class created for each relationship type. This class can be used as an attribute type within a source item type to provide easy manipulation and access to a given item relationship.

Enumerating the contents of the VirtualRelationshipCollection potentially requires that multiple relationship objects be loaded from the repository. The application uses the Count attribute to determine how many relationships can be loaded before enumerating the contents of the set. Adding an object to and removing an object from the set does not require the relationship to be loaded from the repository.

For efficiency, instead of enumerating all item relationships, it is desirable for the application to retrieve only those relationships that meet certain criteria using the VirtualRelationshipCollection object. When you add a relationship object to the set, the expressed relationship is created in the repository when ItemContext.Update is called. If you remove a relationship object from the set, when the ItemContext.Update is called, the represented relationship is deleted from the repository. A virtual set contains the correct set of objects, regardless of whether the relationship objects are added / removed through the Item.Relationships set or any other set of relationships for that item.

The following code defines the VirtualRelationshipCollection class:

b) the type of relationship created

When you create a class for the storage platform schema, a class is created for each relationship declaration. In addition to the classes representing the relationships themselves, a relationship set class is also created for each relationship. These classes are used as attribute types of relational source or target item classes.

This section describes classes created using a number of "sample" classes. That is, given a specified relationship declaration, the generated class is described. The class, type, and endpoint names used within the sample classes are place holders for names for relationships, specified in the schema, and should not be taken literally.

(1) the created relationship type

This section describes the classes created for each relationship type. Yes:

Given this relationship definition, the RelationshipPrototype and RelationshipPrototype Collection classes are created. The RelationshipPrototype class represents the relationship itself. The RelationshipPrototype Collection class provides access to a RelationshipPrototype instance with an item specified as the source endpoint.

(2) RelationshipPrototype class

This is a sample relationship class for a maintenance relationship named " HoldingRelationshipPrototype ", where the source endpoint is named " Head " and specifies the "Foo" item type, and the target endpoint is named " Tail " and the "Bar" item Specifies the type. It is defined as follows:

(3) RelationshipPrototypeCollection class

This is the RelationshipPrototype owned by the specified item. Sample class generated by the RelationshipPrototype class that maintains a set of relationship instances. This is defined as follows:

c) supporting relationships within item classes

The Item class contains a Relationship attribute that provides access to the relationship whose item is the source of the relationship. Relationship attribute has type RelationshipCollection.

(1) Item class

The following code shows the relational context properties of the Item class:

(2) RelationshipCollection class

This class provides access to the relationship instance when the relationship given item is the source of the relationship. This is defined as follows:

d) supporting relationships in search expressions;

It is possible to specify the traversal of the association between the relationship in the search expression and the related item.

(1) Traversing from Item to Relationship

When the current context of the search expression is a set of items, if the item is a source, the association between the item and the relationship instance can be done using the Item.Relationships attribute. Combining with a particular type of relationship can be specified using the search expression Cast operator.

A strongly typed set of relationships (eg Folder.MemberRelationships) can also be used in the search expression. The cast to the relation type is absolute.

Once a relationship set is built, the properties of that relationship can be used in predicates or as targets for estimation. When used to specify the target of the estimate, a relationship set can be returned. For example, the following statement will find all people involved in a system whose relationship's StartDate attribute is greater than or equal to '1/1/2000'.

If the Person type has an attribute EmployerContext of type EmployeeSideEmployerEmployeeRelationships (such as one created for the EmployeeEmployer relation type), it can be written as follows:

(2) Traversing from relationship to item

When the current context of the search expression is a set of relationships, the association from the relationship to the endpoint of the relationship can be traversed by specifying the name of the endpoint. Once a set of related items is built up, the attributes of these items can be used within the predicate or as a target of estimation. When used to specify the target of the estimate, an item set can be returned. For example, the following statement will find all EmployeeOfOrganization relationships whose employee's last name is "Smith" (regardless of the scheme):

Using the search expression Cast operator, you can filter the type of the endpoint item. For example, let's find all the MemberOfFolder relationship instances where the member is a Person entry with alias "Smith":

(3) relationship traversal combination

Any combination traversal can be created by combining the two patterns (traversal from item to relationship and traversal from item to item). For example, let's find all systems with employees with the nickname "Smith":

The following example will find all Person entries that represent people living in families in the "New York" area (TODO: this no longer supports the alternative).

e) exemplary use of relationship support

The following is an example of how relationship support in the storage platform API can be used to manipulate relationships. For the following example, assume the following declaration:

(1) relationship search

It is possible to retrieve a source or target relationship. Filters can be used to select relationships of a specified type and with given attribute values. You can also use filters to select relationships based on related item types or attribute values. For example, the following search may be performed:

All relationships for which a given item is a source

All relationships where a given item is a source whose name matches "A%"

All of the given items are sources FolderMember  relation

All items whose source is the source and whose name is "A%" FolderMember  relation

target  All items with Person FolderMember  relation

target  All items whose Person has the alias "Smith" FolderMember  relation

In addition to the GetSearcher shown above, each relationship class supports static FindAll, FineOne and FineOnly APIs. In addition, the relationship type may be specified when calling ItemContext.GetSearcher, ItemContext.FindAll, ItemContext.FindOne or ItemContext.FindOnly.

(2) navigation from source to target items

Once the relationship object is retrieved through a search, it is possible to "navigate" to the target or source item. The underlying relationship class provides the SourceItem and TargetItem attributes, which return an Item object. The generated relation class provides strongly typed equivalents and named attributes (eg FolderMember.FolderItem and FolderMember.MemberItem). Yes:

Named " Foo Source for relationship and target  By item navigation

target  By item navigation

Even if the target item is not in the domain in which the relationship is found, navigation to the target item operates. In this case, the storage platform API opens a connection to the target domain when needed. The application can determine whether a connection will be requested before retrieving the target item.

Within a disconnected domain target  Item check

(3) navigation from source item to relation

Given an item object, you can navigate to that item as a source without running an explicit search. This is done using strongly typed set attributes such as Item.Relationship set attributes or Folder.MemberRealtionships. It is possible to navigate from the relationship to the target item. This navigation is done even if the target item is not in the item domain associated with the ItemContext of the source item, and the target item is not in the same repository as the target item. Yes:

From the source item target  In relation to item navigation

From folder items target  To the item Foldermember  Relationship navigation

An item can have multiple relationships, so applications should be careful when enumerating a set of relationships. In general, a search is used to identify a particular relationship of interest instead of enumerating the entire set. Also, having a set-based programming model for relationships is well worth it, and there are few items with many relationships, which justifies the risk of misuse by developers. The application can check the number of relationships in the set and use a different programming model if necessary. Yes:

Check the size of the relationship set

The relationship sets described above are "virtual" in the sense that they are not actually populated by objects representing each relationship until the application actually attempts to enumerate the sets. When a set is enumerated, the results reflect what is in the repository and what has been added by the application but not yet stored, and does not reflect any relationships that have been removed by the application but not yet stored.

(4) Create relationships (and items)

A new relationship is created by creating a relationship object, adding it to a set of relationships in the source item, and updating the ItemContext. To create a new item, a maintain or insert relationship must be created. Yes:

Add new item to existing folder

Add existing item to existing folder

Add existing item to new folder

Add new item to new folder

(5) Delete relationships (and items)

Delete maintenance relationship

8. Storage Platform API "Extension"

As mentioned above, every storage platform schema generates a set of classes. These classes have standard methods, such as Find *, and also have properties for getting and setting field values. These classes and related methods form the infrastructure of the storage platform API.

a) domain behavior

In addition to these standard methods, every schema has a set of domain specific methods for it. We call this domain behavior. For example, some domain behaviors in the contact schema are:

Is your email address valid?

Given a folder, get the set of all members of the folder.

Given an item ID, obtain an object representing this item.

Given Person, get his online status.

· Helpers to create new or temporary contacts.

· Etc

While distinguishing between "standard" behavior (such as Find *) and domain behavior, it's important to keep in mind that they are simply seen as methods by the programmer. The distinction between these methods is based on the fact that domain behavior is coded unaltered while standard behavior is automatically generated from the schema file by the storage platform API design time tool.

By their nature, this domain behavior is generated directly. This leads to the real problem that earlier versions of C # required that the entire implementation of a class be in a single file. Therefore, this forces the automatically generated class file to be edited to add domain behaviors. That alone can be a problem.

For this problem, a feature called partial classes has been introduced in C #. Basically, partial classes allow a class implementation to span multiple files. A partial class is identical to a regular class except that the keyword part follows its declaration:

Now, the domain behavior for Person can be placed in different files as follows:

b) behavior of value addition

Data classes with domain behavior form the infrastructure that application developers build. However, it is impossible and undesirable for a data class to expose all conceivable behavior associated with that data. The storage platform allows developers to build the underlying infrastructure provided by the storage platform API. The basic pattern herein is to create a class of methods that take one or more storage platform data classes as parameters. For example, a value-added class for sending email using Microsoft Outlook or Microsoft Windows Messenger might look like this:

This value addition class may be registered in the storage platform. Registration data is associated with schema metadata that the storage platform maintains for all installed storage platform types. This metadata can be stored as a storage platform item and queried.

The registration of value adding classes is a powerful feature, for example, it allows the following scenarios: The right click on the Person object in Shell Explorer and the set of allowed actions could be derived from the value adding class registered for Person.

c) behavior of value addition as a service provider;

In this embodiment, the storage platform API provides a mechanism by which a value addition class can be registered as a "service" for a given type. This allows an application to set up and obtain a service provider of a given type (= value add class). A value-added class that wants to take advantage of this mechanism must implement a well-known interface, for example:

All storage platform API data classes implement the ICachedServiceProvider interface. This interface extends the following System.IServiceProvider interface:

Using this interface, an application can set up a service provider instance as well as request a specific type of service provider.

To support this interface, the storage platform data class maintains a hash table of service providers sorted by type. When a service provider is requested, the implementation first looks at the hash table to see if a service provider of the specified type is set. If no service provider exists, the registered service provider infrastructure is used to identify the service provider of the specified type. An instance of this provider is then created, added to the hash table, and returned. Also note that a shared method on a data class can request a service provider and forward its behavior to that provider. For example, use this to provide a send method for a mail message class that uses an email system specified by the user.

9. Time Framework Design

This section describes how the storage platform schema changes to storage platform API classes on the client and UDT classes on the server in accordance with an embodiment of the present invention. 24 shows related elements.

Referring to FIG. 24, types in a schema are included in an XML file (box 1). This file also contains field level and item level constraints related to the schema. The storage platform class constructor (xfs2cs.exe-box 2) takes this file and creates a partial class (box 5) for the storage UDT and a partial class (box 3) for the client class. For each schema domain, there is an additional method called domain behavior. There are domain behaviors that are meaningful for the repository (box 7), the client (box 6), and both (box 4). The code in boxes 4, 6, and 7 is written directly (not automatically generated). The partial classes in boxes 3, 4, and 6 together form a complete class implementation for the storage platform API domain classes. Boxes 3, 4, and 6 are compiled (box 8) to form a storage platform API class (box 11) (actually, the storage platform API is a box (3, 4, and 6) generated from all initial schema domains. ) Is the result of compiling). In addition to domain classes, there are also additional classes that implement the value addition behavior. These classes use one or more classes in one or more schema domains. This is represented by the box 10. The partial classes in boxes 4, 5, and 7 together form a complete class implementation for the server UDT class. Boxes 4, 5, and 7 are compiled (box 9) to form a server-side UDT assembly (box 12) (actually, the server-side UDT assembly is a box (4, 5, And 7). The DDL instruction generator module (box 13) takes a UDT assembly (box 12) and a schema file (box 1) and installs them on a data store. This process involves the creation of tables and views for types in each schema (among others).

10. Formula of quality

When scaled down on the basis, the application pattern when using the storage platform API opens the ItemContext, uses Find with filter criteria to retrieve the desired object, operates on the object, and sends changes to the store. This section is about the syntax of what becomes a filter string.

The filter string provided when locating a storage platform data object describes the conditions that must be met for the object's attributes to be returned. The syntax used by the storage platform APIs supports type cast and relationship traversal.

a) filter base

The filter string is either empty (indicating that all objects of a particular type should be returned) or a blan representation that each returned object must satisfy. The expression refers to an object's properties. The storage platform API runtime knows how these attribute names map to the storage platform type field names and ultimately the SQL view maintained by the storage platform repository.

Consider the following example:

The properties of nested objects can also be used in filters. Yes:

For sets, you can filter the members using the conditions in square brackets. Yes:

The following example lists all people born after December 31, 1999:

Line 1 creates a new ItemContext object to access "Work Contacts" on the storage platform repository of the local computer. Lines 3 and 4 obtain a set of Person objects whose Birthdate attribute is specified after December 31, 1999, as specified by the expression "Birthdate> '12 / 31/1999 '". Execution of this FindAll operation is illustrated in FIG.

b) type cast

Often the type of the value stored in an attribute is derived from the attribute declared type. For example, the PersonalEAddress attribute in Person contains a set of types derived from EAddress and TelephoneNumber, such as EMailAddress. To filter based on the phone number, you need to cast the Eaddress type to the TelephoneNumber type:

c) filter syntax

The following describes filter syntax supported by the storage platform API according to an embodiment.

11. Remote

a) local / remote transparency within the API

Data access within the storage platform targets the local storage platform instance. If the query (or part of it) references remote data, the local instance acts as a router. Therefore, the API layer provides local / remote transparency; There is no structural difference in the API between local data access and remote data access. It is a function of purely requested scope.

The storage platform data store also implements distributed queries, thus connecting to local storage platform instances and executing queries that include items from different volumes (some on local storage and others on remote storage). It is possible to carry out. The store combines the results and presents it to the application. From the perspective of the storage platform API (and hence the application developer), any remote access is perfectly even and transparent.

The storage platform API allows the application to determine whether a given ItemContext object represents a local or remote connection using the IsRemote attribute, which is an attribute to the ItemContext object. Among other things, an application may want to provide virtual feedback to help set user expectations for performance, trust, and the like.

b) remote storage platform implementation

Storage platform Data stores communicate with each other using special OLEDB providers that operate over HTTP (the default OLEDB providers use TDS). In one embodiment, distributed queries operate through the default OPENROWSET functionality of the relational database engine. Special User Defined Functions (UDFs): DoRemoteQuery (server, queryText) is provided to do the actual remote.

c) access to non-storage platform repositories

In one embodiment of the storage platform of the present invention, there is no generic provider structure that allows any repository to participate in storage platform data access. However, limited provider structures are provided for the special case of Microsoft Exchange and Microsoft Active Directory (AD). This implies that when a provider is on a storage platform they use the storage platform APIs and can access data in AD and Exchange, but the data they can access is limited to the storage platform schematized type. Accordingly, address books (= set of storage platform Person types) are supported in AD, and mail, calendar and contacts are supported for Exchange.

d) relationship with DFS

The storage platform attribute enhancer does not enhance past mount points. Although the namespace is rich enough to access through the mount point, the query does not pass through them. Storage platform volumes can be seen as leaf nodes in the DFS tree.

e) Relationship to GXA / Indigo

Developers can use development platform APIs to expose the "GXA head" on top of the data store. Conceptually, this is no different from creating any other web service. The storage platform API does not use GXA to interact with the storage platform data store. As mentioned above, the API uses TDS to talk to the local repository, and any remote is handled by the local repository using the synchronization service.

12. Pharmaceuticals

The storage platform data model allows value constraints on types. These constraints are automatically evaluated in the repository, and the process is transparent to the user. Note that the constraints are checked on the server. Note that it is sometimes desirable to give developers the flexibility to verify that input data meets constraints without incurring overhead for round trips to the server. This is especially useful for interactive applications where end users enter data used to populate objects. The storage platform API provides these functions.

Recall that the storage platform schema used by the storage platform to create the appropriate database object representing the schema is specified in the XML file. It is used by the design time framework of the storage platform API to automatically generate classes.

This is a partial list of XML files used to generate the contact schema:

The Check tag in the XML specifies a constraint on the Person type. There can be one or more check tags. The constraint is generally checked in the reservoir. To specify that constraints can also be explicitly checked by the application, the XML is modified as follows:

Note the new "InApplication" attribute for the <Check> element set to true. This allows the storage platform API to surface constraints within the API through instance methods on the Person class called Validate (). The application can call this method on the object to ensure that the data is valid, and to avoid potentially unnecessary round trips to the server. This returns a Boolean to indicate the verification result. Note that value constraints still apply to the server, regardless of whether the client calls the <object> .Validate () method. This is an example of how Validate can be used:

There are a number of access paths to storage platform storage (storage platform APIs, ADO.NET, OLEDB, and ADO). This raises the question of reliable constraint checking how to ensure that data written from ODBC meets the same data integrity constraints that can be created from the storage platform API. Since all constraints in the repository are checked, the constraint is now reliable. Regardless of which API path you use to reach the repository, everything written to the repository is filtered through constraint checks in the repository.

13. Share

Shares within the storage platform look like this:

DN <DNS Name> ＼ <Context Service>

Where <DNS Name> is the DNS name of the device, and <Context Service> is an included folder, virtual folder or item in the volume of the device. For example, the device "Johns_Desktop" has a volume called Johns_Information, within which there is a folder called Contacts_Categories, which contains a folder called Work that has a work contact for John:

＼＼Johns_Desktop＼Johns_Information $ ＼Contacts_Categories＼Work

This is shared as "WorkContacts". By definition of this share, "Johns_Desktop" WorkContacts "JaneSmith is a valid storage platform name, identifying the Person item JaneSmith.

a) indicate sharing

The shared item type has attributes such as a shared name, and a shared target, which can be a non-holding link. For example, the aforementioned shared name is WorkContacts, and the target is Contacts_Categories_Work on volume Johns_Information. Here is the schema fragment for the Share type:

b) share management

Because shares are items, shares can be managed like other items. Shares can be created, deleted, and modified. Shares are also secured in the same way as other storage platform items.

c) shared access

An application accesses a remote storage platform share by passing a shared name (eg, "Johns_Desktop" WorkContacts) to the storage platform API when calling the ItemContext.Open () method. ItemContext.Open returns an ItemContext object instance. The storage platform API then talks to the local storage platform service (recalling that access to the remote storage platform repository is done through the local storage platform). The local storage platform service now talks to the remote storage platform service (eg, on the device Johns_Desktop) using the given shared name (eg, WorkContacts). The remote storage platform service then translates WorkContacts into Contacts_Categories＼Work and opens it. Then, queries and other actions are performed like other ranges.

d) discoverability

In one embodiment, the application program may find available shares on a given <DNS Name> in the following manner. According to the first approach, the storage platform API accepts a DNS name (eg Johns_Desktop) as a scope parameter in the ItemContext.Open () method. The storage platform API then uses this DNS name as part of the connection string to connect to the storage platform repository. With this connection, all the application can do is call ItemContext.FindAll (typeof (Share)). The storage platform service then combines all shares on all attached volumes and returns a share set. According to a second scheme, on a local device, an administrator can share on a particular volume by FindAll (typeof (Share)) or on a specific folder by FindAll (typeof (Share), "Target (ShareDestination) .Id = folderId"). Can be found easily.

14. Semantics of Find

Find * methods (regardless of whether they are called on an ItemContext object or on an individual item) generally apply to items (including inserted items) in a given context. Nested elements do not have Find (they can't be searched independently of the Items they contain). Nested elements cannot have Find (they are not searched regardless of their inclusion). This is consistent with the desired semantics by the storage platform data model, where nested elements derive their "identifiers" from inclusion items. To clarify this concept, examples of valid and invalid find operations are as follows:

a) Do you show all the telephone numbers in the system with the local code 206?

Invalid, because the search is done on the phone number (element) without referring to the item.

b) Do you show all phone numbers for all Persons with 206?

Invalid, Person (= item) is referenced, but search criteria are not related to that item.

c) Do you display all the telephone numbers for Murali (= only one person) with a local code of 206?

Because there is a search criterion for valid, Item (Person named "Murali").

This rule is an exception for nested element types derived directly or indirectly from the Base.Relationship type. These types can be queried individually through relation classes. These queries may be supported because the storage platform implementation employs a "master link table" instead of inserting it into the item UDT to store the Relationship element.

15. Storage Platform Contact API

This section provides an overview of the storage platform contact API. The schema behind the contact API is shown in Figures 21A and 21B.

a) Overview of System.Storage.Contact

The storage platform API includes a namespace for handling items and elements in a contact schema. This namespace is called System.Storage.Contact.

For example, this schema has the following classes:

Item: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location

Elements: Profile, PostalAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupancy

b) domain behavior

The following is a list of domain behaviors for a contact schema. When observed from sufficiently high levels, domain behaviors fall into well-organized categories:

Static helpers. For example, Person.CreatePersonalContact (); to create a new human contact.

Instance helpers. For example, user.AutoLoginToAllProfiles (); logs a user (an instance of the User class) into all profiles marked for automatic login.

CategoryGUID. For example, Category.Home, Category.Work, etc .;

· Derived attributes. For example, emailAddress.Address ()-returns a string combining the username and domain fields of a given emailAddress (= instance of the EmailAddress class); And

· Derived set. For example, person.PersonalEamilAddresses-Given an instance of the Person class, get the person's personal email address.

The following table shows a list of these methods and the category to which they belong for each class in a contact with domain behavior.

BasicPresence Category URI UnknownCategoryURI, OfflineCategoryURI, BusyCategoryURI, AwayCategoryURI,
OnlineCategoryURI Static helper ConvertPresenceStateToString-Formats the current state into a positioned string (actually localization needs to be added; it is now done only with familiar English strings) Category Category GUID Home, Work, Primary, Secondary, Cell, Fax, Pager EmailAddress Derived attributes Address-A combination of commercial name and domain Static helper IsValidEmailAddress Folder Derived attributes GetChildItemCollection-creates a set of items based on the target of the FolderMembership Static helper
GetKnownFolder-Specialized query to get a well known folder AddToPersonalContacts-Add items to well-known personal contacts folders Item Static assembly GetItemFromID-performs an ID based query Relationship Instance helper BindToTarget-return item for target Person Derived set PersonalRealtimeAddresses,
PersonalEamilAddresses, PersonalTelephoneNumbers Derived attributes OnlineStatus, OnlineStatusIconSource, PrimaryEmailAddress, PrimarySecurityID Static helper CreatePersonalContact, CreateTemporaryContact-Create a new person in a well known folder GetCurrentUser-get Person for the currently logged in user SecurityID Derived attributes UserName, DomainName, DomainUserName Telephonenumber Instance helper SetFromUserInputString-Parse a phone number string into parts Static helper ParseNumber-Parse a phone number string into parts User Instance helper AutoLoginToAllProfiles-Log to all profiles marked as autologin

16. Storage Platform File API

This section describes an overview of the storage platform file API according to one embodiment of the invention.

a) Introduction

(1) reflect NTFS volumes within the storage platform

The storage platform provides a way to index content within existing NTFS volumes. This is done by extracting ("promoting") an attribute from each file stream or directory in NTFS and storing these attributes as items in the storage platform.

The storage platform file schema defines two entry types, File and Directory, for storing enhanced file system entities. The Directory type is a subtype of the Folder type, which is an include folder containing other Directory items or File items.

Directory entries may include Directory and File entries, which may not include any other type of entry. As far as storage platforms are concerned, Directory and File entries are only read from any of the data access APIs. The File System Enhancement Manager (FSPM) service asynchronously promotes changed attributes to the storage platform. The attributes of File and Directory entries can be changed by the Win32 API. The storage platform API can be used to read any of the attributes of these items, including the stream associated with the File item.

(2) Create files and directories in the storage platform namespace

When an NTFS volume is promoted to a storage platform volume, all files and directories within it reside in a particular part of that volume. This area is only read from the storage platform perspective, and FSPM can create new directories and files and / or change the attributes of existing entries.

The remainder of this volume's namespace contains common overall storage platform item types, such as Principal, Organization, Document, and Folder. The storage platform also allows creating files and directories within any portion of the storage platform namespace. These "raw" files and directories do not have a copy in the NTFS file system, but are stored entirely within the storage platform. In addition, changes to attributes become immediately visible.

However, the programming model remains the same and they are still only read as far as the storage platform data access API is concerned. "Raw" files and directories must be updated using Win32. This simplifies the developer's mental model, namely:

1. Any storage platform item type can be created anywhere in the name space (unless, of course, prevented by permission);

2. Any storage platform item type can be read using the storage platform API;

3. All storage platform item types except files and directories are created using the storage platform API.

4. Use the Win32 API to write file and directory entries to them no matter where they are in the namespace.

5. Changes to file / directory items in the “promoted” namespace may not appear immediately within the storage platform, and within the “voluntary” namespace the changes are immediately reflected within the storage platform.

b) file schema

25 illustrates a schema based on file APIs.

c) Overview of System.Storage.Files

The storage platform API includes a namespace for handling file objects. This namespace is called System.Storage.Files. The data members of the class in System.Storage.Files directly reflect the information stored in the storage platform repository, which can be "promoted" from file system objects, or originally created using the Win32 API. The System.Storage.Files namespace has two classes, FileItem and DirectoryItem. Members of these classes and methods can be easily predicted by looking at the schema diagram in FIG. 25. FileItem and DirectoryItem are only read from the storage platform API. To fix them, you must use the classes in the Win32 API or Systme.IO.

d) code example

In this section, three code examples are provided to illustrate the use of classes in System.Storage.Files.

(1) open and write files

This example shows how to do "normal" file manipulation.

Line 3 uses FindByPath to open the file. Line 7 shows the use of the enhanced property IsReadOnly to check if a file is writable. If so, use the OpenWrite () method on the FileItem object in line 9 to obtain the file stream.

(2) using queries

Storage Platform Because the repository maintains enhanced attributes from the file system, you can easily query rich files. In this example, all files modified in the last 3 days are listed:

This is another example of using a query, which finds all of the recordable files of a particular type (= extension).

e) domain behavior

In one embodiment, in addition to the standard attributes and methods, the file class also has domain behaviors (directly coded attributes and methods). These behaviors are generally based on methods in the corresponding System.IO class.

J. Conclusion

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

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

Appendix A

Appendix B

Appendix C

Claims (91)

As a method for managing the data store, The data store, Item; Element; A plurality of relationships including containment relationships and reference relationships, wherein the containment relationship controls the lifetime of the item, and the containment relationship is a holding relationship or embedding relationship. Relationship is deleted when the maintenance relationship is deleted, the item is a unit of data that can be stored in a data store, has at least one of a type or a subtype, the element and the A plurality of relationships, said element being an instance of a type comprising one or more fields, said plurality of relationships being a link between at least two items; A base schema that creates a framework for creating and organizing each item and setting a base set of attributes; And Organizing the data store to include a core schema defining a set of core types, each item characterized by at least one core type based on an item type or item subtype. How to. The method of claim 1, And the data store comprises a plurality of items, and wherein the plurality of items comprise an item folder and at least one other item that is a member of the item folder. The method of claim 1, And the data store comprises a plurality of items, and wherein the plurality of items comprise a category and at least one other item that is a member of the category. The method of claim 1, Organizing the data store such that the data store includes a second element, and wherein the relationship includes the second element. The method of claim 1, From a common single base item, each item characterized by at least one core type in the set of core types. The method of claim 5, Wherein said common single base item is a base item within a base schema. A computer readable storage medium having computer executable instructions stored thereon, The computer executable instructions are Data storage, Item; Element; A plurality of relationships including a containment relationship and a reference relationship, wherein the containment relationship controls the lifetime of the item, the include relationship is classified as either a maintenance relationship or an insert relationship, and the item is deleted when the maintenance relationship is deleted Wherein the item is a unit of data that can be stored in a data store, has at least one of a type or subtype, includes the element and the plurality of relationships, and the element is an instance of a type comprising one or more fields Wherein the plurality of relationships are links between at least two items; A base schema that creates a framework for creating and organizing each item and setting a base set of attributes; And Computer-readable instructions that perform a step of organizing the data store to include a core schema that defines a set of core types, each item characterized by at least one core type based on an item type or item subtype. Possible storage medium. The method of claim 7, wherein The data store includes a plurality of items, the plurality of items further comprising computer executable instructions for organizing the data store to include an item folder and at least one other item that is a member of the item folder. Possible storage medium. The method of claim 7, wherein The data store includes a plurality of items, the plurality of items further comprising computer executable instructions for organizing the data store to include a category and at least one other item that is a member of the category. media. The method of claim 7, wherein Further comprising computer executable instructions for organizing the data store such that the data store includes a second element, and wherein the relationship comprises the second element. A processor; And a memory, comprising: a computer system; The memory is Item; Element; A plurality of relationships including a containment relationship and a reference relationship, wherein the containment relationship controls the lifetime of the item, the include relationship is classified as either a maintenance relationship or an insert relationship, and the item is deleted when the maintenance relationship is deleted Wherein the item is a unit of data that can be stored in a data store, has at least one of a type or subtype, includes the element and the plurality of relationships, and the element is an instance of a type comprising one or more fields Wherein the plurality of relationships are links between at least two items; A base schema that creates a framework for creating and organizing each item and setting a base set of attributes; And A core schema defining a set of core types, each item characterized by at least one core type based on an item type or item subtype. The method of claim 11, And the memory includes a plurality of items, the plurality of items including an item folder and at least one other item that is a member of the item folder. The method of claim 11, The memory includes a plurality of items, the plurality of items including a category and at least one other item that is a member of the category. The method of claim 11, The memory includes a second element and the relationship includes the second element. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images