RU2371757C2 - Systems and methods of data modelling in storage platform based on subjects - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: data storage control method consists in arranging data storage containing Subjects, Elements and Connections. Subject is the data unit stored in data storage, and in addition, it contains the above Element and the above Connection. Element is an example of the type containing one or several fields. Connection represents connection between at least two Subjects. In addition, data storage contains Base Scheme which sets the structure for creating and arranging each Subject and sets the fundamental set of properties, and Main Scheme for determining the set of the main types; at that, each type is characterised by at least one main type based on Subject type or Subject sub-type.

EFFECT: invention allows creating a new data storage platform which provides the improved possibility of arranging, searching and combined use of all data types in computer system.

14 cl, 37 dwg

Description

Cross reference

This application relates to the subject matter of the inventions described in the following patent transfer applications: US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1748), the filing date of which is the same as the filing date of this application, entitled “SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION "(Systems and methods for representing information units controlled by a hardware / software interface system, but independent of physical representation); US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1749), the filing date of which is the same as the filing date of this application, entitled "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION ”(Systems and methods for separating information units managed by a hardware / software interface system from their physical organization); US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1750), the filing date of which is the same as the filing date of this application, entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM »(Systems and methods for implementing the basic scheme for organizing information units controlled by a hardware / software interface system); US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1751), the filing date of which is the same as the filing date of this application, entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM »(Systems and methods for implementing the basic scheme to provide a top-level structure for organizing information units controlled by a hardware / software interface system); US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1752), the filing date of which is the same as the filing date of this application, entitled "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" (Systems and methods for representing relations between units of information controlled by a hardware / software interface system); US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-2733), the filing date of which is the same as the filing date of this application, entitled "SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM" (Systems and methods pairing application programs with an object-based storage platform); and US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-2734), the filing date of which is the same as the filing date of this application, entitled "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA" (Storage platform for organizing, searching and data sharing).

FIELD OF THE INVENTION

The present invention relates mainly to the field of storage and retrieval of information and, in particular, to an active storage platform for organizing, searching and sharing various types of data in a computerized system.

State of the art

Individual disk capacity has increased by about seventy percent (70%) per year over the past decade. Moore's law accurately predicted the huge increase in central processor power (CPU) that has occurred over the years. Wired and wireless technologies provide ample connectivity and bandwidth. It is assumed that this trend will continue, for several years the average laptop computer will process about one terabyte (TB) of memory and contain millions of files, and 500 gigabyte (GB) drives will become commonplace.

Consumers use their computers primarily to communicate and organize personal information, whether it is traditional style personal information system (PIM) or multimedia data such as digital music or photographs. Significantly increased the number of digital content and the ability to store raw bytes; however, the methods available to consumers for organizing and unifying this data have lagged behind. Information analysis and processing specialists spend a huge amount of time managing and sharing information, and some studies estimate that information analysis and processing specialists spend 15-25% of their time on non-productive activities related to information. Other studies estimate that a typical specialist in the field of information analysis and processing spends about 2.5 hours a day searching for information.

Developers and information technology (IT) departments invest significant amounts of time and money building their own data warehouses for common storage abstractions to represent things like people, places, times and events. This not only leads to duplication of work, but it also creates areas of shared data without mechanisms for sharing or sharing these data. Just think how many address books can exist today on a computer running the Microsoft Windows operating system. Many applications, such as email clients and personal finance programs, accompany individual address books, and there is little sharing among the applications of these address books that each such program individually accompanies. Therefore, the finance program (like Microsoft Money) does not share addresses for payees with the addresses supported in the email contacts folder (like the folder in Microsoft Outlook). In fact, many users have many devices and logically need to synchronize their personal data with each other and with numerous additional sources, including from cell phones to commercial services such as MSN (Microsoft Support Network) and AOL (America Online); however, coordination of shared documents is largely achieved by attaching documents to e-mail messages, i.e. manually and not efficiently.

One reason for this lack of coordination is that traditional approaches to organizing information in computer systems focus on using systems based on a folder with files and a directory (“file systems”) to organize multiple files into a folder directory hierarchy based on an abstraction of physical organization storage medium used to store files. The Multics operating system, developed in the 1960s, can be credited with being innovative in using files, folders, and directories to manage stored data units at the operating system level. Specifically, the Multics operating system used symbolic addresses in the file hierarchy (thus introducing the idea of a file path), where the physical addresses of the files were not transparent to the user (applications and end users). This file system did not at all concern the file format of any individual file, and the connections between them and between files were considered insignificant at the operating system level (i.e., except for the location of the file in the hierarchy). With the advent of the Multics operating system, stored data was organized into files, folders, and directories at the operating system level. These files mainly include the file hierarchy itself (the “directory”) implemented in a special file supported by the file system. This directory, in turn, accompanies a list of elements corresponding to all other files in the directory, and the nodal location of such files in a hierarchy (referred to as folders in this description). This has been the state of the art for about forty years.

However, while providing an acceptable representation of the information residing in the physical storage system of the computer, the file system is nevertheless an abstraction of this physical storage system, and therefore the use of files requires a certain level of indirectness (interpretation) between what the user manipulates (units, having context, features and relationships with other units), and what the operating system provides (files, folders, and directories). Therefore, the user (applications and / or end users) has no choice how to load units of information into the file system structure, even when this execution is inefficient, incompatible, or otherwise undesirable. In addition, existing file systems have little information about the structure of data stored in individual files, and because of this, most of the information remains locked in files that can only be accessed (and they can be understood) by the applications that recorded them. Therefore, this lack of a schematic description of information and information management mechanisms leads to the creation of data silos with little data sharing between individual silos. For example, many personal computer (PC) users have more than five separate repositories that contain information about the people with whom they interact at some level, for example, Outlook contacts, recipients of online accounts, Windows address book, Quicken payment recipients and instant contact contact lists messaging (MOS; IM), as organizing files is a complex problem for these PC users. Since most existing file systems use the model representation of subfolders to organize files and folders when the number of files increases, the amount of work needed to maintain an organization scheme that is flexible and efficient becomes quite huge. In such situations, it would be very useful to have many classifications of a single file; however, the use of hard and flexible binding in existing file systems is difficult and difficult to maintain.

In the past, several unsuccessful attempts have been made to address file system flaws. Some of these previous attempts included the use of associative memory to provide a mechanism by which data could be accessed by content rather than by physical address. However, these efforts were unsuccessful because, although associative memory was useful for small-scale use by devices, such as caches and memory control units, large-scale use for devices, such as physical storage media, was still not possible for many reasons, and, such therefore, such a solution simply does not exist. Other attempts were made using object-oriented database systems (OOBB; OODB), but these attempts, although characterized by certain database characteristics and good non-file representations, were not effective in processing file representations and could not repeat the speed, efficiency, and simplicity of the hierarchical structure based on files and folders at the hardware / software interface system level. Other efforts, such as those that tried to use SmallTalk (and other modifications), turned out to be quite effective in handling file and non-file representations, but they lacked the database features necessary for the efficient organization and use of the relationships that exist between different data files, and thus the overall effectiveness of such systems was unacceptable. Still other attempts to use BeOS (and other studies of such operating systems) turned out to be inappropriate when operating with non-file representations - the main omission is the same for traditional file systems, despite the ability to adequately represent files, at the same time provide some necessary database features.

Database technology is another area of technology in which there are similar complex problems. For example, although the relational database model has been a great commercial success, in reality independent software vendors (ISVs) mainly use a small fraction of the functionality available in relational database software products (such as Microsoft SQL Server). Instead, most of the application’s interaction with such a product takes the form of simple “gets” and “puts”. Although there are a number of easily distinguishable reasons for this, such as platform or database agnostic, one key reason that often goes unnoticed is that the database does not necessarily provide the exact abstraction that the main business application providers really need. For example, although the real world has a concept of “objects”, such as “consumers” or “orders” (together with “subject items” embedded in the order as objects in themselves or on their own), relational databases communicate only in the language tables and rows. Therefore, although an application may need to have aspects of compatibility, locking, security, and / or triggers at the item level (by specifying several), databases mainly provide these features only at the table / row level. Although this may work well if each item is displayed on a single row in some table in the database, in the case of an order with multiple item items there may be reasons why the item is actually displayed in multiple tables, and when so, a simple relational database system completely does not provide the correct abstractions. Therefore, the application must build logic on top of the database to provide these basic abstractions. In other words, the basic relational model does not provide a sufficient platform for storing data on which higher-level applications can be easily developed, since the basic relational model requires a level of indirection between the application and the storage system, where the semantic data structure can be visible only in some applications cases. Although some database vendors embed higher-level functionality in their products, such as providing object-relational capabilities, new organizational models, etc., no one has yet provided the kind of integrated solution needed where a truly integrated solution is a solution , which provides both useful abstractions of the data model (such as “Items”, “Extensions”, “Links”, etc.) for useful domain abstractions (such as “Persons”, “Locations”, “Events” etc.).

Given the aforementioned deficiencies in existing data storage and database technologies, there is a need for a new storage platform that provides improved organization, retrieval and sharing of all types of data in a computer system - a storage platform that extends and extends the data platform beyond existing file systems and database systems and which is intended to be a repository for all types of data. The present invention satisfies this need.

SUMMARY OF THE INVENTION

The following summary provides an overview of various aspects of the invention. It is not intended to provide an exhaustive description of all important aspects of the invention, nor to determine the scope of the invention. Rather, this summary is intended to serve as a preface to the detailed description and the drawings that follow.

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

According to one aspect of the present invention, the storage platform of the present invention comprises a data warehouse implemented on a database processor (s). In various embodiments of the present invention, the database processor comprises object-relational extensions. The data warehouse implements a data model that supports the organization, search, sharing, synchronization and data protection. Specific data types are described in the schemas, and the platform provides a mechanism for expanding the set of schemas for defining new data types (essentially, subtypes of the base types are provided by the schemas). The ability to synchronize facilitates data sharing among users or systems. Features similar to those of the file system are provided that provide the ability for the data store to interact with existing file systems, but without limiting such traditional file systems. The change tracking mechanism provides the ability to track changes in the data warehouse. The storage platform additionally contains a set of application program interfaces that provide applications with the ability to access all of the above capabilities of the storage platform and access the data described in the diagrams.

According to another aspect of the invention, a data model implemented by a data warehouse defines data storage units based on objects, elements, and relationships. An item is a unit of data stored in a data warehouse and may contain one or more elements and relationships. An element is an instance of a type containing one or more fields (also referred to as a property in this description). A bond is a bond between two objects. (As used herein, these and other specific terms may be capitalized to get their parallel meaning relative to other terms used with a similar meaning; however, there is no intention to distinguish between a capitalized term such as “Subject” and this the same term when it is not written in capital letters, for example “subject”, and such a difference should not be assumed or implied.)

According to another aspect of the invention, a computer system comprises a plurality of Items, where each Item constitutes a discrete stored unit of information that can be manipulated by a hardware / software interface system; a plurality of Item Folders that make up the organizational structure for said Items; and a hardware / software interface system for manipulating a plurality of Items, and in which each Item belongs to at least one Item Folder and may belong to more than one Item Folder.

According to another aspect of the invention, a computer system comprises a plurality of Items, where each Item constitutes a discrete unit of information that can be manipulated by a hardware / software interface system, and the Item or some of the property values of the Item are dynamically calculated as opposed to being removed from a long-term storage. In other words, the hardware / software interface system does not require the Item to be stored, and some operations are supported, such as the ability to list the current set of Items or the ability to retrieve the Item by its identifier (which is described in more detail in the sections that describe the application programming interface, or API (API)), storage platforms, for example. The subject may be the current location of the cell phone or the temperature sensor temperature reading.

According to another aspect of the invention, a hardware / software interface system for a computer system in which said hardware / software interface system manipulates a plurality of Items, further comprises Items interconnected by a plurality of Links controlled by the hardware / software interface system. According to another aspect of the invention, a hardware / software interface system for a computer system in which said hardware / software interface system manipulates a plurality of discrete pieces of information having properties understood by said hardware / software interface system. According to another aspect of the invention, a hardware / software interface system for a computer system comprises a basic circuit for determining a set of core Items that the hardware / software interface system understands and can directly process in a predetermined and predictable manner. According to another aspect of the invention, a method is described for manipulating a plurality of discrete information units (“Items”) in a hardware / software interface system for a computer system, said method comprising interconnecting said Items with a plurality of Links and managing said Links at the hardware / software interface system level.

According to another feature of the invention, the storage platform API (API) provides data classes for each item, item extensions, and communications defined in the set of storage platform schemas. In addition, the application programming interface provides a set of integrated environment classes that define a common set of behavior methods for data classes and which, together with data classes, provide a basic programming model for the storage platform API. According to another distinguishing feature of the invention, the storage platform API (API) provides a simplified query model that allows application programmers to generate queries based on various properties of items in the data warehouse, thus allowing the application programmer to be separated from the details of the query language of the underlying processor (tools processing) database. According to another aspect of the storage platform API (API) of the present invention, the API (API) collects changes in the subject that are executed by the application program and then organizes them into the correct updates necessary for the database processor (or any kind of storage processor) on which the storage is implemented data. This allows application programmers to make changes to the subject in memory, while at the same time leaving the complexity of updating the data warehouse for the API (API).

Through its common storage framework and schematized data, the storage platform of the present invention enables more efficient application development for consumers, information analysis and processing professionals, and enterprises. It offers a powerful and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also extends and extends the existing file system and ways to access databases.

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

Brief Description of the Drawings

The foregoing summary, as well as the following detailed description of the invention, is easier to read when read in conjunction with the accompanying drawings. For purposes of illustrating the invention, the drawings show exemplary embodiments of various aspects of the invention; however, the invention is not limited to the described specific methods and means. In the drawings:

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

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

2A illustrates a traditional tree-based hierarchical structure for files grouped into 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 illustrates the structural relationship between Items, Item Folders, and Categories in various embodiments of the present invention;

5A is a block diagram illustrating the structure of an Item;

5B is a block diagram illustrating composite types of properties of the Item of FIG. 5A;

5C is a block diagram illustrating an “Location” Item, which further describes (explicitly lists) its composite types;

figa illustrates an Item as a subtype of an Item defined in the Base Scheme;

figv is a block diagram illustrating the subtype Item of figa, in which its inherited types are explicitly listed (in addition to its immediate properties);

7 is a block diagram illustrating a Base Scheme, including its two types of top-level class, Item and PropertyBase, and additional types of the Base Schema derived from them;

FIG. 8A is a block diagram illustrating Items in a Main Scheme; FIG.

FIG. 8B is a block diagram illustrating property types in the Main Scheme; FIG.

9 is a block diagram illustrating an Item Folder, Items of its members and interconnecting Connections between the Item Folder and Items of its members;

10 is a block diagram illustrating a Category (which, again, represents the Item itself), Items of its members and interconnecting Links between the Category and Items of its members;

11 is a diagram illustrating a hierarchy of a reference type of a data model of a storage platform according to the present invention;

12 is a diagram illustrating how communications are classified according to an embodiment of the present 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 both insert a new record in the same B tree;

15 illustrates a data change detection process according to an embodiment of the present invention;

Fig illustrates an exemplary directory tree;

FIG. 17 illustrates an example in which an existing directory-based file system folder is moved to a storage platform data store in accordance with an aspect of the present invention; FIG.

Fig. 18 illustrates the principle of Inclusion Folders in accordance with an aspect of the present invention;

FIG. 19 illustrates a basic architecture of a storage platform API (API); FIG.

20 schematically represents various components of an IPP stack (API) of a storage platform;

21A and 21B are graphical representations of an exemplary Contact scheme (Items and Elements);

FIG. 22 illustrates an integrated runtime framework of a storage platform API in accordance with an aspect of the present invention; FIG.

23 illustrates a design of a FindAll operation according to an embodiment of the present invention;

24 illustrates a process by which storage platform APIs are generated from a storage platform diagram in accordance with an aspect of the present invention;

25 illustrates a diagram on which a File API is based according to another aspect of the present invention;

26 is a diagram illustrating an access mask format used for data protection purposes according to an embodiment of the present invention;

27 (a), (b) and (c) depict a new identically protected security zone cut out from an existing security zone according to an embodiment of one aspect of the present invention;

FIG. 28 is a diagram illustrating a principle of submitting an item search, according to an embodiment of one aspect of the present invention; FIG. and

29 is a diagram illustrating an example hierarchy of Items, according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

CONTENT

I. INTRODUCTION

A. EXAMPLE COMPUTER ENVIRONMENT

B. TRADITIONAL FILE-BASED STORAGE

II. NEW STORAGE PLATFORM FOR ORGANIZING, SEARCHING AND JOINT USE OF DATA

A. DICTIONARY

B. OVERVIEW OF STORAGE PLATFORM

C. DATA MODEL

1. Items

2. Identification of items

a) References to the subject

(1) ItemIDReference

(2) ItemPathReference

b) Reference type hierarchy

3. Folders and item categories

4. Schemes

a) Basic scheme

b) The basic scheme

5. Communication

a) Communication announcement

b) Attachment connection

c) Implementation Relations

d) Link links

e) Rules and restrictions

f) Ordering links

6. Extensibility

a) Extensions of the subject

b) Type extensions NestedElement

D. DATABASE PROCESSOR

1. Implementation of the data warehouse using user-defined types (OPT; UDT)

2. Display items

3. Display extensions

4. Display of nested elements

5. Identification of objects

6. Naming of objects of the structured query language (JSS; SQL)

7. Naming columns

8. Search submissions

a) subject

(1) The main item search view

(2) Typed item search representations

b) Item extensions

(1) Main view of extension search

(2) Typed Extension Search Views

c) Nested elements

d) Communication

(1) Top link search view

(2) Communication instance search submissions

9. Updates

10. Change tracking and monuments

a) Change tracking

(1) Tracking changes to the “main” search views

(2) Tracking changes in typed search views

b) Monument objects

(1) Objects-monuments of objects

(2) Extension Monuments

(3) Object-monument of communications

(4) Cleaning of monuments

11. Auxiliary API (API) and functions

a) Function [System.Storage] .GetItem

b) Function [System.Storage] .GetExtension

c) Function [System.Storage] .GetRelationship

12. Metadata

a) Schema metadata 75

b) Instance metadata 75

E. PROTECTION

1. Overview

2. Detailed description of the protection model

a) Security descriptor structure

(1) Access mask format

(2) Generalized access rights

(3) Standard access rights

b) Subject-specific rights

(1) Object-specific file and directory rights

(2) WinFSItemRead

(3) WinFSItemReadAttributes 86

(4) WinFSItemWriteAttribute

(5) WinFSItemWrite

(6) WinFSItemAddLink

(7) WinFSItemDeleteLink

(8) Rights to delete an item

(9) Copying Rights

(10) Rights to move an item

(11) Rights to view security policy for

(12) Subject to change of security policy

(13) Rights that do not have a direct equivalent

3. Implementation

a) Creating a new item in the container

b) Adding an explicit access control list (ACL) to the subject

c) Adding an attachment link to an item

d) Removing an attachment link from an item

f) Removing an explicit ACL from an item

f) Modification of the ACL associated with the subject

F. NOTIFICATIONS AND TRACKING OF CHANGES

1. Storage change events

a) Events

b) Observers

2. Change tracking and notification mechanism

a) Change tracking

b) Time stamp management

c) Date change detection - event detection

G. SYNCHRONIZATION

1. Synchronize the storage platform with the storage platform

a) Synchronization management applications

b) Annotating circuits

c) Sync configuration

(1) Community Folder - Mappings

(2) Profiles

(3) Schedules

d) Conflict handling

(1) Conflict Detection

(a) Information-based conflicts

(b) Restriction-based conflicts

(2) Conflict Handling

(a) Automatic conflict resolution

(b) Conflict Records

(c) Inspection and resolution of conflicts

(d) Merging replicas and distributing conflict resolution

2. Synchronization with non-storage platform data warehouses

a) Sync services

(1) Listing Changes

(2) Application of changes

(3) Conflict Resolution

b) adapter implementation

3. Protection

4. Manageability

H. POSSIBILITY OF INTERACTION WITH TRADITIONAL FILE SYSTEMS

1. A model for interoperability

2. Data Warehouse Features

a) Not that

b) Storage structure

c) Not all files migrate

d) New technology file system namespace (FSNT; NTFS) access to storage platform files

e) The expected namespace / drive letters

I. STI PLATFORMS (API)

1. Overview

2. Naming and scopes

3. Components of the Storage Platform API

4. Data classes

5. Integrated runtime

a) Integrated Runtime Classes

(1) ItemContext

(2) ItemSearcher

(a) Type of target

(b) Filters

(c) Preparing searches

(d) Search options

(3) Stream of item results (“FindResult”)

b) Integrated runtime at work

c) General programming patterns

(1) Opening and closing ItemContext objects

(2) Object Search

(a) Search options

(b) FindOne and FindOnly

(c) Short search forms for ItemContext

(d) Search by identifier (ID; ID)) or path

(f) GetSearcher Template

(3) Storage update

6. Protection

7. Communication support

a) Basic types of relationships

(1) Relationship class

(2) ItemReference Class

(3) Class ItemIdReference

(4) Class ItemPathReference

(5) RelationshipId Structure

(6) VirtualRelationshipCollection class

b) Generated link types

(1) Generated link types

(2) RelationshipPrototype class

(3) RelationshipPrototypeCollection Class

c) Support for relations in the class Item

(1) Item class

(2) RelationshipCollection class

d) Support for relationships in search expressions

(1) Passage from items to links

(2) Passage from links to objects

(3) Combining communications

e) Examples of using linking support

(1) Search for links

(2) Navigation from communication to source and target objects

(3) Navigation from source items to links

(4) Creating links (and items)

(5) Removing links (and items)

8. “Extension” of the storage platform API (API)

a) Domain behavior methods

b) Additional behaviors

c) Additional behaviors as service providers

9. Integrated design period environment

10. Request formalism

a) Filter Basics

b) Type casting

c) Filter syntax

11. Remote interaction

a) Local / remote transparency in the API (API)

b) Implementation of the remoting storage platform

c) Access to non-storage platform storage

d) Communication with a distributed file system (RFU; DFS)

e) Link to the global architecture of Extensible Markup Language (GAR; GXA) / Indigo

12. Limitations

13. Sharing

a) Presentation of a shared resource

b) Shared Resource Management

c) Access to shared resources

d) Detectability

14. Semantics of Find

15. IPP (API) contacts storage platform

a) System.Storage.Contact Overview

b) Domain Behaviors

16. IPP (API) of the storage platform file

a) Introduction

(1) Reflection of the FSST volume (NTFS) in the storage platform

(2) Creating a File and Directory in the storage platform namespace

b) File schema

c) System.Storage.Files Overview

d) Code examples

(1) Opening a file and writing to it

(2) Using queries

e) Domain Behaviors

J. CONCLUSION

I. INTRODUCTION

The subject of the present invention is described with the specifics of meeting the requirements of the law. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have suggested that the claimed subject matter can also be carried out in other ways, including various steps or combinations of steps, similar to the steps described herein, together with other present or future technologies. Furthermore, although the term “step” may be used herein to associate with various elements of the methods used, the term should not be interpreted as meaning any particular order among or between the various steps described herein, except and moreover, when explicitly described order of individual steps.

A. EXAMPLE COMPUTER ENVIRONMENT

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

As shown in FIG. 1, an exemplary general-purpose computing system includes a conventional personal computer 20 or the like, including a processor 21, a system memory 22, and a system bus 23 that connects various components of the system, including the system memory to the processor 21. System bus 23 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. Basic input / output system 26 (BSVV (BIOS); BIOS) containing basic routines that facilitate the transfer of information between elements in a personal computer 20 for example, during startup, it is stored in ROM 24. The personal computer 20 may further include a hard disk drive 27 for reading and writing to a hard disk (not shown), magnetic disk drive 28 for reading or writing to a magnetic disk 29 and an optical disk drive 30 for reading or writing to a removable optical disk 31, such as a compact disk or other optical medium. The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are connected to the system bus 23 via the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical disk drive interface 34, respectively. Drives and related computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for personal computer 20. Although the sample environment described herein uses a hard disk, removable magnetic disk 29, and removable optical disk 31 , it will be understood by one skilled in the art that other types of computer-readable media that can also be used in an exemplary operating environment They can store data that can be accessed by a computer, such as magnetic tapes, flash memory cards, digital video disks, Bernoulli cartridges, random access memory (RAM), read-only memory (ROM), etc. Similarly, an example environment may also include many types of monitoring devices, such as temperature sensors and security systems or fire alarms, and other information sources.

A number of program modules may be stored on a hard disk, magnetic disk 29, optical disk 31, in ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. A user may enter commands and information to the personal computer 20 using input devices such as a 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 processor 21 via the serial port interface 46, which is connected to the system bus, but can be connected using other interfaces, such as a parallel port, a game port, or a universal serial bus (USB; 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 typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 also includes a host adapter 55, a small computing system interface (IMSI) bus 56, and an external storage device 62 connected to the IMSI bus 56 (SCSI).

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

When used in a LAN environment, the personal computer 20 is connected to the LAN 51 using a network interface or adapter 53. When used in a WAN environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over a global network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 using the serial port interface 46. In a networked environment, program modules described above with respect to personal computer 20, or portions thereof, may be stored in a remote storage device. It is understood that the network connections shown are exemplary, and other means may be used to establish a communication link between computers.

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

In numerous embodiments of the computer system 200, and again referring to FIG. 1, the hardware component 202 may comprise a central processing unit (CPU; CPU) 21, memory (both ROM 24 and RAM 25), and an I / O base system 26 (BSVV; BIOS) and various input / output devices (BB; I / O), such as keyboard 40, mouse 42, monitor 47 and / or printer (not shown), among other things. Hardware component 202 comprises the underlying physical infrastructure for computer system 200.

The application program component 206 contains various software programs, but is not limited to compilers, database systems, text editors, business programs, video games, and the like. Application programs provide a means by which computer resources are used to solve problems, provide solutions, and process data for various users (machines, other computer systems, and / or end users).

The hardware / software interface system component 204 comprises (and in some embodiments may consist solely of) an operating system that itself contains, in most cases, a shell and a kernel. An “operating system” (OS; OS) is a special program that serves as an intermediary between application programs and computer hardware. Component 204 of the hardware / software interface system may also include a virtual machine manager (DVM; VMM), a common language runtime environment (NLSA; CLR)) or its functional equivalent, a virtual Java machine (BJM; JVM) or its functional equivalent, or other such software components instead of or in addition to the operating system in a computer system. The purpose of a hardware / software interface system is to provide an environment in which a user can execute application programs. The goal of any hardware / software interface system is to make the computer system user-friendly and to use the hardware of the computer in an efficient manner.

A hardware / software interface system typically loads into a computer system at startup and then manages all application programs in the computer system. Application programs interact with a hardware / software interface system by requesting services using an application programming interface (API; API). Some application programs provide the ability for end users to interact with a hardware / software interface system using a user interface such as a command language or graphical user interface (GUI).

A hardware / software interface system traditionally provides many services for applications. In a multi-tasking hardware / software interface system, where many programs can be executed simultaneously, the hardware / software interface system determines which applications should be executed in what order and how much time should be allocated to each application before switching in turn to another application. The hardware / software interface system also manages the sharing of internal memory across multiple applications and operates input and output to and from attached hardware devices, such as hard drives, printers, and remote access ports, over dial-up lines. The hardware / software interface system also sends messages to each application (and in some cases to the end user) regarding the status of operations and any errors that may have occurred. A hardware / software interface system can also offload batch job management (such as printing), so that the starting application is freed from this work and can resume other processing and / or operations. On computers that can provide parallel processing, the hardware / software interface system also controls the separation of the program, so that it runs simultaneously on more than one processor.

A shell of a hardware / software interface system (referred to simply as a “shell” in this description) is an interactive end-user interface to a hardware / software interface system. (A shell can also be referred to as a “command interpreter” or in the operating system as a “shell of an operating system.”) A shell is an external layer of a hardware / software interface system that is directly accessed by application programs and / or end users. In contrast to the shell, the kernel represents the innermost level of a hardware / software interface system that interacts directly with hardware components.

Although it appears that numerous embodiments of the present invention are particularly well suited to computerized systems, nothing in this document is intended to limit the invention to such embodiments. In contrast, as used herein, the term “computer system” is intended to encompass any and all devices configured to store and process information and / or configured to use stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical or virtual in nature.

B. TRADITIONAL FILE-BASED STORAGE

In most computer systems, “files” are currently units of stored information, which may include a hardware / software interface system, as well as application programs, data sets, etc. In all modern hardware / software interface systems (Windows, Unix, Linux, Mac OS, virtual machine systems, etc.) files are basic discrete (stored and retrieved) units of information (for example, data, programs, etc.). ) that can be manipulated by the hardware / software interface system. File groups are usually organized in “folders”. On Microsoft Windows, Macintosh OS, and other hardware / software interface systems, a folder is a collection of files that can be retrieved, moved, and otherwise manipulated as single pieces of information. These folders, in turn, are organized into a tree-based hierarchical structure called the “directory” (described in more detail later in this document). On some other hardware / software interface systems, such as DOS (disk operating system), z / OS, and most Unix-based operating systems, the terms “directory” and / or “folder” are used interchangeably, and Apple's early computer systems (for example, Apple IIe) used the term catalog instead of a directory; however, as used herein, all of these terms are considered to be synonymous and interchangeable and are intended to further include all other equivalent terms and to refer to hierarchical structures of information storage and their components folders and files.

Traditionally, a directory (also known as a folder directory) is a tree-based hierarchical structure in which files are grouped into folders, and folders, in turn, are organized according to relative nodal points that contain the directory tree. For example, as shown in FIG. 2A, the base folder (or “root directory”) 212 of the DOS-based file system may contain many folders 214, each of which may additionally contain additional folders (as “subfolders” of this particular folder) 216, and each of them may also contain additional folders 218 to infinity. Each of these folders can have one or several files 220, although at the level of the hardware / software interface system, the individual files in the folder have nothing in common, except for their location in the tree hierarchy. Not surprisingly, this approach to organizing files in a folder hierarchy indirectly reflects the physical organization of the usual storage medium used to store these files (for example, hard drives, floppy disks, CDs, etc.).

In addition to the above, each folder is a container for its subfolders and its files, i.e. each folder owns its subfolders and files. For example, when a folder is deleted by the hardware / software interface system, the subfolders and files of that folder are also deleted (which, in the case of each subfolder, additionally include their own subfolders and files recursively). Similarly, only one folder usually owns each file, and although the file can be copied and the copy can be located in another folder, the copy of the file itself is a special and separate unit that does not directly relate to the original (for example, changes to the original file are not reflected in the copy file at the hardware / software interface system level). In this regard, files and folders are therefore characteristically “physical” in nature, since folders are treated like physical containers, and files are treated as discrete and separate physical elements within these containers.

II. NEW STORAGE PLATFORM FOR ORGANIZING, SEARCHING AND JOINT USE OF DATA

The present invention relates to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and extends the data platform beyond the types of existing file systems and database systems described above, and is intended to be a repository for all types of data, including a new kind of data called Items.

A. DICTIONARY

For the purposes of this specification and claims, the following terms have the following meanings:

An “item” is a unit of stored information that can be accessed by a hardware / software interface system, which, unlike a simple file, is an object that has a basic set of properties that are usually supported for all objects disclosed to the end user through the shell of a hardware / software interface system . Items also have properties and relationships that are typically supported across all types of Items, including features that enable the introduction of new properties and relationships (and more fully described later in this description).

An “operating system” (OS; OS) is a special program that serves as an intermediary between application programs and computer hardware. The operating system contains, in most cases, a shell and a kernel.

A “hardware / software interface system” is software or a combination of hardware and software that serves as an interface between underlying hardware components of a computer system and applications that run on a computer system. A hardware / software interface system typically comprises (and in some embodiments may consist solely of) an operating system. A hardware / software interface system may also include a virtual machine manager (DVM; VMM), a common language runtime environment (TLLW; CLR) or its functional equivalent, a virtual Java machine (BJM; JVM) or its functional equivalent, or another such software component instead or in addition to the operating system in a computer system. The purpose of a hardware / software interface system is to provide an environment in which a user can execute application programs. The goal of any hardware / software interface system is to make the computer system user-friendly and to use the hardware of the computer in an efficient manner.

B. OVERVIEW OF STORAGE PLATFORM

Referring to FIG. 3, a storage platform 300 according to the present invention comprises a data store 302 implemented on a database processor (means) 314. In one embodiment, the database processor comprises a relational database processor with object-relational extensions. In one embodiment, the relational database processor 314 comprises a Microsoft SQL Server relational database processor.

Data warehouse 302 implements a data model 304 that supports the organization, search, sharing, synchronization, and data protection. Specific data types are described in schemes, such as schemes 340, and the storage platform 300 provides tools 346 for deploying these schemes, as well as for expanding these schemes, as described in more detail below.

The change tracking engine 306 implemented in the data warehouse 302 provides for the ability to track changes in the data warehouse. Data storage 302 also provides security capabilities 308 and distribution capabilities / distribution capabilities 310, both of which are described in more detail below. Data storage 302 also enables the application storage interface 302 to expose the capabilities of data storage 302 to other storage platform components and application programs (e.g., application programs 350a, 350b, and 350c) that use the storage platform.

The storage platform of the present invention further comprises application programming interfaces (APIs) 322 that enable application programs, such as application programs 350a, 350b, and 350c, to access all of the aforementioned storage platform capabilities and access the data described in the diagrams. The storage platform API 322 can be used by application programs in combination with other APIs, such as Object Linking and Embedding APIs (APIs) 324 for databases (OLEDBs) and Microsoft Windows APIs 326 (API) 326 Win32

The storage platform 300 of the present invention can provide a variety of services 328 for application programs, including a synchronization service 330, which facilitates data sharing between users or systems. For example, synchronization service 330 may provide the ability to interact 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. Storage platform 300 also provides file system capabilities that interoperate data storage 302 with existing file systems such as Windows NTFS file system 318.

In at least some embodiments, the storage platform 320 can also provide application programs with additional capabilities that can act on data and interact with other systems. These capabilities can be implemented in the form of additional services 328, such as the Information Agent service 334 and the notification service 332, as well as other utilities 336.

In at least some embodiments, the storage platform is implemented in, or forms an integral part of, the hardware / software interface system of a computer system. For example, and without limitation, the storage platform of the present invention can be implemented in, or forms an integral part of, the operating system, the virtual machine manager (VDM; VMM), the common language runtime environment (NLSA; CLR) or its functional equivalent or the virtual Java machine (BJM ) or its functional equivalent.

Through its common storage framework and schematized data, the storage platform of the present invention allows for more efficient application development for consumers, information analysis and processing specialists, and enterprises. It offers an expandable and highly programmable programming area that not only makes available the capabilities inherent in its data model, but also extends and extends existing ways of accessing file systems and databases.

In the following description and various description of the figures, the storage platform 300 of the present invention may be referred to as “WinFS”. However, the use of this name to refer to a storage platform is for convenience 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 protection of data that resides in the store. In the data model of the present invention, “Subject” is a fundamental unit of storage information. The data model provides a mechanism for declaring Items and extensions of Items and for establishing links between Items and for organizing Items in Item Folders and Categories, which is described in more detail below.

The data model is based on two primitive mechanisms, Types and Relations. Types are structures that provide a format that governs the form of an instance of a Type. The format is expressed as an ordered set of Properties. A property is the name of a value or set of values for this Type. For example, a USPostalAddress type may have properties Street, City, Zip, State, in which Street, City, and State are of type String, and Zip is of type Int32. Street can have many values (i.e. a set of values) that enable the address to have more than one value for the Street property. The system defines some elementary types that can be used to build other types - they include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUID (globally unique identifier (GUID; GUID) ) Type properties can be defined using any elementary types or (with some restrictions noted below) any complex types. For example, a Location Type could be defined that had Coordinate and Address Properties, where the Address Property is of USPostalAddress Type, as described above. Properties can also be required and optional.

Relationships can be declared and represent a mapping between sets of instances of two types. For example, there may be a Link declared between the Person Type and the Location Type, called LivesAt, which determines which people live in which domicile. The relationship has a name, two endpoints, namely the endpoint of the source and the endpoint of the target. Links can also have an ordered set of properties. The endpoints of both the Source and the Goals have a Name and a Type. For example, the LivesAt Link has a Source named Occupant of Type Person and a Target called Dwelling of Type Location, and additionally has StartDate and EndDate properties that indicate the length of time a resident has lived. It should be noted that Person can reside in many places in time, and the place of residence can have many residents, so the most likely place to post information about StartDate and EndDate is the connection itself.

Relationships define the mapping between instances, which are limited to types given as endpoint types. For example, a LivesAt link cannot be a link in which Automobile is Occupant since Automobile is not Person.

The data model really allows you to define subtype-subtype relationships between types. A subtype-subtype relationship, also known as a BaseType relationship, is defined so that if Type A is a BaseType for Type B, then it should be so that each instance of B is also an instance of A. Another way of expressing this is that each an instance that matches B must also match A. If, for example, A has a Name property of Type String, while B has an Age property of Type Int16, then it follows that any instance of B must have both Name and Age. The type hierarchy can be considered as a tree with a single supertype in the root. Branches from the root provide subtypes of the first level, branches at this level provide subtypes of the second level, etc. to subtypes of the very last leaves, which themselves do not have any subtypes. A tree is not limited to uniform depth, but cannot contain any cycles. This Type may have zero or more subtypes and zero or one supertype. A given instance may correspond to at most one type together with supertypes of that type. In other words, for a given instance at any level in the tree, an instance can correspond to at most one subtype at that level.

The type is considered to be Abstract if the type instances must also be an instance of the type subtype.

1. Items

An item is a unit of stored information, which, unlike a simple file, is an object that has a basic set of properties that are usually maintained for all objects disclosed to the end user or application program through a storage platform. Items also have properties and relationships that are typically supported across all types of Items, including features that enable you to enter new properties and relationships, as described below.

Items are objects for general operations such as copying, deleting, moving, opening, printing, backing up, restoring, replicating, etc. Items are units that can be stored and retrieved, and all types of stored information that the storage platform manipulates exist in the form of Items, the properties of Items or the Relationships between Items, each of which is described in more detail in this description below.

Objects are intended to represent real and easily understood data units, such as Contacts, People, Services, Locations, Documents (all different types), etc. 5A is a block diagram illustrating the structure of an Item. The non-integral name of the Item is “Location”. The compound name of the Item is “Core.Location”, which indicates that this structure of the Item is defined as a specific type of Item in the Main Scheme. (The main circuit is described in more detail in this description below).

Location has many properties, including EAddresses, MetropolitanRegion, Neighborhood, and PostalAddresses. A specific property type for each is indicated immediately after the property name and is separated by a colon (“:”) from the property name. To the right of the type name is a series of values allowed for this type of property, between brackets (“[]”), in which the asterisk (“*”) to the right of the colon (“:”) indicates an undefined and / or unlimited number (“many” ) A “1” to the right of the colon indicates that there may be the largest single value. A zero (“0”) to the left of the colon indicates that the property is optional (it can be without a value at all). A “1” to the left of the colon indicates that there must be at least one value (a property is required). Neighborhood and MetropolitanRegion are both of type “nvarchar” (or equivalent), which is a predefined data type or “simple type” (and is denoted by the absence of capitalization in this description). EAddress and PostalAddresses, however, are properties of certain types or “composite types” (denoted by capitalization in this description) of the types EAddress and PostalAddress, respectively. A composite type is a type that is inferred from one or more simple data types and / or from other composite types. Compound types for Item properties also constitute “nested elements”, since the details of the composite type are embedded in the immediate Item to determine its properties, and information related to these composite types is stored with the Item that has these properties (within the boundaries of the Item, as described in this description below). These typesetting principles are well known and readily understood by those skilled in the art.

5B is a block diagram illustrating the composite property types of PostalAddress and EAddress. The PostalAddress property type determines that an Object of the PostalAddress property type can be expected to have zero or one City value, zero or one CountryCode value, zero or one MailStop value, and any number (zero - many) PostalAddressTypes, etc. etc. Thus, this determines the type of data for a particular property in the Item. The type of the EAddress property is defined in the same way as shown. Although not necessarily used in this description of this application, another way of representing the composite types in the Location Item is to derive the Item with the individual properties of each composite type listed in it. 5C is a block diagram illustrating a Location Item, which further describes its composite types. However, it must be understood that this alternative representation of the Location Item in this FIG. 5C is for the exact same Item shown in FIG. 5A. The storage platform of the present invention also allows subtypes to be specified, whereby one type of property can be a subtype of another (where one type of property inherits the properties of another, parent type of the property).

Similarly, but different from properties and their property types, Items essentially represent their own Item Types, which can also be the subject of subtypes. In other words, the storage platform in several embodiments of the present invention enables the Item to be a subtype of another Item (whereby one Item inherits the properties of another, parent Item). In addition, for various embodiments of the present invention, each Item is a subtype of the Item type of the Item, which is the first and fundamental type of Item found in the Base Scheme. (The Basic Scheme is also described in detail in this description below.) FIG. 6A illustrates an Item, a Location Item in this Example, which is a subtype of the type of Item Item located in the Basic scheme. In this drawing, an arrow indicates that the Location item (like all other Items) is a subtype of the Item type. The Item Type of an Item, as the foundational Item from which all other Items are derived, has a number of important properties, such as ItemId and various timestamps, and thus defines the standard properties of all Items in the operating system. In the present figure, these properties of the Item type are inherited by Location and thus become Location properties.

Another way to represent properties in a Location Item, inherited from the Item Type, is to infer 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 its inherited types are described in addition to its immediate properties. It should be noted and understood that this Item is the same Item as that depicted in Fig. 5A, although the Location figure is depicted with all its properties, both direct - shown both in this figure and in Fig. 5A, and inherited — shown in this figure, but not in FIG. 5A (since in FIG. 5A, these properties are referenced by the arrow image that the Location Item is a subtype of the Item Type).

Items are autonomous objects; thus, if you delete an Item, all immediate and inherited properties of the Items are also deleted. Similarly, when retrieving an Item, what is accepted is the Item and all its immediate and inherited properties (including information related to its composite property types). Some embodiments of the present invention may provide the ability to request a subset of properties when retrieving a specific Item; however, for many such default embodiments, an Item is provided with all its immediate and inherited properties when retrieved. In addition, the properties of Items can also be expanded by adding new properties to existing properties of this type of Item. These "extensions", after that, are the real properties of the Item, and subtypes of this type of Item can automatically include the properties of the extension.

The “border” of an Item is represented by its properties (including composite property types, extensions, etc.). An Item Boundary also represents a limitation of an operation performed on an Item, such as copying, deleting, moving, creating, etc. For example, in several embodiments of the present invention, when an Item is copied, everything inside this border of the Item is also copied. For each Item, the boundary covers the following:

- the Item Type of the Item and, if the Item is a subtype of another Item (as is the case with several embodiments of the present invention, where all Items are derived from a single Item and Item Type in the Base Scheme), information about any applicable subtype (i.e. information, referring to the parent type Item). If the original Item being copied is a subtype of another Item, the copy may also be a subtype of the same Item.

- Properties and extensions of the composite type of the Item, if any. If the original Item has properties of composite types (native or advanced), the copy can also have the same composite types.

- Records of the Subject on “ownership relationships”, i.e. own list of the Subject of which other Items (“Subjects of purpose” or target Subjects) owns this Subject (“Owning Subject”). This is particularly relevant for the Item Folders described in more detail below, and the rule indicated below that all Items must belong to at least one Item Folder. In addition, with respect to embedded items, described in more detail below, the embedded item is considered to be part of the Item in which it is embedded, for operations such as copying, deleting, etc.

2. Identification of Items

Items are uniquely identified in the global item space using the ItemID. The Base.Item type defines an ItemID field of type GUID that stores the identifier for the Item. The item must have exactly one identifier in the data store 302.

a) Link to the subject

An item reference is a data structure that contains information for determining the location and identification of an Item. The data model defines an abstract type called ItemReference, from which all reference item types are derived. The ItemReference type defines a virtual method called Resolve. The Resolve method enables an ItemReference and returns an Item. This method is replaced by specific subtypes of ItemReference, which implement the function that retrieves the Item from this link. The Resolve method is called as part of the storage platform API 322.

(1) ItemIDReference

ItemIDReference is a subtype of ItemReference. It defines the Locator field and ItemID. The Locator field names (i.e. identifies) the domain of the item. It is processed by the locator resolution method, which can resolve the Locator value for the subject domain. The ItemID field is an ItemID type.

(2) ItemPathReference

ItemPathReference is a specialization of ItemReference that defines the Locator and Path fields. The Locator field identifies the domain of the item. It is processed by the locator resolution method, which can resolve the Locator value for the subject domain. The Path field contains the (relative) path in the storage platform namespace with the root in the subject domain provided by the Locator.

This type of link cannot be used in the installation operation. The link should basically be resolved using the path resolution process. The Resolve API API 322 storage platform provides this functionality.

b) Reference type hierarchy

The reference forms described above are represented by the hierarchy of the reference type depicted in FIG. 11. Additional reference types that inherit from these types can be defined in schemas. They can be used when declaring a link as a type of target field.

3. Folders and item categories

As described in more detail below, groups of Items can be organized into special Items called Item Folders (which should not be confused with file folders). Unlike most file systems, however, an Item can belong to more than one Item Folder, so when an Item is accessed in one Item Folder and it changes, this modified Item can then be accessed directly from another Item folder. Essentially, although a call to an Item can come from different Mailboxes of Items, what is actually being addressed is actually the same Item. However, the Item Folder does not necessarily own all the Items of its members or may simply share the Items with other folders, so deleting the Item Folder does not necessarily delete the Item. However, in several embodiments of the present invention, the Item must belong to at least one Item Folder, so if a single Item Folder is then deleted for a specific Item, for some embodiments, the Item is automatically deleted, or in alternative embodiments, the Item automatically becomes a member Default Item Folders (for example, Trash Can Item Folders, conceptually similar to the named folders used on various systems, based on files and folders).

As also described in more detail below, Items can also belong to Categories based on the general characteristics described, such as (a) the Type (or Types) of an Item, (b) a specific immediate or inherited property (or properties) or (c) a specific value ( or values) corresponding to the property of the Item. For example, an Item containing specific properties for personal contact information may automatically belong to the Contact Category, and any Item that has contact information properties will likewise automatically belong to this Category. Similarly, any Item that has a location property with a value of “New York City” can automatically belong to the NewYorkCity Category.

Categories are conceptually different from Item Folders in that, while Item Folders can contain Items that are not interconnected (that is, without common characteristics described), each Item in a Category has a common type, property or value (“commonality”) , which are described for this Category, and it is this community that forms the basis for its connection with other Items in the Category and between them. In addition, while the membership of Items in a particular Folder is not forcibly based on any particular aspect of this Item, for some embodiments, all Items having commonality unconditionally associated with the Category can automatically become a member of the Category at the hardware / software interface system level. Conceptually, Categories can also be represented as virtual Subject Folders whose membership is based on the results of a particular query (such as in the context of the database), and Subjects that satisfy the conditions of this query (defined by the Community of Categories), thus, will enclose the Category membership .

Figure 4 illustrates the structural relationship between Items, Item Folders, and Categories in various embodiments of the present invention. Many Items 402, 404, 406, 408, 410, 412, 414, 416, 418 and 420 are members of various Folders 422, 424, 426, 428 and 430 Items. Some Items may belong to more than one Item Folder, for example, Item 402 belongs to Item Folders 422 and 424. Some Items, for example, Items 402, 404, 406, 408, 410 and 412 are also members of one or more Categories 432, 434 and 436, while in other cases, for example, Items 414, 416, 418 and 420 may not belong to any Categories (although this is mostly unlikely in some embodiments, where owning any property automatically means membership in the Category, and thus, the Item must be completely devoid of features in order not to be a member of any category in such an embodiment). In contrast to the hierarchical structure of folders, both Categories and Item Folders have structures more similar to oriented graphs, as shown. In any case, Items, Item Folders and Categories are all Items (albeit of different Item Types).

In contrast to the files, folders and directories, the Items, Item Folders and Categories of the present invention are not characteristic “physical” in nature, since they do not have conceptual equivalents to physical containers, and therefore Items can exist in more than one such location. The ability of Items to exist in more than one location of the Item Folder, as well as the organization in the Categories, provide an improved and expanded degree of data manipulation and storage structure capabilities at the hardware / software interface system level, more than what is currently available in the art.

4. Schemes

a) Basic scheme

In order to provide a comprehensive framework for creating and using Items, various embodiments of the storage platform of the present invention comprise a Basic Scheme that establishes a conceptual framework for creating and organizing Items and properties. The Basic Scheme defines some special types of Objects and properties and features of these special fundamental types from which subtypes can be additionally derived. Using this Basic Scheme allows a programmer to conceptually distinguish Objects (and their respective types) from properties (and their respective types). In addition, the Base Scheme formulates a fundamental set of properties that all Items can possess, since all Items (and their corresponding Item Types) are derived from this fundamental Item in the Base Scheme (and its corresponding Item Type).

As shown in FIG. 7 and with respect to several embodiments of the present invention, the Basic Scheme defines three types of top level: Item, Extension and PropertyBase. As shown, the type of Item is determined by the properties of this fundamental type of Item. In contrast, the top-level property type “PropertyBase” has no predefined properties and is simply a binding from which all other property types are derived and through which all property types that are inferred (usually derived from a single property type) are linked. Properties of the Extension type determine which Item extends the extension, as well as identification to distinguish one extension from another, since the Item can have multiple extensions.

An ItemFolder is a subtype of the type of an Item, which, in addition to the properties inherited from Item, is characterized by a Link to bind to its members (if any), while both IdentityKey and Property are subtypes of PropertyBase. CategoryRef, in turn, is a subtype of IdentityKey.

b) The basic scheme

Various embodiments of the storage platform of the present invention further comprise a Main Scheme that provides a conceptual framework for top-level Item structures. Fig. 8A is a block diagram illustrating Objects in the Main Scheme, and Fig. 8B is a block diagram illustrating property types in the Main Scheme. The difference made between files with various extensions (* .com, * .exe, * .bat, * .sys, etc.), and other such criteria in systems based on files and folders, are similar to the functions of the Main Schema. In the Item-based hardware / software interface system, the Main Scheme defines a set of basic Item types that directly (through the Item type) or indirectly (through the Item subtype) characterize all Items in one or more Item types of the Main Scheme that the Item-based hardware / software the interface system understands and can directly process in a predefined and predictable way. The predefined Item types reflect the most common Items in the Item-based hardware / software interface system, and thus, the level of efficiency is enhanced by the Item-based hardware / software interface system that understands these predefined Item types that the Basic Schema contains.

In some embodiments, the implementation of the Main Scheme is not extensible, i.e. additional Item types cannot be defined by subtypes directly from the Item type in the Base Scheme, except for specific predefined derived types of Item that are part of the Main Schema. By preventing extensions in the Master Schema (i.e., by preventing the addition of new Items to the Master Schema), the storage platform provides authority to use the Item types of the Master Schema, since each subsequent Item type is necessarily a subtype of the Item type of the Master Schema. This structure allows you to get an acceptable degree of flexibility when defining additional Item types, while also preserving the benefits of having a predefined set of basic Item types.

For various embodiments of the present invention and with reference to FIG. 8A, specific Item types supported by the Main Schema may include one or more of the following:

- Categories: Items of this Type Item (and subtypes derived from it) represent valid Categories in the Item-based hardware / software interface system.

- Goods: Items that are identifiable value objects.

- Devices: Items that have a logical structure that supports information processing capabilities.

- Documents: Items with content that is not interpreted by the Item-based hardware / software interface system, but is instead interpreted by an application program that matches the type of document.

- Events: Items that record some cases in the environment.

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

- Communications: Items exchanged between two or more principals (defined below).

- Principals: Items having at least one identifiable identifiable identifier other than ItemID (for example, identification of an individual, organization, group, family, authority, service, etc.).

- Wording: Items that have specific information regarding the environment, including, without limitation, policies, subscriptions, access settings, etc.

Similarly, and with reference to FIG. 8B, specific types of properties supported by the Main Scheme may include one or more of the following:

- Certificates (derived from the underlying PropertyBase type in the Base Schema)

- Principal identification keys (derived from the IdentityKey type in the Base Schema)

- Mailing address (inferred from the Property type in the Base Schema)

- Rich text (inferred from the Property type in the Base Schema)

- EAddress (inferred from the Property type in the Base Schema)

- IdentitySecurityPackage (inferred from the Relationship type in the Base Schema)

- RoleOccupancy (inferred from the Relationship type in the Base Schema)

- BasicPresence (inferred from the Relationship type in the Base Schema)

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

5. Communication

Links are binary links, where one Item is designated as a source, and another Item as a target. The source item and the target item are linked. A source item typically controls the lifetime of a link. That is, when the Source Item is deleted, the relationship between the Items is also deleted.

Links are classified into: Inclusion and Link links. Inclusion relationships control the lifetime of Objects of the target, while linking relationships do not provide any semantics for managing lifetimes. 12 illustrates how communications are classified.

Types of connection Inclusions are further classified in the connection of Attachment and Implementation. When all attachment links for an Item are deleted, the Item is deleted. An attachment relationship controls the lifetime of a target through a link counting mechanism. Implementation links allow you to model compound Items and can be represented as exclusive attachment links. An item may be the target of one or more attachment links; but the Subject can be the goal of only one implementation connection. An object that is the target of an attachment link cannot be the target of any other attachment or attachment link.

Link links do not control the lifetime of the Target. They may be dangling - The subject of the goal may not exist. Link relationships can be used to model links to Items anywhere in the global Item namespace (i.e. including remote data stores).

Selecting an Item does not automatically select its relationship. Applications must explicitly request Item links. In addition, modifying the link does not modify the subject of the source or target; likewise, adding a link does not affect the Source / target Subject.

a) Communication announcement

Explicit communication types are defined by the following elements:

- The name of the relationship is specified in the Name attribute.

- The type of connection, one of the following: Attachments, Implementations, Links. It is set in the Type attribute.

- The endpoints of the source and target. Each endpoint specifies the name and type of the referenced Item.

- The source endpoint field is usually of the type ItemID (not declared), and it must reference the Item in the same data store as the link instance.

- For Attachment and Deployment relationships, the target endpoint field must be of the ItemIDReference type, and it must reference the Item in the same data store as the link instance. For Link relationships, the target endpoint can be of any type of ItemReference and can refer to Items in other storage platforms data warehouses.

- Optionally, one or more fields of a scalar type or PropertyBase type can be declared. These fields may contain data associated with the relationship.

- Link instances are stored in the global link table.

- Each communication instance is uniquely identified by a combination (Source ItemID, Communication ID). The link ID is unique within the given ItemID source for all links originating in this Item regardless of their type.

The source item is the owner of the link. Although the Item, designated as the owner, controls the life of the link, the link itself is separate from the Items with which it is associated. The API 322 of the storage platform provides mechanisms for disclosing the relationships associated with the Item.

Here is an example of a link declaration:

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

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

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

ReferenceType = "ItemIDReference" />

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

platformTypes.DateTime "/>

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

platformTypes.DateTime "/>

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

platformTypes.DateTime "/>

</Relationship>

This is an example link relationship. A link cannot be created if the Person subject to which the source link refers does not exist. Also, if Person is deleted, instances of the relationship between person and organization are deleted. However, if the Organization Item is deleted, the link is not deleted, and it is dangling.

b) Attachment connection

Attachment links are used to model the management of the lifetime of Objects based on reference counting.

An item can be a source endpoint for zero or more links to Items. An Item that is not an embedded Item may be the target in one or more attachment relationships.

The target endpoint reference type must be ItemIDReference, and it must reference the Item in the same store as the link instance.

Attachment links control the lifetime of the target endpoint. Creating an instance of the connection of the attachment and the Item for which it is the goal is an atomic operation. Additional instances of the attachment link may be created, the purpose of which is the same Item. When the last instance of the attachment link with this Item as the endpoint of the target is deleted, the Target is also deleted.

The types of Endpoint Items specified in the link declaration are enforced when the link instance is created. Endpoint Item Types cannot be changed after communication has been established.

Attachment links play a key role in creating the Item namespace. They contain the “Name” property, which defines the name of the Target with respect to the Source. This relative name is unique to all attachment relationships originating from this Item. An ordered list of these relative names, starting from the root Item to this Item, forms the full name for the Item.

Attachment bonds form an oriented acyclic graph (OAS; DAG). When an attachment relationship is created, the system ensures that no loop is created, thus ensuring that the Item namespace forms an OAG.

Although the attachment relationship controls the lifetime of the Target, it does not control the interoperability of the Target. The subject of the goal is operationally independent of the Object that is owned by the attachment link. Copying, Moving, Reserving and other operations on the Item, which is the source of the attachment link, do not affect the Item, which is the target of the same link, for example, i.e. backup of a Folder Item does not automatically reserve all Items in a folder (FolderMember link targets).

The following is an example of an attachment relationship:

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

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

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

ReferenceType = "ItemIDReference" />

</Relationship>

The FolderMembers association allows you to implement the Folder principle as a generalized collection of Items.

c) Implementation Relations

Implementation relationships model the principle of privileged control over the lifetime of the Target. They make possible the concept of compound Items.

Creating an instance of the connection of the introduction and the Subject, which represents the goal, is an atomic operation. An item can be a source of zero or more implementation links. However, an Item may be the goal of one and only one implementation link. An object that is the target of an implementation link cannot be the target of an attachment link.

The target endpoint reference type must be ItemIDReference, and it must reference the Item in the same data store as the link instance.

The types of Endpoint Items specified in the link declaration will typically be invoked when the link instance is created. Endpoint Item Types cannot be changed after communication is established.

Deployment relationships control the endpoint interoperability of the target. For example, the operation of serializing an Item may include the serialization of all implementation links originating from this Item, as well as all their goals; Copying an Item also copies all of its embedded Items.

The following is an example declaration:

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

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

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

ReferenceType = "ItemIDReference" />

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

platformTypes.bigint "/>

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

platformTypes.float "/>

</Relationship>

d) Link links

Linking a link does not control the lifetime of the Item to which it refers. Even more, link links do not guarantee the existence of a target, nor do they guarantee the type of target specified in the link declaration. This means link links can be dangling. Also, link links can reference Items in other data stores. Link links can appear as a principle similar to linking on web pages.

An example link link declaration is as follows:

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

<Source ItemType = "Document" ItemType = "Base.Document" />

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

ReferenceType = "ItemIDReference" />

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

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

platformTypes.nvarchar (256) "/>

</Relationship>

Any reference type is allowed at the target endpoint. Items that are involved in linking links can be of any type Item.

Link links are used to model most links without managing the lifetime between Items. Since the existence of the goal is not forced, the link link is convenient for modeling loosely coupled links. Link links can be used for Objects in other data warehouses, including storages on other computers.

e) Rules and restrictions

The following additional rules and restrictions apply to relationships:

1. The subject should be the goal of (exactly one attachment relationship) or (one or more attachment links). The one exception is the root Item. The subject may be the target of zero or more link links.

2. The subject, which is the goal of the implementation link, cannot be a source of attachment links. It can be a source of link links.

3. The subject cannot be a source of attachment links if it is promoted from a file. It can be a source of implementation links and link links.

4. An item that is distributed (promoted) from a file cannot be the target of an implementation link.

f) Ordering links

In at least one embodiment, the storage platform of the present invention supports link ordering. Ordering is achieved through a property called “Order” in the base definition of relationships. There is no restriction on uniqueness on the Order field. The order of links with the same value of the order property is not guaranteed, but it is guaranteed that they can be ordered after links with a lower value of order and before links with a higher value of the order field.

Applications can receive links in the default order by ordering by combination (SourceItemID, RelationshipID, Order). All communication instances originating from this Item are ordered as a single collection, regardless of the type of relationship in the collection. This, however, ensures that all links of a given type (for example, FolderMembers) constitute an ordered subset of the collection of links for a given Item.

An API 312 data warehouse for manipulating relationships implements a set of operations that supports the ordering of relationships. The following terms are introduced to help explain operations:

RelFirst represents the first relationship in an ordered collection with an OrdFirst value of order;

RelLast represents the last relationship in an ordered collection with an OrdLast value of priority;

RelX represents this association in the collection with an OrdX priority value;

RelPrev represents the closest association in the collection to RelX with a priority OrdPrev value less than OrdX ; and

RelNext is the closest association in the collection to RelX with a priority OrdNext value greater than OrdX .

InsertBeforeFirst (SourceItemID, Relationship)

Inserts a link as the first link in the collection. The value of the Order property of the new link may be less than OrdFirst.

InsertAfterLast (SourceItemID, Relationship)

Inserts a link as the last link in the collection. The value of the Order property of the new link may be greater than OrdLast.

InsertAt (SourceItemID, ord, Relationship)

Inserts a relationship with the specified value for the Order property.

InsertBefore (SourceItemID, ord, Relationship)

Inserts a link before the link with the given priority value. A new connection can be assigned the value "Order", which is located between OrdPrev and ord, not including them.

InsertAfter (SourceItemID, ord, Relationship)

Inserts a link after a link to a given priority value. A new relationship may be assigned the value "Order", which is between ord and OrdNext, not including them.

MoveBefore (SourceItemID, ord, RelationshipID)

Moves the connection with this identifier (ID; ID) of the connection before the connection with the specified value "Order". Relationships can be assigned a new “Order” value, which is located between OrdPrev and ord, not including them.

MoveAfter (SourceItemID, ord, RelationshipID)

Moves the connection with the given communication ID (ID) after communication with the specified value "Order". Relationships can be assigned a new priority value, which is between ord and OrdNext, not including them.

As previously mentioned, each Item must be a member of the Item Folder. In the language of Links, each Item must have a link to the Item Folder. In several embodiments of the present invention, some relationships are represented by Relationships existing between Items.

As implemented for various embodiments of the present invention, a Link provides a directional binary link that is “distributed” by one Item (source) to another Item (target). The Link is owned by the Source Item (the Item that distributes it), and thus the Link is deleted if the source is deleted (for example, the Link is deleted when the Source Item is deleted). In addition, in some cases, the Link may share the ownership of the Object of the target, and such ownership may be reflected in the IsOwned property (or its equivalent) of the Link (as shown in FIG. 7 for the type of Relationship property). In these embodiments, creating a new IsOwned Link automatically increases the number of links to the Target, and deleting such a Link can reduce the number of links to a Target. For such specific embodiments, the Items continue to exist if they have a number of links greater than zero and are automatically deleted if and when the number reaches zero. Again, the Item Folder is an Item that has (or is configured to have) a set of Links to other Items, these other Items containing membership in the Item Folder. Other actual implementations of the Relationships are possible and contemplated by the present invention to achieve the functionality described herein.

Regardless of the actual implementation, Communication is a selectable connection from one object to another. The possibility that an Item belongs to more than one Item Folder, as well as to one or more Categories, and whether these Items, Folders and Categories are open or closed, is determined by the meaning given to the existence (or its absence) in the structure based on the Items. These logical Links represent the meaning assigned to the set of Links, regardless of the physical implementation, which are specifically used to achieve the functionality described in this document. Logical Links are established between an Item and its Item Folder (s) or Categories (or vice versa), since, essentially, Item Folders and Categories each represents a special type of Item. Consequently, with Item Folders and Categories you can act in the same way as with any other Item - copy, add to an email message, embed in a document, etc. etc. without limitation, Item Folders and Categories can be serialized and deserialized (imported and exported) using the same mechanisms as for other Items. (For example, in Extensible Markup Language (RPN; XML), all Items can have a serialization format, and this format applies equally to Item Folders, Categories, and Items.)

The above Links, which represent the relationship between the Item and its Item Folder (s), can logically spread from the Item to the Item Folder, from the Item Folder to the Item, or both. A link that logically spreads from an Item to an Item Folder means that the Item Folder is open to this Item and shares its membership information with this Item; and vice versa, the absence of a logical Link from the Item to the Item Folder means that the Item Folder is closed to this Item and does not share its membership information with this Item. Similarly, the Link that logically spreads from the Item Folder to the Item means that the Item is open and shared for this Item Folder, while the lack of a logical Link from the Item Folder to the Item means that the Item is closed and not shared. Therefore, when the Item Folder is exported to another system, it is the “open” Items that are shared in the new context, and when the Item searches its Item Folders for other shared Items, it is the “open” Item Folders that provide the item with information regarding shared Items that belong to them.

9 is a block diagram illustrating an Item Folder (which, again, is the Item itself), Items of its members and interconnecting Links between the Item Folder and the Items of its members. Folder 900 Items has many Members 902, 904, and 906 as members. Folder 900 Items has a Link 912 from itself to Subject 902, which means that Subject 902 is open and shared for Folder 900 Items, its members 904 and 906, and any other Item, Category, or Item Folders (not shown) that can access the 900 Item Folder. However, there is no Link from Subject 902 to Folder 900 of Subjects, which means that Subfolder 900 of Subjects is private to Subject 902 and does not share its membership information with Subject 902. Subject 904, on the other hand, does have a 924 Link from itself to Folder 900 Items, which means that Folder 900 Items is open and shares its membership information with Item 904. However, there is no Link from Folder 900 Items to Item 904, which means Item 904 is private and not shared for Folder 900Items, its other members 902 and 906, and any other Item, Category or Item Folders (not shown) that can access the Item 900 Folder. In contrast to its Relationships (or lack thereof) to Items 902 and 904, the Item 900 Folder has a Connection 916 from itself to Item 906, and Item 906 has a Connection 926 back to Item 900 Folder, which together means that Item 906 is open and shared used for the Folder 900 Items, its members 902 and 904 and any other Folders of Items, Categories or items (not shown) that can access the Folder 900 Items, and that the Folder 900 Items is open and shares its membership information with Item 906 .

As previously described, the Items in the Item Folder do not need to share a commonality, since the Item Folders are not “described”. Categories, on the other hand, are described by a community that is common to all Items of its members. Therefore, membership in a Category is, by its nature, limited to Items having the described generality, and in some embodiments, all Items satisfying the description of the Category are automatically made members of the Category. Thus, while Item Folders make it possible to represent trivial type structures through their membership, Categories allow membership based on the described generality.

Of course, Category descriptions are logical in nature, and therefore a Category can be described by any logical representation of types, properties and / or values. For example, a logical representation for a Category may be that its membership contains Items that have one of two properties, or both. If these described properties for the Category are “A” and “B”, then the membership of the Categories may contain Items that have property A, but not B, Items that have property B, but not A, and Items that have both properties A and B. This logical representation of properties is described by the logical operator "OR", where the set of members described by the Category is Items having properties A or B. Similar logical operands (including without limitation "AND", "EXCLUSIVE OR" and "NO" separately or in combinations) can also be used for descriptions of the category, which is clear to a person skilled in the art.

Despite the difference between the Item Folders (not described) and the Categories (described), the Linking of Categories to Items and the Linking of Items to Categories are essentially the same as described in this document for Item Folders and Items in many embodiments of the present invention.

10 is a block diagram illustrating a Category (which, again, represents the Item itself), Items of its members and interconnecting Links between the Category and Items of its members. Category 1000 has as members many Objects 1002, 1004, and 1006, all of which share some combination of common properties, values, or types 1008 described (by description 1008 'of generality) by Category 1000. Category 1000 has Link 1012 from itself to Item 1002 , which means that Item 1002 is open and shared for Category 1000, its members 1004 and 1006, and any other Categories, Item Folders or Items (not shown) that can access Category 1000. However, there is no Link from Item 1002 to Category 1000 which means that Category 1000 is closed to Item 1002 and does not share its membership information with Item 1002. Item 1004, on the other hand, does have a Link 1024 from itself to Category 1000, which means that Category 1000 is open and shared uses its membership information with Item 1004. However, there is no Link distributed from Category 1000 to Item 1004, which means that Item 1004 is closed and is not shared for Category 1000, its other members 1002 and 1006, and any other their Categories, Folders of Items or Items (not shown) that can refer to Category 1000. In contrast to its Relationships (or their absence) with Items 1002 and 1004, Category 1000 has a Link 1016 from itself to Item 1006, and Item 1006 has a Link 1026 back to Category 1000, which together means that Item 1006 is open and shared for Category 1000, its members 1002 and 1004 Items and any other Categories, Item Folders or Items (not shown) that can access Category 1000, and what Category 1000 is from rytoy and shares its membership information with the subject in 1006.

Finally, since Categories and Item Folders themselves are Items, and Items can have a Link to each other, Categories can have a Link to Item Folders and vice versa, and Categories, Item Folders and Items can have a Link to other Categories, Item Folders and Items respectively in some alternative embodiments. However, in various embodiments, the implementation of the Item Folder structure and / or Category structure at the hardware / software interface system level is prohibited from looping. Where the structures of Subject and Category Folders are similar to oriented graphs, embodiments that prohibit cycles are similar to oriented acyclic graphs (DAGs), which, according to the mathematical definition in the field of graph theory, are oriented graphs in which the path does not start and doesn't end at the same vertex.

6. Extensibility

It is assumed that the storage platform is provided with an initial set of circuits 340, as described above. In addition, however, in at least some embodiments, the storage platform enables consumers, including independent software vendors (ISVs), to create new schemes 344 (i.e., new Item and Nested Element types). This section deals with the mechanism for creating such schemas by extending the Item types and Nested Element types (or simply “Element” types) defined in the source schema set 340.

Preferably, the extension of the original set of Item and Nested Element types is limited as follows:

NPVO (ISV) is allowed to introduce new types of Item, i.e. subtype of Base.Item;

NPVO (ISV) is allowed to introduce new types of Nested Element, i.e. subtype of Base.NestedElement;

NPPO (ISV) is allowed to introduce new extensions, i.e. subtype of Base.NestedElement; but

NPVO (ISV) cannot determine the subtype of any types (types Item, Nested Element or Extension) defined by the source set of storage platform circuits 340.

Because the Item type or Nested Element type, defined by the source set of storage platform schemas, cannot exactly match the needs of an ISV application, you must enable the ISV to configure the type. This is permitted with the concept of Extension. Extensions are strongly typed instances, but (a) they cannot exist independently, and (b) they must join an Item or Nested Element.

In addition to addressing the need for schema extensibility, Extensions are also intended to address the issue of “multiple type assignment”. Since in some embodiments, the storage platform may not support multiple inheritance or overlapping subtypes, applications can use Extensions as a way to model instances with overlapping types (for example, a Document is a legal document as well as a security document).

a) Extensions of the subject

To ensure the extensibility of the Item, the data model additionally defines an abstract type called Base.Extension. This is the root type for the extension type hierarchy. Applications can specify a Base.Extension subtype to create specific extension types.

The Base.Extension type is defined in the Base schema as follows:

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

<Property Name = "ItemID"

Type = "the storage platformTypes.uniqueidentified"

Nullable = "false"

MultiValued = "false" />

<Property Name- "ExtensionID"

Type = "the storage platformTypes.uniqueidentified"

Nullable = "false"

MultiValued = "false" />

</Type>

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

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

Extension types have fields;

Fields can be types of simple and nested elements; and

Extension types can have subtypes.

The following restrictions apply to extension types:

Extensions cannot be sources and targets of links;

Extension type instances cannot exist independently of the subject; and

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

There are no restrictions on the types of extensions that can be associated with this type of Item. Any type of extension is allowed to expand any type of item. When multiple instances of extensions are attached to an item, they are independent of each other, both in structure and in behavior.

Instances of extensions are stored and accessed separately from the item. All instances of the extension type are accessible from the global extension view. An efficient query can be made that will return all instances of a given type of extension no matter what type of item they are associated with. The storage platform API (API) provides a programming model that can store, retrieve, and modify item extensions.

Subtypes of extension types can be specified using a single storage platform inheritance model. Deriving from an extension type creates a new extension type. The structure or behavior method of an extension cannot override or replace the structure or behavior methods of a hierarchy of type of objects.

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

Extensions are considered to be part of the subject for interoperability purposes. Copy / Move, Backup / Restore, and other general operations that the storage platform defines can work with extensions as part of the item.

Consider the following example. The Contact type is defined in the Windows Typeset.

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

<Property Name = "Name"

Type = "String"

Nullable = "false"

MultiValued = "false" />

<Property Name = "Address"

Type = "Address"

Nullable = "true"

MultiValued = false "/>

</Type>

A customer relationship management (CRM) application developer would like to attach a CRM application extension to contacts stored in a storage platform. The application developer defines a CRM extension, which contains an additional data structure that the application can manipulate.

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

<Property Name = "CustomerID"

Type = "String"

Nullable = "false"

MultiValued = "false" />

...

</ Type

The developer of a personnel management application (UK; HR) may also wish to attach additional data with Contact. This data is independent of the UVM application data (CRM). Application developer can create extension again

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

<Property Name = "EmployeeID"

Type = "String"

Nullable = "false"

MultiValued = "false" />

...

</Type>

CRMExtension and HRExtension are two independent extensions that can be attached to Contact items. They are created and addressed to them independently of each other.

In the above example, fields and methods of type CRMExtension cannot replace fields and methods of the Contact hierarchy. It should be noted that instances of the CRMExtension type can join Item types, excluding Contact.

When a Contact item is retrieved, its item extensions are not retrieved automatically. If you have a Contact item, the item extensions associated with it can be accessed by querying the global view of the extension for extensions with the same ItemId.

All CRMExtension extensions in the system can be accessed using a representation of the CRMExtension type, regardless of which item they belong to. All item extensions on an item share the same item identifier. In the above example, an instance of Contact and attached instances of CRMExtension and HRExtension have the same ItemID.

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

Item versus Item Extension versus NestedElement Item Item extension NestedElement Item ID Has its own item ID Shares the item ID of the item Does not have its own item ID. A nested element is part of an item. Storage The item hierarchy is stored in its own tables. The hierarchy of item extensions is stored in its own tables. Stored with item Query / Search May query item tables May query item extension tables It can mainly be requested only in a context that includes an item Query / Search Scope Can search all instances of item type Can search all instances of item extension type It can mainly search only in instances of the type of an embedded element of a single (inclusive) subject Relations Semantics May have Item Links No Links to item extensions No Links to Nested Elements Association with subjects May be linked to other items using attachment links, embedding links and flexible links They can basically have connections only with the help of extensions. The semantics of extensions are similar to the semantics of embedded objects. Has links to the subject using fields. Nested items are part of the item.

b) Extension of NestedElement types

Nested Element types are not extended using the same mechanism as Item types. Extensions of nested elements are stored and accessed using the same mechanisms as the type fields of nested elements.

The data model defines the root for the types of nested elements called Element:

<Type Name = "Element"

IsAbstract = "True">

<Property Name = "ElementID"

Type = "the storage platformTypes.uniqueidentifier"

Nullable = "false"

MultiValued = "false" />

</Type>

The type NestedElement inherits from this type. The element type NestedElement additionally defines a field that is a multiset of Elements.

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

IsAbstract = "True">

<Property Name = "Extensions"

Type = "Base.Element"

Nullable = "false"

MultiValued = "true" />

</Type>

NestedElement extensions differ from item extensions in the following ways:

Extensions of nested elements are not extension types. They do not belong to the extension type hierarchy whose root is the Base.Extension type.

Extensions of nested elements are stored together with other fields of the subject and are not with global access - a query cannot be made that retrieves all instances of this type of extension.

These extensions are stored in the same way as other nested elements (items) are stored. Like other nested kits, NestedElement extensions are stored in the OPT (UDT). They are accessible through the Extensions field of the type of nested elements.

Collection interfaces used to access properties with many values are also used to access and iterate over a set of type extensions.

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

Item extensions compared to NestedElement extensions Item Extension NestedElement Extension Storage Item extension hierarchy is stored in its own tables Stored like nested elements Query / Search May query item extension tables It can mainly be requested only in a context that includes an item Query / Search Scope Can search all instances of item type extensions It can mainly perform searches only within instances of the type of an embedded element of a single (inclusive) subject Programmability Requires special APIs for extensions and special queries on extension tables NestedElement extensions are like any other field with many values of a nested element; APIs of the normal type of the nested element are used Behavior method May associate a behavior method Behaviors not allowed (?) Link Semantics No Links to item extensions No Links to NestedElement Extensions Item ID Shares the item ID of the item Does not have its own item ID. The NestedElement extension is part of the subject.

D. DATABASE PROCESSOR

As mentioned above, the data warehouse is implemented on a database processor. In the present embodiment, the database processor comprises a relational database processor that implements SQL Server query language, such as a Microsoft SQL Server processor, with object-relational extensions. This section describes the data model mapping that the data warehouse implements for relational storage and provides information on the logical APIs used by the storage platform clients according to the present embodiment. It is understood, however, that a different mapping may be applied when a different database processor is used. Indeed, in addition to implementing the conceptual data model of the storage platform on a relational database processor, it can also be implemented on other types of databases, for example, object-oriented databases and RNR (XML) databases.

An object-oriented (OO) database system provides for persistence and transactions for programming language objects (for example, C ++, Java). The concept of the “item” storage platform is well displayed on the “Object” in object-oriented systems, although it is necessary to add embedded collections to the Objects. The principles of other types of storage platforms, like inheritance and types of nested elements, are also mapped onto systems of an object-oriented type. Object-oriented systems usually already support object identification; therefore, the identification of the item may be mapped to the identification of the object. Methods of behavior (operation) of objects are well displayed on object methods. However, object-oriented systems usually lack organizational capabilities and are poorly searched. Also, object-oriented systems do not provide support for unstructured and semi-structured data. To support the complete storage platform data model described in this document, concepts like links, folders, and extensions must be added to the data object model. In addition, mechanisms such as promotion, synchronization, notification, and protection must be implemented.

Like object-oriented systems, databases of RNR (XML) based on the definition of RNR (XML) schema (OPC; XSD) support type systems based on single inheritance. The item type system of the present invention can be mapped onto an OPC type model (XSD). OPC (XSD) also does not provide support for behaviors. OPC (XSD) for items must be supplemented with item behavior methods. RNR databases (XML) deal with single ODP (XSD) documents, and they lack the ability to organize and search widely. As with object-oriented databases, in order to support the data model described in this document, other concepts, such as links and folders, must be built into such databases as RNR (XML); It is also necessary to implement mechanisms such as synchronization, notification and protection (security).

1. The implementation of the data warehouse using the OPT (UDT)

In the present embodiment, the relational database processor 314, which in one embodiment comprises a Microsoft SQL Server processor, supports embedded scalar types. Built-in scalar types are "native" and "simple." They are native in the sense that the user cannot define their own types, and they are simple in that they cannot encapsulate a composite structure. User-defined types (below: UDT) provide a mechanism for extensibility of types above and beyond the native scalar type system, thereby allowing users to expand the type system by defining composite, structured types. If defined by the user, the UDT can be used anywhere in the type system where the built-in scalar type can be used.

According to an aspect of the present invention, storage platform diagrams are mapped to UTT classes in a database processor storage. Data warehouse objects are mapped to classes of opt-in storage (UDT) inferred from the Base.Item type. Like Subjects, Extensions are also mapped to UDT classes and use inheritance. The root type of Extension is Base.Extension, from which all Extension types are derived.

OPT (UDT) is a class of nuclear weapons library (CLR) - it has a state (i.e. data fields) and a method of behavior (i.e. subroutines). OPT (UDT) are defined using any managed language - C #, VB.NET and others. OPT methods and operators (UDT) can be called in T-SQL with respect to an instance of this type. OPT (UDT) can be: the type of a column in a row, the type of a subroutine parameter in T-SQL, or the type of a variable in T-SQL.

The following example illustrates the basics of OPT (UDT). Suppose MapLib.dll has an assembly called MapLib. This assembly has a class called Point in the BaseTypes namespace:

namespace BaseTypes

{

public class Point

{

// returns the distance from the given point.

public double Distance (Point p)

{

// returns the distance between Point p and this Point

}

// other material in the class

}

}

The following T-SQL code associates the Point class with the SQL Server OPT (UDT) called Point. The first step calls CreateAssembly, which loads the MapLib assembly into the database. In the second step, “Create Type” is called to create the user-defined “Point” type and associates it with the managed type BaseTypes.Point:

CREATE ASSEMBLY MapLib

FROM '\\ mysrv \ share \ MapLib.dll'

go

CREATE TYPE Point

EXTERNAL NAME 'BaseTypes.Point'

go

If it is created, the Point UDT can be used as a column in the table and the methods can be called in T-SQL, as shown below:

Create table Cities (

Name varchar (20),

State varchar (20),

Location Point)

- Extract Distance Cities

- from coordinates (32, 23)

Declare @p point (32, 23), @distance float

Select Location :: Distance (@p)

From cities

Mapping storage platform schemas to UTT classes is fairly straightforward at a high level. Basically, the storage platform schema is mapped to the SNRN (CLR) namespace. The type of storage platform is mapped to the CLR class. Inheritance of the CLR class reflects the inheritance of the Storage Platform Type, and the property of the storage platform maps to the property of the CLR class.

The Item Hierarchy depicted in FIG. 29 is used as an example in this document. It shows the Base.Item type, from which all Item types are derived, along with a set of derived Item types (e.g. Contact.Person and Contact.Employee), with the inheritance indicated by arrows.

2. Display items

Given the desirability of a global search for Items and support in the relational database of this embodiment of type inheritance and replaceability, one possible implementation of storing Items in a database repository would be to store all Items in a single table with a column of type Base.Item. Using type substitution, Items of all types could be stored, and the search could be filtered by type and subtype of Item, using the Yukon "is of ( Type )" operator.

However, due to the importance of overhead associated with such an approach, in the present embodiment, the Items are divided by the top-level type, so that the Items of each “family” of the type are stored in a separate table. With this separation scheme, a table is created for each type of Item, inheriting directly from Base.Item. Types inheriting below these are stored in the corresponding table of the type family, using type substitutions, as described above. Only the first level of inheritance from Base.Item is considered specifically. For the exemplary Item hierarchy shown in FIG. 29, this leads to the following type family tables:

create table Contact. [Table! Person] (

_Item Contact.Person not null,

{Change Tracking Information}

)

create table Doc. [Table! Document] (

_Item Doc.Document not null,

{Change Tracking Information}

)

The Shadow table is used to store copies of global search properties for all Items. This table can be supported by the Update () method of the storage platform API (API), by which all data changes are performed. Unlike type family tables, this global Item table contains only scalar properties of the top level of an Item, not a complete UDT Item. The structure of the global Item table is as follows:

create table Base. [Table! Item] (

ItemID uniqueidentifier not null constraint [PK_Clu_Item! ItemID] primary key clustered,

TypeID uniqueidentifier not null,

{Additional properties of Base.Item},

{Change Tracking Information}

)

The Global Item table enables you to navigate to an Item object stored in a type family table by expanding ItemID and TypeID. ItemID basically uniquely identifies the Item in the data warehouse. A TypeID may be displayed using metadata that is not described here in the type name and view including the Subject.

Since discovering an Item by its ItemID can be a simple operation both in the context of the global table of Items and otherwise, the GetItem () function is provided to retrieve an Item by the ItemID of the Item. This function has the following declaration:

Base.Item Base.GetItem (uniqueidentifier ItemID)

For convenient access and concealment of implementation details, to the extent possible, all queries of Items can be performed in relation to the views built on the tables of Items described above. Specifically, views can be created for each type of Item in relation to the corresponding table of the type family. These type representations can select all Items of the associated type, including subtypes. For convenience, in addition to the UDT object, views can expand columns for all top-level fields of this type, including inherited fields. The views for the exemplary hierarchy of Items shown in FIG. 29 are as follows:

create view Contact.Person as

select _Item.ItemID, {Base.Item Properties}, {Contact.Person Properties}, {Change Tracking Information}, _Item

from Contact. [Table! Person]

- Note that the Contact.Employee view uses the predicate "where"

--to limit the set of detected Items to Contact.Employee instances

create view Contact. Employee as

select _Item.ItemID, {Base.Item Properties}, {Contact.Person Properties}, {Properties

Contact Employee},

{Change Tracking Information}, cast (_Item as Contact.Employee)

from Contact. [Table! Person]

where _Item is of (Contact. Employee)

create view Doc. Document as

select _Item.ItemID, {Base.Item Properties}, {Doc.Document Properties}, {Information on

change tracking}, _Item

from Doc. [Table! Document]

--Note that the Doc.WordDocument view uses the predicate "where"

--to limit the set of discovered Items to instances of Doc.WordDocument

create view Doc.WordDocument as

select _Item.ItemID, {Base.Item Properties}, {Doc.Document Properties}, {Properties

Doc.WordDocument},

{Change Tracking Information}, cast (_Item as Doc.WordDocument)

from Doc. [Table! Document]

where _Item is of (Doc.WordDocument)

For completeness, a view can also be created using the global Item table. This view may initially expand the same columns as the table:

create view Base.Item as

select ItemID, TypeID, {Base.Item Properties}, {Tracking Information

changes}

from Base. [Table! Item]

3. Display extensions

Extensions are very similar to Items and have some of the same requirements. As another root type that supports inheritance, Extensions are subject to many of the same considerations and trade-offs during storage. Because of this, a similar type family mapping is applied to Extensions, rather than a single table approach. Of course, in other embodiments, a single table approach may be used.

In the present embodiment, an Extension is associated with exactly one Item through an ItemID and contains an ExtensionID that is unique in the context of the Item. The Extensions table has the following definition:

create table Base. [Table! Extension] (

ItemID uniqueidentifier not null,

ExtensionID uniqueidentifier not null,

TypeID uniqueidentifier not null,

{Base.Extension Properties},

{Change Tracking Information},

constraint [PK_Clu_Extension! ItemID! ExtensionID]

primary key clustered (ItemID asc, ExtensionID asc)

)

As with Items, a function can be provided to retrieve an Extension by its identifier, which consists of a pair of ItemID and ExtensionID. This function has the following declaration:

Base.Extension Base.GetExtension (uniqueidentifier ItemID, uniqueidentifier ExtensionID,)

For each type of Extension, a View is created similar to the views of the Item type. Suppose that the hierarchy of Extensions is parallel to the sample hierarchy of Items with the following types: Base.Extension, Contact.PersonExtension, Contact.

create view Contact. [Extension! PersonExtension] as

select _Extension.ItemID, _Extension.ExtensionID, {EmployeeExtension. The following views can be created:

create view Base.Extension as

select ItemID, ExtensionID, TypeID, {Base.Extension Properties}, {Information on

change tracking}

from Base. [Table! Extension] Properties of Base.Extension, {Properties

Contact.PersonExtension},

{Change Tracking Information}, _Extension

from Base. [Table! PersonExtension]

create view Contact. [Extension! EmployeeExtension] as

select _Extension.ItemID, _Extension.ExtensionID, {Base.Extension Properties), {Properties

Contact.PersonExtension},

{Contact.EmployeeExtension Properties}, {Tracking Information

changes}

cast (_Extension as Contact.EmployeeExtension)

from Base. [Table! PersonExtension]

where _Extension is of (Contact.EmployeeExtension)

4. Display of nested elements

Nested elements are types that can be embedded in Items, Extensions, Links or other Nested elements, forming structures with a large depth of nesting. Like Items and Extensions, Nested Elements are implemented as OPT (UDT), but they are stored in Items and Extensions. Therefore, Nested Elements do not have a storage display other than their Containers of Items and Extensions. In other words, there are no tables on the system that directly store instances of NestedElement types, and there are no views specifically allocated to Nested Elements.

5. Identification of objects

Each entity in the data model, i.e. Each Item, Extension and Link, has a unique key value. An item is uniquely identified by its ItemID. An extension is uniquely identified by means of a compound key (ItemId, ExtensionId). A relationship is identified by a compound key (ItemId, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.

6. Naming of objects of the LSS (SQL)

All objects created in the data warehouse can be stored in the name of the SCL (SQL) schema that is derived from the name of the storage platform schema. For example, a Base Storage Platform Schema (often called a “Base”) can create types in the SQL [SQL] scheme “[System.Storage]”, such as “[System.Storage] .Item”. A prefix is added to the generated names using a qualifier to eliminate naming conflicts. When appropriate, an exclamation mark (!) Is used as a separator for each logical part of the name. The table below summarizes the naming convention used for objects in the data warehouse. Each schema element (Item, Extension, Link, and Presentation) is listed along with the decorated naming convention used to access instances in the data warehouse.

An object Name decoration Description Example Top Subject Search Submission Master! Item Provides a summary of items in the current item domain [System.Storage].
[ Master! Item ] Typed view of a Search item Item Type Provides data for all properties from an item and any parent type (s). [AcmeCorp.Doc]. [OfficeDoc] Top View Search Extensions Master! Extension Provides a summary of all extensions in the current item domain. [System.Storage].
[ Master! Extension ] Typed extension search view Extension ! Extension Type Provides data for all properties for extension [AcmeCorp.Doc].
[ Extension ! StickyNote] Top View Links Master! Relationship Provides a summary of all links in the current item domain. [System.Storage].
[ Master! Relationship ] Relationship View Relationship ! Link Name Provides all the data associated with this association. [AcmeCorp.Doc].
[ Relationship ! AuthorsFromDocument] Performance View ! View Name Provides all columns / types based on the view schema definition. [AcmeCorp.Doc].
[ View ! DocumentTitles]

7. Naming columns

When mapping any object model to the repository, there is the possibility of naming conflicts due to additional information stored with the application object. To avoid naming conflicts, all columns not specific to the type (columns that do not map directly to the named Property in the type declaration) are prefixed with an underscore (_). In the present embodiment, the underscore (_) characters are prohibited as the initial character of any identifier property. Further, to unify the naming between the CLR and the data warehouse, all properties of the types or element of the scheme (communication, etc.) of the storage platform must have the first character written in capital letters.

8. Search submissions

Views are provided by the storage platform to search for stored content. A JSS view is provided for each type of Item and Extension. Further, views are provided to support Links and Views (defined by the Data Model). All SQL Server views and underlying tables in the storage platform are read-only. Data may be stored or modified using the Update () method of the storage platform API (API), as described in more detail below.

Each view that is explicitly defined in the scheme (defined by the developer of the scheme and not automatically generated by the storage platform) of the storage platform can be referred to as a named view of SQL Server [<schema-name]. [ View! <view_name>]. For example, a view named “BookSales” in the “AcmePublisher.Books” schema can be accessed using the name “[AcmePublisher.Books]. [View! BookSales]”. Since the output format of the view is configured based on each view (determined by an arbitrary request provided by the party that defines the view), the columns are directly displayed based on the definition of the presentation of the diagram.

All SQL Server (SQL) search views in the storage platform data warehouse use the following collation for columns:

1. The logical “key” column (s) of the presentation result, such as ItemId, ElementId, RelationshipId, ...

2. Metadata information by type of result, such as TypeId .

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

4. Type-specific column (s) (Properties of the declared type).

5. Type-specific representations (family representations) also contain an object column that returns the object.

Members of each type family are searchable using a sequence of Item views, with one view per Item type in the data store.

a) subject

Each Item search view contains a string for each instance of the Item of a particular type or its subtypes. For example, a view for a Document may return instances of Document, LegalDocument, and ReviewDocument. Given this example, the representations of Items can be represented at a conceptual level as shown in FIG. 28.

(1) The main item search view

Each instance of the storage platform data warehouse defines a special Item view called the Master Item view . This view provides an informational summary for each Item in the data warehouse. The view provides one column for a property of type Item, a column that describes the type of the Item, and several columns that are used to provide change tracking and synchronization information. The main item view is identified in the data warehouse using the name “[System.Storage]. [Master! Item]”.

Column Type of Description ItemId ItemId Item Storage Platform Identification _TypeId Typeid The TypeId of the Item identifies the exact type of the Item and can be used to retrieve information by type using the Metadata directory. _RootItemId ItemId ItemId of the first non-implanted predecessor that controls the lifetime of this item. <global change tracking> ... Global Change Tracking Information <Item Properties> not applicable One column per property of type Item

(2) Typed item search representations

Each type of Item also has a search representation. Along with being similar to the representation of the root Item, this view also provides access to the Item object using the "_Item" column. Each typed representation of the subject search is identified in the data warehouse using the name [ Name ]. [ Name ]. For example, [AcmeCorp.Doc]. [OfficeDoc].

Column Type of Description ItemId ItemId Item Storage Platform Identification <type change tracking> ... Type Change Tracking Information <parent properties> <characteristic properties One column per parent property <item properties> <property specific> One column per exceptional property of this type _Item Type NLWW (CLR) Item NLW Object (CLR) - Type of declared Item

b) Item extensions

All Subject Extensions in WinFS are also available using search views.

(1) Main view of extension search

Each instance of the data warehouse defines a special extension view called the Extension Extension Main View . This view provides an informational summary of each Extension in the data warehouse. The view has a column on the Extensions property, a column that describes the type of Extensions, and several columns that are used to provide change tracking and synchronization information. The main extension view is identified in the data warehouse using the name "[System.Storage]. [Master! Extension]".

Column Type of Description ItemId ItemId Identification of the Item storage platform this extension is associated with ExtensionId ExtensionId (GUID) ID of this extension instance _TypeId Typeid TypeId Extensions - Identifies the exact type of extension and can be used to retrieve extension information using the Metadata directory. <global change tracking> ... Global Change Tracking Information <extension properties> <extension specific> One column per property of type Extension

(2) Typed Extension Search Views

Each type of Extension also has a search view. Along with being similar to the main extension view, this view also provides access to the Item object through the _Extension column. Each typed extension search lookup is identified in the data store using the name [ Name ]. [ Extension! ExtensionName ]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt].

Column Type of Description ItemId ItemId Identification of the Item storage platform this extension is associated with ExtensionId ExtensionId (GUID) ID of this extension instance <type change tracking> ... Type Change Tracking Information <parent properties> <property specific> One column per parent property <extension properties> <property specific> One column per exceptional property of this type _Extension Extension type CLR (Instance Type) NLB Object (CLR) - Type of declared Extension

c) Nested elements

All nested items are stored in instances of Items, Extensions, or Links. Essentially, they are accessed by querying the appropriate search for Items, Extensions, or Links.

d) Communication

As described above, Links form the fundamental unit of binding between Items in the storage platform data warehouse.

(1) Top link search view

Each data store provides a Main Relationship view . This view provides information on all instances of relationships in the data warehouse. The main relationship view is identified in the data warehouse using the name “[System.Storage]. [Master! Relationship]”.

Column Type of Description ItemId ItemId Source Endpoint Identification (ItemId) RelationshipId RelationshipId (GUID) Link Instance ID _RelTypeId RelationshipTypeId RelTypeId Links - Identifies the type of link instance using the Metadata directory <global change tracking> ... Global Change Tracking Information TargetItemReference ItemReference Target Endpoint Identification _Relationship Relationship An instance of the Relationship object for this instance

(2) Communication instance search submissions

Each advertised Link also has a search representation that returns all instances of a particular link. Along with being similar to the main view of a link, this view also provides named columns for each property of the link data. Each view of the link instance search is identified in the data store using the name [ Name ]. [ Relationship ! Name the link ]. For example, [AcmeCorp.Doc]. [Relationship! DocumentAuthor].

Column Type of Description ItemId ItemId Source Endpoint Identification (ItemId) RelationshipId RelationshipId (GUID) Link Instance ID <type change tracking> ... Type Change Tracking Information TargetItemReference ItemReference Target Endpoint Identification <source name> ItemId Named source endpoint identification property (alias for ItemId) <target name> ItemReference or derived class Named target endpoint identification property (alias and type casting for TargetItemReference) <communication property> <property specific> One column per link definition property _Relationship LINES type (CLR) of the Link instance NLW object (CLR) - type of declared Link

9. Updates

All views in the storage platform data warehouse 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 the only stored procedure defined by the data store that uses an “operation” that details the action to be performed. The ProcessUpdategram method is a stored procedure that accepts an ordered set of operations, known as an “updategram”, which together details the set of actions to be performed.

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

1. Operations on Items:

but. CreateItem (Creates a new item in the context of an embed or attach relationship)

b. UpdateItem (updates an existing Item)

2. Relationship Operations:

but. CreateRelationship (creates an instance of link or attach link)

b. UpdateRelationship (updates link instance)

c. DeleteRelationship (deletes link instances)

3. Operations on Extensions:

but. CreateExtension (Adds an extension to an existing Item)

b. UpdateExtension (updates an existing extension)

from. DeleteExtension (removes the extension)

10. Change tracking and monuments

Change tracking and monument facilities are provided by the data warehouse, as described in more detail below. This section provides the general structure of change tracking information disclosed in the data warehouse.

a) Change tracking

Each search view provided by the data warehouse contains columns used to provide change tracking information; columns are common across all views of Items, Extensions, and Links. Views of the Storage Platform Schema, defined explicitly by the developers of the schemes, do not automatically provide information on tracking changes - such information is provided implicitly using the search views on which the view itself is built.

For each item in the data warehouse, change tracking information is available from two places - the “main” representation of the elements and the “typed” representation of the elements. For example, change tracking information on the type of Item AcmeCorp.Document.Document is available from the Main Item View “[System.Storage]. [Master! Item]” and the typed Item Search View [AcmeCorp.Document]. [Document].

(1) Tracking changes to the “main” search views

Information on tracking changes in the main views of the search provides information on the versions of creating and updating the element, information on which synchronization partner created the element, which synchronization partner last updated the element, and version numbers from each partner for creation and updating. Partners in synchronization relationships (described below) are identified by the partner key . A single OPT object (UDT) named _ChangeTrackingInfo of type [System.Storage.Store] .ChangeTrackingInfo contains all this information. The type is defined in the System.Storage schema. _ChangeTrackingInfo is available in all global search views for Subject, Extension and Link. A ChangeTrackingInfo type definition is:

<Type Name = "ChangeTrackingInfo" BaseType = "Base.NestedElement">

<FieldProperty Name = "CreationLocalTS" Type = "SqlTypes.SqlInt64"

Nullable = "False" />

<FieldProperty Name = "CreatingPartnerKey"

Type = "SqlTypes.SqlInt32" Nullable = "False" />

<FieldProperty Name = "CreatingPartnerTS"

Type = "SqlTypes.SqlInt64" Nullable = "False" />

<FieldProperty Name = "LastUpdateLocalTS"

Type = "SqlTypes.SqlInt64" Nullable = "False" />

<FieldProperty Name = "LastUpdatingPartnerKey"

Type = "SqlTypes.SqlInt32" Nullable = "False" />

<FieldProperty Name = "LastUpdatingPartnerTS" Type = "SqlTypes.SqlInt64"

Nullable = "False" />

</Type>

These properties contain the following information:

Column Description CreationLocalTS Local Machine Creation Timestamp _CreatingPartnerKey PartnerKey is the partner who created this entity. If the entity was created locally, then it represents the PartnerKey of the local machine. _CreatingPartnerTS The timestamp of the point in time at which this entity was created for the partner matching _CreatingPartnerKey. _LastUpdateLocalTS Local timestamp corresponding to the time point of the update on the local machine _LastUpdatingPartnerKey PartnerKey is the partner who last updated this entity. If the last entity update was performed locally, then it represents the PartnerKey of the local machine. _LastUpdatingPartnerTS The timestamp of the point in time at which this entity was updated with a partner matching _LastUpdatingPartnerKey.

(2) Tracking changes in typed search views

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

Column Type of Description <global change tracking> ... Information from global change tracking _ChangeUnitVersions MultiSet <ChangeUnitVersion> Description of version numbers of units of change in a specific item _ElementSyncMetadata ElementSyncMetadata Additional version-independent metadata about this subject that is of interest only for the duration of the Synchronization. _VersionSyncMetadata VersionSyncMetadata Additional version-specific metadata about this version that is of interest only for the duration of the Synchronization.

b) Monument objects

The data warehouse provides information about monument objects for Items, Extensions and Links. Representations of objects-monuments provide information about both existing entities and entities that are objects-monuments (objects, extensions and communications) in one place. Representations of objects-monuments of objects and extensions do not provide access to the corresponding object, while the representation of objects-monuments of connections provides access to the object of communication (the object of communication is NULL in the case of the connection, which is a monument object).

(1) Objects-monuments of objects

Monument items are retrieved from the system using the [System.Storage]. [Tombstone! Item] view.

Column Type of Description ItemId ItemId Item Identification _TypeID Typeid Item Type <Item Properties> ... Properties specific to all items _RootItemId ItemId ItemId of the first non-implementing item that contains this item. _ChangeTrackingInfo NLW Instance (CLR) of type ChangeTrackingInfo Change Tracking Information for this Item _IsDeleted Bit This is a flag that is 0 for active items, and 1 for items that are monument objects. _DeletionWallclock Utcatetime Local time Coordinated Universal Time (UTC), according to the partner who deleted the item. It is NULL if the Item is valid.

(2) Extension Monuments

Extension monument objects are retrieved from the system using the [System.Storage]. [Tombstone! Extension] view. Information on tracking changes to extensions is similar to that provided for Items with the addition of the ExtensionId property.

Column Type of Description ItemId ItemId Identification of the item that owns the Extension ExtensionId ExtensionId Extension ID Extensions _TypeID Typeid Extension type _ChangeTrackingInfo NLW Instance (CLR) of type ChangeTrackingInfo Change tracking information for this extension _IsDeleted Bit This is a flag that is 0 for active items and 1 for extensions that are monument objects _DeletionWallclock Utcatetime The time / date of local time of VKV according to the partner who deleted the extension. It is NULL if the extension is valid.

(3) Object-monument of communications

Connection memorabilia are retrieved from the system using the [System.Storage]. [Tombstone! Relationship] view. Information about objects-monuments of connections is similar to that provided for Extensions. However, additional information is provided on the ItemRef of the link instance target. In addition, a communication object is also selected.

Column Type of Description ItemId ItemId Identification of the Subject that owns the link (identification of the endpoint of the source of communication) RelationshipId RelationshipId RelationshipId Communication _TypeID Typeid Type of communication _ChangeTrackingInfo NLW Instance (CLR) of type ChangeTrackingInfo Change Tracking Information for this Link _IsDeleted Bit This is a flag that is 0 for active items and 1 for extensions that are monument objects _DeletionWallclock Utcatetime Time / date of local time of VKV in accordance with the partner who deleted the connection. It is NULL if the link is valid. _Relationship NJWS Instance (CLR) This is the communication object for the current communication. It is NULL for relationships that are monument objects. TargetItemReference ItemReference Target Endpoint Identification

(4) Cleaning of monuments

To prevent unlimited growth of information on monuments, the data warehouse provides for the task of cleaning monuments. This task determines when information on monuments can be discarded. The task calculates the boundary using the local version of creation / update and then truncates information on the monument objects by discarding all earlier versions of the monument objects.

11. API Helper and Functions

Basic mapping also provides a number of helper functions. These functions are provided to assist in performing common data model operations.

a) Function [System.Storage] .GetItem

Returns an Item object with this ItemId

//

Item GetItem (ItemId ItemId)

b) Function [System.Storage] .GetExtension

// Returns the extension object for the given ItemId and ExtensionId

//

Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId)

c) Function [System.Storage] .GetRelationship

// Returns the communication object for the given ItemId and RelationshipId

//

Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)

12. Metadata

There are two types of metadata presented in the Repository: instance metadata (Item type, etc.) and type metadata.

a) Schema metadata

Schema metadata is stored in the data warehouse as instances of the Item types from the Meta scheme.

b) Instance metadata

Instance metadata is used by the application to query the type of the Item and find the extensions associated with the Item. With this ItemId for the Item, the application can request a global representation of the item to return the type of the Item and use this value to request the presentation of Meta.Type to return information about the declared type of the Item. For example,

// Returns The Item object metadata for this instance of the Item

//

SELECT m._Item AS metadataInfoObj

FROM [System.Storage]. [Item] i INNER JOIN [Meta]. [Type] m ON i._TypeId = m.ItemId

WHERE i.ItemId = @ItemId

E. PROTECTION

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

1. Overview

According to the present embodiment, the degree of granularity with which the security policy of the storage platform is set and enforced is at the level of various operations on an item in the data warehouse; there is no way to provide protection for parts of an object separately from the whole. The security model defines a set of principals who can be granted access or denied access to perform these operations on the subject through access control lists (ACL's). Each ACL (ACL) is an ordered collection of access control records (ACEs).

The security policy for the subject can be fully described by the discretionary access control policy and the system access control policy. Each of them is a set of ACL's. The first set (discretionary access control list (DACL; DACL's) describes the discretionary access granted to various principals by the owner of the item, while the second set of ACL's is referred to as system access control lists (DRMS; SALC's), which specify how the system is audited when the object is manipulated in some way. In addition to them, each item in the data warehouse is associated with a security identifier (IDB; SID) that corresponds to the owner of the item (IDB; SID) of the Owner).

The primary mechanism for organizing items in the data warehouse of the storage platform is the inclusion hierarchy mechanism. The inclusion hierarchy is implemented using attachment relationships between objects. The attachment relationship between two items A and B, expressed as “A includes B,” allows item A to influence the lifetime of item B. Basically, an item in the data store cannot exist until there is an attachment link from another item to him. The attachment relationship, in addition to managing the lifetime of the item, provides the necessary mechanism for distributing security policies for the item.

The security policy set for each item consists of two parts - the part that is explicitly set for this item, and the part that is inherited from the parent of the item in the data warehouse. An explicitly defined security policy for any item consists of two parts - a part that controls access to the subject in question, and a part that affects the security policy inherited by all its descendants in the inclusion hierarchy. The security policy inherited by a descendant is a function of an explicitly defined policy and inherited policy.

Since the security policy is transmitted using attachment links and can also be replaced on any item, you must specify how the current security policy for the item is determined. In the present embodiment, an item in the data warehouse inclusion hierarchy inherits an ACL along each path from the storage root to the item.

In a legacy ACL, for any given path, the ordering of the various ACE's in the ACL determines the final security policy that is enforced. The following concept is used to describe the ordering of ACEs in an ACL. The ordering of the ACE in the ACL, which is inherited by the subject, is determined by the following two rules.

The first rule delaminates ACE's, inherited from various objects on the way to subject I from the root of the inclusion hierarchy. ACE's inherited from the nearest container take precedence over records inherited from the remote container. Intuitively, this provides the administrator with the ability to replace ACE's that inherit from more distant inclusion hierarchies. The rule is as follows:

For all L inherited ACL's in subject I

For all items I1, I2

For all ACE's A1 and A2 in L,

I1 is the precursor of I2, and

I2 is the precursor of I3, and

A1 is an itch (ACE) inherited from I1, and

A2 is an itch (ACE) inherited from I2,

means that

A2 precedes A1 in L

The second rule orders ACE's, which do not allow access to the subject, before ACE's, which provides access to the subject.

For all L inherited ACL's in subject I

For all items I1 '

For all ACE's A1 and A2 in L,

I1 is the precursor of I2 and,

A1 is ACCESS_DENIED_ACE inherited from I1, and

A2 is ACCESS_GRANTED_ACE inherited from I1,

means that

A1 precedes A2 in L

In the case where the inclusion hierarchy is a tree, there is exactly one path from the root of the tree to the item, and the item has exactly one inherited ACL. In such cases, the ACL inherited by the subject corresponds to the ACL inherited by the file (subject) in the existing Windows security model, based on the relative ordering of the ACE's in them.

However, the inclusion hierarchy in the data warehouse is a directed acyclic graph (OAG; DAG), since many attachment connections are allowed to objects. Under such conditions, there are many paths to the subject from the root of the inclusion hierarchy. Since an item inherits an ACL in each path, each item is associated with a collection of ACL's as opposed to a single one. It should be noted that this differs from the traditional file system model, where exactly one ACL is associated with a file or folder.

There are two aspects that need to be clarified when the inclusion hierarchy is DAG, as opposed to a tree. It requires a description of how the current security policy for an item is calculated when it inherits more than one ACL from its parents, and how they are organized and presented is directly related to the administration of the security model for the storage platform data warehouse.

The following algorithm evaluates the access rights for a given principal to a given subject. This document uses the following notation to describe ACL's associated with the subject.

Inherited_ACLs (ItemId) - a set of ACL's inherited by the item whose item identification is ItemId from their parents in the repository.

Explicit_ACL (ItemId) - COURT (ACL), explicitly defined for the item whose identification is ItemId.

NTSTATUS

ACLAccessCheck (

PSID pOwnerSid, PDACL pDacl, DWORD DesiredAccess, Handle ClientToken PPRIVILEGE_SET pPrivilegeSet, DWORD * pGrantedAccess)

The above routine returns STATUS_SUCCESS if the requested access was not explicitly denied, and pGrantedAccess determines which of the rights required by the user was granted by the specified ACL. If any required access was explicitly denied, the routine returns STATUS_ACCESS_DENIED.

NTSTATUS

WinFSItemAccessCheck (

WINFS_ITEMID ItemId, DWORD DesiredAccess, Handle ClientToken PPRIVILEGE_SET pPrivilegeSet)

{

NTSTATUS Status PDACL pExplicitACL = NULL; PDACL pInheritedACLs = NULL; DWORD NumberOfInheritedACLs = 0;

pExplicitACL = GetExplicitACLForItem (ItemId);

GetInheritedACLsForItem (ItemId, & pInheritedACLs, & NumberOfInheritedACLs)

Status = ACLAccessCheck (

pOwnerSid,

pExpficitACL,

DesiredAccess,

ClientToken

pPrivilegeSet,

&GrantedAccess);

if (Status! = STATUS_SUCCESS)

return Status;

if (DesiredAccess == GrantedAccess)

return STATUS SUCCESS;

for (

i = 0;

(i <NumberOfInheritedACLs && Status == STATUS_SUCCESS);

i ++) {

GrantedAccessForACL = 0;

Status = ACLAccessCheck (

pOwnerSid,

pExpficitACL,

DesiredAccess,

ClientToken

pPrivilegeSet,

&GrantedAccessForACL);

if (Status = STATUS_SUCCESS) {

GrantedAccess | = GrantedAccessForACL;

}

}

If ((Status == STATUS_SUCCESS) &&

(GrantedAccess! = DesiredAccess)) {

Status = STATUS_ACCESS_DENIED;

}

return Status;

}

The scope of the security policy defined on any item encompasses all descendants of the item in the inclusion hierarchy defined on the data warehouse. For all items where an explicit policy is defined, the inventors, in fact, define a policy that is inherited by all their descendants in the inclusion hierarchy. A valid ACL inherited by all descendants is obtained by taking each ACL inherited by the item and adding the inherited ACE's to the explicit ACL to the beginning of the ACL. This is referred to as a set of heritable ACL's associated with the subject.

In the absence of any explicit security specification in the inclusion hierarchy with a root in the subject of the folder, the folder protection specification applies to all descendants of this subject in the inclusion hierarchy. Thus, each item for which an explicit specification of the security policy is provided defines a zone of identically protected items, and valid ACL's for all items in the zone are a set of inherited ACL's for that item. This fully defines the zones in the case of the inclusion hierarchy, which is a tree. If each zone were to be associated with a number, then it would be sufficient to simply include the zone to which the object belongs, together with the object.

However, for inclusion hierarchies, which are DAG's, the points in the inclusion hierarchy at which the effective security policy changes are determined by two kinds of items. The first is items for which an explicit ACL has been set. Typically, these are points in the inclusion hierarchy where the administrator explicitly defined the ACL. The second is items that have more than one parent, and parents have different security policies associated with them. Typically, these are items that represent the merging points of the security policy defined for the volume and indicate the beginning of a new security policy.

With this definition, all items in the data warehouse belong to one of two categories - those that are the root of the identically protected security zone, and those that are not them. Items that do not define a security zone belong to exactly one security zone. As in the case of trees, the effective protection for an item can be set by specifying the zone to which the item belongs together with the item. This leads to a direct model of the storage platform data warehouse security administration based on different, identically protected areas in the warehouse.

2. Detailed description of the protection model

This section provides details on how items are protected by describing how individual rights in the Security Descriptor and the ACL's contained therein affect various operations.

a) Security descriptor structure

Before describing the details of a security model, an elementary description of security descriptors is useful. The security descriptor contains security information associated with the protected object. The security descriptor consists of the SECURITY_DESCRIPTOR structure and associated security information. The security descriptor may include the following security information:

1. IDB (SID's) for the owner and primary group of the object.

2. DUDL (DACL), which sets the access rights that are allowed or denied to specific users or groups.

3. DBMS (SACL), which defines the types of access attempts that generate audit records for an object.

4. A set of control bits that specify the meaning of the security descriptor or its individual members.

Preferably, applications cannot directly manipulate the contents of the security descriptor. There are functions for setting and retrieving security information in the object's security descriptor. In addition, there are functions for creating and initializing a security descriptor for a new object.

The Discretionary Access Control List (DACL) identifies guardians who are allowed or denied access to the protected object. When a process tries to access the protected object, the system checks the ACE's in the DACL of the object to determine whether to provide access to it. If the object does not have a DACL, the system provides full access to everyone. If the DACL of an object does not have an ACE's, the system prohibits all attempts to access the object, since the DACL does not provide any access rights. The system checks the ACE's sequentially until it detects one or more ACE's that provide all requested access rights, or until any of the requested access rights are denied.

The System Access Control List (SACL; SACL) enables administrators to record attempts to access a protected object. Each ACE defines the types of access attempts by a given guardian that cause the system to generate an event in the security log. The ACE in the SACL can generate audit records when an access attempt is unsuccessful, when it is successful, or both. The SACL can also give an alert when an unregistered user tries to access an object.

All types of ACEs contain the following access control information:

1. A security identifier (IDB; SID) that identifies the guardian to whom the ACE is applied.

2. An access mask that sets access rights controlled by an ACE.

3. A flag that indicates the type of itch (ACE).

4. A set of bit flags that determine whether child containers or objects can inherit an ACE from the primary object to which the ACL is attached.

The following table lists the three types of ACEs supported by all protected objects.

Type of Description Access Denial Itch Used by the DACL to deny access rights to a guardian. ACE with permission Used by the DACL to authorize the trustee with access rights. ACE Auditing System Used by the SACL to generate an audit record when the guardian attempts to use the specified permissions.

(1) Access mask format

All protected objects organize their access rights using the access mask format shown in FIG. In this format, the lower 16 bits are for access rights specific to the object, the next 7 bits are for standard access rights that apply to most types of objects, and the 4 high bits are used to specify generalized access rights that each type of object can map to a set of standard and rights specific to the object. The ACCESS_SYSTEM_SECURITY bit corresponds to the SACL access right of the object.

(2) Generalized access rights

Generic rights are set in the 4 high-order bits of the mask. Each type of protected object maps these bits to a set of its standard and object-specific access rights. For example, a file object maps the GENERIC_READ bit to the standard READ_CONTROL and SYNCHRONIZE access rights and to the object-specific access rights FILE_READ_DATA, FILE_READ_EA and FILE_READ_ATTRIBUTES. Other types of objects map the GENERIC_READ bit to any set of permissions that is appropriate for this type of object.

Generic access rights can be used to specify the type of access required when opening an object handle. This is usually simpler than setting all the relevant standard and specific rights. The following table shows the constants defined for generic access rights.

Constant Generalized meaning GENERIC_ALL Read, write and execute access GENERIC_EXECUTE Execution Access GENERIC_READ Read access GENERIC_WRITE Write access

(3) Standard access rights

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

Constant Meaning DELETE The right to delete an object. READ_CONTROL The right to read information in the security descriptor of an object, not including information in a DBMS (SACL). SYNCHRONIZE The right to use the object for synchronization. This allows the thread to wait until the object is in a signal state. Some types of objects do not support this access right. WRITE_DAC The right to modify the DACS in the object security descriptor. WRITE_OWNER The right to change the owner in the object security descriptor.

b) Subject-specific rights

In the structure of the access mask of FIG. 26, the rights specific to the subject are placed in the section Rights specific to the object (the lower 16 bits). Since in the present embodiment, the storage platform discloses two sets of APIs for security administration — Win32 and the storage platform API (API), object-specific file system rights should be considered in order to motivate the development of object-specific storage platform rights.

(1) Object-specific file and directory rights

Consider the following table:

Referring to the table above, it should be noted that in file systems there are fundamental differences between files and directories, which is why the rights of files and directories overlap on the same bits. File systems define very granular rights, allowing applications to control the behavior of these objects. For example, they enable applications to distinguish between Attributes (FILE_READ / WRITE_ATTRIBUTES), Extended Attributes, and the DATA stream associated with the file.

The purpose of the storage platform security model of the present invention is to simplify the rights assignment model, therefore, applications working with data storage items (Contacts, Email messages, etc.) basically do not need to distinguish between attributes, advanced attributes and data streams, for example. However, granular Win32 rights are retained for files and folders, and access semantics are determined using the storage platform, so compatibility with Win32 applications can be ensured. This mapping is described with each item right specified below.

The following item rights are set with the associated valid operations. Win32 equivalent rights are also provided that support each of these item rights.

(2) WinFSItemRead

This right provides read access to all elements of the subject, including subjects related to the subject through embedded links. It also makes it possible to list items associated with this item using attachment links (also known as a list of directory files). It includes the names of items linked through link links. This right is mapped to:

File:

(FILE_READ_DATA | SYNCHRONIZE)

Folder:

(FILE_LIST_DIRECTORY | SYNCHRONIZE)

The semantics are such that a security application can install WinFSItemReadData and set the rights mask as a combination of the file rights specified above.

(3) WinFSItemReadAttributes

This right provides read access to the basic attributes of an Item in much the same way that file systems distinguish between basic attributes of a file and data streams. Preferably, these basic attributes are those that are constantly in the base item from which all items are derived. This right is mapped to:

File:

(FILE_READ_ATTRIBUTES)

Folder:

(FILE_READ_ATTRIBUTES)

(4) WinFSItemWriteAttributes

This right provides write access to the basic attributes of an Item in much the same way that file systems distinguish between basic attributes of a file and data streams. Preferably, these basic attributes are constantly 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 provides the ability to record in all elements of the subject, including items related through embedded links. This right also provides the ability to add or remove embedded links to other items. This right is mapped to:

File:

(FILE_WRITE_DATA)

Folder:

(FILE_ADD_FILE)

In the data warehouse of the storage platform, there is no distinction between objects and folders, since objects can also have Attachment Links to other objects in the data warehouse. Therefore, if you have FILE_ADD_SUBDIRECTORY (or FILE_APPEND_DATA) rights, you may have an item that is the source of Links to other items.

(6) WinFSItemAddLink

This right provides the ability to add attachment links to items in storage. It should be noted that, since the security model for many Attachment Links changes the protection of the item and changes can bypass WRITE_DAC if they come from a point with a higher position in the hierarchy, WRITE_DAC is required on the destination to be able to create a Link to it. This right is mapped to:

File:

(FILE_APPEND_DATA)

Folder:

(FILE_ADD_SUBDIRECTORY)

(7) WinFSItemDeleteLink

This right provides the ability to remove attachment to an item, even if the principal is not granted the right to remove this item. This is consistent with the file system model and contributes to cleanup. This right is mapped to:

File:

(FILE_DELETE_CHILD) - Note that file systems do not have a file equivalent for this right, but inventors have such a concept about objects that have Attachments to others, and therefore they transfer this right also to non-folders.

Folder:

(FILE_DELETE_CHILD)

(8) Rights to delete an item

The item becomes deleted if the last Link of attachment to the item disappears. There is no explicit concept of deleting an item. There is a cleaning operation that removes all Attachment Links to an item, but this is a higher level opportunity and is not a primitive of the system.

Any item specified using the path can be disconnected if either of two conditions is satisfied: (1) the parent item on this path provides write access to the subject, or (2) standard rights to the item itself are granted by DELETE. When the last Link is deleted, the item is removed from the system. Any item specified using the ItemID can be disconnected if standard rights to the item itself are granted by DELETE.

(9) Copying Rights

An item can be copied from the source to the destination folder if the subject is provided with WinFSItemRead on the item and WinFSItemWrite on the destination folder.

(10) Rights to move an item

Moving a file in the file system requires only DELETE rights to the source file and FILE_ADD_FILE to the destination directory, since it saves the ACL to the destination. However, the flag can be set in a call to MoveFileEx (MOVEFILE_COPY_ALLOWED), which allows the application to specify that if it moves between volumes, it can allow CopyFile semantics. There are 4 potential options for what happens with a security descriptor when moving:

1. Carries the entire ACL with the file — the default semantics of movement within the volume.

2. Carries the entire ACL with the file and marks the ACL as protected.

3. Carries only explicit ACEs and re-inherits at destination.

4. Does not transfer anything and re-inherits at the destination - the semantics of moving between volumes by default - as when copying a file.

In the present protection model, if the application sets the MOVEFILE_COPY_ALLOWED flag, the fourth option is performed for cases both between volumes and inside the volume. If this flag is not set, the second option is executed, unless the destination is also the same security zone (i.e., the same inheritance semantics). Moving at the storage platform level also implements the fourth option and requires READ_DATA to the source in much the same way as it would when copying.

(11) Rights to view security (protection) policies for

The subject protection can be viewed if the subject grants the standard READ_CONTROL right to the subject.

(12) Subject to change of security policy

The protection of the subject can be changed if the subject grants the standard WRITE_DAC right to the subject. However, since the data warehouse provides implicit inheritance, this has implications on how security can vary across hierarchies. The rule is that if the root of the hierarchy provides WRITE_DAC, then the security policy changes throughout the hierarchy, regardless of the fact that specific items within the hierarchy (or OAS; DAG) do not provide WRITE_DAC to the subject.

(13) Rights that do not have a direct equivalent

In the present embodiment, FILE_EXECUTE (FILE_TRAVERSE for directories) do not have a direct equivalent in the storage platform. The model saves them for compatibility with Win32, but does not have any access decisions made for items based on these rights. As for FILE_READ / WRITE_EA, since the data warehouse items do not have a concept of extended attributes, there is no semantics for this bit. However, the bit remains for compatibility with Win32.

3. Implementation

All items that define identically protected areas have an entry associated with them in the protection table. The protection table is defined as follows:

Item Identification Item Ordpath Explicit COURT (ACL) of Items COURT (ACL's) ways COURT (ACL's) zone

The Item Identification entry is the Identification of the Root Item of an identically protected security zone. An Ordpath Entry entry is an ordpath associated with the root of an identically protected security zone. The Explicit COURT (ACL) Entry entry is an explicit ACL defined for the root of an identically protected security zone. In some cases, it can be NULL, for example, when a new security zone is defined, since the item has many parents belonging to different zones. The ACL's Path Record is a set of ACL's inherited by the subject, and the Zone ACL's Record is a set of ACL's defined for the identically protected security zone associated with the subject.

The calculation of the effective protection for any item in this repository strengthens this table. To determine the security policy associated with the item, obtain the security zone associated with the item and retrieve the ACL's associated with that zone.

Since the security policy associated with the subject is changed either by directly adding explicit ACL's, or by indirectly adding attachment links that lead to the creation of new security zones, the protection table is maintained with data updates to ensure that the above algorithm is valid for determining the effective protection of the subject.

Various changes to the repository and the accompanying algorithms for maintaining the security table are as follows:

a) Creating a new item in the container

When an item is re-created in the container, it inherits all ACL's associated with the container. Since the newly created item has only one parent, it belongs to the same zone as its parent. Thus, there is no need to create a new entry in the protection table.

b) Adding an explicit ACL to the subject

When an ACL is added to an item, it defines a new security zone for all its descendants in the inclusion hierarchy, which belongs to the same security zone as the given item. For all items that belong to other security zones but are descendants of the given item in the inclusion hierarchy, the security zone remains unchanged, but the current ACL associated with the zone changes to reflect the addition of a new ACL.

The introduction of this new security zone may trigger additional zone definitions for all items that have multiple attachment links with predecessors that cover the old security zone and the newly defined security zone. For all such items, you must define a new security zone and repeat the procedure.

27 (a), (b) and (c) depict a new identically protected security zone cut out of an existing security zone by introducing a new explicit ACL. This is indicated by the node designated 2. However, the introduction of this new zone leads to an additional zone 3 created due to an object having a plurality of attachment bonds.

The following sequence of updates in the protection tables reflects the decomposition of identically protected security zones.

c) Adding an attachment link to an item

When an Attachment Link is added to an item, this leads to one of three possibilities. If the purpose of the connection is attachment, i.e. the subject in question is the root of the security zone, the current ACL associated with the zone is changed, and no additional modifications to the protection table are required. If the security zone of the source of the new Attachment Link is identical to the security zone of the existing parents of the item, no change is required. However, if the item now has parents who belong to different security zones, then a new security zone is formed with this item as the root of the security zone. This change applies to all items in the inclusion hierarchy by modifying the security zone associated with the item. All items that belong to the same security zone as the item in question and their descendants in the inclusion hierarchy must be changed. If a change is made, all items that have multiple Attachment Links should be examined to determine if additional changes are required. Additional changes may be required if any of these items has parents of different security zones.

d) Removing an attachment link from an item

When the Attachment Link is removed from the item, you can collapse the security zone to the zone of its parents if certain conditions are met. More specifically, this can be accomplished under the following conditions: (1) if the deletion of the Attachment Link results in an item that has one parent and an explicit ACL is not specified for that item; (2) if the deletion of the Attachment Link results in an item whose parents are all in the same security zone and an explicit ACL is not defined for that item. Under such conditions, the safety zone may be marked as being the same as the parent. This mark should be applied to all items whose safety zone corresponds to the collapsible zone.

f) Removing an explicit ACL from an item

When an explicit ACL is removed from the item, you can collapse the security zone with the root in that item to the zone of its parents. More specifically, this can be accomplished if the removal of an explicit ACL results in an item whose parents in the inclusion hierarchy belong to the same security zone. Under such conditions, the safety zone may be marked as being the same as the parent, and the change applies to all items whose safety zone corresponds to the collapsible zone.

f) Modification of the ACL associated with the subject

In this scenario, no new additions to the protection table are required. The current ACL associated with the zone is updated, and a new ACL change extends to the security zones that it affects.

F. NOTIFICATIONS AND TRACKING OF CHANGES

According to another aspect of the present invention, the storage platform provides notification capability, which enables applications to track data changes. This feature is primarily intended for applications that support a changing state or execute business logic on data change events. Applications register item notifications, item extensions, and item communications. Notifications are delivered asynchronously after committing data changes. Applications can filter notifications by type of subject, extension and communication, as well as type of operation.

According to one embodiment, the storage platform API 322 provides two kinds of notification interfaces. First, applications record simple data change events triggered by changes in items, item extensions, and item relationships. Secondly, applications create objects of "observers" to control sets of objects, extensions of objects and relations between objects. The state of the observer object can be saved and re-created after a system failure or after the system goes offline for an extended period of time. A single notification may reflect many updates.

1. Storage change events

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

a) Events

Item, ItemExtension and ItemRelationship disclose data change events that are used by applications to register data change notifications. The following code sample shows the definition of the ItemModified and ItemRemoved event handlers for the base class Item.

//Developments

public event ItemModifiedEventHandler Item_ItemModified ;

public event ItemRemovedEventHandler Item_ItemRemoved ;

All notifications carry enough data to retrieve a modified item from the data store. The following code sample shows how to log events on an Item, ItemExtension or ItemRelationship:

myItem.ItemModified + = new ItemModifiedEventHandler (this.onItemUpdate);

myItem.ItemRemoved + = new ItemRemovedEventHandler (this.onItemDelete);

In the present embodiment, the storage platform ensures that the applications will be notified if the corresponding item has been modified or deleted since the last delivery of the notification or in the case of a new registration since the last retrieval from the data store.

b) Observers

In the present embodiment, the storage platform defines observer classes for controlling objects associated with (1) a folder or folder hierarchy, (2) the context of an item, or (3) a specific item. For each of the three categories, the storage platform provides specific observer classes that control associated objects, item extensions, or item relationships, for example, the storage platform provides the corresponding classes FolderItemWatcher, FolderRelationshipWatcher and FolderExtensionWatcher.

When creating an observer, an application may request notifications of pre-existing items, i.e. items, extensions, or links. This option is mainly for applications that accompany a closed item cache. If not requested, applications receive notifications of all updates that occur after the observer object has been created.

Along with the delivery of notifications, the storage platform provides the WatcherState object. WatcherState can be serialized and saved to disk. The state of the observer can subsequently be used to re-create the corresponding observer after a failure or when reconnecting after going offline. The newly re-created observer will re-generate unconfirmed notifications. Applications indicate the delivery of a notification by calling the “Exclude” method to the corresponding state of the observer by submitting a link to the notification.

The storage platform delivers separate copies of the observer state to each event handler. Observer states received on subsequent calls to the same event handler assume delivery of all previously received notifications.

As an example, the following code sample shows the definition of a FolderItemWatcher.

The following code sample shows how to create a folder watcher object to control the contents of a folder. The observer generates notifications, i.e. events when new musical items are added or existing musical items are updated or deleted. Folder watchers control either a specific folder or all folders in a folder hierarchy.

2. Change tracking and notification mechanism

The storage platform provides a simple, yet effective mechanism for tracking data changes and generating notifications. The client retrieves notifications on the same connection as that used to retrieve the data. This greatly simplifies security (protection) system checks, eliminates delays and restrictions on possible network configurations. Notifications are retrieved by calling select statements. To prevent polling, clients can use the waitfor feature provided by the database processor 314. Fig depicts the basic principle of notifications storage platform. This waitfor request can be executed synchronously, in which case the calling thread is blocked until the results are available, or asynchronously, in this case the thread is not blocked, and the results are returned on a separate thread when available.

The combination of “waitfor” and “select” is attractive for controlling data changes that fall within a specific data range, since changes can be controlled by setting notification blocking on the corresponding data range. This is true for many common storage platform scenarios. Changes to individual items can be effectively controlled by setting notification locks on the appropriate data range. Changes to folders and folder trees can be controlled by setting notification locks on path ranges. Changes to types and their subtypes can be controlled by setting notification locks on type ranges.

In general terms, there are three distinct phases associated with the processing of notifications: (1) changing or even detecting data, (2) matching subscriptions and (3) delivery of notifications. Excluding synchronous delivery of notifications, i.e. notification delivery as part of a data change transaction, the storage platform can implement two forms of notification delivery:

1) Immediate event detection : Event detection and subscription matching is performed as part of the update transaction. Notifications are inserted into the table controlled by the subscriber; and

2) Delayed event detection : Event detection and subscription matching is performed after committing the update transaction. Subsequently, the actual subscriber or intermediary detects events and generates notifications.

Immediate event detection requires the execution of additional code as part of update operations. This allows you to collect data from all events of interest, including events that indicate a change in relative state.

Deferred event detection eliminates the need to add additional code to update operations. Event detection is performed by the final subscriber. Deferred event detection naturally groups event detection and event delivery and is well suited to the query execution infrastructure of database processor 314 (e.g., SQL Server).

Deferred event detection is based on recording or recording left by update operations. The storage platform supports a set of logical timestamps along with memorial objects for deleted data items. When scanning the data warehouse for changes, clients provide a timestamp that defines the lowest limit for detecting changes, and a set of timestamps to prevent duplicate notifications. Applications can receive notifications for all changes that occur after a point in time indicated by a lower limit.

Sophisticated applications with access to basic views can further optimize and reduce the number of SQL statements (SQL) needed to control a potentially large set of items by creating tables of closed parameters and a duplicate filter. Applications with special needs, such as those that must support rich presentation capabilities, can use the available integrated change tracking environment to monitor data changes and regenerate their private (private) snapshots.

It is therefore preferred that, in one embodiment, the storage platform implements a pending event detection approach, which is described in more detail below.

a) Change tracking

All definitions of items, extensions, and item relationships have a unique identifier. Change tracking accompanies a set of logical timestamps for recording the creation, update, and deletion times for all data items. Records of monument objects are used to represent deleted data objects.

Applications use this information to effectively control whether a particular item, item extension, or item link has been added, updated, or deleted since the application last accessed the data store. The following example illustrates this mechanism.

All deleted items, item extensions and communications are recorded in the corresponding table of monuments. The template is shown below.

For performance reasons, the storage platform supports a set of global tables for items, item extensions, links, and path names. These global lookup tables can be used by applications to effectively control data ranges and retrieve associated timestamp and type information.

b) Time stamp management

Logical timestamps are "local" to the database store, i.e. storage platform volumes. Timestamps are monotonically increasing 64-bit values. Saving a single label is often sufficient to detect whether a data change has occurred since the last connection to the storage platform volume. However, in more realistic scenarios, you need to save a few more timestamps to check for duplication. The reasons are explained below.

Relational database tables are logical abstractions built on top of a set of physical data structures, i.e. In-trees, heaps, etc. Assigning a timestamp to a newly created or updated record is not an elementary action. Inserting this record into the underlying data structures can occur at different points in time, so applications may consider the records to be faulty.

Fig. 14 depicts two transactions, both of which insert a new record into the same B-tree. Since transaction T3 inserts its record before it is scheduled to be inserted by transaction T2, the application scanning the B-tree can see the records inserted by transaction T3 before the records inserted by transaction T2. Thus, the reader may incorrectly assume that he saw all the records created before the time point “10”. To solve this issue, the database processor 314 provides a function that returns the lowest limit to which all updates have been completed and inserted into the corresponding underlying data structures. In the above example, the return low would be “5”, assuming the reader started before transaction T2 was completed. The lower limit provided by the database processor 314 enables applications to efficiently determine which items to ignore when scanning a database or data range for data changes. In general, it is assumed that transactions of atomicity, consistency, isolation, reliability (ANIN; ACID) thus last a very short time, the lower limits are expected to be very close to the most recent distributed timestamps. In the presence of long-running transactions, applications must retain individual timestamps to detect and discard duplicates.

c) Data change detection - event detection

When querying the data store, applications receive a lower limit. Subsequently, applications use this limit to scan the data warehouse for records whose timestamp for creating, updating, or deleting is longer than the returned lower limit. 15 illustrates this process.

To prevent duplicate notifications, applications remember timestamps that are larger than the returned low limit and use them to filter duplicates. Applications create local temporary session tables for efficiently handling a large set of duplicate timestamps. Before issuing a select statement, the application inserts all previously returned duplicate timestamps and deletes those older than the last returned lower limit, as shown below.

G. SYNCHRONIZATION

According to another aspect of the present invention, the storage platform provides a synchronization service 330 that (i) enables multiple instances of the storage platform (each with its own data store 302) to synchronize parts of its content in accordance with a flexible set of rules, and (ii) provides infrastructure for third parties to synchronize the data warehouse storage platform of the present invention with other data sources that implement specific protocols.

Storage platform synchronization with the storage platform occurs among a group of participating replicas. For example, with reference to FIG. 3, it may be desirable to provide synchronization between the data store 302 of the storage platform 300 with another remote data store 338 under the control of another instance of the storage platform, possibly running on a different computer system. The total number of members in this group is not necessarily known for any given replica at any given time.

Different replicas can make changes independently (i.e. at the same time). The synchronization process is defined as providing information to each replica about changes made by other replicas. This synchronization feature, in fact, is with many leading.

The ability to synchronize the present invention enables replicas:

- determine what changes are known to another replica;

- request information about changes that are not known to this replica;

- transmit information about changes that are not known to another replica;

- determine when two changes are in conflict with each other;

- apply the changes locally;

- transfer conflict resolution to other replicas to guarantee merging; and

- resolve conflicts based on predefined policies for resolving conflicts.

1. Synchronize the storage platform with the storage platform

The main application of the storage platform synchronization service 330 of the present invention is the synchronization of multiple instances of the storage platform (each with its own data store). The synchronization service operates at the level of storage platform schemas (rather than the underlying tables of the database processor 314). Thus, for example, “Scopes” are used to define synchronization sets, as described below.

The synchronization service works on the principle of "clean change." Instead of recording and sending individual operations (such as transactional replication), the synchronization service sends the final result of these operations, thus often combining the results of many operations into a single resultant change.

The synchronization service basically does not recognize transaction boundaries. In other words, if two changes are made to the storage platform data warehouse in one transaction, there is no guarantee that these changes will be applied to all other replicas atomically - one can be shown without the other. An exception to this principle is that if two changes are made in the same Item in the same transaction, then it is guaranteed that these changes will be sent and applied to other replicas atomically. Thus, Items represent the units of consistency of the synchronization service.

a) Synchronization management applications

Any application can connect to the synchronization service and initiate the synchronization operation. Such an application provides all the parameters necessary for synchronization (see the synchronization profile below). Such applications are referred to herein as Synchronization Management Applications (ASNs; SCAs).

When two instances of the storage platform are synchronized, synchronization is initiated on one side through the SCA. This SCA informs the local synchronization service of synchronization with the remote partner. On the other hand, the synchronization service is driven by messages sent by the synchronization service from the source machine. She responds based on long-term configuration information (see mappings below) present on the destination machine. The synchronization service can run as scheduled or in response to events. In these cases, the synchronization service that implements the schedule becomes the SCA.

To activate synchronization, two steps must be completed. First, the schema designer must annotate the storage platform schema with the appropriate synchronization semantics (denoting Change Units, as described below). Secondly, synchronization must be configured correctly on all machines that have a storage platform instance that must participate in synchronization (as described below).

b) Annotating circuits

The fundamental concept of synchronization service is the concept of Unit of Change. Unit of Change is the smallest part of a schema that is individually tracked by the storage platform. For each Unit of Change, the synchronization service can determine whether it has changed or has not changed since the last synchronization.

The designation of Units of Change in the scheme serves several purposes. First, it determines how often the synchronization service sends messages. When a change is made inside the Change Unit, the entire Change Unit is sent to other replicas, because the synchronization service does not know which part of the Change Unit has been changed. Secondly, it determines the granularity of conflict detection. When two simultaneous changes (these terms are defined in detail in the following sections) are performed in one change unit, the synchronization service establishes a conflict; on the other hand, if simultaneous changes are made in different units of change, then no conflict is established and the changes are automatically combined. Thirdly, it has a strong influence on the amount of metadata stored by the system. Most synchronization service metadata is stored on a Unit of Change basis; thus, making Change Units smaller increases synchronization overhead.

Determining Units of Change requires finding the right compromises. For this reason, the synchronization service enables circuit designers to participate in the process.

In one embodiment, the synchronization service does not support Change Units that are larger than the item. However, it does support the ability to define change units that are smaller than an element, namely grouping the set of element attributes into a separate Unit of Change. In this embodiment, this is done using the following syntax:

c) Sync configuration

A group of storage platform partners who wish to keep some parts of their data synchronous are referred to as a synchronization community. When community members want to stay in sync, they don't have to present the data in exactly the same way; in other words, synchronization partners can transform the data that they synchronize.

In a peer-to-peer interaction scenario, it is not possible for peer systems to support transform mappings for all their partners. Instead, the synchronization service takes the approach of defining "Community Folders." A community folder is an abstraction that represents a hypothetical “shared folder” with which all community members synchronize.

This concept is best illustrated with an example. If Joe wants to keep the My Documents folders of his multiple computers in sync, Joe defines a community folder called, say, JoesDocuments. Then, on each computer, Joe configures the mapping between the hypothetical JoesDocuments folder and the local My Documents folder. From now on, when Joe's computers are synchronized with each other, they communicate in the document language in JoesDocuments, rather than their local objects. Thus, all of Joe’s computers understand each other without having to know who the others are — the Community Folder becomes the lingua franca (common language) of the synchronization community.

Configuring the synchronization service consists of three steps: (1) defining mappings between local folders and community folders; (2) definitions of synchronization profiles that determine what is synchronized (for example, with whom to synchronize and which subsets should be sent and which ones should be received); and (3) defining schedules for which various synchronization profiles should be executed or executed manually.

(1) Community Folder - Mappings

Community Folder mappings are stored as RNR (XML) configuration files on individual machines. Each mapping has the following schemes:

/ mappings / communityFolder

This element refers to the community folder for which this mapping is intended. The name adheres to Folder syntax rules.

/ mappings / localFolder

This item refers to the local folder into which the mapping is converted. The name adheres to Folder syntax rules. The folder must already exist for the display to be valid. Items in this folder are considered to synchronize to this display.

/ mappings / transformations

This element defines how to convert items from the community folder to the local folder and vice versa. If absent or empty, no conversion is performed. In particular, this means that no IDs are displayed. This configuration is mainly used to create the Mailbox cache.

/ mappings / transformations / mapIDs

This element requests that the newly generated local IDs (IDs) be assigned to all items displayed from the community folder, rather than reusing the community IDs. The synchronization execution period saves the display of IDs for converting items back and forth.

/ mappings / transformations / localRoot

This member requests that all root items in the community folder be made children of the given root.

/ mappings / runAs

This element controls under whose authority requests are processed regarding this mapping. If absent, the sender is assumed.

/ mappings / runAs / sender

The presence of this element indicates that the message sender should be simulated for this display, and requests should be processed under its access parameters.

(2) Profiles

A synchronization profile is a complete set of parameters needed to start synchronization. It is delivered via a SCA to the Synchronization Run Period to initiate synchronization. The synchronization profiles for synchronizing the storage platform with the storage platform contain the following information:

- Local Folder serving as a source and destination for changes;

- The name of the Remote Folder to synchronize with it - this Folder must be published from the remote partner by means of display, as defined above;

- Direction - the synchronization service supports synchronization only in send mode, only in receive mode and in send-receive mode;

- Local Filter - selects what local information to send to the remote partner. Expressed as a storage platform request for a local folder;

- Remote Filter - selects what remote information to retrieve from a remote partner - expressed as a request to the storage platform for the community folder;

- Transformations - determine how to convert objects to and from the local format;

- Local protection - defines whether the changes extracted from the remote endpoint should be applied at the permissions of the remote endpoint (simulated) or the user initiating synchronization locally; and

- Conflict resolution policy - sets whether conflicts should be rejected, registered, or automatically resolved - in the latter case, it determines which conflict resolution mechanism to use, as well as configuration parameters for it.

The Synchronization Service provides the CLR class of the execution period, which allows you to easily build Synchronization Profiles. Profiles can also be serialized to and from RPN files (XML) for easy storage (often along with schedules). However, there is no standard place in the storage platform where all profiles are stored; CCP (SCAs) have the right to create a profile in place even without ensuring its permanence. It should be noted that there is no need to have a local mapping to initiate synchronization. All synchronization information can be set in the profile. The mapping, however, is required in order to respond to synchronization requests initiated by the remote side.

(3) Schedules

In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, it is based on the fact that another component performs this task - the Windows Scheduler, which is available in the Microsoft Windows operating system. The synchronization service includes a command-line utility that acts as a SCA and starts synchronization based on the synchronization profile stored in the .pnr (XML) file. This utility makes it very easy to configure the Windows Scheduler to synchronize, either on schedule or in response to events such as a user logging in or logging out of the system.

d) Conflict handling

Conflict handling in the synchronization service is divided into three stages: (1) conflict detection that occurs at the time the changes are applied — this stage determines whether the change can be safely applied; (2) automatic resolution and registration of conflicts - during this stage (which occurs immediately after the conflict is detected), they turn to the means of automatic conflict resolution to find out whether a conflict can be resolved - if not, the conflict can be optionally registered; and (3) inspection and resolution of conflicts - this stage takes place if some conflicts have been recorded, and occurs outside the context of the synchronization session - at this point in time, registered conflicts can be resolved and deleted from the log.

(1) Conflict Detection

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

(a) Information-based conflicts

Information-based conflicts occur when two replicas make independent changes in the same Unit of Change. Two changes are called independent if they are performed without information about each other, in other words, the version of the first is not covered by information about the second, and vice versa. The synchronization service automatically detects all such conflicts based on replica information, as described above.

It is sometimes useful to consider conflicts as branching in the history of versions of a unit of change. If there are no conflicts during the existence of a unit of change, its history of versions is a simple chain - each change occurs after the previous one. In the case of information-based conflicts, two changes occur in parallel, causing the chain to split, and it becomes a version tree.

(b) Restriction-based conflicts

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

A constraint-based conflict involves two independent changes (similar to a knowledge-based conflict), but they do not affect the same unit of change. Rather, they affect different units of change, but with the constraint that exists between them.

The synchronization service detects constraint violations at the time the changes are applied and automatically establishes constraint-based conflicts. Resolving constraint-based conflicts usually requires a user-configurable part of the program that modifies the changes so as not to violate the constraint. The synchronization service does not provide a general purpose mechanism to accomplish this.

(2) Conflict Handling

When a conflict is detected, the synchronization service can take one of three actions (selected by the initiator of synchronization in the Synchronization Profile): (1) reject the change, returning it to the sender; (2) register the conflict in the conflict log; or (3) automatically resolve the conflict.

If the change is rejected, the synchronization service acts as if the change did not arrive at the replica. Non-acknowledgment is sent back to the initiator. This resolution policy is mainly useful on stand-alone replicas (such as file servers) where conflict logging is not allowed. Instead, such cues make others deal with conflicts by rejecting them.

Sync initiators configure conflict resolution in their Synchronization Profiles. The synchronization service supports combining multiple conflict resolution tools in one profile as follows: firstly, by defining a list of conflict resolution tools to test one by one until one of them succeeds; and secondly, by associating conflict resolution tools with conflict types, for example, directing conflict-based update-update information to a single resolution tool, but all other conflicts to registration.

(a) Automatic conflict resolution

Synchronization provides a number of default conflict resolution tools. This list includes:

- local wins: ignore incoming changes if they are in conflict with locally stored data;

- remote wins: ignore local data if they are in conflict with incoming changes;

- wins of the last author: the choice of either local wins or remote wins per unit of change, based on the time stamp of the change (note that the synchronization service does not rely mainly on clock values; this means of resolving conflicts is the only exception to this rule);

- deterministic: the choice of the winner so as to ensure that it is the same on all replicas, but not meaningful in other respects - one embodiment of the implementation of synchronization services uses lexicographic comparisons of partner IDs to implement this feature.

In addition, an NPV (ISV) can implement and install its own conflict resolution tools. Specialized conflict resolution tools can accept configuration parameters; such parameters should be set via the SCA in the Conflict Resolution section of the Synchronization Profile.

When a conflict resolver handles a conflict, it returns a list of operations that should be performed (instead of a conflicting change) back to the production environment. The synchronization service then applies these operations that have correctly adjusted remote information to include what the conflict handler took into account.

It is possible that another conflict is detected when applying the resolution. In this case, a new conflict must be resolved before resuming initial processing.

When considering conflicts as branches in the history of versions of the subject of conflict resolution, they can be considered as compounds that combine two branches to form one point. In this way, conflict resolution turns version histories into DAGs.

(b) Conflict Records

A very private type of conflict resolution mechanism is the Conflict Recorder. The Synchronization Service registers conflicts as Items of type ConflictRecord. These records refer back to items that are in conflict (unless the items themselves have been deleted). Each conflict record contains an incoming change that caused the conflict; type of conflict: update-update, update-delete, delete-update, insert-insert or restriction; and the version of the incoming change and the details of the replica sending it. Reported conflicts are available for inspection and resolution, as described below.

(c) Inspection and resolution of conflicts

The synchronization service provides an API (API) for applications to check the conflict log and offer conflict resolution in it. API (API) enables the application to list all conflicts or conflicts related to this Item. It also enables such applications to resolve recorded conflicts in one of three ways: (1) remote wins — accepting the registered change and overwriting the conflicting local change; (2) local wins - ignoring the conflicting parts of the registered change; and (3) propose a new change - where the application offers a pool that, in its opinion, resolves the conflict. If conflicts are resolved by the application, the synchronization service removes them from the log.

(d) Merging replicas and distributing conflict resolution

In complex synchronization scenarios, the same conflict can be detected on multiple replicas. If this happens, the following things can happen: (1) a conflict can be resolved on one replica, and a resolution can be sent on another; (2) the conflict is automatically resolved on both replicas; or (3) the conflict is resolved manually on both replicas (through the Conflict Inspection API).

To ensure merging, the synchronization service routes conflict resolution to other replicas. When a change that resolves the conflict arrives at the replica, the synchronization service automatically finds any conflict entries in the log that are resolved by this update and eliminates them. In this sense, conflict resolution on one replica is linked across all other replicas.

If other winners are selected through different replicas for the same conflict, the synchronization service applies the principle of binding conflict resolution and selects one of two resolutions to automatically win relative to the other. The winner is selected in a deterministic manner that is guaranteed to give the same results at any time (one embodiment uses lexicographic comparisons of replica IDs).

If different “new changes” are offered by different replicas for the same conflict, the synchronization service considers this new conflict as a special conflict and uses the Conflict Recorder to prevent it from spreading to other replicas. This situation usually occurs when manually resolving conflicts.

2. Synchronization with data warehouses of non-storage platforms

According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for NPVs (ISVs) to implement Synchronization Adapters, which enable the storage platform to synchronize with legacy systems such as Microsoft Exchange, AD (Active Directory), Hotmail, and others. Synchronization Adapters have advantages over the many Synchronization Services provided by the synchronization service, as described below.

Despite the name, there is no need to implement Sync Adapters as additional software modules for some storage platform architecture. If required, the “synchronization adapter” simply can be any application that uses the synchronization service workspace interfaces to receive services, such as enumerating and applying changes.

To make it easier for others to configure and perform synchronization for this database machine, the developers of the Sync Adapter support the disclosure of the standard interface of the Sync Adapter, which performs synchronization with the Sync Profile as described above. The profile provides configuration information for the adapter, some of which the adapters pass to the Synchronization Environment to manage the services of the environment (for example, Folders for synchronization).

a) Sync services

The synchronization service provides a number of synchronization services for adapter compilers. In the rest of this section, it is convenient to refer to the machine on which the storage platform synchronizes as a “client”, and the database machine is not a storage platform with which the adapter communicates as a “server”.

(1) Listing Changes

Based on the change tracking data supported by the synchronization service, Change Enumeration enables synchronization adapters to easily list the changes that have occurred in the Data Warehouse Folder since the last synchronization attempt was made with this partner.

Changes are listed based on the principle of the "anchor point" - an opaque structure that represents information about the latest synchronization. The binding takes the form of Information storage platform, as described in the previous sections. Sync adapters using change enumeration services fall into two broad categories: those that use “stored bindings” versus those that use “supplied bindings”.

The difference is based on where the information about the last synchronization is stored - on the client or on the server. It is often easier for adapters to store this information on the client — a database machine often cannot conveniently store this information. On the other hand, if many clients are synchronized with one database machine, storing this information on the client is inefficient and in some cases incorrect - this makes one client unaware of changes that another client has already pushed to the server. If the adapter wants to use the binding stored on the server, the adapter needs to submit it back to the storage platform at the time the changes are enumerated.

For the storage platform to support binding (either for local or remote storage), the storage platform must be provided with information about the changes that were successfully applied on the server. These and only these changes can be included in the binding. During enumeration of changes, Synchronization Adapters use the Acknowledgment interface to report which changes have been successfully applied. At the end of synchronization, adapters that use the supplied bindings must read the new binding (which includes all successfully applied changes) and send it to their database machine.

Often, adapters need to store adapter-specific data along with the items that they insert into the storage platform data warehouse. Common examples of such data are remote IDs and remote versions (timestamps). The synchronization service provides a mechanism for storing this data, and Enumeration of Changes provides a mechanism for receiving this additional data along with the returned changes. This in most cases eliminates the need for adapters to re-query the database.

(2) Application of changes

Applying Changes enables Sync Adapters to apply the changes received from their database machine to the local storage platform. The adapters are expected to translate the changes into a storage platform schema.

The main purpose of applying changes is automatic conflict detection. As in the case of synchronizing the storage platform with the storage platform, a conflict is defined as two overlapping changes that are performed without information about each other. When adapters use Apply Changes, they must specify the binding for which conflict is being detected. Applying Changes sets a conflict if an overlapping local change is detected that is not covered by the adapter. Like Change Enumeration, adapters can use either stored or supplied bindings. Applying Changes supports the efficient storage of adapter-specific metadata. Such data can be attached by the adapter to the applied changes and can be saved by the synchronization service. Data may be returned the next time the change is listed.

(3) Conflict Resolution

The Conflict Resolution Mechanisms described above (registration and automatic resolution options) are also available for synchronization adapters. Sync adapters can set policies to resolve conflicts when changes are applied. If specified, conflicts can be transmitted to the specified conflict handler and resolved (if possible). Conflicts can also be logged. It is possible that the adapter might detect a conflict when trying to apply a local change to the database machine. In this case, the adapter can still transmit the conflict to the Synchronization runtime for resolution in accordance with the policy. In addition, Synchronization Adapters may request that any conflicts detected by the synchronization service be sent back to them for processing. This is especially useful when the database machine can store or resolve conflicts.

b) adapter implementation

Although some “adapters” are simply applications that use runtime interfaces, adapters support standard adapter interfaces. These interfaces enable Synchronization Management Applications: to request that the adapter synchronize in accordance with this Synchronization Profile; cancel active synchronization; and receive a progress report (percent completion) of the active (current) synchronization.

3. Protection

The synchronization service tries to make the smallest possible in the security model implemented by the storage platform. How to define new rights for synchronization, existing rights are used. Specifically,

- anyone who can read the Data Warehouse Item can list the changes for this item;

- anyone who can write to a Data Warehouse Item can apply changes to this item; and

- anyone who can expand a Data Warehouse Item can associate synchronization metadata with this item.

Sync does not support copyright information. When a change is made to replica A by user U and sent to replica B, the fact that the change was originally made to A (or through U) is lost. If B directs this change to replica C, then it is done by B, not A. This leads to the following restriction: if the replica is not trusted to make its own changes to the item, it cannot direct the changes made by others.

When the synchronization service is initiated, it is executed by the Synchronization Management Application. The synchronization service imitates the identification of the CCP (SCA) and performs all operations (both local and remote) under this authentication. To illustrate, note that user U cannot initiate a local synchronization service pulling changes from a remote storage platform for items that user U does not have read access to.

4. Manageability

Controlling a distributed community of replicas is a complex issue. The synchronization service can use the “projection” algorithm to collect and distribute information about the state of replicas. The properties of the projection algorithm ensure that information about all configured replicas is ultimately collected and that corrupted (non-responding) replicas are detected.

This community monitoring information is made available on each replica. Monitoring tools can be run on a randomly selected replica to verify this monitoring information and make administrative decisions. Any configuration changes must be made directly to the affected replicas.

H. POSSIBILITY OF INTERACTION WITH TRADITIONAL FILE SYSTEMS

As mentioned above, the storage platform of the present invention, in at least some embodiments, is intended to be implemented as an integral part of the hardware / software interface system of a computer system. For example, the storage platform of the present invention can be implemented as an integral part of an operating system, such as the Microsoft Windows family of operating systems. With this capability, the storage platform API (API) becomes part of the operating system API (API) through which application programs interact with the operating system. Thus, the storage platform becomes the means by which application programs store information about the operating system, and the Item-based data model of the storage platform therefore replaces the traditional file system of such an operating system. For example, as implemented in the Microsoft Windows family of operating systems, the storage platform can replace the FSNT file system (NTFS) implemented in this operating system. Currently, application programs access the FSNT file system services (NTFS) using the Win32 APIs, which are exposed by the Windows operating system family.

Recognizing, however, that a complete replacement of the NTFS file system (NTFS) with the storage platform of the present invention would require recording existing Win32-based application programs, and such recording may be undesirable, it would be useful if the storage platform of the present invention provides some interoperability with existing file systems such as FSNT (NTFS). In one embodiment of the present invention, therefore, the storage platform enables application programs that rely on the Win32 programming model to access the contents of the storage of the storage platform data as well as the traditional NTFS file system. To this end, the storage platform uses a naming convention, which is a subset of Win32 naming conventions, to facilitate easy interoperability. Further, the storage platform supports accessing files and directories stored on the volume of the storage platform using the Win32 API.

1. A model for interoperability

According to this aspect of the present invention and according to the exemplary embodiment described above, the storage platform implements one namespace in which non-file and file objects can be organized. The following benefits are achieved with this model:

1. Folders in the data warehouse can contain both file and non-file objects, thus representing a single namespace for file and schematized data. In addition, it also provides a unified model of protection, sharing and administration for all user data.

2. Since both file and non-file objects are accessible using the storage platform API (API's) and there are no special rules for files in this approach, it represents a more error-free programming model for application developers to work with it.

3. All namespace operations go through the storage platform and, therefore, are processed synchronously. It is important to note that the strong distribution (promotion) of properties (separated from the contents of the file) still occurs asynchronously, but synchronous operations provide a much more predictable environment for users and applications.

As a result of this model, in the present embodiment, search capabilities may not be provided by data sources that do not migrate to the storage platform data warehouse. They include removable media, remote servers, and files on the local drive. A Sync Adapter is provided, which explicitly shows proxy items (shortcuts + distribution metadata) in the storage platform for items that reside on external file systems. Proxy objects do not try to simulate files either in the sense of the hierarchy of the data source namespace or in the sense of protection.

The symmetry achieved on the model of the namespace and programming between file and non-file content provides the best way for applications to migrate content over time from file systems to more structured objects in the storage platform data warehouse. By providing their own type of file objects in the storage platform data warehouse, application programs can move file data to the storage platform, while still having the ability to manipulate this data using Win32. In the end, application programs can completely migrate (migrate) to storage platform APIs and structure their data based on Storage platform Items, not files.

2. Data Warehouse Features

In order to provide the required level of interoperability, in one embodiment, the following features of the storage platform data warehouse are implemented.

a) Not that

The storage platform data warehouse is not disclosed as a separate file system volume. The storage platform at a new level uses FILESTREAMs directly hosted on the FSNT (NTFS). Thus, there is no change in format on the disk, thereby eliminating any need to expand the storage platform as a new file system at the volume level.

Instead, a data warehouse (namespace) is configured according to the FSST (NTFS) volume. The database and FILESTREAMs that support this part of the namespace are located on the FSNT volume (NTFS) with which the storage platform data warehouse is associated. A data repository corresponding to the system volume is also provided.

b) Storage structure

The storage structure is best illustrated by an example. Consider, as an example, the directory tree on the system volume of a machine called HomeMachine , as shown in FIG. In accordance with a feature of the present invention, the ability to interact with a file system corresponding to a drive with: \ has a storage platform data store disclosed for Win32 APIs using a shared resource of a universal naming convention (USI; UNC) named, for example, "WinFSOnC". This makes the associated data warehouse accessible through the following WSI name (UNC):

\\ HomeMachine \ WinFSOnC.

In this embodiment, the files and / or folders must explicitly migrate (migrate) from the FSNT (NTFS) to the storage platform. Therefore, if the user wants to move the My Document folder to the storage platform data warehouse so that he takes advantage of all the additional search / categorization features offered by the storage platform, the hierarchy will look as shown in Fig. 17. It is important to note that these folders actually move in this example. Another issue that should be noted is that the namespace is moved to the storage platform, the actual threads are renamed as FILESTREAMs with the corresponding pointers connected in the storage platform.

c) Not all files migrate

Files that match user data or that require the search / categorization that the storage platform provides are candidates for migration to the storage platform data warehouse. Preferably, in order to limit the compatibility of application programs with the storage platform, the set of files that migrate to the storage platform of the present invention, in the context of the Microsoft Windows operating system, is limited to the files in the MyDocuments folder, the Favorites folder in Internet Explorer (IE), the History folder in IE and .ini files in Desktop in the Documents and Settings folder. Preferably, Windows system file migration is not allowed.

d) FSNT Namespace Access (NTFS) to Storage Platform Files

In the embodiment described herein, it is desirable that files migrated to the storage platform are not accessible from the NTFS namespace, even if the actual file streams are stored in NTFS. This eliminates the complex blocking and protection factors that arise from a multi-threaded implementation.

e) The expected namespace / drive letters

Access to files and folders in the storage platform is provided through the name of the USI (UNC) in the form \\ <machine name> \ <WinfsShareName>. For a class of applications that require a drive letter to work, the drive letter can be mapped to that name, the UNC.

I. STI PLATFORMS (API)

As mentioned above, the storage platform contains an API (API) that enables application programs to access the features and capabilities of the storage platform described above and access items stored in the data warehouse. This section describes one embodiment of a storage platform API in a storage platform of the present invention.

FIG. 19 shows a basic architecture of an API (API) of a storage platform according to the present embodiment. The storage platform API uses the SQLClient 1900 to interact with local data store 302 and can also use the SQLClient 1900 to interact with remote data stores (eg, data store 340). Local storage 302 can also interact with remote data storage 340 using either a Distributed Query Processor (RPQ; DQP), or using the storage platform synchronization service described above. The storage platform API 322 also serves as a bridge for the data warehouse notifications, transferring application subscriptions to the notification processing tool 332, and routing notifications to the application (e.g., application 350a, 350b or 350c), which is also described above. In one embodiment, the storage platform API 322 can also define a limited “provider” architecture so that it can access data in Microsoft Exchange and AD.

1. Overview

The data access mechanism of the present embodiment of the IPP (API) of the storage platform of the present invention relates to four areas: request, navigation, actions, events.

Inquiry

In one embodiment, the storage platform data warehouse is implemented on a relational database processor 314; as a result, the fully expressive power of the SQL language is inherent in the storage platform. Higher-level request objects provide a simplified model for requesting storage, but cannot encapsulate the full expressive power of storage.

Navigation

The data model of the storage platform builds a system with wide capabilities and extensible type on the abstractions of the underlying database. For a developer, storage platform data is a network of items. The storage platform API allows you to navigate from item to item using filtering, links, folders, etc. This is a higher level of abstraction than basic SQL (SQL) queries; at the same time, it allows you to use powerful filtering and navigation capabilities with well-known NLW (CRL) coding patterns.

Actions

The storage platform API (API) reveals common actions on all objects - Create, Delete, Update; they are expanded as object methods. In addition, domain-specific actions, such as SendMail, CheckFreeBusy, etc., are also available as methods. The integrated API environment (API) uses well-defined patterns that ISPs can use to add capabilities by defining additional actions.

Developments

The data in the storage platform is dynamic. To enable applications to respond when data in the repository changes, the APIs provide the developer with powerful capabilities for handling events, subscriptions and notifications.

2. Naming and scopes

It is useful to point out the difference between a namespace and a naming convention . The term namespace , as it is widely used, refers to the set of all names available on some system. The system can be a RNR (XML) scheme, a program, the World Wide Web, the set of all ftp sites (and their contents), etc. Naming is a process or algorithm used to assign unique names to all entities of interest in a namespace. Thus, naming is of interest, since it is desirable to uniquely refer to a given unit in the namespace. Thus, the term “namespace,” as used herein, refers to the set of all names available in all instances of the storage platform in the universe. Items are named entities in the storage platform namespace. The WSI Naming Agreement (UNC) is used to guarantee the uniqueness of item names. Each item in each storage of the storage platform in the universe is addressable by the name of USI (UNC).

The highest organizational level in the storage platform namespace is a service , which is simply an instance of the storage platform. The next level of organization is volume . A volume is the largest standalone item container. Each storage platform instance contains one or more volumes. Inside the volume are objects . Items are elementary data units in a storage platform.

Data in the real world is almost always organized according to some system that makes sense in a given domain. The basis of all such data organization schemes is the concept of dividing the aggregate of our data into named groups. As described above, this concept is modeled on a storage platform using the Folder principle. A folder is a special type of Item; There are 2 types of Folders: Power Folders and Virtual Folders.

Referring to FIG. 18, an Include Folder is an item that contains Attachment Links to other Items and is equivalent to the general principle of a file system folder. Each Item is “included” in at least one inclusion folder.

Virtual Folder is a more dynamic way to organize a collection of Items; it is simply the name given to the set of Items — the set is either listed explicitly or specified upon request. The Virtual Folder itself is an Item and can be considered as representing a set of Links (not attachments) to a set of Items.

Sometimes there is a need to model a more concise representation of inclusion; for example, a Word document embedded in an e-mail message, in a sense, is tied more tightly to its container than, for example, a file contained in a folder. This view is expressed by the principle of Embedded Objects. An Embedded Item has a special kind of communication that refers to another Item; the referenced Item may be attached or otherwise manipulated only within the context of the including Item.

Finally, the storage platform provides the concept of categories as a way to classify Items and Elements. Each Item or Item in the storage platform may have one or more categories associated with it. The category, in essence, is simply the name by which the Item / Element is tagged (marked). This name can be used in searches. The data model of the storage platform allows you to define a hierarchy of categories, thus allowing for tree-based classification of data.

The unique name for this item is a triple: (<serviceName>, <volumeID>, <ItemID>). Some items (specifically Folder and VirtualFolder) are collections of other items. This leads to an alternative way to identify items: (<serviceName>, <volumeID>, <itemPath>).

Storage platform names include the concept of a service context: a service context is a name that maps to a pair (<volumeName>, <path>). It identifies an item or set of items - for example, a folder, virtual folder, etc. With the service context principle, the name of the USI (UNC) for any item in the storage platform namespace becomes:

\\ <serviceName> \ <serviceContext> \ <itemPath>

Users can create and delete service contexts. Also, the root directory in each volume has a predefined context: volume-name $.

The ItemContext evaluates the query (for example, the Find operation) by limiting the results returned to those Items that are on the given path.

3. Components of the Storage Platform API

20 schematically represents various components of a storage platform API (API) according to the present embodiment. The storage platform API (API) consists of the following components: (1) data classes 2002, which represent the types of items and items of the storage platform, (2) an integrated execution environment 2004 that manages the persistence of the object and provides support classes 2006; and (3) 2008 tools that are used to generate CLR classes from storage platform schemas.

According to one aspect of the present invention, during the design period, the schema author submits the schema document 2010 and code for the domain methods 2012 to the storage platform API set 2008 tool kit. These tools generate client-side data classes 2002 and a storage schema 2014 and definitions of 2016 storage classes for this schema. “Domain” refers to a particular scheme; for example, inventors talk about domain methods for classes in the Contacts schema, etc. These 2002 data classes are used during an application developer run in conjunction with the 2006 classes of the storage platform APIs (APIs) for manipulating storage platform data.

In order to illustrate various aspects of the storage APIs of the present invention, examples are provided based on an exemplary Contacts scheme. A graphical representation of this exemplary diagram is illustrated in FIGS. 21A and 21B.

4. Data classes

According to an aspect of the present invention, each type of Item, Item and Element Extension, and also each Link in the storage platform data warehouse has a corresponding class in the storage platform API (API). Roughly, type fields are mapped to class fields. Each item, item extension, and item in the storage platform is available as an object of the corresponding class in the storage platform API. A developer may request the creation, modification, or deletion of these objects.

The storage platform contains an initial set of schemas. Each scheme defines a set of types of Items and Elements and a set of Links. The following is one embodiment of an algorithm for generating data classes from these schema entities:

For each circuit S:

For each Item I in S, a class called System.Storage.S.I is generated. This class has the following members:

- Overloaded constructors, including constructors that make it possible to set the initial folder and name of the new item.

- A property for each field in I. If the field is multi-valued, the property will be a collection of the corresponding Element type.

- An overloaded static method that finds many items matching the filter (for example, a method called “FindAll”).

- An overloaded static method that finds the only item matching the filter (for example, a method called “FindOne”).

- A static method that finds an item by its ID (for example, a method called “FindByID”).

- A static method that finds an item by its name relative to ItemContext (for example, a method called “FindByName”).

- A method that saves changes to an item (for example, a method called “Update”).

- Overloaded static methods Create, which create new instances of the subject. These methods allow you to set the initial folder of the item in various ways.

For each Element E in S, a class called System.Storage.S.E is generated. This class has the following members:

- A property for each field in E. If the field is multi-valued, the property will be a collection of the corresponding Element types.

For each Element E in S, a class called System.Storage.S.ECollection is generated. This class follows the general .NET Framework directives for strongly typed collection classes. For Relationship-based item types, this class will also include the following members:

- An overloaded method that finds many Item objects that match a filter that implicitly includes an item in which the collection appears as a source. Overloads include some that allow filtering based on the Item subtype (for example, a method called “FindAllTargetItems”).

- An overloaded method that finds a single Item object that matches a filter that implicitly includes an item in which the collection appears as a source. Overloads include some that allow filtering based on the Item subtype (for example, a method called “FindOneTargetItem”).

- An overloaded method that finds objects such as a nested element that matches a filter that implicitly includes an item in which the collection appears as a source (for example, a method called “FindAllRelationships”).

- An overloaded method that finds objects such as a nested element that matches a filter that implicitly includes an item in which the collection appears as a source (for example, a method called "FindAllRelationshipsForTarget").

- An overloaded method that finds a single object such as a nested element that matches a filter that implicitly includes an object in which the collection appears as a source (for example, a method called “FindOneRelationship”).

- An overloaded method that finds a single object such as a nested element that matches a filter that implicitly includes an object in which the collection appears as a source (for example, a method called "FindOneRelationshipForTarget").

For Link R, a class called System.Storage.S.R is generated in S. This class has one or two subclasses, depending on whether one or both of the communication roles defines an endpoint field.

Classes are also generated in the same way for each Item Extension that was created.

Data classes exist in the System.Storage namespace. <Names>, where <Names> is the name of the corresponding schema, such as Contacts, Files, etc. For example, all classes matching the Contacts schema are in the System.Storage.Contacts namespace.

As an example, with reference to FIGS. 21A and 21B, the contact diagram leads to the following classes contained in the System.Storage.Contact namespace:

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

- Elements : NestedElementBase, NestedElement, IdentityKey, SecurityID, EAddress, ContactEAddress, TelehoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, WindowsPresence, Relationship, TemplateRelationship, Relation, Relation, Relation, Relation, Relation, Relation, Relation, Relation , HouseHoldMemberData, FamilyData, SpouseData, ChildData

As another example, the detailed structure of the Person type, as defined in the Contacts schema, is shown in the RNR (XML) below:

<Type Name = "Person" MajorVersion = "1" MinorVersion = "0"

ExtendsType = "Core.Principal" ExtendsVersion = "1">

<Field Names = "Birthdate" Type = "the storage platformTypes.datetime"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "Gender" Type = "Base.CategoryRef"

Nullable = "true" MultiValued = "false"

TypeMajorVersion = "l" />

<Field Name = "PersonalNames" Type = "Contact.FullName"

Nullable = "true" MultiValued = "true"

TypeMajorVersion = "1" />

<Field Name = "PersonalEAddresses" Type = "Core.EAddress"

Nullable = "true" MultiValued = "true"

TypeMajorVersion = "1" />

<Field Name = "PersonalPostalAddresses"

Type = "Core.PostalAddress" Nullable = "true"

MultiValued = "true" TypeMajorVersion = "1" />

<Field Name = "PersonalPicture" Type = "the storage platformTypes.image"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "Notes" Type = "Core.RichText" Nullable = "true"

MultiValued = "true" TypeMajorVersion = "1" />

<Field Name = "Profession" Type = "Base.CategoryRef"

Nullable = "true" MultiValued = "true"

TypeMajorVersion = "1" />

<Field Name = "DataSource" Type = "Base.IdentityKey"

Nullable = "true" MultiValued = "true"

TypeMajorVersion = "1" />

<Field Name = "ExpirationDate" Type = "the storage platformTypes.datetime"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "HasAllAddressBookData" Type = "the storage platformTypes.bit"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "EmployeeOf" Type = "Contact.EmployeeData"

Nullable = "true" MultiValued = "true"

TypeMajorVersion = "1" />

</Type>

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

partial public class Person:

System.Storage.Core.Principal,

System.Windows.Data.IDataUnit

{

public System.Data.SqlTypes.SqlDateTime

Birthdate {get; set; }

public System.Storage.Base.CategoryRef

Gender {get; set:)

public System.Storage.Contact.FullNameCollection

PersonalNames {get; }

public System.Storage.Core.EAddressCollection

PersonalEAddresses {get; }

public System.Storage.Core.PostalAddressCollection

PersonalPostalAddresses {get; }

public System.Data.SqlTypes.SqlBinary

PersonalPicture {get; set; }

public System.Storage.Core.RichTextCollection

Notes {get; }

public System.Storage.Base.CategoryRefCollection

Profession {get; }

public System.Storage.Base.IdentityKeyCollection

DataSource {get; }

public System.Data.SqlTypes.SqlDateTime

ExpirationDate {get; set; }

public System.Data.SqlTypes.SqlBoolean

HasAllAddressBookData {get; set; }

public System.Storage.Contact.EmployeeDataCollection

EmployeeOf {get; }

public Person ();

public Person (System.Storage.Base.Folder folder, string name);

public static new System.Storage.FindResult

FindAll (System.Storage.ItemStore store);

public static new System.Storage.FindResult

FindAll (

System.Storage.ItemStore store,

string filter);

public static new Person

FindOne (

System.Storage.ItemStore store,

string filter);

public new event

System.Windows.Data.PropertyChangedEventHandler

PropertyChangedHandler;

public static new Person

FindByID (

System.Storage.ItemStore store,

long item_key);

}

As another example, the detailed structure of the TelephoneNumber type, as defined in the Contacts schema, is shown in the NEX (XML) below:

<Type Name = "TelephoneNumber" ExtendsType = "Core.EAddress"

MajorVersion = "1" MinorVersion = "0" ExtendsVersion = "1">

<Field Name = "CountryCode" Type = "the storage platformTypes.nvarchar (50)"

Nullable = "true" MultiValued = "false"

TypeMajorVersion = "1" />

<Field Name = "AreaCode" Type = "the storage platformTypes.nvarchar (256)"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "Number" Type = "the storage platformTypes.nvarchar (256)"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "Extension" Type = "the storage platformTypes.nvarchar (256)"

Nullable = "true" TypeMajorVersion = "1" />

<Field Name = "PIN" Type = "the storage platformTypes.nvarchar (50)"

Nullable = "true" TypeMajorVersion = "1" />

</Type>

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

partial public class TelephoneNumber:

System.Storage.Core.EAddress,

System.Windows.Data.IDataUnit

{

public System.Data.SqlTypes.SqlString CountryCode

{get; set; }

public System.Data.SqlTypes.SqlString AreaCode

{get; set; }

public System.Data.SqlTypes.SqlString Number

{get; set; }

public System.Data.SqlTypes.SqlString Extension

{get; set; }

public System.Data.SqlTypes.SqlString PIN

{get; set; }

public TelephoneNumber ();

public new event

System.Windows.Data.PropertyChangedEventHandler

PropertyChangedHandler;

}

The class hierarchy resulting from this scheme directly reflects the type hierarchy in this scheme. As an example, consider the Item types defined in the Contact schema (see FIGS. 21A and 21B). The class hierarchy corresponding to this in the storage platform API (API) will be as follows:

Object

DataClass

Elementbase

Rootoottase

Item

Principal

Group

Household

Organization

Person

User

Service

Presence service

ContactService

ADService

Rootootbase

... (Element Classes)

Another scheme, a scheme that makes it possible to represent all media of audio / video in the system (converted audio files, audio CDs, digital multifunction disks (DTM; DVD), home video, etc.), allows users / applications to store , organize, search, and manipulate various types of audio / video media. The basic layout of media documents is sufficiently generalized to represent any media, and extensions to this basic layout are designed to handle domain-specific properties separately for audio and video media. This scheme, and many, many others, is supposed to work directly or indirectly under the Basic scheme.

5. Integrated runtime

The basic storage platform API (API) programming model is the persistence of objects. Application programs (or “applications”) search the store and retrieve objects that represent the data in the store. Applications modify retrieved objects or create new objects, then cause these changes to spread to the repository. This process is controlled by an ItemContext. Searches are performed using the ItemSearcher object, and search results are available using the FindResult object.

a) Integrated Runtime Classes

According to another aspect of the storage platform API (API) of the storage platform, the integrated runtime implements a number of classes to support the operation of data classes. These integrated environment classes define a common set of behaviors for data classes and, together with data classes, provide a basic programming model for the storage platform API. Classes in the integrated runtime belong to the System.Storage namespace. In the present embodiment, the integrated environment classes contain the following main classes: ItemContext, ItemSearcher and FindResult. Other minor classes, enumeration values, and delegates may also be provided.

(1) ItemContext

The ItemContext object (i) represents the set of domains of the subject in which the application program wants to search, (ii) maintains state information for each object that represents the state of the data retrieved from the storage platform, and (iii) manages the transactions used in interacting with a storage platform and any file system with which a storage platform can interact.

ItemContext provides the following services as the persistence processor for objects:

1. Deserializes data read from storage into objects.

2. Accompany the identification of the object (the same object is used to represent the given subject, regardless of how many times this subject has been included in the query result).

3. Tracks the condition of the object.

ItemContext also runs a number of services unique to the storage platform:

1. Generates and executes updategram operations of the storage platform, necessary to ensure the constancy of changes.

2. Creates connections to a variety of data storages necessary for direct navigation through link relationships and for modifying and saving objects retrieved from a multi-domain search.

3. Ensures that items supported by files are updated correctly when changes are saved to the item (s) representing the item.

4. Manages transactions across multiple storage platform connections and when updating data stored in file-supported items and file stream properties, a transactional file system is updated.

5. Performs operations of creating, copying, moving, and deleting items that take into account the semantics of storage platform relationships, file-supported items, and typed stream properties.

Appendix A presents a listing of the source code for the ItemContext class according to one embodiment.

(2) ItemSearcher

The ItemSearcher class supports simple searches that return whole Item objects, Item object streams, or value streams projected from Item. ItemSearcher encapsulates a core functionality that is common to all of these: the principle of the type of target and the parameterized filters that apply to this type of target. ItemSearcher also provides the ability to pre-compile or prepare crawlers as an optimization, when the same search will be performed on many types. Appendix B provides a source code listing of the ItemSearcher class and several closely related classes according to one embodiment.

(a) Type of target

The type of search target is set when building ItemSearcher. The target type is the CLR type, which is mapped to the requested extent by the data store. Specifically, it is the type of NLW (CLR) that is mapped to the type of subject, communication and extension of the subject, as well as schematized representations.

When retrieving a crawler using the ItemContext.GetSearcher method, the crawler target type is set as a parameter. When the GetSearcher static method is called on the type of an item, link, or extension of an item (for example, Person.GetSearcher), the type of target is the type of item, link, or extension of the item.

Search expressions provided in ItemSearcher (for example, a search filter and using search options or projection definitions) are always relative to the type of search target. These expressions can specify properties such as goals (including properties of nested elements) and can specify connections for communication and extensions of objects, as described elsewhere.

The type of search target is made available using a read-only property (for example, the ItemSearcher.Type property).

(b) Filters

ItemSearcher contains a property for defining filters (for example, a property named “Filters” as a collection of SearchExpression objects) that defines the filter used in the search. All filters in the collection are combined using the logical AND operator when a search is performed. The filter may contain links to parameters. Parameter values are set using the Parameters property.

(c) Preparing searches

In situations where the same search must be performed repeatedly, perhaps only with parameter changes, some improvement in performance can be obtained by pre-compiling or preparing the search. This is accomplished with a set of ItemSearcher preparation methods (for example, a method for preparing Find that returns one or more Items, possibly called “PrepareFind”, and a method for preparing Find, which returns a projection, possibly called “PrepareProject”). For example:

ItemSearcher searcher = ...;

PreparedFind pf = searcher.PrepareFind ();

...

result = pf.FindAll ();

...

result = pf.FindAll ();

(d) Search options

There are a number of options that can be applied to a simple search. They can be set, for example, in a FindOptions object and passed to Find methods. For example:

ItemSearcher searcher = Person.GetSearcher (context);

FindOptions options = new FindOptions ();

options.MaxResults = 10;

options.SortOptions.Add ("PersonalNames.Surname", SortOrder.Ascending);

FindResult result = searcher.FindAll (options);

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

ItemSearcher searcher = Person.GetSearcher (context);

FindResult result = searcher.FindAll (

new SortOption ("PersonalNames.Surname", SortOrder.Ascending));

The DelayLoad variant determines whether binary large property values are loaded when the search results are retrieved, or whether the load is delayed until they are referenced. The MaxResults variant determines the maximum number of results that are returned. It is equivalent to the TOP statement in the SQL (SQL) query. It is very often used in conjunction with sorting.

The sequence of SortOption objects can be specified (for example, using the FindOptions.SortOptions property). Search results will be sorted as specified by the first SortOption object, then as specified by the second SortOption object, etc. SortOption defines a search expression that indicates the property that will be used for sorting. The expression specifies one of the following:

1) scalar property in the type of search target;

2) a scalar property in a nested element that can be called from the type of the search target by going through properties with a single value; or

3) the result of the aggregation function with a valid argument (for example, Max applied to a scalar property in a nested element, which can be called from the type of the search target by passing through properties with many values or relationships).

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

1. “Birthdate” - valid, date of birth is a scalar property of type Person;

2. "PersonalNames.Surname" - invalid, PersonalNames is a property with many values, and the aggregation function was not used;

3. "Count (PersonalNames)" is a valid number of PersonalNames.

4. "Case (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate" - invalid, uses a connection and properties with many values without an aggregation function.

5. “Max (Cast (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate)” is the valid, most recent start date for the home email address.

(3) Stream of item results (“FindResult”)

ItemSearcher (for example, using the FindAll method) returns an object that can be used to access objects returned from the search (for example, the FindResult object). Appendix C presents a listing of the source code for the FindResult class and several closely related classes according to one embodiment thereof.

There are two separate ways to get results from a FindResult object: using a reader template defined by IObjectReader (and IAsyncObjectReader), and using an enumerator template defined by IEnumerable and IEnumerator. An enumerator pattern is standard in CLR and supports language constructs like foreach in C #. For example:

ItemSearcher searcher = Person.GetSearcher (context);

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

FindResult result = searcher.FindAll ();

foreach (Person person in result) ...;

The reader template is supported, as it enables more efficient processing of results by eliminating data copying in some cases. For example:

ItemSearcher searcher = Person.GetSearcher (context);

searcher.Filters.Add ("PersonalNames.SurName = 'Smith'");

FindResult result = searcher.FindAll ();

while (result.Read ())

{

Person person = (Person) result.Current;

...

}

In addition, the reader template supports asynchronous operation:

ItemSearcher searcher = Person.GetSearcher (context);

searcher.Filters.Add ("PersonalNames.SurName = 'Smith'");

FindResult result = searcher.FindAll ();

IAsyncResult asyncResult = result.BeginRead (new AsyncCallback (MyCallback));

void MyCallback (IAsyncResult asyncResult)

{

if (result.EndRead (asyncResult))

{

Person person = (Person) result.Current;

...

}

}

In the present embodiment, FindResult should be closed when it is no longer needed. This can be accomplished by calling the Close method or using language constructs such as the using statement in C #. For example:

ItemSearcher searcher = Person.GetSearcher (context);

searcher.Filters.Add ("PersonalNames.SurName = 'Smith'");

using (FindResult result = searcher.FindAll ())

{

while (result.Read ())

{

Person person = (Person) result.Current;

...

}

}

b) Integrated runtime at work

22 illustrates an integrated runtime in operation. The integrated runtime works as follows:

1. The application 350a, 350b or 350c communicates with an item in a storage platform.

2. The 2004 Integrated Environment creates an ItemContext 2202 corresponding to the attached item and returns it to the application.

3. The application submits Find to this ItemContext to obtain a collection of Items; the returned collection conceptually represents a graph 2204 objects (due to relationships).

4. The application modifies, deletes and inserts data.

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

c) General programming patterns

This section provides many examples of how storage platform APIs (APIs) classes can be used to manipulate items in a data warehouse.

(1) Opening and closing ItemContext objects

The application receives an ItemContext object that it will use to interact with the data store, for example, by calling the static method ItemContext.Open and providing a path or paths that identify the domains of the items that will be associated with the ItemContext. Item Domains limit the scope of searches performed using the ItemContext, so that only the domain item and items contained in this item will be searched. Examples are the following:

Open ItemContext with the shared resource of the DefaultStore storage platform on the local computer

ItemContext ic = ItemContext.Open ();

Open ItemContext with this shared storage platform resource

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

Open ItemContext with an item under a shared platform resource

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

Open ItemContext with multiple item domains

ItemContext ic = ItemContext.Open (@ "\\ myserver1 \ My Documents",

@ "\\ jane1 \ My Documents",

@ "\\ jane2 \ My Documents");

When an ItemContext is no longer needed, it should be closed.

Explicit Closing ItemContext

ItemContext ic = ItemContext.Open ();

...

ic.Close ();

Closing an ItemContext with a using statement

using (ItemContext ic = ItemContext.Open ())

{

...;

}

(2) Object Search

According to another aspect of the present invention, the storage platform API provides a simplified query model that enables application programmers to generate queries based on various properties of items in a data warehouse, in a way that separates the application programmer from the details of the query language of the underlying database processor .

Applications can search the domains specified when the ItemContext was opened using the ItemSearcher returned by the ItemContext.GetSearcher method. Search results are accessed using the FindResult object. Assume the following declarations for examples below:

ItemContext ic = ...;

ItemSearcher searcher = null;

FindResult result = null;

Item item = null;

Relationship relationship = null;

ItemExtension itemExtension = null;

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

Search for all items of this type

searcher = ic.GetSearcher (typeof (Person));

result = searcher.FindAll ();

foreach (Person p in result) ...;

Search for items of this type that match the filter

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

result = searcher.FindAll ();

foreach (Person p in result) ...;

Use parameter in filter string

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("Birthdate <@Date");

searcher.Parameters ["Date"] = someDate;

result = searcher.FindAll ();

foreach (Person p in result) ...;

Search for relations of this type and satisfying the filter

searcher = ic.GetSearcher (typeof (EmployeeEmployer));

searcher.Filters.Add ("StartDate <= @Date AND (EndDate> = @Date OR isnull (EndDate))");

searcher.Parameters ["Date"] = someDate;

result = searcher.FindAll ();

Foreach (EmployeeEmployer ee in result) ...;

Search for items with this type of relationship and matching the filter

searcher = ic.GetSearcher (typeof (Folder));

searcher.Filters.Add ("MemberRelationships.Name like 'A%'"); // See [ApiRel]

result = searcher.FindAll ();

Foreach (Folder f in result) ...;

Search for item extensions of this type and matching the filter

searcher = ic.GetSearcher (typeof (ShellExtension));

searcher.Filters.Add ("Keywords.value = 'foo'");

result = searcher.FindAll ();

foreach (ShellExtension se in result) ...;

Search for items with extensions of items of this type and matching the filter

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("Extensions.Cast (@Type) .Keywords.Value = 'Foo'"); // See [ApiExt]

searcher.Parameters ["Type"] = typeof (ShellExtension);

result = searcher.FindAll ();

foreach (Person p in result) ...;

(a) Search options

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

Sort Search Results

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

SearchOptions options = new SearchOptions ();

options.SortOptions.Add (new SortOption ("Birthdate", SortOrder.Ascending));

result = searcher.FindAll (options);

foreach (Person p in result) ...;

// Short form available

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

result = searcher.FindAll (new SortOption ("Birthdate", SortOrder.Ascending));

foreach (Person p in result) ...;

Limit the number of results

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

SearchOptions options = new SearchOptions ();

options.MaxResults = 10;

result = searcher.FindAll (options);

foreach (Person p in result) ...;

(b) FindOne and FindOnly

In the case where it is useful to extract only the first result, especially when specifying the sorting criterion. Also, as expected, some searches return only one object and are not expected to return no objects.

Single Object Search

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

Person p = searcher.FindOne (new SortOption ("Birthdate" SortOrder.Ascending)) as Person;

if (p! = null) ...;

Search for the only object that is expected to always exist

searcher = ic.GetSearcher (typeof (Person));

searcher.Filters.Add ("PersonalNames [Surname = 'Smith' AND Givenname 'John']");

try

{

Person p = searcher.FindOnly ();

...;

}

catch (Exception e)

{

...;

}

(c) Short search forms for ItemContext

There are also some abbreviated ItemContext methods that make simple searches as easy as possible.

Search using the short form ItemContext.FindAll

result = ic.FindAll (typeof (Person), "PersonalNames.Surname = 'Smith'");

foreach (Person p in result) ...;

Search using the short form ItemContext.FindOne

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

(d) Search by ID or path

In addition, Items, links, and item extensions can be retrieved by providing their ID. Items can also be retrieved along the way.

Get items, links, and item extensions by their ID

item = ic.FindItemById (iid);

relationship = ic.FindRelationshipById (iid, rid);

itemExtension = ic.FindItemExtensionById (iid, eid);

Get items along the way

// Only one domain

item = ic.FindItemByPath (@ "temp \ foo.txt");

// One or many domains

result = ic.FindAllItemsByPath (@ "temp \ foo.txt");

foreach (Item I in result) ...;

(f) GetSearcher Template

There are many places in the storage platform API (API) where it is desirable to provide an auxiliary method that performs a search in the context of another object or with specific parameters. The GetSearcher template makes such scenarios possible. There are many GetSearcher methods in the API. Each returns an ItemSearcher preconfigured to perform this search. For example:

searcher = itemContext.GetSearcher ();

searcher = Person.GetSearcher ();

searcher = EmployeeEmployer.GetSearcherGivenEmployer (organization);

searcher = person.GetSearcherForReports ();

You can add additional filters before performing a search:

searcher = person.GetSearcherForReports ();

searcher.Filters.Add ("PersonalNames.Surname = 'Smith'");

You can choose how many results you want:

FindResult findResult = searcher.FindAll ();

Person person = searcher.FindOne ();

(3) Storage update

If an object was retrieved through a search, it can be modified by the application as needed. New objects can also be created and associated with existing objects. If the application has made all the changes that form the logical group, the application calls ItemContext.Update to ensure that these changes are persistent in the repository. According to another aspect of the storage platform API (API) of the present invention, the API collects changes to the subject made by the application program and then organizes them into the correct updates required by the database processor (or any kind of storage processor) on which the storage is implemented data. This makes it possible for application programmers to make changes to an item in memory, while at the same time leaving the complexity of data warehouse updates for the API.

Save Changes to a Single Item

Person p = ic.FindItemById (pid) as Person;

p.DisplayName = "foo";

p.TelephoneNumbers.Add (new TelephoneNumber ("425-555-1234"));

ic.Update ();

Save Changes to Many Items

Household h1 = ic.FindItemById (hid1) as Household;

Household h2 = ic.FindItemById (hid2) as Household;

Person p = ic.FindItemById (pid) as Person;

h1.MemberRelationships.Remove (p);

h2.MemberRelationships.Add (p);

ic.Update ();

Create New Item

Folder f = ic.FindItemById (fid) as Folder;

Person p = new Person ();

p.DisplayName = "foo";

f.Relationships.Add (new FolderMember (p, "foo"));

ic.Update ();

// Or using the short form ...

Folder f = ic.FindItemById (fid) as Folder;

Person p = new Person ();

p.DisplayName = "foo";

f.MemberRelationships.Add (p, "foo");

ic.Update ();

Remove links (and possibly Target)

searcher = ic.GetSearcher (typeof (FolderMember));

searcher.Filters.Add ("SourceItemId = @ fid");

searcher.Filters.Add ("TargetItemId = @ pid");

searcher.Parameters.Add ("fid", fid);

searcher.Parameters.Add ("pid", pid);

foreach (FolderMember fm in searcher.FindAll ()) fm.MarkForDelete ();

ic.Update ();

// Or using the short form ...

Folder f = ic.FindItemById (fid) as Folder;

f.MemberRelationships.Remove (pid);

ic.Update ();

Add Item Extension

Item item = ic.FindItemById (iid);

MyExtension me = new MyExtension ();

me.Foo = "bar";

item.Extensions.Add (me);

ic.Update ();

Delete Item Extensions

searcher = ic.GetSearcher (typeof (MyExtension));

searcher.Filters.Add ("ItemId = @ iid");

searcher.Parameters.Add ("iid", iid);

foreach (MyExtension me in searcher.FindAll ()) me.MarkForDelete ();

ic.Update ();

// Or using the short form ...

Item i = ic.FindItemById (iid);

i.Extensions.Remove (typeof (MyExtension));

ic.Update ();

6. Protection

With reference to section II.E above (Security), in the present embodiment of the storage platform API (API), there are five methods available in the Item Context for retrieving and modifying the security policy associated with the item in storage. They are:

1. GetItemSecurity;

2. SetItemSecurity;

3. GetPathSecurity;

4. SetPathSecurity;

5. GetEffectiveItemSecurity.

GetItemSecurity and SetItemSecurity provide a mechanism for retrieving and modifying the explicit ACL associated with an item. This COURT (ACL) is independent of the paths that exist to the subject, and will be in effect regardless of the attachment relationships for which the subject acts as a target. This enables administrators to draw conclusions about the protection of the subject, regardless of the paths that exist to the subject, if they wish.

GetPathSecurity and SetPathSecurity provide a mechanism for extracting and modifying the ACL that exists in an item due to an attachment link from another folder. This COURT (ACL) consists of a COURT (ACL) of various subject predecessors along the path in question along with an explicit ACL, if any, provided for that path. The difference between this COURT (ACL) and COURT (ACL) in the previous case is that this COURT (ACL) remains in effect only as long as there is a corresponding attachment relationship, while the explicit COURT (ACL) of the item is independent of from what connection attachment to the subject.

The ACL, which can be set on the subject using SetItemSecurity and SetPathSecurity, is limited to inherited and characteristic of the ACE's. They cannot contain any ACE that is marked as inherited.

GetEffectiveItemSecurity retrieves the various path-based ACLs as well as the explicit ACL on the subject. This reflects the authorization policy in force on this subject.

7. Communication support

As described above, the storage platform data model defines “connections” that enable objects to be connected to each other. When data classes for a schema are generated, the following classes are obtained for each type of relationship:

1. The class that represents the relationship itself. This class derives from the Relationship class and contains members specific to the relationship type.

2. Strongly typed class of the "virtual" collection. This class derives from VirtualRelationshipCollection and allows connection instances to be created and deleted.

This section describes link support in the storage platform API.

a) Basic types of relationships

The storage platform API (API) provides several types in the System.Storage namespace that form the base of the API relationship. They are:

1. Relationship - the basic type of all relationship classes

2. VirtualRelationshipCollection - the base type for all link collections

3. ItemReference, ItemIdReference, ItemPathReference - represent types of links to the item; the relationship between these types is shown in Fig.11.

(1) Relationship class

The following is a base class for link classes.

public abstract class Relationship: StoreObject

{

// Create with default values.

protected Relationship (ItemIDReference targetItemReference);

// Informs the link that it has been added to the link collection.

// The object polls the collection to determine the item

// source, subject context, etc.

internal AddedToCollection (VirtualRelationshipCollection collection);

// ID of the communication.

public RelationshipId RelationshipId {get; }

// ID of the source item.

public ItemId SourceItemId {get; }

// Get the source item.

public Item SourceItem {get; }

// Link to the subject of the target.

public ItemIdReference TargetItemReference {get; }

// Get the subject of the target (call

// TargetItemReference.GetItem ()).

public Item TargetItem {get; }

// Determine if ItemContext already has a domain connection

// target object (calls

// TargetItemReference.IsDomainConnected).

public bool IsTargetDomainConnected {get; }

// The name of the target in the namespace. Name must be

// unique in all attachment connections

// source.

public OptionalValue <string> Name {get; set;}

// Determines if this is an attachment relationship or

// links.

public OptionalValue <bool> IsOwned {get; set;}

}

(2) ItemReference Class

The following is a base class for item reference types.

public abstract class ItemReference: NestedElement

{

// Create with default values.

protected ItemReference ();

// Returns the referenced item.

public virtual Item GetItem ();

// Determines if a connection has been made to the domain

// referenced item.

public virtual bool IsDomainConnected ();

}

ItemReference objects can identify items that exist in the repository, except for the repository in which the reference to the item itself is constantly located. Each derived type defines how the link to the remote store is created and used. The GetItem and IsDomainConnected implementations in the derived classes use ItemContext multi-domain support to load items from the required domain and determine if a connection to the domain has already been established.

(3) Class ItemIdReference

The following is the ItemIdReference class — a reference to an Item that uses the item ID to identify the target item (target item).

public class ItemIdReference: ItemReference

{

// Builds a new ItemIdReference with values by

// default.

public ItemIdReference ();

// Builds a new ItemIdReference to the given item.

// The domain associated with the Item is used in

// as a locator.

public ItemIdReference (Item item);

// Builds a new ItemIdReference with an empty locator and

// given the ID of the target.

public ItemIdReference (ItemId itemId);

// Builds a new ItemIdReference with the given locator and

// the values of the ID of the item.

public ItemIdReference (string locator, ItemId itemId);

// ID of the target item.

public ItemId ItemId {get; set;}

// A path identifying that a WinFS item that

// contains the subject of the target in its domain. If null,

// the domain that contains the item is unknown.

public OptionalValue <string> Locator {get; set;}

// Determines if a connection is made to a domain

// referenced item.

public override bool IsDomainConnected ();

// Retrieves the referenced item.

public override Item GetItem ();

}

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

(4) Class ItemPathReference

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

public class ItemPathReference: ItemReference

{

// Builds a link to the path to the item with values by

// default.

public ItemPathReference ();

// Builds a link to the path to the item without a locator and with this

// path.

public ItemPathReference (string path);

// Builds a link to the path to the item with the given locator and

// path.

public ItemPathReference (string locator, string path);

// A path identifying that a WinFS item that

// contains the subject of the target in its domain.

public OptionalValue <string> Locator {get; set;}

// Path to the subject of the target relative to the domain of the subject,

// specified by the locator.

public string Path {get; set;}

// Determines if a connection has been made to the domain

// referenced item.

public override bool IsDomainConnected ();

// Retrieves the referenced item.

public override Item GetItem ();

}

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

(5) RelationshipId Structure

The RelationshipId structure encapsulates the GUID of a communication ID.

public class RelationshipId

{

// Generates a new GUID (ID) links.

public static RelationshipId NewRelationshipId ();

// Initializes a new GUID (GUID) communication ID (ID).

public RelationshipId ();

// Initializes with the given GUID.

public RelationshipId (Guid id);

// Initializes the string representation of the GUID.

public RelationshipId (string id);

// Returns a string representation of the GUID of the communication ID.

public override string ToString ();

// Convert an instance of System.Guid to an instance

// RelationshipId.

public static implicit operator RelationshipId (Guid guid);

// Converts an instance of RelationshipId to an instance

// System.Guid.

public static implicit operator Guid (RelationshipId relationshipId);

}

This dimensional type wraps guid so that parameters and properties can be strongly typed as the binding ID. OptionalValue <RelationshipId> should be used when the communication ID is nullable. An Empty value, such as that provided by System.Guid.Empty, is not expanded. RelationshipId cannot be built with an empty value. When the default constructor is used to create the RelationshipId, a new GUID is created.

(6) VirtualRelationshipCollection class

The VirtualRelationshipCollection class implements a collection of communication objects, which includes objects from the data store, plus new objects that were added to the collection, but do not include objects that were deleted from the store. Objects of a given type of communication with a given source object ID are included in the collection.

It is the base class for the link collection class that is generated for each type of link. This class can be used as a property type in a source item type to provide access and provide easy manipulation of these item relationships.

Enumerating the contents of a VirtualRelationshipCollection requires a potentially large number of link objects to be loaded from storage. Applications should use the Count property to determine how many links can be loaded before they list the contents of the collection. Adding and removing objects to / from the collection does not require loading links from the repository.

For efficiency, it is preferable that applications search for relationships that meet specific criteria, instead of listing all the relationships of the item using the VirtualRelationshipCollection object. Adding link objects to the collection encourages the creation of the presented links in the repository when ItemContext.Update is called. Removing link objects from the collection causes the presented link to be deleted in the repository when ItemContext.Update is called. The virtual collection contains the correct set of objects regardless of whether the link object is added / removed using the Item.Relationships collection or any other link collection of this item.

The following code defines the VirtualRelationshipCollection class:

public abstract class VirtualRelationshipCollection: ICollection

{

// The collection will contain relationships of the given type,

// owned by the item identified

// via itemId.

protected VirtualRelationshipCollection (ItemContext itemContext,

ItemId itemId,

Type relationshipType);

// The enumerator will return all objects retrieved

// from the repository, without any object that has a state

// Deleted, in addition to objects that have state

// Inserted.

public IEnumerator GetEnumerator ();

// Returns the number of the number of communication objects that

// would be returned by the enumerator. This number is calculated without

// need to retrieve all objects from the repository.

public int Count {get; }

// Always returns false.

public bool ICollection.IsSynchronized () {get; }

// Always returns this object.

public object ICollection.SyncRoot {get; }

// Searches for the required objects in the repository.

public void Refresh ();

// Adds the given relationship to the collection. The object must have

// state Constructed or Removed. If condition

// is Constructed, it changes to Added. If

// the state is Removed, it changes to Retrieved

// or Modified, which is appropriate. ID of the subject of the communication source

// must be the same as the source object ID

// provided when the collection was compiled.

protected void Add (Relationship relationship);

// Removes the specified association from the collection. State of the object

// must be Added, Retrieved or Modified. If

// the state of the object is Added, it will be set

// in Constructed. If the state of the object is Retrieved

// or Modified, it will be installed in Removed. ID

// the subject of the communication source must be the same as

// ID of the source item provided when

// collection has been compiled.

protected void Remove (Relationship relationship);

// Objects that have been removed from the collection.

public ICollection RemovedRelationships {get; }

// Objects that have been added to the collection.

public ICollection AddedRelationships {get; }

// Objects that were retrieved from storage. This

// collection will be empty until it is

// listed VirtualRelationshipCollection, or called

// Refresh (getting this property value is not

// the reason for filling the collection).

public ICollection StoredRelationships {get; }

// Asynchronous methods.

public IAsyncResult BeginGetCount (IAsyncCallback callback, object state);

public int EndGetCount (IAsyncResult asyncResult);

public IAsyncResult BeginRefresh (IAsyncCallback callback, object state);

public void EndRefresh (IAsyncResult asyncResult);

}

b) Generated link types

When generating classes for a storage platform scheme, a class is generated for each link declaration. In addition to the class that represents the link itself, a link collection class is also generated for each link. These classes are used as the type of properties in source object classes or relationship targets.

This section describes the classes that are generated using a number of prototype classes. Those. if there is a given link declaration, the class that is generated is described. It is important to note that the class, type, and endpoint names used in the prototype classes are placeholders for the names specified in the schema for communication, and should not be taken literally.

(1) Generated link types

This section describes the classes that are generated for each type of relationship. For example:

Relationship Name = " RelationshipPrototype " BaseType = "Holding">

<Source Name = " Head " ItemType = "Foo"/>

<Target Name = " Tail " ItemType = "Bar" ReferenceType = "ItemIDReference"/>

<Property Name = "SomeProperty" Type = "WinFSTypes.String" />

</Relationship>

With this relationship definition, the RelationshipPrototype and RelationshipPrototype Collection classes will be generated. The RelationshipPrototype class represents the relationship itself. The RelationshipPrototype Collection class provides access to RelationshipPrototype instances that have the specified item as the source endpoint.

(2) RelationshipPrototype class

This is a prototype attachment linkage class called “ HoldingRelationshipPrototype” , where the source endpoint is named “ Head ” and sets the item type to “Foo”, and the target endpoint is called “ Tail ” and sets the item type to “Bar”. It is defined as follows:

public class RelationshipPrototype : Relationship

{

public RelationshipPrototype (Bar tail Item);

public RelationshipPrototype (Bar tail Item, string name);

public RelationshipPrototype (Bar tail Item, string name, bool IsOwned);

public RelationshipPrototype (Bar tail Item, bool IsOwned);

public RelationshipPrototype (ItemIdReference tail ItemReference);

// Gets the Head object (calls base.SourceItem).

public Foo Head Item {get; }

// Get the Tail item (calls base.TargetItem).

public Bar Tail Item {get; }

// Represents additional properties declared in the schema for communication. They

// generated exactly as for properties in the type of an object or nested element.

public string SomeProperty {get; set;}

public static ItemSearcher GetSearcher (ItemContext itemContext);

public static ItemSearcher GetSearcher (Foo head Item);

public static FindResult FindAll (string filter);

public static RelationshipPrototype FindOne (string filter);

public static RelationshipPrototype FindOnly (string filter);

}

(3) RelationshipPrototypeCollection Class

This prototype class generated by the class RelationshipPrototype, which maintains a collection of copies of communications RelationshipPrototype, owned by the specified object. It is defined as follows:

public class RelationshipPrototype Collection: VirtualRelationshipCollection

{

public RelationshipPrototype Collection (ItemContext itemContext,

ItemId head ItemId);

public void Add ( RelationshipPrototype relationship);

public RelationshipPrototype Add (Bar bar);

public RelationshipPrototype Add (Bar bar, string name);

public RelationshipPrototype Add (Bar bar, string name, bool IsOwned);

public RelationshipPrototype Add (Bar bar, bool IsOwned);

public void Remove ( RelationshipPrototype relationship);

public void Remove (Bar bar);

public void Remove (ItemId barItemId);

public void Remove (RelationshipId relationshipId);

public void Remove (string name);

}

c) Support for relationships in the Item class

The Item class contains the Relationships property, which provides access to the relationships in which this item is the source of the relationship. The Relationships property is of type RelationshipCollection.

(1) Item class

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

public abstract class Item: StoreObject

{

...

// A collection of links in which this item is the source.

public RelationshipCollection Relationships {get;}

...

}

(2) RelationshipCollection class

This class provides access to instances of relationships in which the subject is the source of the relationship. It is defined as follows:

public class RelationshipCollection: VirtualRelationshipCollection

{

public RelationshipCollection (ItemContext itemContext,

ItemId head ItemId);

public void Add (Relationship relationship);

public Relationship Add (Bar bar);

public Relationship Add (Bar bar, string name);

public Relationship Add (Bar bar, string name, bool IsOwned);

public Relationship Add (Bar bar, bool IsOwned);

public void Remove (Relationship relationship);

public void Remove (Bar bar);

public void Remove (ItemId barItemId);

public void Remove (RelationshipId relationshipId);

public void Remove (string name);

}

d) Support for relationships in search expressions

You can specify the progress of the connection between the connections and the corresponding objects in the search expression.

(1) Passage from items to links

When the current context of the search expression is a collection of items, the connection between items and link instances where the item is the source can be made using the Item.Relationships property. Joining a specific type of relationship can be specified using the Cast operator of a search expression.

Strongly typed link collections (e.g. Folder.MemberRelationships) can also be used in a search expression. Casting to a connection type is implicit.

If a set of relationships has been established, the properties of this relationship are available for use in predicates or as a projection target. When used to set a projection target, a set of relationships will be returned. For example, the following statement will find all people in the organization where the StartDate property of the links has a value greater than or equal to “1/1/2000”.

FindResult result = Person.FindAll (context,

"Relationships. Cast (Contact.EmployeeOfOrganization). StartDate>'1/1/2000'");

If the Person type has an EmployerContext property of the EmployeeSideEmployerEmployeeRelationships type (generated for the EmployeeEmployer association type), this can be written as:

FindResult result = Person.FindAll (context,

"EmployerRelationships.StartDate> '1/1/2000'");

(2) Passage from links to objects

When the current context of the search expression is a set of links, the passage of the connection from the link to any endpoint of the link can be performed by specifying the name of the endpoint. If a set of related objects has been installed, the properties of these objects are available for use in predicates or as a projection target. When used to set a projection target, a set of items will be returned. For example, the following statement will find all EmployeeOfOrganization relationships (regardless of organization), where the employee’s last name is Smith.

FindResult result = EmployeeOfOrganization.FindAll (context,

" Employee .PersonalNames [SurName = 'Smith']");

The Cast operator of a search expression can be used to filter the type of an endpoint item. For example, to find all instances of the MemberOfFolder relationship, where the member is Person with the last name “Smith”:

FindResult result = MemberOfFolder.FindAll (context,

"Member.Cast (Contact.Person) .PersonalNames [Surname = 'Smith']");

(3) Combining communications

The previous two patterns, passing from objects to connections and from connections to objects, can be combined to achieve arbitrarily complex walkthroughs. For example, to find all organizations with an employee who has the last name "Smith":

FindResult result = Organization.FindAll (context,

"EmployeeRelationships." +

"Employee." +

"PersonalNames [SurName = 'Smith']");

The example below finds all Person objects representing people who live in a family located in the New York area (TODO: this is no longer supported ... what an alternative).

FindResult result = Person.FindAll (context,

"Relationships.Cast (Contact.MemberOfHousehold)." +

"Household." +

"Relationships.Cast (Contact.LocationOfHousehold)." +

"MetropolitonRegion = 'New York'");

e) Examples of using linking support

The following are examples of how communications support in a storage platform API can be used to manipulate communications. For the examples below, suppose the following declarations:

ItemContext ic = ...;

ItemId fid = ...; // ID of the folder item

Folder folder = Folder.FindById (ic, fid);

ItemId sid = ...; // ID of the source item.

Item source = Item.FindById (ic, sid);

ItemId tid = ...; // ID of the target item.

Item target = Item.FindById (ic, tid);

ItemSearcher searcher = null;

(1) Search for links

You can search for source or target relationships. Filters can be used to select relationships of a given type and which have given property values. Filters can also be used to select relationships based on the related item type or property values. For example, the following searches may be performed:

All communications where this item is the source

searcher = Relationship.GetSearcher (folder);

foreach (Relationship relationship in searcher.FindAll ()) ...;

All communications where this item is a source that has a name that matches “A%”

searcher = Relationship.GetSearcher (folder);

searcher.Filters.Add ("Name like 'A%'");

foreach (Relationship relationship in searcher.FindAll ()) ...;

All communications of FolderMember where this item is the source

searcher = FolderMember.GetSearcher (folder);

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

All communications of FolderMember, where the given subject is a source and a name similar to "A%"

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("Name like 'A%'");

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

All FolderMember connections where the subject of the target is Person

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("MemberItem.Cast (Person)");

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

All communications of FolderMember, where the subject of the target is Person with the surname “Smith”

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("MemberItem.Cast (Person) .PersonalNames.Surname = 'Smith'");

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

In addition to the GetSearcher APIs shown above, each link class supports the FindAll, FindOne, and FindOnly static APIs. In addition, the type of links can be specified when calling ItemContext.GetSearcher, ItemContext.FindAll, ItemContext.FindOne or ItemContext.FindOnly.

(2) Navigation from communication to source and target objects

If the communication object was retrieved by searching, you can "navigate" to the subject of the target or source. The base relationship class provides the SourceItem and TargetItem properties that return an Item object. The generated link class provides equivalent strongly typed and named properties (e.g., FolderMember.FolderItem and FolderMember.MemberItem). For example:

Navigate to the source item and target to associate with the name “Foo”

searcher = Relationship.GetSearcher ();

searcher.Filters.Add ("Name = 'Foo'");

foreach (Relationship relationship in searcher.FindAll ())

{

Item source = relationship.SourceItem;

Item target = relationship.TargetItem;

}

Navigate to a target item

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("Name like 'A%'");

foreach (FolderMember folderMember in searcher.FindAll ())

{

Item member = folderMember.TargetItem;

...

}

Navigation to the target item works even if the target item is not in the domain where the connection was detected. In such cases, the storage platform API (API) opens a connection to the target domain when necessary. Applications can determine if a connection is required before retrieving the target item.

Verify Target in an Unconnected Domain

searcher = Relationship.GetSearcher (source);

foreach (Relationship relationship in searcher.FindAll ())

{

if (relationship.IsTargetDomainConnected)

{

Item member = relationship.TargetItem;

...

}

}

(3) Navigation from source items to links

If you have an item’s object, you can navigate to the links for which the item is the source without performing an explicit search. This is accomplished using the collection property Item.Relationships or a strongly typed collection property such as Folder.MemberRelationships. From communication, you can navigate to the target item. Such navigation works even if the target is not in the target domain associated with the ItemContext of the source, including the case when the target is not in the same store as the target. For example:

Navigate from a Source Item to a Link to Target Items

Console.WriteLine ("The subject {0} is the source of the following relationships:", source.ItemId);

foreach (Relationship relationship in source.Relationships)

{

Item target = relationship.TargetItem;

Console.WriteLine ("{0} ==> {1}", relationship.RelationshipId, target.ItemId);

}

Navigate from Folder Subject to Foldermember Links to Target Subjects

Console.WriteLine ("The subject {0} is the source of the following links:", folder.ItemId);

foreach (FolderMember folderMember in folder.MemberRelationships)

{

Item target = folderMember.GetMemberItem ();

Console.WriteLine ("{0} ==> {1}", folderMember.RelationshipId, target.ItemId);

}

An item can have many links, so applications should be careful when listing a collection of links. In general, a search should be used to identify specific relationships of interest, rather than listing the entire collection. Nevertheless, if the collection-based programming model for links is valuable enough and items with many links in sufficient quantity, then the danger of improper use by the developer is justified. Applications can check the number of links in the collection and use a different programming model, if necessary. For example:

Check link collection size

if (folder.MemberRelationships.Count> 1000)

{

Console.WriteLine ("Too many links!");

}

else

{

...

}

The link collections described above are “virtual” in the sense that they are not actually populated with objects that represent each link, unless the application attempts to enumerate the collection. If the collection is listed, the results reflect what is in the repository, plus what was added by the application but not yet saved, but not any links that were deleted by the application but not saved.

(4) Creating links (and items)

New links are created by creating a link object, adding it to the link collection in the source item and updating the ItemContext. To create a new item, an attachment or embedment relationship must be created. For example:

Add a new item to an existing folder

Bar bar = new Bar ();

folder.Relationships.Add (new FolderMember (bar, "name"));

ic.Update ();

// Or

Bar bar = new Bar ();

folder.MemberRelationships.Add (new FolderMember (bar, "name"));

ic.Update ();

// Or

Bar bar = new Bar ();

folder.MemberRelationships.Add (bar, name);

ic.Update ();

Add existing item to existing folder

folder.MemberRelationships.Add (target, "name");

ic.Update ();

Add existing item to new folder

Folder existingFolder = ic.FindItemById (fid) as Folder;

Folder newFolder = new Folder ();

existingFolder.MemberRelationships.Add (newFolder, "a name");

newFolder.MemberRelationships.Add (target, "a name");

ic.Update ();

Add new item to new folder

Folder existingFolder = ic.FindItemById (fid) as Folder;

Folder newFolder = new Folder ();

existingFolder.MemberRelationships.Add (newFolder, "a name");

Bar bar = new Bar ();

newFolder.MemberRelationships.Add (bar, "a name");

ic.Update ();

(5) Removing links (and items)

Remove attachment link

// If the source item and the link ID are known ...

RelationshipId rid = ...;

Relationship r = ic.FindRelationshipById (fid, rid);

r.MarkForDelete;

ic.Update ();

// Otherwise ...

folder.MemberRelationships.Remove (target);

ic.Update ();

8. “Extension” of the storage platform API (API)

As noted above, each storage platform schema leads to 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 their associated methods form the basis of the storage platform API.

a) Domain behavior methods

In addition to these standard methods, each circuit has a set of domain-specific methods for this. Inventors call them domain behavior methods. For example, some of the domain behavior methods in the Contact schema are:

- Is the email address valid?

- For this folder, get a collection of all members of the folder.

- For a given item ID, get the object representing this item.

- For a given Person, get his operational status.

- Helper functions to create a new contact or temporary contact.

- Etc.

It is important to note that while inventors make a distinction between “standard” behavior methods (Find *, etc.) and domain behavior methods, they just look like methods for a programmer. The difference between these methods is that standard behaviors are automatically generated from the schema files by the tools of the storage platform API (API) design period, while domain behaviors are hard-coded.

By their nature, these domain behaviors must be created manually. This leads to a practical problem: the initial version of C # requires that the entire implementation of the class be inside a single file. Thus, this makes it necessary to edit files of automatically generated classes in order to add domain behavior methods. This in itself can be a problem.

A feature called partial classes has been introduced in C # for problems such as these. Essentially, a partial class allows class implementations to span multiple files. A partial class is the same as a regular class, except that its declaration is preceded by a partial keyword:

partial public class Person: DerivedItemBase

{

// implementation

}

Now the domain behavior methods for Person can be placed in another file, like this:

partial public class Person

{

public EmailAddress PrimaryEmailAddress

{

get {/ * implementation * /}

}

}

b) Additional behaviors

Data classes with domain behavior methods form the foundation on which application developers create. However, it is neither possible nor desirable for the data classes to reveal any potential behavior method related to that data. The storage platform allows the developer to build on the basic functionality offered through the storage platform API. The basic template here is a class entry whose methods take one or more classes of the storage platform as parameters. For example, additional classes for sending e-mail using Microsoft Outlook or using Microsoft Windows Messenger may be as follows:

MailMessage m = MailMessage.FindOne (...);

OutlookEMailServices.SendMessage (m);

Person p = Person.FindOne (...);

WindowsMessagerServices m = new WindowsMessagerServices (p);

m.MessageReceived + = new MessageReceivedHandler (f);

m.SendMessage ("Hello");

These additional classes can be registered on the storage platform. Registration data is associated with schema metadata that the storage platform supports for each installed type of storage platform. This metadata is stored as storage platform items and may be requested.

Registration of additional classes is a powerful feature; for example, it makes the following scenario possible: Right-clicking on a Person object in the Shell Explorer and a set of valid actions can be deduced from additional classes registered for Person.

c) Additional behaviors as service providers

In the present embodiment, the storage platform API (API) provides a mechanism by which additional classes can be registered as “services” for a given type. This allows the application to install and obtain service providers (= additional classes) of this type. Additional classes that wish to use this mechanism must implement a well-known interface; eg:

interface IChatServices

{

void SendMessage (string msg);

event MessageReceivedHandler MessageReceived;

}

class WindowsMessengerServices: IChatServices

{

...

}

class YahooMessengerServices: IChatServices

{

...

}

All storage platform API data classes (APIs) implement the ICachedServiceProvider interface. This interface extends the System.IServiceProvider interface as follows:

interface ICachedServiceProvider: System.IServiceProvider

{

void SetService (System.Type type, Object provider);

void RemoteService (System.Type type);

}

Using this interface, applications can install an instance of a service provider and also request a specific type of service provider.

To support this interface, the storage platform data class maintains a hash table of service providers with a key of type. When a service provider is requested, the implementation first searches the hash table to check whether a service provider of the specified type has been specified. If not, the registered service provider infrastructure is used to identify the service provider of the specified type. Then an instance of this provider is created, added to the hash table and returned. Note that it is also possible that the shared data class method queries the service provider and directs the operation to that provider. For example, this can be used to provide the Send method of a mail message class that uses a user-defined email system.

9. Integrated design period environment

This section describes how the Storage Platform Schema is transformed into Client Storage Platform APIs and Storage Classes (UDT) on the server according to the present embodiment. The diagram in FIG. 24 shows the components involved.

With reference to FIG. 24, the types in the schema are contained in a .pdf (XML) file (block 1). This file also contains the field level and item level restrictions associated with the circuit. The generator (xfs2cs.exe - block 2) of the Storage Platform Class accepts this file and generates partial classes for the opt-in (UDT) (block 5) of the storage and partial classes for the classes (block 3) of the client. For each schema domain, there are additional methods that the inventors call domain behavior methods. There are domain behavior methods that make sense on the repository (block 7), on the client (block 6), and in both places (block 4). The code in blocks 4, 6 and 7 is written manually (not automatically generated). The partial classes in blocks 3, 4, and 6 together form the full implementation of the classes for the API classes of the storage platform domains. Blocks 3, 4, and 6 are compiled (block 8) to form storage platform API classes - block 11 (in fact, the storage platform API (API) is the result of compiling blocks 3, 4, and 6, which are the result of all the initial domains of the scheme ) In addition to domain classes, there are additional classes that implement an additional behavior method. These classes use one or more classes in one or more schema domains. This is represented by block 10. The partial classes in blocks 4, 5, and 7 together form the complete implementation of the classes for the classes of the opt-in (UDT) server. Blocks 4, 5, and 7 are compiled (block 9), forming a server-side OPT assembly (UDT) - block 12 (in fact, server-side OPT assembly (UDT) is the result of the compiler plus compiling blocks 4, 5 and 7, which are result of all the initial domains of the scheme). The module (block 13) of the Dynamic Data Library Command Generator (DBD; DDL) receives the assembly (block 12) of the OPT (UDT) and the file (block 1) of the Scheme and installs them in the data warehouse. This process involves, among other things, generating tables and views for types in each schema.

10. Request formalism

Turning to the basics, the application template when using the storage platform API (API) is: Open ItemContext; use Find with filter criteria to retrieve the required objects; perform an operation on objects and send the changes back to the repository. This section deals with the syntax of what is used in the filter string.

The filter string provided when a search for storage platform data objects is performed describes the conditions that the properties of objects must satisfy in order to be returned. The syntax used in the storage platform API (API) supports type casting and association.

a) Filter Basics

The filter string is either empty, indicating that all objects of a given type should be returned, or a Boolean expression that each returned object must satisfy. The expression refers to the properties of the object. The storage platform APIs for the storage platform know how these property names map to field names such as the storage platform and, ultimately, to SQL Server views supported by storage platform storage.

Consider the following examples:

// Find all the people

FindResult res1 = Person.FindAll (ctx)

// Find all people who have a Gender property value

// equal to "Male"

FindResult res2 = Person.FindAll (ctx, "Gender = 'Male'")

// Find all people who have a Gender property value

// equal to "Male" and who were born in the last millennium.

FindResult res3 = Person.FindAll (

ctx

"Gender = 'Male' And Birthdate <'1/1/2001'")

Properties of nested objects can also be used in the filter. For example:

// Find all people who have been modified in the last 24 hours

FindResult res1 = Person.FindAll (

ctx

String.Format ("Item.Modified> '{0}'", DateTime.Now.Subtract (new TimeSpan (24,0,0))));

For collections, you can filter members using the condition in square brackets. For example:

// Find all people with the name "John" and last name

// "Smith"

FindResult res1 = Person.FindAll (

ctx

"PersonalNames [GivenName = 'John' And Surname = 'Smith']")

// Find all people with a direct address from provider 'x'

// and with operational status category 'y'

FindResult res2 = Person.FindAll (

ctx

"PersonalRealtimeAddress [ProviderURI = 'x']. BasicPresence." +

"OnlineStatus.Category = 'y'")

The following example lists all people who were born after 12/31/1999:

ItemContext ctx = ItemContext.Open ("Work Contacts");

FindResult results =

Person.FindAll (ctx, "Birthdate> '12 / 31/1999 '");

foreach (Person person in results)

Console WriteLine (person.DisplayName);

ctx.Close ();

Line 1 creates a new ItemContext to access the “Work Contacts” on the shared storage platform resource on the local computer. Lines 3 and 4 receive a collection of Person objects, where the Birthdate property sets the date after 31/12/1999, as specified by the expression "Birthdate> '12 / 31/1999 '." The execution of this FindAll operation is illustrated in FIG.

b) Type casting

It often happens that the type of value stored in a property is inferred from the type with declared properties. For example, the PersonalEAddresses property in Person contains a collection of types derived from EAddress, such as EMailAddress and TelephoneNumber. To filter based on the telephone code of the zone, you need a cast from the EAddress type to the TelephoneNumber type:

// Find all people with a phone number in area code 425

FindResult res1 = Person.FindAll (

ctx

"PersonalEAddresses." +

"Cast (System.Storage.Contact.TelephoneNumber))." +

"AreaCode = '425'");

// Alternatively, you can pass the type name as follows:

FindResult res1 = Person.FindAll (

ctx

String.Format ("PersonalEAddresses.Cast ({0})). AreaCode = '425'",

typeof (TelephoneNumber) .FullName))

c) Filter syntax

The following is a description of the filter syntax supported by the storage platform API (API) according to one embodiment.

Filter :: = EmptyFilter | Condition

EmptyFilter :: =

Condition :: = SimpleCondition | CompoundCondition |

Parentalized condition

SimpleCondition :: = ExistanceCheck | Comparison

ExistanceCheck :: = PropertyReference

Comparison :: = PropertyReference ComparisonOp Constant

CompoundCondition :: = SimpleCondition BooleanOp Condition

ParenthesizedCondition :: = '(' Condition ')'

ComparisonOp :: = '! =' | '==' | '=' | '<' | '>' | '> =' | '<='

BooleanOp :: = 'And' | '&&' | 'Or' | '||'

Constant :: = StringConstant | NumericConstant

StringConstant :: = '''( any Unicode character ) *'''

Note: inserted characters' are disabled by duplication.

NumericConstant :: = 0-9 *

PropertyReference :: = SimplePropertyName | CompoundPropertyName

SimplePropertyName :: = ( all Unicode characters except '.' And space ) * Filter?

Filter :: = '[' Condition ']'

CompoundPropertyName :: =

(TypeCast | RelationshipTraversal | SimplePropertyName) '.' PropertyReference

Typecast :: = 'Cast (' TypeName ')'

RelationshipTraversal :: = TraversalToSource | TraversalToTarget

TraversalToSource :: = 'Source (' FullRelationshipName ')'

TraversalToTarget :: = 'Target (' FullRelationshipName ')'

TypeName :: = fully qualified name of the type of NLDW (CLR)

FullRelationshipName :: = SchemaName '.' RelationshipName

SchemaName :: = the storage platformName

RelationshipName :: = the storage platformName

the storage platformName :: = as defined in [SchemaDef]

11. Remote interaction

a) Local / remote transparency in the API (API)

Access to data in the storage platform targets a local instance of the storage platform. The local instance serves as a router if the request (or part of it) refers to remote data. The API level thus provides local / remote transparency: there is no structural difference in the API (API) between access to local and remote data. This is just a feature of the requested scope.

The storage platform data warehouse also implements distributed queries; in this way, you can connect to a local instance of the storage platform and run a query that includes items from different volumes, some of which are located on local storage and others on remote storage. The repository combines the results and presents them to the application. From the perspective of the storage platform API (and therefore the application developer), any remote access is completely direct and transparent.

The storage platform API allows the application to determine whether a given ItemContext (returned by the ItemContext.Open method) represents a local or remote connection using the IsRemote property - this is a property of the ItemContext. Among other things, an application may need to provide visual feedback in order to facilitate the installation of user-expected performance, reliability, etc.

b) Implementation of the remoting storage platform

The storage platform data warehouses communicate with each other using a special provider of OLEDB (OLEDB), which is implemented using the Hypertext Transfer Protocol (HTTP); (the OLEDB provider uses the table data stream transfer protocol (PDD; TDS by default) . In one embodiment, the distributed query is processed by the OPENROWSET default functionality of the relational database processor. A special user-defined function (UDF) DoRemoteQuery (server, queryText) is provided to perform the actual remote interaction.

c) Access to non-storage platform storage

In one embodiment of the storage platform of the present invention, there is no generic provider architecture that enables any storage to participate in accessing the storage platform data. However, there is a limited provider architecture for the specific case of Microsoft Exchange and Microsoft Active Directory (AD). This means that developers can use the storage platform APIs and access data in AD and Exchange as if they were in a storage platform, but that the data they can access is limited to the schematized types of storage platform. Thus, the address book (= collection of Person types of the storage platform) is supported in AD, and mail, calendar, and contacts are supported for Exchange.

d) RFU Relations (DFS)

The distributor of storage platform properties does not extend beyond mount points. Even if the namespace is full enough to access through mount points, requests do not go through them. Storage platform volumes can look like leaves in an RFF tree (DFS).

f) Links to GAR (GXA) / Indigo

A developer can use the storage platform API (API) to deploy the “GAR Headend (GXA)” at the top of the data warehouse. Conceptually, this is no different from creating any other web service. The storage platform API (API) does not interact with the storage platform data warehouse using the GAR (GXA). As mentioned above, the API (API) interacts with local storage using the PDD (TDS); any remote interaction is controlled by local storage using the synchronization service.

12. Limitations

The storage platform data model allows type limits. These restrictions are evaluated on the repository automatically, and the process is transparent to the user. Note that restrictions are checked on the server. Having noted this, it is sometimes desirable to provide the developer with the flexibility to verify that the input meets the constraints without causing the overhead of a full crawl for the server. This is especially useful in interactive applications where the end user enters data that is used to populate an object. The storage platform API (API) provides this capability.

Recall that a storage platform schema is defined in a .png (XML) file that is used by the storage platform to generate the corresponding database objects representing the schema. It is also used by the Storage Platform Integrated Environment Design Period (API) framework to automatically generate classes.

Here is a partial listing of the RNR (XML) file used to generate the Contacts schema:

<Schema Name = "Contacts" MajorVersion = "1" MinorVersion = "8">

<ReferencedSchema Name = "Base" MajorVersion = "1" />

<Type Name = "Person" MajorVersion = "1" MinorVersion = "0"

ExtendsType = "Principal" ExtendsVersion = "1">

<Field Name = "Birthdate" Type = "the storage platformTypes.datetime"

Nullable = "true" MultiValued = "false" />

<Field Name = "Gender" Type = "the storage platformTypes.nvarchar (16)"

Nullable = "true" MultiValued = "false" />

<Field Name = "PersonalNames" Type = "FullName" TypeMajorVersion = "1"

Nullable = "true" MultiValued = "true" />

<Field Name = "PersonalEAddresses" Type = "EAddress"

TypeMajorVersion = "1" Nullable = "true" MultiValued = "true" />

<Field Name = "PersonalPostalAddresses" Type = "PostalAddress"

TypeMajorVersion = "1" Nullable = "true" MultiValued = "true" />

<Check> expression </Check>

</Type>

...

...

</Schema>

The validation tags in the RNR (XML) above define restrictions on the type Person. There can be more than one validation tag. The above limitation is usually checked in the repository. To specify that the constraint can also be explicitly checked by the application, the aforementioned RNR (XML) is modified like the one below:

<Schema Name = "Contacts" MajorVersion = "1" MinorVersion = "8">

<ReferencedSchema Name = "Base" MajorVersion = "1" />

<Type Name = "Person" ...>

<Field Name = "Birthdate" Type = "the storage platformTypes.datetime"

Nullable = "true" MultiValued = "false" />

...

<Check InApplication = "true"> expression </Check>

</Type>

...

...

</Schema>

Note the new "InApplication" attribute of the <Check> element, which is set to true. This causes the detection of an API (API) storage platform restrictions in the API (API) using an instance of the Person class called Validate (). An application can call this object method to ensure that the data is valid, and to prevent a potentially useless full crawl for the server. It returns a boolean expression to indicate the results of the check. Note that value restrictions still apply on the server, regardless of whether or not the client calls the <object> .Validate () method. Here is an example of how Validate can be used:

ItemContext ctx = ItemContext.Open ();

// Create a contact in the user folder My Contacts.

Folder f = UserDataFolder.FindMyPersonalContactsFolder (ctx);

Person p = new Person (f);

// Create the person’s birthday

p.Birthdate = new DateTime (1959, 6, 9);

// Add a name categorized as a personal name

FullName name = new FullName (FullName.Category.PrimaryName);

name.GivenName = "Joe";

name.Surname = "Smith";

p.PersonalNames.Add (name);

// check the Person object

if (p.Validate () == false)

{

// data does not represent a valid person

}

// save changes

p.Update ();

ctx.Close ();

There are many ways to access storage platform storage — the storage platform's API (API), ADO.Net, the open database interface (ODBC), SRED (OLEDB), and ActiveX data objects (ADO). This raises the question of checking the reliability of constraints, i.e. how can we guarantee that data recorded from, for example, ODIVB, pass through the same data integrity restrictions as data written from the storage platform API (API). Since all restrictions are checked in the repository, the restrictions are now reliable. Regardless of which API path (API) is used to access the repository, all records in the repository are filtered using checks of restrictions in the repository.

13. Sharing

The shared resource in the storage platform is:

\\ <SDI Name> \ <Context Service>,

where <SDI Name> is the name of the domain name service (DNS; DNS) of the machine, and <Context Service> is the inclusion folder, virtual folder, or item in the volume on this machine. For example, suppose the Johns_Desktop machine has a volume named Johns_Information, and in this volume there is a folder called Contacts_Categories; this folder contains a folder called Work, which has work contacts for John:

\\ Johns_Desktop \ Johns_Information $ \ Contacts_Categories \ Work

It can be shared as WorkContacts. With the definition of this shared resource, \\ Johns_Desktop \ WorkContacts \ JaneSmith is the name valid for the storage platform and identifies the Person JaneSmith object.

a) Presentation of a shared resource

The type of the shared resource object has the following properties: the name of the shared resource and the purpose of the shared resource (this may be a non-attachment relationship). For example, the aforementioned shared resource name is WorkContacts, and the target is Contacts_Categories \ Work on the Johns_Information volume. Below is a fragment of the diagram for the Share type:

<Schema

xmlns = "http://schemas.microsoft.com/winfs/2002/11/18/schema"

Name = "Share" MajorVersion = "1" MinorVersion = "0">

<ReferencedSchema Name = "Base" MajorVersion = "l" />

<ReferencedSchema Name = "the storage platformTypes" MajorVersion = "l" />

<Type Name = "Share" MajorVersion = "1" MinorVersion = "0"

ExtendsType = "Base.Item" ExtendsVersion = "1">

<Field Name = "Name" Type = "the storage platformTypes.nvarchar (512)"

TypeMajorVersion = "1" />

<Field Name = "Target" Type = "Base.RelationshipData" TypeMajorVersion = "1" />

</Type>

</Schema>

b) Shared Resource Management

Since a shared resource is an item, shared resources can be managed, like other items. A shared resource can be created, deleted, and modified. Shared resource protection is also provided, similar to other storage platform items.

c) Access to shared resources

The application accesses the shared resource of the remote storage platform by passing the name of the shared resource (for example, \\ Johns_Desktop \ WorkContacts) to the storage platform API in the call to the ItemContext.Open () method. ItemContext.Open returns an instance of the ItemContext. The storage platform API (API) then interacts with the local storage platform service (recall that access to the shared resources of the remote storage platform is performed using the local storage platform). In turn, the local storage platform service interacts with the remote storage platform service (for example, on a Johns_Desktop machine) with a given shared resource name (for example, WorkContacts). The Remote Storage Platform service then converts WorkContacts to Contacts_Categories \ Work and opens it. After that, the request and other operations are performed in the same way as other scopes.

d) Detectability

In one embodiment, the application program can detect the shared resources available on this <LED Name>, as follows. According to the first method, the storage platform API (API) accepts the name of the DNS (DNS) (for example, Johns_Desktop) as the scope parameter in the ItemContext.Open () method. The storage platform API (IPP) is then connected to the storage of the storage platform with this SDI name (DNS) as part of the connection string. With this connection, the only possible thing the application can do is call ItemContext.FindAll (typeof (Share)). The storage platform service then consolidates all shared resources on all attached volumes and returns a collection of shared resources. According to the second method, on the local machine, the administrator can easily find shared resources on a specific volume using FindAll (typeof (Share)) or a specific folder using FindAll (typeof (Share), "Target (ShareDestination) .Id = FolderId").

14. Semantics of Find

Find * methods (regardless of whether they are called on an ItemContext or an individual item) are mainly applied to Items (including embedded items) in this context. Nested items do not have Find - you cannot search on them regardless of their including Items. This is consistent with the semantics required by the storage platform data model, where nested elements derive their “identity” from the enclosing item. To make this clearer, examples of valid and invalid search operations are given here:

a) Show all the phone numbers in the system that have area code 206?

Invalid because the search is performed by phone numbers - item - without a link to the item.

b) show all phone numbers in all Person that have area code 206?

Invalid, even if it refers to Person (= item), the search criteria does not include this item.

c) Show all Murali phone numbers (= one single person) that have area code 206?

Valid because there is a search criterion for an Item (Person named "Murali"). An exception to this rule are types of nested elements that are derived directly or indirectly from the Base.Relationship type. These types can be requested individually using link classes. Such queries can be supported, since the storage platform implementation uses the “main linking table” to store Relationship elements instead of embedding them in the object's UDTs.

15. IPP (API) contacts storage platform

This section provides an overview of the Storage Platform Contacts API. The circuitry supported by the IPP (API) of the Contacts is shown in FIGS. 21A and 21B.

a) System.Storage.Contact Overview

The storage platform API (API) includes a namespace for working with objects and elements in the Contacts schema. This namespace is called System.Storage.Contact.

This scheme has, for example, the following classes:

- Items : UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location

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

b) Domain Behaviors

The following is a list of domain behavior methods for the Contacts schema. When viewed from a sufficiently high level, domain behavior methods fall into well-recognized categories:

- Static helper functions, for example, Person.CreatePersonalContact () to create a new personal contact;

- Helper functions of instances, for example, user.AutoLoginToAllProfiles (), which registers the user (an instance of the User class) in all profiles that are marked for automatic registration;

- CategoryGUID, for example, Category.Home, Category.Work, etc .;

- Derived properties, for example, emailAddress () - returns a string that combines the username and domain fields of the given emailAddress (= instance of the EmailAddress class); and

- Derived collections, for example, person.PersonalEmailAddresses - if you have an instance of the Person class, we get her personal email addresses.

The table below shows for each class in Contacts that has domain behavior methods, a list of these methods and the category to which they belong.

Basicpresence Unified Resource Identifiers (URIs) categories UnknownCategoryURI, OfflineCategoryURI, BusyCategoryURI, AwayCategoryURI, OnlineCategoryURI Static Helper Functions ConvertPresenceStateToString - formats the presence state as a localized string (in fact, you need to add localization; exactly what friendly English string currently does). Category GUID category Home, Work, Primary, Secondary, Cell, Fax, Pager EmailAddress Derived Properties Address - combines the username and domain Static Helper Functions IsValidEmailAddress Folder Derived Properties GetChildItemCollection - Creates a collection of items based on the Targets from the FolderMembership. Static Helper Functions GetKnownFolder - specialized queries for getting well-known folders AddToPersonalContacts - Adds an item to the well-known personal contacts folder Items Static Helper Functions GetItemFromID - Executes a request based on an ID Relationship Helper Instance Functions BindToTarget - returns Item for Target Person Derived Collections PersonalRealtimeAddresses, PersonalEmailAddresses, PersonalTelephoneNumbers Derived Properties OnlineStatus, OnlineStatusIconSource, PrimaryEmailAddress, PrimarySecurityID Static Helper Functions CreatePersonalContact, CreateTemporaryContact - creates a new identity in a well-known folder GetCurrentUser - Get Person for the currently logged in user Securityid Derived Properties UserName, DomainName, DomainUserName TelephoneNumber Helper Instance Functions SetFromUserInputString - Parses a telephone number string into parts Static Helper Functions ParseNumber - Parses a phone number string into parts User Helper Instance Functions AutoLoginToAllProfiles - logs all profiles that are marked for automatic registration

16. IPP (API) of the storage platform file

This section provides an overview of the Storage Platform File APIs according to one embodiment of the present invention.

a) Introduction

(1) Reflection of the FSST volume (NTFS) in the storage platform

The storage platform provides a way to index by content in existing volumes of FSNT (NTFS). This is done by extracting (“distributing”) the properties from each file stream or directory into the NTFS and storing these properties as Items in the storage platform.

The Storage Platform File Schema defines two types of items - File and Directory - for storing common file system entities. The Directory type is a subtype of the Folder type; it is an inclusion folder that contains other Directory objects or File objects.

A Directory object can contain Directory and File objects; it cannot contain items of any other type. As for the storage platform, the Directory and File objects are read-only from any data access API. The File System Distribution Manager (FSPM) service asynchronously distributes the changed properties to the storage platform. The properties of File and Directory objects can be changed using the Win32 API. The storage platform API can be used to read any properties of these items, including the stream associated with the File item.

(2) Creating a File and Directory in the storage platform namespace

When an FSNT volume (NTFS) becomes common before a storage platform volume, all files and directories in it are located in a specific part of that volume. This area is read-only on the storage platform side; FSPM can create new directories and files and / or modify the properties of existing items.

The rest of the namespace of this volume may contain the usual range of types of storage platform items — Principal, Organization, Document, Folder, etc. The storage platform also allows you to create Files and Directories in any part of the storage platform namespace. These "native" Files and Directories have no equivalents in the FSNT file system (NTFS); they are stored exclusively in the storage platform. In addition, changes in properties immediately become visible.

However, the programming model remains the same: they nevertheless remain read-only, as for the APIs for accessing storage platform data. Native Files and Directories must be updated using Win32 APIs. This simplifies the intelligent developer model, which is:

1. Any type of storage platform item can be created anywhere in the namespace (unless it is prevented by permissions, of course).

2. Any type of storage platform item can be read using the storage platform's API (API).

3. Any type of storage platform item is recordable using the storage platform's API (API), with the exception of File and Directory.

4. To write to File and Directory objects, regardless of where they are in the namespace, use the Win32 API.

5. Changes to File / Directory objects in the “distribution” namespace may not appear immediately in the storage platform; in the “without distribution” namespace, changes are reflected immediately in the storage platform.

b) File schema

25 illustrates a diagram on which a File API is based.

c) System.Storage.Files Overview

The storage platform API (API) includes a namespace for working with file objects. This namespace is called System.Storage.Files. The members of these classes in System.Storage.Files directly reflect the information stored in the storage of the storage platform; This information is “distributed” from file system objects or this information can be created in its own way using the Win32 API. The System.Storage.Files namespace has two classes: FileItem and DirectoryItem. The members of these classes and their methods can easily be predicted by looking at the diagram diagram in FIG. 25. FileItem and DirectoryItem are only read from the storage platform APIs. To modify them, you must use the Win32 API or classes in System.IO.

d) Code examples

this section provides three code examples that illustrate the use of classes in System.Storage.Files.

(1) Opening a file and writing to it

This example shows how to perform “traditional” file manipulation.

ItemContext ctx = ItemContext.Open ();

FileItem f = FileItem.FindByPath (ctx, @ "\ My Documents \ billg.ppt");

// example of handling file properties - make sure the file

// not only for reading

if (! f.IsReadOnly)

{

FileStream fs = f.OpenWrite ();

// Read, write, close the fs file stream

}

ctx.Close ();

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

(2) Using queries

Because storage platform storage stores properties that are distributed from the file system, powerful file queries can be easily performed. This example lists all files modified in the last three days:

// List all files modified in the last 3 days

FindResult result = FileItem.FindAll (

ctx

"Modified> = '{0}'",

DateTime.Now.AddDays (-3));

foreach (FileItem file in result)

{

...

}

Here is another example of using queries - in this example, all recorded files of a certain type are searched (= extension):

// Find all writable .cs files in a specific directory.

// Equivalent: dir c: \ win \ src \ api \ *. Cs / a-r-d

DirectoryItem dir =

DirectoryItem.FindByPath (ctx, @ "c: \ win \ src \ api");

FindResult result = dir.GetFiles (

"Extension = 'cs' and IsReadOnly = false");

foreach (File file in result)

{

...

}

e) Domain Behaviors

In one embodiment, in addition to the standard properties and methods, the file class also has domain behavior methods (manually encoded properties and methods). These behaviors are mainly based on the methods in the corresponding System.IO classes.

J. CONCLUSION

As the foregoing illustrates, 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 principles of data storage beyond existing file systems and database systems and is intended to be a repository for all types of data, including structured, unstructured or semi-structured data, such as relational (tabular) data, RNR ( XML) and a new data form called Items. Through its common storage base and schematized data, the storage platform of the present invention enables more efficient application development for customers, information analysis and processing specialists, and enterprises. It offers a powerful and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also extends and extends the existing file system and database access methods. It is understood that in the embodiments described above, changes can be made without departing from their broad ideas of the invention. Therefore, the present invention is not limited to the specific described embodiments, but it is intended to cover all modifications that fall within the spirit and scope of the invention defined in the appended claims.

As is apparent from the above, all or parts of the various systems, methods, and aspects of the present invention may be implemented as program code (i.e., instructions). This program code can be stored on computer-readable media such as magnetic, electrical or optical storage media, including but not limited to floppy disks, compact discs (CD-ROM), rewritable compact discs (CD-RW), read-only DTMs (DVD-ROM), rewritable digital media (DVD-RAM), magnetic tape, flash memory, hard drive or any other machine-readable storage medium in which, when program code is downloaded and executed by a machine, such as a computer or server, the car becomes mouth A tool for practicing the invention. The present invention can also be implemented in the form of program code that is transmitted over some data transmission medium, such as via electric wires or cables, via fiber optic cables, via a network, including the Internet or an intranet, or by any other type of transmission in which, when the program code is received and downloaded and executed by a machine, such as a computer, the machine becomes a device for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor and provides a unique device that works similarly to special logic circuits.

APPENDIX A

namespace System.Storage

{

abstract class ItemContext: IDisposable, IServiceProvider

{

Members creating and managing ItemContext

// Applications cannot create objects directly

// ItemContext, nor derive classes from ItemContext.

interal ItemContext ();

// Create an ItemContext that can be used to

// search for given paths, or if no path is specified,

// default storages on the local computer.

public static ItemContext Open ();

public static ItemContext Open (string path);

public static ItemContext Open (params string [] paths);

// Returns the paths specified when it was created

// ItemContext.

public string [] GetOpenPaths ();

// Create a copy of this ItemContext. Copy will have

// independent state of transaction, caching and

// updates. The cache will initially be empty. Expected,

// that using a cloned ItemContext will be more

// efficient than opening a new ItemContext using

// same domain (s) of items.

public ItemContext Clone ();

// Close ItemContext. Any attempt to use

// ItemContext, after it is closed, will be

// throw an ObjectDisposedException.

public void Close ();

void IDisposable.Dispose ();

// True, if any domain specified when it was opened

// ItemContext, allowed for the remote computer.

public bool IsRemote {get; }

// Returns an object that the requested one can provide

// type of service. Returns null if cannot be

// requested service provided. Using a template

// IServiceProvider makes factorization of APIs possible,

// which are normally not used and can be confusing

// developers, from the ItemContext class. ItemContext can

// provide the following types of services: IItemSerialization,

// IStoreObjectCache

public object GetService (Type serviceType);

Upgrade related members

// Save Changes Submitted By Everyone

// modified objects and all objects,

// passed to MarkForCreate or MarkForDelete. Can

// throw UpdateCollisionException if detected

// update conflict.

public void Update ();

// Save the changes represented by the given objects.

// Objects must be either modified or transferred

// MarkForCreate or MarkForDelete, otherwise created

// ArgumentException. Can create

// UpdateCollisionException if a conflict is detected

// updates.

public void Update (object objectToUpdate);

public void Update (IEnumerable objectsToUpdate);

// Regenerates the contents of the specified objects from the repository.

// If the object has been modified, change

// overwrite, and the object is no longer considered

// modified. Throws an ArgumentException if

// something other than an item, an item extension, or

// communication.

public void Refresh (object objectToRefresh);

public void Refresh (IEnumerable objectsToRefresh);

// Set when the update detects that

// data has been changed in the storage between when

// the modified object was retrieved, and when it was

// an attempt was made to save it. If not

// event handler registered, update creates

// exception. If a handler is registered

// events, it can create an exception for

// prematurely stop updating, call

// overwrite the modified data object in the storage

// or merge changes made to the repository and to

// object.

public event ChangeCollisionEventHandler UpdateCollision;

// Set at various points during processing

// updates to provide information on the progress of the process

// updates.

public event UpdateProgressEventhandler UpdateProgress;

// Asynchronous Version Updates

public IAsyncResult BeginUpdate (IAsyncCallback callback, object state);

public IAsyncResult BeginUpdate (object objectToUpdate,

IAsyncCallback callback,

object state);

public IAsyncResult BeginUpdate (IEnumerable objectsToUpdate,

IAsyncCallback callback,

object state);

public void EndUpdate (IAsyncResult result);

// Asynchronous versions of regeneration

public IAsyncResult BeginRefresh (object objectToRefresh,

IAsyncCallback callback,

object state);

public IAsyncResult BeginRefresh (IEnumerable objectsToRefresh,

IAsyncCallback callback,

object state);

public void EndRefresh (IAsyncResult result);

Transactional Members

// Start the transaction with the specified isolation level.

// The default isolation level is ReadCommited.

// In all cases, a distributed transaction is triggered,

// since it can, if necessary, cover

// typed properties of the items in the change flow.

public Transaction BeginTransaction ();

public Transaction BeginTransaction (System.Data.IsolationLevel isolationLevel);

Search Related Members

// Creates An ItemSearcher That Will Search For This

// subject context for objects of a given type.

// Throws an ArgumentException if a type other than

// subject, communication or extension of the subject.

public ItemSearcher GetSearcher (Type type);

// Finds the item by its ID.

public Item FindItemById (ItemId ItemId);

// Finds an item along its path. The path may be absolute

// or relative. If it is relative, then it is created

// NotSupportedException if multiple

// item domains when ItemContext was opened.

// Returns null if no such item exists.

// Creates a connection to the \\ machine \ part

// used domain resource to retrieve the item.

// The item will be associated with this domain.

public Item FindItemByPath (string path);

// Finds an item along its path. Path is relative

// in relation to the given domain of objects. Creates

// connection to the specified domain to retrieve the item.

// The item will be associated with this domain. Returns

// null if no such item exists.

public Item FindItemByPath (string domain, string path);

// Finds a set of items along the way. The way is

// relative to the given domains of objects,

// when the ItemContext was opened. Returns empty

// result if no such item exists.

public FindResult FindAllItemsByPath (string path);

// Finds a relationship by its ID.

public Relationship FindRelationshipById (ItemId itemID,

RelationshipId relationshipId);

// Finds the extension of the item by its ID.

public ItemExtension FindItemExtensionById (ItemId itemId,

ItemExtensionId itemExtensionId);

// Finds all items, links, or item extensions

// of the specified type, not necessarily satisfying the given

// filter. Throws an ArgumentException if a type is specified,

// different from one of these.

public FindResult FindAll (Type type);

public FindResult FindAll (Type type, string filter);

// Find any item, link, or extension of the item

// a given type that satisfies the given type.

// Throws an ArgumentException if a type other than

// one of these. Returns null if not detected

// such an object.

public object FindOne (Type type, string filter);

// Finds an item, link, or extension of the item

// a given type that matches the given filter.

// Throws an ArgumentException if a type other than

// one of these. Throws an ObjectNotFoundException, if not

// such an object was detected. Creates

// MultipleObjectsFoundException if more than one has been detected

// single object.

public object FindOnly (Type type, string filter);

// Returns true if an item, relationship, or

// extensions of an item of a given type that satisfies

// this filter. Throws an ArgumentException if set

// type other than one of these.

public bool Exists (Type type, string filter);

// Specifies how many objects returned by the search are related

// to the object identification map supported by

// via ItemContext.

public SearchCollisionMode SearchCollisionMode {get; set; }

// Set when PreserveModifiedObjects is set

// for ResultMapping. This event provides an opportunity

// selective update by application modified

// the object with the data retrieved by the search.

public event ChangeCollisionEventHandler SearchCollision;

// Embeds an object from another ItemContext in the context of this

// subject. If an object representing the same

// item, link or extension of the item no longer exists

// in this identification map ItemContext, object clone

// created and added to the map. If the object

// really exists, it is updated by state and

// the contents of the given object in a way that is

// compatible with SearchCollisionMode.

public Item IncorporateItem (Item item);

public Relationship Incorporate Relationhip (Relationship relationship);

public ItemExtension IncorporateItemExtension (ItemExtension itemExtension);

}

// Handler for ItemContext.UpdateCollision and

// ItemSearcher.SearchCollision.

public delegate void ChangeCollisionEventHandler (object source,

ChangeCollisionEventArgs args);

// Arguments for the delegate ChangeCollisionEventHandler.

public class ChangeCollisionEventArgs: EventArgs

{

// Modified object of the item, extension of the item or

// communication.

public object ModifiedObject {get; }

// Properties from the repository.

public IDictionary StoredProperties {get; }

}

// Handler for ItemContext.UpdateProgress.

public delegate void UpdateProgressEventHandler (ItemContext item Context,

UpdateProgressEventArgs args);

// Arguments for the delegate UpdateProgressEventHandler

public class ChangeCollisionEventArgs: EventArgs

{

// Current update operation.

public UpdateOperation CurrentOperation {get; }

// The object that is currently being updated.

public object CurrentObject {get; }

}

// Specifies how many objects returned by the search are related

// to the object identification map supported by

// via ItemContext.

public enum SearchCollisionMode

{

// Indicates that new objects should be created and

// returned. Ignored objects representing one and

// same item, item extension or map link

// identification. If this option is specified, do not

// Set the SearchCollision event.

DoNotMapSearchResults,

// Indicates that the objects from the identification map should be

// returned. If the contents of the object has been modified

// application, the contents of the modified

// object. If the object has not been modified, its contents

// updated with the data returned by the search. application

// can provide a handler for the SearchCollision event

// and selectively update the object as required.

PreserveModifiedObjects,

// Indicates that the objects from the identification map should be

// returned. The contents of the object are updated with data,

// returned by the search, even if the object was modified

// application. If this option is specified, it will not

// set the SearchCollision event.

OverwriteModifiedObjects

}

// Current update operation.

public enum UpdateOperation

{

// Provided when first called

// Update. CurrentObject will be null.

OverallUpdateStarting,

// Provided just before Update

// returns the result after a successful update.

// CurrentObject will be null.

OverallUpdateCompletedSucessfuIly,

// Provided just before Update creates

// exception. CurrentObject will represent

// is an exception object.

OverallUpdateCompletedUnsuccessfully,

// Provided when update starts

// object. CurrentObject will reference the object that

// will be used for updated.

ObjectUpdateStaring,

// Provided when a new connection is needed.

// CurrentObject will be a string that

// contains a path identifying the domain of objects,

// passed ItemContext.Open or retrieved from the field

// Location connection.

Openingconnection

}

}

ANNEX B

namespace System.Storage

{

// Searches for a specific type in the context of the item.

public class ItemSearcher

{

Constructors

public ItemSearcher ();

public ItemSearcher (Type targetType, ItemContext context);

public ItemSearcher (Type targetType, ItemContext context,

params SearchExpression [] filters);

The properties

// Filters used to identify matching

// objects.

public SearchExpressionCollection Filters {get;}

// ItemContext, which sets the domains to be searched

public ItemContext ItemContext {get; set;}

// Collection of search parameters.

public ParameterCollection Parameters {get;}

// Type with respect to which the crawler will work. For

// simple searches is the type of object to be returned.

public Type TargetType {get; set;}

Search methods

// Find TargetType objects that satisfy

// conditions specified by Filters. Returns empty

// FindResult if no such objects exist.

public FindResult FindAll ();

public FindResult FindAll (FindOptions findOptions);

public FindResult FindAll (params SortOption [] sortOptions);

// Find any single TargetType object that

// satisfies the conditions specified by Filters.

// Returns null if no such objects exist.

public object FindOne ();

public object FindOne (FindOptions findOptions);

public object FindOne (params SortOption [] sortOptions);

// Finds a TargetType object that satisfies

// conditions specified by Filters. Creates

// ObjectNotFoundException if no such object was found.

// Throws MultipleObjectsFoundException if found

// more than one object.

public object FindOnly ();

public object FindOnly (FindOptions findOptions);

// Determines if a TargetType exists that

// satisfies the conditions specified by Filters.

public bool Exists ();

// Creates an object that can be used to

// to do the same search more efficiently

// repeatedly.

public PreparedFind PrepareFind ();

public PreparedFind PrepareFind (FindOptions findOptions);

public PreparedFind PrepareFind (params SortOption [] sortOptions);

// Retrieves the number of records to be returned

// via FindAll ().

public int GetCount ();

// Asynchronous versions of various methods.

public IAsyncResult BeginFindAll (AsyncCallback callback,

object state);

public IAsyncResult BeginFindAll (FindOptions findOptions,

AsyncCallback callback,

object state);

public IAsyncResult BeginFindAll (SortOption [] sortOptions,

AsyncCallback callback,

object state);

public FindResult EndFindAll (IAsyncResult ar);

public IAsyncResult BeginFindOne (AsyncCallback callback,

object state);

public IAsyncResult BeginFindOne (FindOptions findOptions,

AsyncCallback callback,

object state);

public IAsyncResult BeginFindOne (SortOption [] sortOptions,

AsyncCallback callback,

object state);

public object EndFindOne (IAsyncResult asyncResult);

public IAsyncResult BeginFindOnly (AsyncCallback callback,

object state);

public IAsyncResult BeginFindOnly (FindOptions findOptions,

AsyncCallback callback,

object state);

public IAsyncResult BeginFindOnly (SortOption [] sortOptions,

AsyncCallback callback,

object state);

public object EndFindOnly (IAsyncResult asyncResult);

public IAsyncResult BeginGetCount (AsyncCallback callback,

object state);

public int EndGetCount (IAsyncResult asyncResult);

public IAsyncResult BeginExists (AsyncCallback callback,

object state);

public bool EndExists (IAsyncResult asyncResult);

// Options used when performing the search.

public class FindOptions

{

public FindOptions ();

public FindOptions (params SortOption [] sortOptions);

// Specifies whether to load delayed fields.

public bool DelayLoad {get; set;}

// The number of matches that are returned.

public int MaxResults {get; set;}

// Collection of search options.

public SortOptionCollection SortOptions {get;}

}

// Represents the name and value of the parameter.

public class Parameter

{

// Initializes the Parameter object by name and value.

public Parameter (string name, object value);

// Name of the parameter.

public string Name {get;}

// The value of the parameter.

public object Value {get; set;}

}

// Collection of parameter name / value pairs.

public class ParameterCollection: ICollection

{

public ParameterCollection ();

public int Count {get;}

public object this [string name] {get; set;}

public object SyncRoot {get;}

public void Add (Parameter parameter);

public Parameter Add (string name, object value);

public bool Contains (Parameter parameter);

public bool Contains (string name);

public void CopyTo (Parameter [] array, int index);

void ICollection.CopyTo (Array array, int index);

IEnumerator IEnumerable.GetEnumerator ();

public void Remove (Parameter parameter);

public void Remove (string name);

}

// Represents a search that has been optimized for

// multiple execution.

public class PreparedFind

{

public ItemContext ItemContext {get;}

public ParameterCollection Parameters {get;}

public FindResult FindAll ();

public object FindOne ();

public object FindOnly ();

public bool Exists ();

}

// Specifies the sorting options used in the search.

public class SortOption

{

// Initializes the object with default values.

public SortOption ();

// Initializes the SortOptions object by

// SearchExpression, order.

public SortOption (SearchExpression searchExpression, SortOrder order);

// Search for SearchExpression that identifies the property,

// which will be sorted.

public SearchExpression Expression {get; set;}

// Sets the sort order in ascending or descending order.

public SortOrder Order {get; set;}

}

// Collection of objects of sorting options.

public class SortOptionCollection: IList

{

public SortOptionCollection ();

public SortOption this [int index] {get; set;}

public int Add (SortOption value);

public int Add (SearchExpression expression, SortOrder order);

int IList.Add (object value);

public void Clear ();

public bool Contains (SortOption value);

bool IList.Contains (object value);

public void CopyTo (SortOption [] array, int index);

void ICollection.CopyTo (Array array, int index);

public int Count {get;}

IEnumerator IEnumerable.GetEnumerator ();

public void Insert (int index, SortOption value);

void IList.Insert (int index, object value);

public int IndexOf (SortOption value);

int IList.IndexOf (object value);

public void Remove (SortOption value);

void IList.Remove (object value);

public void RemoveAt (int index);

public object SyncRoot {get;}

}

// Sets the sort order using the SortOption object.

public enum SortOrder

{

Ascending,

Descending

}

}

APPENDIX C

namespace System.Storage

{

public abstract class FindResult: IAsyncObjectReader

{

public FindResult ();

// Moves FindResult to the next position in the result.

public bool Read ();

public IAsyncResult BeginRead (AsyncCallback callback, object state);

public bool EndRead (IAsyncResult asyncResult);

// The current object.

public object Current {get;}

// Returns whether or not FindResult contains any

// objects.

public bool HasResults {get;}

// Returns whether or not FindResult is closed.

public bool IsClosed {get;}

// Returns the type of items in this FindResult.

public Type ObjectType {get;}

// Closes FindResult

public void Close ();

void IDisposable.Dispose ();

// Returns an enumerator by FindResult, starting from the current

// position. Promotion of any enumerator on FindResult

// promotes all enumerators, as well as FindResult itself.

IEnumerator IEnumerable.GetEnumerator ();

public FindResultEnumerator GetEnumerator ();

}

public abstract class FindResultEnumerator: IEnumerator, IDisposable

{

public abstract object Current {get; }

public abstract bool MoveNext ();

public abstract void Reset ();

public abstract void Close ();

void IDisposable.Dispose ();

}

}

namespace system

{

// General interface for iterating over objects.

public interface IObjectReader: IEnumerable, IDisposable

{

object Current {get;}

bool IsClosed {get;}

bool HasResults {get;}

Type ObjectType {get;}

bool Read ();

void Close ();

}

// Adds asynchronous methods to IObjectReader

public interface IAsyncObjectReader: IObjectReader

{

IAsyncResult BeginRead (AsyncCallback callback, object state);

bool EndRead (IAsyncResult result);

}

}

Claims (14)

1. The method of managing the data warehouse, which consists in the fact that:
organize the data warehouse in such a way that the data warehouse contains:
Thing;
Element;
Many Links containing Inclusion and Referencing links, and Inclusion links control the life of the Items, and the mentioned Inclusion links are classified into Attachment and Deployment links, and the Item is deleted when all Attachment links for the Item are deleted;
moreover, said Item is a data unit stored in a data warehouse and has at least one of a type or subtype and includes said Item and said Set of Links, said Item being an instance of a type containing one or more fields, and wherein said plurality of Bonds is a bonding between at least two Items;
A Basic Scheme that establishes a structure for the creation and organization of each Item and establishes a fundamental set of properties; and
A Basic Scheme that defines a set of basic types, each Item being characterized in at least one basic type based on the type of the Item or the subtype of the Item. 2. The method according to claim 1, in which the data warehouse is further organized in such a way that the data warehouse contains a plurality of Items, said plurality of Items comprising a Folder of Items and at least one other Item that is a member of said Item Folder. 3. The method according to claim 1, in which the data warehouse is further arranged in such a way that the data store contains a plurality of Items, said plurality of Items containing a Category and at least one other Item that is a member of said Category. 4. The method according to claim 1, in which the data warehouse is further arranged in such a way that the data store contains a second Element, and wherein said Communication contains said second Element. 5. The method according to claim 1, in which each Item from a set of core Items is derived from a Common Single Base Item. 6. The method according to claim 1, in which the aforementioned General Unique Basic Subject is a fundamental Subject in the Basic Scheme. 7. Computer-readable media containing computer-executable instructions for performing steps in which:
organize the data warehouse in such a way that the data warehouse contains:
Thing;
Element;
Many Links containing Inclusion and Referencing links, and Inclusion links control the life of the Items, and the mentioned Inclusion links are classified into Attachment and Deployment links, and the Item is deleted when all Attachment links for the Item are deleted;
moreover, said Item is a data unit stored in a data warehouse and has at least one of a type or subtype and includes said Item and said Set of Links, said Item being an instance of a type containing one or more fields, and wherein said Set of Links is a linking between at least two Items;
A Basic Scheme that establishes a structure for the creation and organization of each Item and establishes a fundamental set of properties; and
A Basic Scheme that defines a set of basic types, each Item being characterized in at least one basic type based on the type of the Item or the subtype of the Item. 8. The computer-readable medium of claim 7, further comprising computer-executable instructions for organizing the data warehouse in such a way that the data store contains a plurality of Items, said plurality of Items comprising a Folder of Items and at least one other Item that is a member of said Item Folders. 9. The computer-readable medium according to claim 7, further comprising computer-executable instructions for organizing the data warehouse in such a way that the data warehouse contains a plurality of Items, said plurality of Items containing a Category and at least one other Item that is a member of said Category. 10. The computer-readable medium of claim 7, further comprising computer-executable instructions for organizing the data store in such a way that the data store contains a second Item, and in which said Communication contains said second Item. 11. A computer system containing:
processor and
memory containing:
Thing;
Element;
Many Links containing Inclusion and Referencing links, and Inclusion links control the life of the Items, and the mentioned Inclusion links are classified into Attachment and Deployment links, and the Item is deleted when all Attachment links for the Item are deleted;
moreover, said Item is a data unit stored in a data warehouse and has at least one of a type or subtype and includes said Item and said Set of Links, said Item being an instance of a type containing one or more fields, and wherein said Set of Links is a linking between at least two Items;
A Basic Scheme that establishes a structure for the creation and organization of each Item and establishes a fundamental set of properties; and
A Basic Scheme that defines a set of basic types, each Item being characterized in at least one basic type based on the type of the Item or the subtype of the Item. 12. The computer system of claim 11, wherein the memory comprises a plurality of Items, said plurality of Items comprising an Item Folder and at least one other Item that is a member of said Item Folder. 13. The computer system of claim 11, wherein the memory contains a plurality of Items, said plurality of Items containing a Category and at least one other Item that is a member of said Category. 14. The computer system according to claim 11, in which the memory contains the second Element and in which said Communication contains the said second Element.

Images