RU2412461C2 - Systems and methods of interfacing application programs with article based storage platform - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: storage platform includes: a processor and computer-readable data medium on which instructions are recorded, computer-executed operating system functions having a kernel which includes data base management apparatus, generation of elements which include metadata and storage of elements, where the database management apparatus contain a base scheme and a mechanism which is configured to expand said base scheme for determining the data scheme and separation of data into program-defined alteration elements based on the data scheme. The alteration element is the smallest part of the scheme which can be separately controlled by database management apparatus.

EFFECT: fast access to data storage.

16 cl, 35 dwg

Description

Cross reference

The invention is related to the inventions disclosed in the following general assignment applications: US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1748) filed simultaneously with this application, entitled "SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION "; US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1749), filed simultaneously with this application, entitled "SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION"; US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1750), filed simultaneously with 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 "; U.S. Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1751), filed simultaneously with 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 "; US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-1752), filed simultaneously with this application, entitled "SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM"; US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-2734) filed simultaneously with this application, entitled "STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"; and US Patent Application No. (not yet assigned) (Attorney Register No. MSFT-2735), filed simultaneously with this application, entitled "SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM".

FIELD OF THE INVENTION

The present invention relates generally 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 computer system.

State of the art

Over the past decade, there has been an increase in individual disk capacity by about seventy percent (70%) per year. Moore's law accurately predicted a significant increase in the processing power of central processing units (CPUs) over the years. Wired and wireless technologies provide great connectivity and bandwidth. Provided that current trends continue, in a few years the average portable computer will have a storage capacity of about one terabyte (TB), and will contain millions of files, and hard drives with a capacity of 500 gigabytes (GB) will become widespread.

Consumers use their computers mainly for communication and for organizing personal information, whether it be data in the traditional style of a personal information system (PIM) or multimedia data, such as digital music or photographs. The volume of digital content and the ability to store raw bytes have increased significantly; however, ways of organizing and unifying these data available to consumers have not been adequately developed. Information technology specialists spend a lot of time organizing and sharing information, and according to some studies, information technology experts spend 15-25% of their time on non-productive activities related to information. According to other studies, a typical IT specialist spends about 2.5 hours daily searching for information.

Developers and information technology (IT) departments spend a lot of time and money building their own data warehouses for common storage abstractions to represent personalities, places, times and events. This leads not only to duplication of work, but also to the creation of islands of common data without any mechanisms for a common search or sharing of this data. Just imagine how many address books can exist today on the computer on which the Microsoft Windows operating system is installed. Many applications, such as email clients and personal financial programs, support separate address books, and applications can only slightly share the address book data that is individually supported by each such program. Consequently, a financial program (like Microsoft Money) cannot share the addresses of money recipients with the addresses supported in the email contacts folder (for example, Microsoft Outlook). Indeed, many users have several devices, and it would be logical if they synchronized their personal data between them and through an extensive set of additional devices, including cell phones, for such commercial services as MSN and AOL; However, to work with public documents, you basically have to attach documents to e-mail messages, i.e. act manually and ineffectively.

One of the reasons for this lack of cooperation, which is typical of traditional approaches to organizing information in computer systems, is to use file-based systems, folders and directories (“file systems”) to organize sets of files into director hierarchical folder structures based on the abstraction of the physical organization of the storage environment used to store files. The Multics operating system, developed in the 60s, first used files, folders, and directories to manipulate stored data units at the operating system level. In particular, Multics used symbolic addresses in the file hierarchy (thereby 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 was in no way associated with the file format for any single file, and the relationship between the files was not considered at the operating system level (i.e., did not relate to the position of the file in the hierarchy). With the advent of Multics, the stored data began to be organized into files, folders and directories at the operating system level. These files, in general, include the file hierarchy itself (the “directory”) embodied in a special file supported by the file system. This directory, in turn, maintains a list of entries corresponding to all other files in the directory and the node position of such files in the hierarchy (referred to as folders here). This has been the state of the art for about forty years.

Although the file system provides a reasonable representation of the information stored in the physical storage system of the computer, it is nevertheless an abstraction of this physical storage system, as a result of which the use of files requires a level of mediation (interpretation) between what the user manipulates (units having context , signs and relationships to other units), and what the operating system provides (files, folders, and directories). Therefore, users (applications and / or end users) have no choice but to enter units of information into the file system structure, even if it is inefficient, inadequate, or undesirable for any reason. In addition, the existing file systems know little about the structure of data stored in separate files and, as a result, most of the information remains locked in files that are accessible (and understandable) only for the applications that recorded them. Thus, the lack of a schematic description of information and information manipulation mechanisms leads to the creation of data silos with very little possibility of sharing data between individual silos. For example, many personal computer (PC) users have more than five different repositories that contain information about the people they chat with at some level, such as Outlook Contacts, online account addresses, Windows Address Book, Quicken Payees, and instant messenger friends lists messaging (IM), since organizing files is a significant challenge for these PC users. Since most existing file systems use a subfolder model to organize files and folders, as the number of files increases, the effort required to maintain a flexible and efficient organization scheme increases many times over. In this case, it would be very useful to have several classifications of one file; however, using hard or soft links in existing file systems is very inconvenient and difficult to implement.

Earlier, several unsuccessful attempts were made to fix file system flaws. Some of these previous attempts have involved the use of content-addressable memory to provide a mechanism for accessing data by content rather than by physical address. However, these efforts were unsuccessful because, although the content-addressable memory was useful for small-scale use by devices such as cache blocks and memory management blocks, large-scale use for devices such as physical storage media was still impossible for a number of reasons and, therefore, such a solution simply does not exist. Attempts were made to use object-oriented database systems (OODB), but these attempts, despite the strengths of the database and good non-file representations, were ineffective in processing file representations and could not be compared in speed, efficiency, and simplicity with a hierarchical structure based on folders at the system level of the hardware-software interface. Other attempts, such as attempts to use SmallTalk (and other derivatives), proved to be very effective in processing file and non-file representations, but they lacked the database features needed to efficiently organize and use the relationships existing between different data files, resulting in overall efficiency such systems proved to be unacceptable. There were attempts to use BeOS (and other similar development of operating systems) that turned out to be inadequate when processing non-file representations - they suffered the same drawbacks as traditional file systems - despite the ability to adequately represent files, while providing some necessary database features.

Database technology is another area of technology in which similar difficulties exist. For example, although the relational database model has gained great commercial success, in reality, independent software vendors (ISVs) typically use a small fraction of the functionality of relational database software products (for example, Microsoft SQL Server). On the contrary, most applications interact with such a product through simple commands such as “gets” and “puts”. Although there are a number of obvious reasons for this, such as a lack of confidence in a platform or database, one key reason that often goes unnoticed is that the database does not always provide exactly the abstractions that most commercial application providers need. For example, while the real world uses the concept of “articles”, for example, “consumers” or “orders” (together with the introduced “lowercase articles” of order as articles in or themselves), relational databases operate only in terms of tables and rows. Therefore, while an application may require aspects of consistency, blocking, security, and / or triggers at the article level (etc.), in the general case, databases provide these attributes only at the table / row level. Although this may work well if each entry is displayed on a single row in some database table, in the case of an order with multiple lowercase entries, for one reason or another the entry is actually displayed on multiple tables and, at the same time, a simple relational database system does not fully provides the correct abstraction. Therefore, the application must build logic over 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 it is easy to develop higher-level applications, since the basic relational model requires a mediation level between the application and the storage system, where the semantic data structure can be seen in the application in certain cases. Although some database vendors integrate higher-level functionality into their products, for example, providing relational capabilities of objects, new organizational models, etc., none of them has yet provided the necessary comprehensive solution, and a true comprehensive solution is which provides useful data model abstractions (for example, “articles”, “extensions”, “relationships”, etc.) for useful domain abstractions (for example, “persons”, “places”, “events”, etc. .).

In view of the above-mentioned shortcomings of existing storage technologies and databases, a new storage platform is needed that provides improved ability to organize, search and share all types of data in a computer system - a storage platform that extends the data platform beyond existing file systems and database systems and which is designed to be a repository for all data types. The present invention satisfies this need.

SUMMARY OF THE INVENTION

The following Summary of the Invention 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. On the contrary, this section serves as an introduction to the following detailed description and drawings.

The present invention relates to a storage platform for organizing, searching and sharing data. The storage platform according to the present invention extends the concept of data storage beyond existing file systems and database systems and is intended to be a storage for all types of data, including structured, unstructured or partially 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 machine. According to various embodiments of the present invention, the database engine comprises a relational database machine with relational object 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 diagrams, and the platform provides a mechanism for expanding a plurality of diagrams to define new data types (in essence, subtypes of the main types are provided by diagrams). The ability to synchronize facilitates the sharing of data between users or systems. Features similar to the file system are provided that allow the data warehouse to interact with existing file systems, but without being limited to such traditional file systems. The change tracking mechanism provides the ability to track changes to the data warehouse. The storage platform additionally contains a set of application programming interfaces that allow applications to access all of the aforementioned storage platform capabilities and access the data described in the diagrams.

According to another aspect of the invention, a data model implemented through a data warehouse defines storage units in terms of articles, elements, and relationships. An article 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 properties here). A relationship is the relationship between two articles (these and other specific terms used here can be capitalized so that they can be distinguished from other terms used in the immediate vicinity; however, there is no intention to distinguish between a capitalized term, for example “Article”, and the same term written in lowercase, for example “article”, and no such differences are implied or implied).

According to another aspect of the invention, a computer system comprises a plurality of Articles, each Article containing a discrete, stored unit of information that can be manipulated by a hardware-software interface system; the totality of the Folders of articles that form the organizational structure of the said Articles; and a software and hardware interface system for manipulating a set of Articles, each Article belonging to at least one Article Folder and may belong to more than one Article Folder.

According to another aspect of the invention, a computer system comprises a collection of Articles, each Article containing a discrete, stored unit of information that can be manipulated by a hardware-software interface system, and an Article or some of the property values of an Article are dynamically calculated and not removed from the persistent storage. In other words, the system of the hardware-software interface does not require saving the Article, and certain operations are supported, for example, the ability to list the current set of Articles or the ability to retrieve an Article by its identifier (which is more fully described in the sections where the application programming interface or API is described) of the storage platform - for example, the Article may be the current location of the cell-phone or the temperature read by the temperature sensor.

According to another aspect of the invention, a hardware-software interface system for a computer system, said software-hardware interface system manipulating a plurality of Articles, further comprises Articles related to each other by a plurality of Relationships controlled by a software-hardware interface system. According to another aspect of the invention, a software-hardware interface system for a computer system is provided, said software-hardware interface system manipulating a plurality of discrete units of information having properties understood by a software-hardware interface system. According to another aspect of the invention, a software-hardware interface system for a computer system comprises a kernel circuit for defining a plurality of Core Articles that the software-hardware interface system understands and can directly process in a predetermined and predictable order. According to another aspect of the invention, a method is disclosed for manipulating a collection of discrete information units (“Articles”) in a software-hardware interface system for a computer system, the method comprising interconnecting said Articles through a set of Relations and managing these Relations at the level of a software-hardware interface system.

According to another feature of the invention, the storage platform API provides data classes for each article, article extension, and relationship defined in a variety of storage platform schemas. In addition, the application programming interface provides many structure classes that define a common set of behaviors for data classes and which, together with data classes, provide a basic programming model for the storage platform API. According to another feature of the invention, the storage platform API provides a simplified query model that allows application developers to generate queries based on various properties of articles in a data warehouse, while the application developer is isolated from the details of the query language of the underlying database machine. According to another aspect of the storage platform API according to the present invention, the API collects the changes to the article made by the application program, and then organizes them into the correct updates required by the database machine (or storage machine of any kind) on which the data warehouse is implemented. This allows application developers to make changes to the article in memory, leaving the API complex aspects of data warehouse updates.

Due to its common storage foundation and schematized data, the storage platform according to the present invention allows more efficiently developing an application for consumers, IT professionals and enterprises. It provides a rich and extensible application programming interface that not only makes available the features inherent in this data model, but also extends and extends the existing file system and database access methods.

Other features and advantages of the invention follow from the following detailed description of the invention and the accompanying drawings.

Brief Description of the Drawings

The foregoing summary of the invention, as well as the following detailed description of the invention, can be better understood in conjunction with the accompanying drawings. To illustrate the invention, illustrative embodiments of various aspects of the invention are shown in the drawings; however, the invention is not limited to the specific methods and tools disclosed. In the drawings:

figure 1 is a block diagram of a computer system in which you can include aspects of the present invention;

figure 2 is a block diagram of a computer system divided into three components: a hardware component, a component of a software-hardware interface system and a component of application programs;

figa is a traditional tree-like hierarchical structure of files grouped into folders in a directory in a file-based operating system;

figure 3 is a block diagram of a storage platform according to the present invention;

4 is a structural relationship between Articles, Article Folders, and Categories according to various embodiments of the present invention;

figa is a block diagram of the structure of the Article;

figv is a block diagram of complex types of properties of the Article shown in figa;

figs is a block diagram of the Article "position", which further describes its complex types (listed explicitly);

figa - illustrates the Article as a subtype of the Article in the Basic scheme;

figv is a block diagram of a subtype of the Article shown in figa, which explicitly lists its own types (in addition to its direct properties);

7 is a block diagram of the Basic scheme, including its two types of top-level classes, Item and PropertyBase, and additional types of the Basic scheme derived from them;

figa is a block diagram illustrating Articles in the kernel;

Fig. 8B is a block diagram illustrating property types in a kernel diagram;

Fig.9 is a block diagram illustrating the Folder of articles, its articles and the relationship between the Folder of articles and its articles;

10 is a block diagram illustrating a Category (which, in turn, is an article itself), the articles included in it, and the relationship between the Category and the articles included in it;

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

12 is a diagram illustrating how classifying relationships according to an embodiment of the present invention;

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

Fig. 14 is a diagram illustrating an example in which two transactions insert a new record into the same binary tree;

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

Fig. 16 is an example of a directory tree;

17 is 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. 18 illustrates the concept of Enable Folders according to an embodiment of the present invention;

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

FIG. 20 schematically represents various components of a storage platform API stack;

figa and 21B is a graphical representation of an illustrative Scheme of contacts (Articles and Elements);

FIG. 22 is a structure of a storage platform API runtime in accordance with an aspect of the present invention; FIG.

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

24 illustrates a process for generating storage platform API classes from a storage platform diagram in accordance with an aspect of the present invention;

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

FIG. 26 is a diagram of a format of an access mask used to protect data according to an embodiment of the present invention; FIG.

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

28 is a diagram illustrating a concept of a search type of an Article according to an embodiment of one aspect of the present invention;

29 is a diagram of an illustrative article hierarchy according to an embodiment of the present invention. Detailed Description of the Invention

Content

I. Introduction

A. Illustrative computing environment

B. Traditional file-based storage

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

A. Glossary

B. Storage platform overview

C. DATA MODEL

1. Articles

2. Article identification

a) Links to the article

(1) ItemIDReference

(2) ItemPathReference

b) Link type hierarchy

3. Article folders and Categories

4. Schemes

a) Basic scheme

b) Kernel layout

5. Relations

a) Declaration of relationship

b) Support attitude

c) Implementation Relations

e) Rules and restrictions

f) Streamlining relationships

6. Extensibility

a) Article extensions

b) Extension of types of nested elements

D. DATABASE MACHINE

1. Implementing a data warehouse using UDT

2. Display articles

3. Display extensions

4. Display of nested elements

5. Object identification

6. Naming SQL objects

7. Naming columns

8. Types of search

a) Article

(1) The main type of article search

(2) Typed Article Search Types

b) Article extensions

(1) Main view of extension search

(2) Typed extension search types

c) Nested elements

d) Relationships

(1) The main type of relationship search

(2) Types of relationship instance search

9. Updates

10. Track changes and gravestones

a) Change tracking

(1) Track changes in the “main” types of searches

(2) Tracking changes in typed search types

b) Tombstones

(1) Tombstones articles

(2) Gravestone extensions

(3) Tombstones of a relationship

(4) Tombstone Cleaning

11. API and helper functions

a) Function [System.Storage] .GetItem

b) Function [System.Storage] .GetExtension

c) Function [System.Storage] .GetRelationship

12. Metadata

a) Schema metadata

b) Instance metadata

E. Security

1. Overview

2. Detailed description of the security model

a) Security descriptor structure

(1) Access mask format

(2) General permissions

(3) Standard access rights

b) Article-specific rights

(1) Rights depending on the object “file” and “directory”

(2) WinFSItemRead

(3) WinFSItemReadAttributes

(4) WinFSItemWriteAttributes

(5) WinFSItemWrite

(6) WinFSItemAddLink

(7) WinFSItemDeleteLink

(8) Rights to delete an article

(9) Rights to copy an article

(10) Rights to Move Articles

(11) Rights to view security policy on an article

(12) Rights to change security policy on the article

(13) Rights not directly equivalent

3. Implementation

a) Create a new article in the container

b) Adding an explicit ACL to the article

c) Adding a support relationship to an article

d) Removing a support relationship from an article

f) Removing an explicit ACL from an article

f) Change in ACL associated with an article

F. Notification and Change Tracking

1. Saving change events

a) Events

b) Observers

2. Change tracking and notification mechanism

a) Change tracking

b) Time stamp management

c) Data change detection - event detection

G. Sync

1. Synchronization between storage platforms

a) Synchronization management applications

b) Annotation of the scheme

c) Sync configuration

(1) Community Folder - Mappings

(2) Profiles

(3) Schedules

d) Conflict handling

(1) Conflict Detection

(a) Knowledge-based conflicts

(b) Conflict based conflicts

(2) Conflict Handling

(a) Automatic conflict resolution

(b) Conflict Records

(c) Inspection and resolution of conflicts

(d) Convergence of copies and distribution of conflict resolution

2. Synchronization with data warehouses not related to the storage platform

a) Sync services

(1) Listing Changes

(2) Application of changes

(3) Conflict Resolution

b) adapter implementation

3. Security

4. Manageability

H. Interoperability with traditional file systems

1. Interaction model

2. Data Warehouse Features

a) Not that

b) Storage structure

c) Not all files migrate

d) Access from the NTFS namespace to storage platform files

e) The expected namespace / drive letters

I. STORAGE PLATFORM API

1. Overview

2. Naming and scopes

3. Storage Platform API Components

4. Data classes

5. The structure of the runtime environment

a) Runtime structure classes

(1) ItemContext

(2) ItemSearcher

(a) Target type

(b) Filters

(c) Preparing searches

(d) Find options

b) Runtime structure during work

(1) Opening and closing ItemContext objects

(2) Object Search

(a) Search options

(b) FindOne and FindOnly

(c) Short search calls on ItemContext

(d) Finding by ID or path

(f) GetSearcher Template

6. Security

7. Relationship 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 relationship types

(1) Generated Relationship Types

(2) RelationshipPrototype class

(3) RelationshipPrototypeCollection Class

c) Relationship support in the class Item

(1) Item class

(2) RelationshipCollection class

d) Relationship support in search expressions

(1) Transition from articles to relationships

(2) Transition from relationship to articles

(3) Combination of circumvention

e) Examples of using relationship support

(1) Relationship search

(2) Navigation from relationship to source and target articles

(3) Navigation from source articles to relationships

(4) Creating relationships (and articles)

(5) Deleting relationships (and articles)

8. "Extension" of the storage platform API

a) Domain Behaviors

b) Add Value Behaviors

c) Value-adding behaviors as service providers

9. The structure of the development environment

10. Request formalism

a) Basics of filtration

b) Type casts

11. Remote operations

a) Local / remote transparency in the API

b) Implementing remote operations on the storage platform

c) Access to non-storage vaults

d) Relation to DFS

f) Attitude towards 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. Storage platform Contacts API

a) System.Storage.Contact Overview

b) Domain Behavior

16. Storage Platform API File

a) Introduction

(1) Reflection of an NTFS volume on a storage platform

(2) Creating files and directories 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 specifically described in order to satisfy the established requirements. However, the description itself is not intended to limit the scope of this patent. In contrast, the inventors contemplate that the claimed subject matter can be embodied in other ways, including other steps or combinations of steps similar to those described in this document, together with other current or future technologies. In addition, although the term “step” can be used here to mean various elements of the methods used, the term should not be interpreted as implying any particular order among or between the various steps disclosed here, unless and until the order of the individual steps has been explicitly described.

A. Illustrative computing environment

Numerous embodiments of the present invention may be performed on a computer. Figure 1 and the following description are intended to provide a brief, general description of a suitable computing system environment in which the invention may be implemented. Although not required, various aspects of the invention can be described in the general context of computer-executable instructions, for example, program modules, executed by a computer, for example, a client workstation or server. In general, program modules include procedures, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In addition, the invention can be practiced in other computer system configurations, including handheld devices, multiprocessor systems, microprocessor or programmable consumer electronics, network PCs, minicomputers, universal computers, and the like. The invention can also be applied in practice in distributed computing environments where tasks are performed by remote processing devices connected to each other via a data network. In a distributed computing environment, program modules are located on both local and remote computer storage devices.

1, a general-purpose illustrative computing system includes a traditional personal computer 20 and the like, including a processor 21, a system memory 22, and a system bus 23 that connects various components of the system, including system memory, to the processor 21. The system bus 23 may refer to any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using various bus architectures. System memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. Basic input / output system (BIOS) 26, which contains basic procedures that help transfer information between computer elements, for example, at startup, are usually stored in ROM 24. The personal computer 20 may also include a hard disk drive 27 that reads from or writes to a stationary hard disk that is not shown, a magnetic disk drive 28 that reads from or writes to a removable magnetic disk 29, and an optical disk drive 30 that reads from or writes to a removable optical disc 31, for example, a CD-ROM 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 associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for personal computer 20. Although the illustrative embodiment described herein uses a hard disk, removable magnetic disk 29, and removable optical disk 31, those skilled in the art in this area it is obvious that in the illustrative form, you can also use other types of computer-readable media on which data can be stored, which m can be accessed by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAM), permanent memories (ROM), etc. Similarly, an illustrative environment may also include numerous types of tracking devices, such as thermal sensors and security and fire alarm systems, and other information sources. Various software modules can be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including the operating system 35, one or more application programs 36, other program modules 37 and program data 38. The user can enter commands and information to the personal computer 20 through 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, and the like. These and other input devices are often connected to the processor 21 via a serial port interface 46, which is connected to the system bus, but can be connected via other interfaces, for example a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 through 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 illustrative system shown in FIG. 1 also includes a host adapter 55, a small computer system interface (SCSI) bus 56, and an external storage device 62 connected to the SCSI bus 56.

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, server, router, network PC, peer device, or other common network node, and typically includes many or all of the elements described above with respect to the personal computer 20, although only storage device 50 is shown in FIG. 1. Logical connections describing nye in Figure 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, computer networks, enterprise-wide intranets and the Internet.

When used in a LAN network environment, the personal computer 20 is connected to the LAN 51 via a network interface or adapter 53. When used in a LAN network environment, the personal computer 20 typically includes a modem 54 or other means of establishing communication in a global network 52, such as the Internet. The modem 54, which may be internal or external, may be connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules described with respect to personal computer 20, or some of them, may be stored in a remote storage device. Note that the network connections shown are illustrative, and other means of establishing a communication link between computers can be used.

2, a computer system 200 can be roughly divided into three components: a hardware component 202, a software-hardware interface system component 204, and an application program component 206 (also referred to herein as a “user component” or “software component” here).

In various embodiments of the computer system 200 of FIG. 1, the hardware component 202 may comprise a central processing unit (CPU) 21, memory (ROM 24 and RAM 25), a basic input / output system (BIOS) 26, and various input / output devices ( I / O), for example, a keyboard 40, a mouse 42, a monitor 47 and / or a printer (not shown), etc. The hardware component 202 contains the basic physical infrastructure for the computer system 200.

The application component 206 contains various application programs, including but not limited to compilers, database systems, text editors, commercial programs, video games, etc. Application programs provide tools to use computer resources to solve problems, provide solutions and process data for various users (machines, other computer systems and / or end users).

The system component of the hardware-software interface 204 contains (and, in some embodiments, may contain exclusively) an operating system, which itself contains, in most cases, a shell and a kernel. An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware / software interface system component 204 may also include a virtual machine manager (VMM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM), or its functional equivalent, or other 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 software-hardware interface system is to make the computer system user-friendly and to use computer equipment efficiently.

A hardware-software interface system is usually loaded into a computer system at startup, after which it controls all application programs in a computer system. Application programs interact with the hardware-software interface system, requesting services through the application programming interface (API). Some application programs allow end users to interact with a hardware-software interface system through a user interface, such as a command language or graphical user interface (GUI).

The hardware-software interface system traditionally provides various services for applications. In a multi-tasking system of a hardware-software interface, where several programs can be executed simultaneously, the system of a hardware-software interface determines which applications should act in what order and how much time is allotted to each application before switching to another application in a queue order. The hardware-software interface system also manages the sharing of internal memory among multiple applications and operates input and output to and from connected hardware devices, such as hard drives, printers, and dial-up ports. The hardware-software interface system also sends messages to each application (and, in a specific case, to the end user) regarding the status of operations and any errors that may occur. The hardware-software interface system can also take control of batch jobs (for example, printing), so that the initiating 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 division of the program so that it runs simultaneously on more than one processor.

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

Although it is contemplated that numerous embodiments of the present invention are particularly suitable for computer systems, nothing in this document is intended to limit the invention to such embodiments. In contrast, the term "computer system" as used herein is intended to encompass any and all devices capable of storing and processing information and / or capable of using stored information to control the behavior or performance of the device itself, regardless of whether such devices are inherently electronic, mechanical logical or virtual.

B. Traditional file-based storage

In most modern computer systems, “files” are units of stored information that can 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 the main discrete (stored and retrieved) units of information (for example, data, programs, etc.) that can be manipulated by a 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 separate pieces of information. These folders, in turn, are organized into a tree-like hierarchical structure called the “directory” (discussed in more detail below). On some other hardware-software interface systems, such as DOS, z / OS and most Unix-based operating systems, the terms “directory” and / or “folder” are used interchangeably, and in earlier Apple computer systems (such as Apple IIe) instead of “ directory "uses the term" directory "; however, here all these terms are used interchangeably and are regarded as synonyms and are intended to additionally include all other equivalent terms and links to hierarchical information storage structures and their components of folders and files.

Traditionally, a directory (also called a file directory) is a hierarchical structure in which files are grouped into folders, and folders, in turn, are organized according to the relative nodal positions that make up the directory tree. For example, according to FIG. 2A, the base folder of a DOS-based file system (or “root directory”) 212 may comprise a plurality of folders 214, each of which may further comprise additional folders (as “subfolders” of a particular folder) 216, and each of they may also contain additional folders 218, and so on ad infinitum. Each of these folders can have one or more files 220, although, at the system-level hardware-software interface, the individual files in the folder have nothing in common except their position in the tree hierarchy. Not surprisingly, this approach to organizing files in a folder hierarchy indirectly reflects the physical organization of the typical storage environments used to store these files (for example, hard drives, floppy disks, CD-ROMs, etc.).

In addition to the above, each folder is a container for its subfolders and its files, i.e. Each folder has its own subfolders and files. For example, when the firmware system deletes a folder, the subfolders and files of that folder are also deleted (which, in the case of each subfolder, additionally includes its own subfolders and files recursively). Similarly, each file usually belongs to only one folder, and although the file can be copied and the copy can be in another folder, the copy of the file itself is a distinct and separate unit that does not have a direct connection with the original (for example, changing the original file does not are reflected in the copy file at the system-level hardware-software interface). In this regard, files and folders have a characteristic “physical” nature, since folders are considered as physical containers, and files are considered as discrete and separate physical elements in 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 the data platform beyond all types of existing file systems and database systems discussed above and is intended to be a repository for all types of data, including a new form of data, the so-called Articles.

A. Glossary

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

An “article” is a unit of stored information available to a system of a hardware-software interface, which, unlike a simple file, is an object having a basic set of properties that are generally supported for all objects that the shell of a system of a hardware-software interface represents to the end user . Articles also have properties and relationships that are generally supported across all types of articles, including features that allow you to introduce new properties and relationships (and discussed in more detail below).

An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer equipment. 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 exclusively comprise) an operating system. A hardware-software interface system may also include a virtual machine manager (VMM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM), or its functional equivalent, or other 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 software-hardware interface system is to make the computer system user-friendly and to use computer equipment efficiently.

B. Storage platform overview

3, a storage platform 300 according to the present invention comprises a data warehouse 302 implemented on a database engine 314. According to one embodiment, the database machine comprises a relational database machine with relational object extensions. In one embodiment, the relational database engine 314 comprises a Microsoft SQL Server relational database machine.

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

The change tracking engine 306 implemented in the data warehouse 302 provides the ability to track changes in the data warehouse. The data warehouse 302 also provides the protective capabilities 308 and the extension / retraction capability 310, discussed in more detail below. Data warehouse 302 also provides a set of application programming interfaces 312 that open data warehouse capabilities 302 to other storage platform components and applications (e.g., application programs 350a, 350b, and 350c) that use the storage platform.

The storage platform according to the present invention further comprises application programming interfaces (APIs) 322 that allow 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. Storage platform API 322 can be used by applications in conjunction with other APIs, such as API 324 DB OLE and API 326 Win32 Microsoft Windows.

The storage platform 300 according to the present invention can provide a variety of services 328 to application programs, including a synchronization service 330, which facilitates the sharing of data 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 data store 302, as well as access to data stores 342 having other formats. Storage platform 300 also provides file system capabilities that allow data warehouse 302 to interact with existing file systems, such as Windows NTFS file system 318.

In at least some embodiments, the storage platform 320 may also provide applications with additional capabilities that allow data to be operated on and interoperable with other systems. These features can be implemented as additional services 328, for example, services 334 Info Agent and services 332 notification, as well as other utilities 336.

In at least some embodiments, the storage platform is embodied in or forms an integral part of the hardware-software interface of a computer system. For example, and without limitation, the storage platform according to the present invention can be embodied in the operating system, virtual machine manager (VMM), common language runtime (CLR), or its functional equivalent, or Java virtual machine (JVM), or its functional equivalent , or be an integral part of them.

Due to its common storage foundation and schematized data, the storage platform according to the present invention allows more efficiently developing an application for consumers, IT professionals and enterprises. It provides a rich and extensible programming area that not only makes available the features inherent in this data model, but also extends and extends the existing file system and database access methods.

In the following description and according to various figures, the storage platform 300 of the present invention may be referred to as "WinFS." However, this storage platform name is used for convenience of description only and does not imply any limitation.

C. DATA MODEL

The data warehouse 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 in the warehouse. In the data model of the present invention, an “article” is the basic unit of information storage. The data model provides a mechanism for declaring Articles and Extensions of an article both for setting relations between Articles and for organizing Articles in Article Folders and Categories, which is described in more detail below.

The data model relies on two primitive mechanisms, Types and Relations. Types are structures that provide a format that defines the shape of an instance of a Type. The format is expressed as an ordered set of Properties. A property is a name for a value or set of values of a given Type. For example, the type USPostalAddress (US mailing address) can have the properties Street (street), City (city), Zip (zip code), State (state), and the values Street, City and State are of type String (string), and the value Zip has type Int32. Street can be multi-valued (i.e. have multiple values), so the Street property can have more than one value. The system defines certain primitive types that can be used in conjunction with other types, which include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUID. Type properties can be set using any of the primitive types or (with some restrictions listed below) any of the constructed types. For example, you can specify the Location Type, which has the Coordinate Properties and Address, where the Address Property has the USPostalAddress type described above. Properties may also be required or optional.

You can define relationships that represent the mapping between sets of instances of two types. For example, you can specify the Relationship between the Person Type and the Location Type, called LivesAt (lives in), which indicates who lives where. The relationship has a name, two endpoints, namely, the source endpoint and the target endpoint. Relations can also have an ordered set of properties. Source and destination endpoints have Name and Type. For example, a LivesAt relationship has a Source named Occupant of type Person and a Target called Dwelling of type Location and also has properties StartDate (start date) and EndDate (end date) that indicate the period of time during which the tenant lives in this place of residence. Note that a person can live in several places of residence over time, and a place of residence can have several residents, so, most likely, the place to put information StartDate and EndDate is in the relationship.

Relationships define a relationship between instances that is limited to types defined as endpoint types. For example, a LivesAt relationship cannot be a relationship in which the Tenant is a Car, since the Car is not a Person.

The data model allows you to specify a subtype-supertype relationship between types. The subtype-supertype relation, also known as the BaseType relation (base type), is defined in such a way that if Type A is the base type for Type B, it is true that each instance of B is also an instance of A. This can also be expressed so that each instance that matches B must also match A. If, for example, A has the Name property of type String and B has the Age property of type Int16, then instance B must have both Name and Age. A hierarchy of types can be envisaged as a tree, the root of which is a single supertype. Branches from the root provide subtypes of the first level, branches at this level provide subtypes of the second level, etc. to edge subtypes that themselves do not have subtypes. A tree does not have to be uniform in depth, but cannot contain cycles. This Type can have zero or many subtypes and zero or one supertype. This instance can correspond, at most, to one type together with supertypes of this 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.

A type is called abstract if the type instances must also be an instance of the type subtype.

1. Articles

An article is a unit of stored information available to a system of a hardware-software interface, which, unlike a simple file, is an object that has a basic set of properties that are generally supported for all objects that the storage platform presents to the end user or application program. Articles also have properties and relationships that are generally supported across all types of articles, including features that allow you to introduce new properties and relationships, as discussed below.

Articles are objects of common operations, such as copying, deleting, moving, opening, printing, backing up, duplicating, etc. Articles are units that can be stored and retrieved, and all forms of stored information that the storage platform manipulates exist in the form of Articles, properties of Articles or Relations between Articles, each of which is discussed in more detail below.

Articles are intended to represent real-world and easily understood data units, such as: Contacts, Persons, Services, Places, Documents (of all kinds), etc. On figa shows a block diagram of the structure of the Article. The unspecified name of the Article is "Location". The specified name of the Article is “Core.Location”, which indicates that the structure of this Article is defined as a specific type of Article in the Kernel Scheme (the kernel schema is discussed in more detail below.)

A provision article has a property or properties, including EAddress, Metropolitan Region, Neighborhood and PostalAddress. A specific property type for each of them is indicated immediately after the property name and is separated by a colon (":") from the property name. To the right of the type name, the number of values allowed for this type of property is indicated in square brackets ("[]"), and the asterisk ("*") to the right of the colon (":") indicates an indefinite and / or unlimited number ("many" ) A “1” to the right of the colon indicates that there can be at most one value. A zero (“0”) to the left of the colon indicates that the property is optional (it may not matter at all); A “1” to the left of the colon indicates that there must be at least one value (required property). Neighborhood and MetropolitanRegion are of type "nvarchar" (or equivalent), which is the preferred data type or "simple type" (as indicated by the absence of a capital letter). However, EAddresses and PostalAddresses are properties of the specified types or “complex types” (indicated by the capital letter) of the EAddress and PostalAddress types, respectively. A complex type is a type that is derived from one or more simple data types and / or from other complex types. Complex types for properties Articles also form “nested elements”, since complex type details are embedded in a direct article to set its properties, and information related to these complex types is supported through an article that has these properties (within the bounds of the Article, which are described below ) These concepts of type definition are well known and obvious to experts in this field.

5B is a block diagram illustrating the complex property types PostalAddress and EAddress. The property type PostalAddress determines that an Article with a property of type PostalAddress expectedly has zero or one City value, zero or one CountryCode value, zero or one MailStop value, and any number (from zero to many) PostalAddressType, etc. etc. Thus, the data form for a particular property is specified in the Article. Although this application is optionally used in this application, another way of representing complex types in the “clause” Article is to extract an Article with the individual properties of each complex type from those listed here. On figs shows a block diagram illustrating the Article "position", in which its complex types are further described. However, it should be understood that this alternative representation of the “Position” Article in this FIG. 5C refers to exactly that Article that is illustrated in FIG. 5A. The storage platform according to the present invention also allows the determination of subtypes, 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).

Similar but different from properties and their property types, Articles internally present their own Article Types, which may also be subject to subtypes. In other words, the storage platform according to several embodiments of the present invention allows an Article to be a subtype of another Article (whereby one article inherits the properties of another, parent article). In addition, for various embodiments of the present invention, each article is a subtype of "Item" (article) of the type of article, which is the first and main type of article found in the Basic scheme (the basic scheme will also be discussed in detail below), in figa the Article is shown, in this example the Article “provision”, as a subtype of the type of the article “Article” found in the Basic Scheme. In this drawing, the arrow indicates that the Article “provision” (like all other Articles) is a subtype of the type of the article “Article”. The type of the article “Article”, as the main Article, from which all other articles are derived, has a number of important properties, for example, ItemId, and various time stamps, due to which it sets the standard properties of all Articles in the operating system. On figa, these properties of the type of article "Article" are inherited by the article "position" and, thus, become the properties of the article "position".

Although the way of representing properties in the “Clause” Article inherited from the type of the “Article” article is to extract the “Clause” article with individual properties of each type of property from the parent Article specified here. On figv shows a block diagram illustrating the Article "position", which, in addition to its direct properties, describes its inherited types. It should be noted and understood that this Article is the same Article that is illustrated in FIG. 5A, although in this figure the article “position” is shown with all its properties, both direct, shown in this figure and FIG. 5A, and inherited, shown in this figure, but not in FIG. 5A (whereas in FIG. 5A, these properties are represented by an arrow indicating that the Article “position” is a subtype of the type of the article “article”).

Articles are autonomous objects; thus, if you delete an Article, all direct and inherited properties are also deleted. Similarly, when retrieving Articles, they receive the Article and all its direct and inherited properties (including information related to its complex types of properties). Certain embodiments of the present invention make it possible to request a subset of properties when retrieving a particular article; however, by default, in many such embodiments, upon retrieval, an Article is provided with all its direct and inherited properties. In addition, the properties of Articles can also be expanded by adding new properties to existing properties such as this Article. These “extensions” are then the true properties of the Article, and subtypes of this type of article may include the properties of the extension.

The “border” of an Article is represented by its properties (including complex types of properties, extensions, etc.). The boundary of the Article also represents the limit of the operation carried out on the Article, for example, copying, deleting, moving, creating, etc. For example, in some embodiments of the present invention, when copying an article, everything within the article is also copied. For each article, the border covers the following:

- The type of Article for the Article and, if the Article is a subtype of another Article (which is the case in several embodiments of the present invention, where all Articles are derived from the same Article and Article Type in the Basic Scheme), any applicable subtype information (i.e. information, related to the parent type of the article). If the source Article to be copied is a subtype of another Article, then the copy may also be a subtype of the same Article.

- Properties and extensions of a complex article type, if any. If the original Article has the properties of complex types (natural or advanced), then the copy can also have the same complex types.

- Entries on an “affiliation relationship”, i.e. own list of Articles, which indicates which other Articles (“Target Articles”) belong to this Article (“Article Owner”). This applies in particular to the Article Folder discussed in more detail below, and to the rule established below, according to which all Articles must belong to at least one Article Folder. In addition, in connection with the embedded articles, described in more detail below, the embedded article is considered part of the article in which it is embedded for operations such as copying, deleting, etc.

2. Article identification

Articles are uniquely identified in the global article space through ItemID. The Base.Item type specifies the ItemID field of the GUID type in which the identification of the Article is stored. An article must have exactly one identification in data warehouse 302.

a) Links to the article

A link to an article is a data structure that contains information for finding and identifying an article. In the data model, an abstract type is specified under the name ItemReference, from which all types of article links are derived. The ItemReference type defines a virtual method called Resolve. The Resolve method resolves the ItemReference and returns the Article. This method is replaced by specific subtypes of ItemReference, which implement a function that retrieves an Article by reference. The Resolve method is called as part of the storage platform API 322.

(1) ItemIDReference

ItemIDReference is a subtype of ItemReference. It sets the Locator (pointer) and ItemID fields. The Locator field gives the name (i.e. identifies) the domain of the article. It is processed by the method of resolving pointers, which can resolve the value of the Locator field in relation to the domain of the article. The ItemID field is of type ItemID.

(2) ItemPathReference

ItemPathReference is a special case of ItemReference, which sets the Locator and Path fields. The Locator field identifies the domain of the article. It is processed by the method of resolving pointers, which can resolve the value of the Locator field in relation to the domain of the article. The Path field contains a (relative) path in the storage platform namespace that has a root in the article domain provided by the Locator field.

This type of link cannot be used in the set operation. The link should, in general, be resolved through the path resolution process. The Resolve API 322 method of the storage platform provides this functionality.

b) Link type hierarchy

The link forms discussed above are represented by the link type hierarchy illustrated in FIG. Additional link types that inherit from these types can be specified in schemas. They can be used in the relationship declaration as a type of target field.

3. Article folders and Categories

As discussed in more detail below, groups of Articles can be organized into special Articles called Article Folders (which should not be confused with file folders). However, unlike most file systems, an article can belong to more than one Article Folder, therefore, when accessing an Article in one Article Folder and its revision, this audited Article can be accessed directly from another Article Folder. In essence, although access to an Article can be from different Article Folders, what is accessed is actually the same Article. However, the Article Folder does not necessarily own all the articles included in it, or can simply share the articles with other folders, so deleting the Article Folder does not necessarily delete the Article. However, according to several embodiments of the present invention, the Article must belong to at least one Article Folder, therefore, when deleting a single Article Folder for a specific Article, then, for some embodiments, the article is automatically deleted or, in alternative embodiments, , The article automatically becomes the default Article Folder item (for example, Trash Can Article Folders (Recycle Bin), conceptually similar to the folders used in various file-based systems folders).

As discussed in more detail below, Folders can also belong to Categories based on a common feature described, for example, (a) the type (or types) of articles, b) a specific direct or inherited property (or properties), or c) a specific value (or values), corresponding property of the article. For example, an Article containing specific properties for personal contact information may automatically belong to the Contact Category, and any article having contact information properties will automatically belong to this category. Similarly, any article that has a position property with the value "New York City" can automatically belong to the NewYorkCity Category.

Categories are conceptually different from Article Folders in that, while Article Folders can contain Articles that are not related to each other (i.e., without a common characteristic described), each Article in the Category has a common type, property, or the meaning (“community”) that is described for this Category, and this is the community that forms the basis for its relationship to other Articles in the Category. In addition, while the membership of an Article in a particular Folder is not necessarily based on any particular aspect of this Article, for certain embodiments, all articles having a commonality categorically associated with the Category can automatically become Category elements at the system-hardware interface level . In principle, Categories can also be considered as virtual Article Folders, belonging to which is based on the results of a particular query (for example, in the context of a database), and thus Articles that meet the conditions of this query (specified by the Community of Categories) will contain membership to Category.

Figure 4 shows the structural relationship between Articles, Article Folders and Categories according to various embodiments of the present invention. Articles 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 belong to different Folders of Articles 422, 424, 426, 428, and 430. Some Articles may belong to more than one Article Folder, for example, Article 402 belongs to the Folders of Articles 422 and 424. Some Articles, such as Articles 402, 404, 406, 408, 410, and 412, also belong to one or more Categories 432, 434, and 436, while other articles, such as Articles 414, 416, 418 , and 420, may not belong to any Category (although this is highly unlikely in some embodiments where the possession of a property automatically entails the belonging to the Category, and so as not to belong to any category in such an embodiment, the Article should not have any signs). In contrast to the hierarchical structure of folders, the structure of Categories and Article Folders is more like directed graphs. In any case, Articles, Article Folders and Categories are Articles (albeit of different Article Types).

Unlike files, folders and directories, Articles, Article folders and Categories according to the present invention do not have a characteristic “physical” nature, since they do not have conceptually equivalent physical containers, so Articles can exist in more than one such place. The ability for articles to exist in more than one Article Folder, as well as the ability to be combined into Categories, provides advanced and enriched data manipulation capabilities and storage structure capabilities at the hardware-software interface level that exceed the capabilities available in modern technology.

4. Schemes

a) Basic scheme

To provide a universal basis for the creation and use of Articles, various embodiments of a storage platform according to the present invention comprise a Basic Scheme that establishes a basic structure for creating and organizing Articles and properties. The basic schema defines certain special types of Articles and properties and the characteristics of these special basic types from which subtypes can be additionally derived. Using this Basic Scheme allows a programmer to fundamentally distinguish Articles (and their respective types) from properties (and their respective types). In addition, the Basic Scheme defines the basic set of properties that all Articles may possess, since all Articles (and their respective Article Types) are derived from this main Article in the Basic Scheme (and its corresponding Article Type).

7, and in connection with several embodiments of the present invention, the base schema defines three top-level types: Item, Extension, and PropertyBase. It is shown that the Item type is defined by the properties of this main type of the "Item" article. On the contrary, the top-level property type “PropertyBase” has no predefined properties and is only an anchor from which all other property types are derived and through which all derived property types are linked (being deduced together from a single property type). Properties of the Extension type specify which Article extends the extension, as well as identification, which distinguishes one extension from another, since an Article can have several extensions.

An ItemFolder is a subtype of the type of the article “article”, which, in addition to the properties inherited from the Article, defines a Relationship for establishing links with its elements (if any), while IdentityKey and Property are subtypes of PropertyBase. CategoryRef, in turn, is a subtype of IdentityKey.

b) Kernel layout

Various embodiments of a storage platform according to the present invention comprise a Core Scheme that provides a principal structure for top-level Article type structures. On figa shows a block diagram illustrating the Articles in the kernel diagram, and figv shows a block diagram illustrating the types of properties in the kernel diagram. The differences between files with different extensions (* .com, * .exe, * .bat, * .sys, etc.) and other similar criteria in systems based on files and folders are similar in function to the kernel scheme. In a system of hardware-software interface based on Articles, the Kernel Scheme defines many types of kernel articles that directly (by type of article) or indirectly (by subtype of an article) characterize all Articles into one or more types of articles The basis of the articles is understood and can be directly processed in a predetermined and predictable way. The predefined article types reflect the most commonly used Articles in the article-based software and hardware interface system, and thus, the level of efficiency of the software-hardware interface system based on articles that understands these predefined article types that contain the kernel schema is increased.

In some embodiments, the core design is non-extensible, i.e. no additional article types can be directly derived as subtypes of the article type in the Basic Scheme, except for specific predefined derived article types that are part of the Kernel Scheme. By inhibiting the formation of extensions to the Kernel Scheme (i.e., by preventing the addition of new Articles to the Kernel Scheme), the storage platform allows the use of article types of the Kernel Scheme, since each subsequent article type is necessarily a subtype of the type of the Kernel Scheme article. This structure allows a reasonable degree of flexibility when defining additional types of articles, while at the same time preserving the benefits of having a predefined set of types of core articles.

For various embodiments of the present invention and as shown in FIG. 8A, the specific article types supported by the Core Schema may include one or more of the following:

- Categories: Articles of this type of article (subtypes derived from it) represent suitable Categories in the system of hardware-software interface based on articles.

- Commodities: Articles that are identifiable valuable items.

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

- Documents: Articles whose contents are not interpreted by the system of hardware-software interface based on articles, but are interpreted by an application program corresponding to the type of document.

- Events: Articles in which certain events in the medium are recorded.

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

- Communications: Articles of communication between two or more principals (defined below).

- Principals: Articles that have at least one uniquely provable identification in addition to ItemId (for example, identification of an individual, organization, group, home ownership, authority, service, etc.).

- Affirmations: Articles with specific information regarding the environment, including, without limitation, policies, subscriptions, mandates, etc.

Similarly, as shown in FIG. 8B, the specific types of properties supported by the Kernel Scheme may include one or more of the following:

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

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

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

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

- Email address (Eaddress) (derived 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)

These Articles and Properties are described below according to their respective properties shown in FIGS. 8A and 8B.

5. Relations

Relations are binary relations in which one Article is considered the source (source) and the other is the target (target). The source article and the target article are related. The original article, in the general case, controls the relationship's lifetime. Thus, when deleting the original article, the relationship between the Articles is also deleted.

Relationships are divided into inclusion relationships and link relationships. Inclusion relationships control the lifetime of targeted articles, and linking relationships do not provide any semantics for managing lifetimes. 12 shows how relationships are classified.

The types of inclusion relationships are further subdivided into support and implementation relationships. If you delete all Article support relationships, the article is deleted. The support relationship controls the target's lifetime by reference to a reference mechanism. Implementation relationships allow you to model compound Articles, and they can be considered as exclusive support relationships. An article may be the goal of one or more support relationships; but an Article may be the goal of only one implementation relationship. An article that is the goal of an implementation relationship cannot be the goal of any other support or implementation relationship.

Link relationships do not control the lifetime of the target article. They can be hanging, i.e. may not have a target article. Link relationships can be used to model links to Articles anywhere in the global article namespace (i.e., including remote data stores).

Sampling an Article does not imply an automatic sampling of its relationship. Applications must explicitly request Article relations. In addition, a change in attitude does not change the source or target article; likewise, adding a relationship does not affect the source / target article.

a) Declaration of relationship

Explicit relationship types are defined by the following elements:

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

- Type of relationship, one of the following: Holding, Embedding, Reference. It is set in the Type attribute.

- Source and target endpoints. Each endpoint defines the name and type of the Article referred to.

- The field of the source endpoint, in general, is of the type ItemID (not declared) and should refer to the Article located in the same data warehouse as the instance of the relationship.

- For support and implementation relationships, the target endpoint field must be of type ItemIDReference and must refer to an Article located in the same repository as the relationship instance. For a link relationship, the target endpoint can be any endpoint of type ItemReference and can link to Articles in other data warehouses of the storage platform.

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

- Relationship instances are stored in the global relationship table.

- Each instance of a relationship is uniquely identified by a combination (ID of the source article, ID of the relationship). Relationship ID is unique in this ID of the source article for all relationships the source of this article is, regardless of their type.

The original article is the owner of the relationship. Although the Article, indicated as the owner, controls the life time of the relationship, the relationship itself is separate from the articles to which it relates. Storage platform API 322 provides mechanisms for presenting relationship related to an article.

Here is an example of a declaration of a relationship:

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

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

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

ReferenceType = "ItemIDReference" />

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

platformTypes.DateTime "/>

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

platformTypes.DateTime "/>

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

platformTypes.DateTime "/>

</Relationship>

This is an example of a link relationship. A relationship cannot be created if the “person” article referred to by the original link does not exist. In addition, when you delete the article "person", copies of the relationship between the person and the organization are deleted. However, when you delete the article "organization", the relationship is not deleted and freezes.

b) Support attitude

Support relationships are used to model the reference count based on the life span of the targeted articles.

An article can be the starting point for zero or more relationships with articles. An article that is not embedded in the Article may be the target for one or more support relationships.

The target endpoint link type must be ItemIDReference and it must refer to an article located in the same store as the relationship instance.

Support relationships apply target endpoint lifetime management. Creating an instance of a support relationship and an article that is its goal is an elementary operation. You can create additional instances of a support relationship that target the same article. When you delete the last instance of a support relationship that has a target endpoint of this article, the target article is also deleted.

The types of endpoint articles specified in the relationship declaration are typically used when creating an instance of the relationship. The types of articles that are endpoints cannot change after defining a relationship.

Support relationships play a key role in shaping the article namespace. They contain the "Name" property, which sets the name of the target article relative to the original article. The relative name is unique to all support relationships originating in this article. An ordered list of these relative names, starting with the root article and ending with this article, forms the full name of the article.

Support relationships form a directed acyclic graph (DAG). When creating a support relationship, the system ensures that the loop is not created, and thus ensures that the article namespace forms a DAG.

Although the support relation controls the lifetime of the target article, it does not control the operational consistency of the article, which is the target endpoint. The target article is operationally independent of the article that owns it through a support relationship. Copy, Move, Backup, etc. operations on an article that is the source of the support relationship do not affect the article that is the target of the same relationship, for example, backing up the “folder” article does not automatically backup all the articles in this folder (goals relationship FolderMember).

Here is an example of a support relationship:

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

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

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

ReferenceType = "ItemIDReference" />

</Relationship>

The FolderMembers relationship defines the concept of a Folder as a general view of a collection of Articles.

c) Implementation Relations

Implementation relationships model the concept of exceptional time management of the target article. They define the concept of composite articles.

Creating an instance of the implementation relationship and the article, which is its goal, is an elementary operation. An article can be a source for zero or more implementation relationships. However, an article may be the goal of one and only one implementation relationship. An article that is the goal of an implementation relationship cannot be the goal of a support relationship.

The target endpoint reference type must be ItemIDReference and must refer to an article located in the same data store as the relationship instance.

The types of endpoint articles specified in the relationship declaration are typically used when creating an instance of the relationship. The types of articles that are endpoints cannot change after defining a relationship.

Deployment relationships control the operational consistency of the target endpoint. For example, the operation of converting an article to a sequential view may include converting to a sequential view of all of the implementation relationships emanating from the article, as well as all of their goals; copying an article also leads to copying all articles embedded in it.

Here is an example declaration:

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

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

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

ReferenceType = "ItemIDReference" />

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

platformTypes.bigint "/>

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

platformTypes.float "/>

</Relationship>

d) Link relationships

The link relation does not control the lifetime of the article to which it refers. Moreover, link relationships do not guarantee the existence of a goal, nor do they guarantee the type of goal specified in the relationship declaration. This means that the link relationship may freeze. In addition, the link relationship may link to articles in other data stores. Link relationships can be seen as a concept similar to links on web pages.

Here is an example of a link relationship declaration:

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

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

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

ReferenceType = "ItemIDReference" />

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

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

platformTypes.nvarchar (256) "/>

</Relationship>

Any type of link is allowed at the target endpoint. Articles that are involved in relation to a link can have any type of article.

Relationships are used to model relationships between articles that are least related to life time management. Since the existence of a goal is not required, the reference relationship is convenient for modeling loosely coupled relationships. Target link relationship articles may be located in other data stores, including stores on other computers.

e) Rules and restrictions

The following additional rules and restrictions apply to relationships:

1. The article should be the goal of (exactly one implementation relationship) or (one or more support relationships). The exception is the root article. An article may be the goal of a zero or more link relationship.

2. An article that is the goal of an implementation relationship cannot be a source of support relationships. It can be a source of link relationships.

3. An article cannot be a source of a support relationship if it is pushed from a file. It can be a source of implementation relationships and link relationships.

4. An article that can be pushed from a file cannot be the goal of an embedding relationship.

f) Streamlining relationships

According to at least one embodiment, a storage platform according to the present invention supports ordering of relationships. Ordering is achieved through a property called "Order" in the base definition of the relationship. The Order field is not subject to any restrictions related to uniqueness. The order of relations with the same value of the property “order” is not guaranteed, however, it is guaranteed that they will stand after relations with a lower value of “order” and before relations with a higher value of “order”.

Applications can receive relationships in the default order, thanks to ordering by combination (SourceItemID, RelationshipID, Order). All instances of the relationship that have the source of this article are ordered as a single collection, regardless of the type of relationship in the collection. However, this ensures that all relationships of this type (for example, FolderMembers) are an ordered subset of the collection of relationships for this article.

Relationship manipulation data warehouse API 312 implements many operations that support ordering of relationships. To facilitate the explanation of these operations, we introduce the following terms:

RelFirst is the first relation in an ordered collection with an order value of OrdFirst ;

RelLast is the last relation in an ordered collection with an order value of OrdLast ;

RelX is a given relation in an ordered collection with an order value of OrdX ;

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

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

InsertBeforeFirst (SourceItemID, Relationship)

Inserts a relation as the first relation in the collection. The value of the order property of a new relationship may be less than OrdFirst.

InsertAfterLast (SourceItemID, Relationship)

Inserts a relation as the last relation in the collection. The value of the “order” property of the new relationship may be greater than OrdLast.

InsertAt (SourceItemID, ord, Relationship)

Inserts a relation with the specified value of the order property.

InsertBefore (SourceItemID, ord, Relationship)

Inserts a relation before a relation with a given order value. The new relation can be assigned the value “order” between OrdPrev and ord, non-exclusively.

InsertAfter (SourceItemID, ord, Relationship)

Inserts a relation after a relation with a given order value. The new relation can be assigned the value "order" between ord and OrdNext, non-exclusively.

MoveBefore (SourceItemID, ord, RelationshipID)

Moves the relationship with the given relationship ID before the relationship with the specified order value. A relationship can be assigned a new value, “order,” between OrdPrev and ord, non-exclusively.

MoveAfter (SourceItemID, ord, RelationshipID)

Moves the relationship with the given relationship ID after the relationship with the specified order value. A relationship can be assigned a new value, “order,” between ord and OrdNext, non-exclusively.

As noted above, each article must be an element of the Article Folder. In terms of relationships, each article should relate to the Article Folder. In some embodiments of the present invention, certain relationships are represented by Relations existing between the Articles.

According to an implementation, for various embodiments of the present invention, the Relationship provides a directional binary relation that is “expanded” by one Article (source) to another Article (target). The relation belongs to the original article (the article that extends it) and, thus, the relation is deleted when the source is deleted (for example, the relation is deleted when the original article is deleted). In addition, in some cases, the Relationship may simultaneously belong to (be jointly owned) the target article, and such ownership may be reflected in the IsOwned property (or its equivalent) of the Relationship (according to Fig. 7 for the type of the Relationship property). In these embodiments, creating a new IsOwned relationship automatically leads to an increment in the reference count of the target article, and deleting an IsOwned relationship automatically leads to a negative increment of the reference count of the target article. For these specific embodiments, articles continue to exist if they have a reference count greater than zero, and are automatically deleted if and when the counter reaches zero. Again, the Article Folder is an Article that has (or is capable of having) many relationships with other Articles, and these other Articles contain affiliation with the Article Folder. Other actual relationship implementations are possible and contemplated by the present invention to provide the functionality described herein.

Regardless of the actual implementation, the relation is a selectable connection from one object to another. The ability of an article to belong to more than one Article Folder, as well as one or more Categories, and whether these articles, folders and categories are public or private, is determined by the values attributed to the presence (or absence) of the article-based structure. These logical relationships are values assigned to a plurality of relationships, regardless of physical implementation, that are specifically used to provide the functionality described herein. Logical relationships are established between the Article and its Folder (s) of articles or Categories (and vice versa), since, in essence, Folders of articles and Categories are special types of articles. Consequently, Article Folders and Categories can be handled in the same way as with any other Articles - copy, add to an email message, embed in a document, etc. without limitation - both Article Folders and Categories can be converted to a sequential view and from a sequential view (import and export) using the same mechanisms as for other articles (for example, in XML all articles can have a sequential format, and this format is equal applies to Article Folders, Categories and Articles.)

The above relationships, which represent the relationship between an Article and its Folder (s) of articles, can be logically expanded from an Article to a Folder of articles, from a Folder of articles to an Article, or both. A relationship that logically expands from an Article to an Article Folder indicates that the Article Folder is public in relation to this Article and shares its membership information with this Article; on the contrary, the absence of a logical relationship from an Article to an Article Folder indicates that the Article Folder is private with respect to this Article and does not share its membership information with this Article. Similarly, a relationship that logically expands from an Article Folder to an Article indicates that the Article is public and shared with respect to this Article Folder, while a lack of a logical relationship from the Article Folder to an Article indicates that the article is private and not shared. Therefore, when the Article Folder is exported to another system, it is the “public” Articles that are shared in a new context, and when the article searches for its article folders for other shared articles, it’s the “public” Article Folders that provide the article with information about the shared articles, belonging to them.

Fig. 9 is a block diagram illustrating an Article Folder (which, by itself, is also an Article), its articles, and the relationship between the Article Folder and its articles. A folder of 900 articles contains a combination of Articles 902, 904 and 906. A folder of 900 articles has a Relationship of 912 from itself to Article 902, which indicates that Article 902 is public and shared with respect to the Folder 900 of articles, its elements 904 and 906, or any other Article Folders, Categories or Articles (not shown) that can access the Folder of 900 articles. However, there is no Relationship from Article 902 to the Folder of 900 articles, which indicates that the Folder of 900 articles is private with respect to Article 902 and does not share its membership information with Article 902. On the other hand, Article 904 has a ratio of 924 from itself to the Folder 900 articles, which indicates that the Folder of 900 articles is public and shares its ownership information with Article 904. However, there is no Relationship from the Folder of 900 articles to Article 904, which indicates that Article 904 is private and not shared mine in relation to the Folder of 900 articles, its elements 902 and 906 and any other Folders of articles, Categories or Articles (not shown) that can access the Folder of 900 articles. Unlike these Relationships (or in their absence) to Articles 902 and 904, the Folder of 900 articles has a Relationship of 916 from itself to Article 906, and Article 906 has a Relationship of 926 back to a Folder of 900 articles that together indicate that Article 906 is public and shared with respect to the Folder of 900 articles, its elements 902 and 904 and any other Folders of articles, Categories or Articles (not shown) that can access the Folder of 900 articles, and that the Folder of 900 articles is public and shares its information accessories with Article 906.

As discussed previously, Articles in the Article Folder do not need to be shared with each other since the Article Folders are not “described”. On the other hand, categories are described by a commonality that is common to all articles included in it. Therefore, belonging to the Category is internally limited by Articles having the described generality and, in certain embodiments, all Articles meeting the Category description automatically become Category elements. Thus, while Article Folders allow you to represent structures of trivial types based on their affiliation, Categories allow affiliation on the basis of a given generality.

Of course, the descriptions of the Category are logical in nature and therefore the Category can be described by any logical representation of types, properties and / or values. For example, a logical representation of a Category may be a condition of belonging to it, according to which an Article must have one of two properties, or both. If these described properties for the Category are designated as "A" and "B", then belonging to the Category may provide that Articles have property A, but not B, Articles have property B, but not A, and Articles have both properties A and B This logical representation of properties is described by the logical operator "OR", while the many elements described by the Category are Articles that have the property A OR B. Similar logical operators (including without limitation "AND", "XOR" and "NOT" individually or together) can also be used to describe categories that are obvious to experts in this field.

Despite the difference between Article Folders (not described) and Categories (described), the relation of categories to articles and the relation of articles to categories is essentially the same as described above for article folders and articles in many embodiments of the present invention.

Figure 10 shows a block diagram illustrating a category (which is an article in itself), the articles included in it, and the relationship between the category and the articles included in it. Categories 1000 belong to articles 1002, 1004, and 1006, which all share a combination of common properties, values, or types 1008 described (generality description 1008 ') by category 1000. Category 1000 relates 1012 from itself to article 1002, which indicates that the article 1002 is public and shared with respect to category 1000, its elements 1004 and 1006 and any other categories, article folders or articles (not shown) that can access category 1000. However, there is no relationship from article 1002 to category 1000, which indicates t, that category 1000 is private with respect to article 1002 and does not share its membership information with article 1002. On the other hand, article 1004 relates 1024 from itself to category 1000, which indicates that category 1000 is public and shares its membership information with article 1004. However, there is no relationship extended from category 1000 to article 1004, which indicates that article 1004 is private and not shared with respect to category 1000, its other elements 1002 and 1006, and any other to other categories, article folders or articles (not shown) that can access category 1000. In contrast to this relationship (or in its absence) with articles 1002 and 1004, category 1000 has a relationship of 1016 from itself to article 1006, and article 1006 relates 1026 back to category 1000, which together indicate that article 1006 is public and shared with respect to category 1000, its articles 1002 and 1004, and any other categories, article folders, or articles (not shown) that may access category 10 00, and that category 1000 is public and shares its membership information with article 1006.

Finally, since Categories and Article Folders themselves are Articles, and Articles can relate to each other, Categories can relate to Article folders and vice versa, and Categories, Article Folders and Articles can relate to other Categories, Article Folders and Articles, respectively , according to some alternative embodiments. However, in various embodiments, Article Folder structures and / or Category structures are prohibited from containing loops at the system-level hardware-software interface. When the structures of the Article Folder and Category are similar to oriented graphs, embodiments that prohibit loops resemble oriented acyclic graphs (DAGs), which, according to the mathematical definition of graph theory, are directed graphs in which no path can begin and end in one and the same peak.

6. Extensibility

The storage platform is intended to be provided with an initial set of circuits 340 as described above. In addition, according to at least some embodiments, the storage platform allows consumers, including independent software vendors (ISVs), to create new schemes 344 (i.e., new types of “Item” and “nested item” "(Nested Element)). This section is devoted to the mechanism for creating such schemes by expanding the types of "article" and the types of "nested element" (or simply types of "element") defined in the initial set of schemes 340.

Preferably, the expansion of the initial set of article types and nested elements is limited as follows:

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

ISVs are allowed to introduce new types of Nested Element, i.e. subtype of Base.NestedElement;

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

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

Since the type of article or the type of the nested item specified by the initial set of storage platform schemas may not fully meet the needs of the ISV, you must enable the ISV to modify the type. This is possible by formalizing extensions. Extensions are strongly typed instances, but (a) they cannot exist independently and (b) they must be attached to the article or nested element.

In addition to satisfying the need for schema extensibility, extensions are also designed to address the issue of "multiple type definitions". Since, in some embodiments, the storage platform may not support multiple inheritance or overlapping subtypes, applications can use extensions to model overlapping instances of a type (for example, a Document is both a legal document and a protected document).

a) Article extensions

To ensure the extensibility of articles, the data model additionally defines an abstract type called Base.Extension. This is the root type in the extension type hierarchy. Applications can define subtypes of Base.Extension to create specific types of extensions.

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

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

<Propety 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 article the extension is associated with. An article with this ItemID must exist. An extension cannot be created if an article with this ItemID does not exist. When you delete an article, all extensions with the same ItemID are deleted. The tuple (ItemID, ExtensionID) uniquely identifies the extension instance.

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

Extension types have fields.

Fields can be primitive types or nested element types.

Extension types allow subtypes to be defined.

The following restrictions apply to extension types:

extensions cannot be the sources and goals of relationships;

instances of extension types cannot exist independently of the article; and

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

The types of extensions that may be associated with this type of article are not subject to any restrictions. Any type of extension can expand any type of article. When several instances of the extension are attached to the article, they are independent of each other both in structure and in behavior.

Extension instances are provided with storage and access separate from the article. All instances of the extension type are available for the global extension type. You can create an effective query that returns all instances of this type of extension, regardless of what type of article they are associated with. Storage platform APIs provide a programming model that allows you to save, retrieve, and modify extensions on articles.

Extension types can be types obtained by defining subtypes using a single storage platform inheritance model. Deriving an extension type creates a new extension type. The structure or behavior of an extension cannot replace or replace the structure or behavior of a hierarchy of article types.

By analogy with article types, instances of the extension type can be directly accessed due to the view associated with the extension type. The extension’s ItemID indicates which article it belongs to and can be used to retrieve the corresponding “article” object from the global view of the article.

For operational consistency, extensions are considered part of the article. Copy / Move, Backup / Restore, and other well-known operations defined on the storage platform can be performed on extensions as part of an article.

Consider the following example. In the Windows type set, the Contact type is set.

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

<Property Name = "Name"

Type = "String"

Nullable = "false"

MultiValued = "false" />

<Property Name = "Address"

Type = "Address"

Nullable = "true"

MultiValued = "false" />

</ Tour>

The CRM application developer wants to attach the CRM application extension to the contacts stored in the storage platform. The application developer defines a CRM extension that 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 HR application developer also wishes to attach additional data to the contacts. This data is independent of CRM application data. Again, the application developer can create an extension

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

<Property Name = "EmployeeID"

Type = "String"

Nullable = "false"

MultiValued = "false" />

...

</Type>

CRMExtension and HRExtension are two independent extensions that you can add to your contact articles. Their creation and access to them are carried out independently of each other.

In the above example, fields and methods of the CRMExtension type cannot replace fields and methods of the contact hierarchy. It should be noted that instances of the CRMExtension type can be attached to other types of articles, in addition to “contacts”.

When you extract the article "contact", its extension articles are not automatically extracted. For this “contact” article, you can access the related article extensions by requesting a global view of extensions for extensions with the same ItemId.

All CRMExtension extensions in the system can be accessed through a view of the CRMExtension type, regardless of which article it belongs to. All article extensions for an article share the same article identifier. In the above example, the instance of the contact article and the instances of the attached CRMExtension and HRExtension have the same ItemID.

The following table summarizes the similarities and differences between article types, extensions, and nested elements:

Compare article, article extension, and nested item Article Article Extension Nested element Article id Has its own article id Together with the article uses the article ID Does not have its own article ID. The nested element is part of the article. Storage The article hierarchy is stored in its own tables. Article extension hierarchy is stored in its own tables. Stored with article Query / Search May query article tables Can query article extension tables In general, it can only be requested in the context containing the article Request / Search Scope Can search across all instances of an article type Can search across all instances of an article extension type In the general case, it can search only among instances of the type of a nested element of one (containing) article Relationship semantics May relate to articles Not related to article extensions Not related to nested elements Link to Articles May be related to other articles through a maintenance, implementation and soft relationship. In general, it can only be connected through extensions. The semantics of extensions are similar to the semantics of nested articles Associated with the article through the fields. Nested elements are part of the article.

b) Extension of types of nested elements

Types of nested elements are not expanded using the same mechanism as article types. The extensions of nested elements are provided with storage and access using the same mechanisms as for the type fields of nested elements.

The data model sets 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 set of multiple elements.

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

IsAbstract = "True">

<Property Name = "Extensions"

Type = "Base.Element"

Nullable = "false"

MultiValued = "true" />

</Type>

Extensions of a nested element differ from the extensions of an article as follows.

Nested item extensions are not extension types. They do not belong to the extension type hierarchy whose root is the Base.Extension type.

Extensions of a nested element are stored together with other fields of the article and are not globally accessible - you cannot create a query that retrieves all instances of this type of extension.

These extensions are stored in the same way as other nested items (articles). Like other nested sets, extensions of the nested element are stored in the UDT. They are available through the Extensions field of the nested item type.

Collection interfaces used to access multi-valued properties are also used to access and iterate over multiple type extensions.

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

Comparing article extensions and nested item extensions Article Extension Nested Item Resolution Storage Article extension hierarchy is stored in its own tables. Stored as nested items Query / Search May query article extension tables In general, it can only be requested in the context containing the article Request / Search Scope Can search across all instances of an article extension type In the general case, it can search only among instances of the type of a nested element of one (containing) article Programmability Need special extension APIs and special extension table queries Extensions of a nested element are similar to any other multivalued field of a nested element; normal nested element type APIs are used Behavior Can bind behavior No behavior allowed (?) Relationship semantics No relation to article extensions No relation to nested item extensions Article id Together with the article uses the article ID Does not have its own article ID. Extension of a nested element is part of the article

D. DATABASE MACHINE

As noted above, the data warehouse is implemented on a database machine. According to this embodiment, the database engine comprises a relational database engine that implements an SQL query language, such as a Microsoft SQL Server machine, with relational object extensions. This section describes the mapping of the data model that the data warehouse implements to relational storage and provides information on the logical API consumed by the clients of the storage platform according to this embodiment. However, it is understood that when using a different database machine, a different mapping can be used. Indeed, in addition to implementing a basic data model on a relational database machine, it can also be implemented on other types of databases, for example, object-oriented databases and XML databases.

An object-oriented (OO) database system provides stability and transactions for programming language objects (for example, C ++, Java). The concept of an “article” of a storage platform is mapped to an “object” in object-oriented systems, although built-in collections need to be added to objects. Other concepts of storage platform types, such as inheritance and nested element types, also map to the object-oriented type system. Object-oriented systems usually already support object identification; therefore, article identification can be mapped to object identification. Article behaviors (operations) are mapped to object methods. However, object-oriented systems usually lack organizational capabilities and search tools. In addition, object-oriented systems do not provide support for unstructured and partially structured data. To support the complete storage platform data model described here, concepts such as relationships, folders, and extensions need to be added to the data object model. In addition, mechanisms such as promotions, synchronization, notifications, and security need to be implemented.

Like object-oriented systems, XML databases based on XSD (XML Schema Definition) support a single-inheritance type system. The article type system of the present invention can be mapped to an XSD type model. XSD also does not provide behavior support. XSD for articles needs to be complemented by article behaviors. XML databases deal with individual XSD documents and lack organization and large-scale search capabilities. As with object-oriented databases, in order to support the data model described here, other concepts must be included in such XML databases, such as relationships and folders; In addition, mechanisms such as synchronization, notifications, and security must be implemented.

1. Implementing a data warehouse using UDT

According to this embodiment, the relational database engine 314, which, according to one embodiment, comprises a Microsoft SQL Server machine, supports built-in scalar types. Built-in scalar types are "native" and "simple." They are native in the sense that the user cannot set their own types, and they are simple in the sense that they cannot encapsulate a complex structure. User-defined types (UDTs) provide a mechanism for extensibility of types beyond the native scalar type system, allowing users to extend the type system by defining complex, structured types. Once defined by the user, UDT cannot be used anywhere in the type system in which the built-in scalar type can be used.

According to an aspect of the present invention, storage platform schemes are mapped to UDT classes in the storage of a database machine. Data warehouse articles are mapped to UDT classes inferred from the Base.Item type. Like articles, extensions also map to UDT classes and use inheritance. The root type of extension is Base.Extension, from which all extension types are derived.

UDT is a CLR class, it has state (i.e. data fields) and behavior (i.e. procedures). UDTs are set using any managed language - C #, VB.NET, etc. UDT methods and operators can be invoked in T-SQL for an instance of this type. A UDT can be: a column type in a row, a procedure parameter type in T-SQL, or a variable type in T-SQL.

The following example illustrates the basics of UDT. Let MapLib.dll have an assembler called MapLib. This assembler has a class called Point, under 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 content in the class

}

}

The following T-SQL code associates the Point class with a SQL Server UDT called Point. The first step calls "CreateAssembly", which loads the MapLib assembler into the database. The second step calls "Create Type" to create a user-defined type, "Point" and associate it with the BaseTypes.Point managed type:

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

go

CREATE TYPE Point

EXTERNAL NAME 'BaseTypes.Point'

go

After creating the UDT, “Point” can be used as a column in a table, and methods can be called in T-SQL, as shown below:

Create table Cities (

Name varchar (20),

State varchar (20),

Location Point)

- Extract the distance between cities

- from coordinates (32,23)

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

Select Location :: Distance (@p)

From cities

The mapping of the storage platform schema to the UDT classes is fairly straightforward at a high level. In general, the storage platform schema maps to the CLR namespace. The type of storage platform is mapped to the CLR class. CLR class inheritance reflects the inheritance of the storage platform type, and the storage platform property maps to the CLR class property.

The article hierarchy shown in FIG. 29 is used as an example in this document. The Base.Item type is shown, from which all article types are derived, together with many derived article types (for example, Contact.Person and Contact.Employee), with the inheritance indicated by arrows.

2. Display articles

If you want to be able to globally search for an article, and for support in a relational database, according to this embodiment of inheriting and substituting types, one possible implementation of storing articles in a database repository involves storing all the articles in one table with a column of type Base.Item. Using the type substitution, you can save articles of all types and you can filter searches by type and subtype of the article using the Yukon operator "is of ( Type )".

However, due to issues related to the workload associated with this approach, according to this embodiment, the articles are divided by the top-level type, for example, the articles of each “family” of types are stored in a separate table. According to this separation scheme, a table is created for each type of article that inherits directly from Base.Item. Types inheriting below them 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 separately. For the example hierarchy of the article shown in FIG. 29, this gives 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 properties subject to global search for all articles. This table can be supported by the Update () method of the storage platform API through which all data changes are made. Unlike type family tables, this global article table contains only scalar properties of the top-level article, and not the entire UDT article object. The structure of the global article 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 article table allows navigation to the article object stored in the type family table by opening the ItemID and TypeID. ItemID, in general, uniquely identifies an article in a data warehouse. TypeID can be displayed using metadata, which are not described here, in the type name and view containing the article.

Since retrieving an article by its ItemID can be a normal operation, both in the context of the global table of articles and elsewhere, the GetItem () function is provided to retrieve the article object for this ItemID of the article. This function has the following declaration:

Base.Item Base.GetItem (uniqueidentifier ItemID)

For ease of access and to conceal implementation details, as far as possible, all article requests should be relative to the views built on the above article tables. In particular, views can be created for each type of article relative to the corresponding table of type families. These types of types can select all articles of the corresponding type, including subtypes. For convenience, in addition to the UDT object, views can represent columns for all top-level fields of this type, including inherited fields. Views for an example of the hierarchy of the article 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 number of articles found

- instances of Contact.Employee

create view Contact.Employee as

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

{Contact.Person Properties},

{Contact.Employee Properties},

{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},

{Change Tracking Information}, _Item

from Doc. [Table! Document]

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

- to limit the set of articles found to be instances

- Doc.WordDocument

create view Doc.WordDocument as

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

{Doc.Document Properties},

{Doc.WordDocument Properties},

{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 from the global table of articles. This view initially opens the same columns as the table:

create view Base.Item as

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

{Change Tracking Information}

from Base. [Table! Item]

3. Display extensions

Extensions are very similar to articles and obey some of the same requirements. As another root type that supports inheritance, extensions are subject to many of the same considerations and trade-offs in storage. As a result, similar type mappings are applied to extensions, instead of a single table approach. Of course, in other embodiments, a single table approach can be used.

According to this embodiment, the extension is associated with exactly one article through an ItemID and contains an ExtensionID that is unique in the context of the article. The extension 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 articles, a function can be provided to retrieve an extension by its identification, which is formed by 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 types of article types. Let the extension hierarchy be parallel to the article hierarchy example, with the following types: Base.Extension, Contact.PersonExtension, Contact.EmployeeExtension. You can create the following views:

create view Base.Extension as

select ItemID, ExtensionID, TypeID,

{Base.Extension Properties},

{Change Tracking Information}

from Base. [Table! Extension]

create view Contact. [Extension! PersonExtension] as

select _Extension.ItemID,

_Extension.ExtensionID,

{Base.Extension Properties},

{Contact.Person Extension Properties},

{Change Tracking Information}, _Extension

from Base. [Table! PersonExtension]

create view Contact. [Extension! EmployeeExtension] as

select _Extension.ItemID,

_Extension.ExtensionID,

{Base.Extension Properties},

{Contact.PersonExtension Properties},

{Contact.EmployeeExtension Properties},

{Change Tracking Information},

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 articles, extensions, relationships, or other nested elements to form deeply nested structures. Like articles and extensions, nested elements are implemented as UDTs, but they are stored in articles and extensions. Therefore, nested items do not have a repository that appears outside their article and extension containers. In other words, there are no tables in the system that directly store instances of types of a nested element, and there are no types specific to nested elements.

5. Object identification

Each entity in the data model, i.e. each article, extension and attitude, has a unique key value. An article is uniquely identified by its ItemId. An extension is uniquely identified by a compound key (ItemId, ExtensionId). ItemId, ExtensionId, and RelationshipId are GUID type values.

6. Naming SQL objects

All objects created in the data warehouse can be saved in the SQL schema name derived from the storage platform schema name. For example, the Base Storage Platform Schema (often referred to as "Base") can spawn types in the SQL schema "[System.Storage]", for example, "[System.Storage] .Item". Generated names are prefixed with a qualifier to avoid naming conflicts. If necessary, an exclamation mark (!) Is used as a separator for the logical part of the name. The table below describes the naming convention used for objects in the data warehouse. Each element of the schema (article, extension, relationship, and view) is listed in conjunction with the naming convention used to access instances in the data warehouse.

An object Name decoration Description Example The main type of article search Master! Item Provides a summary of articles in the current article domain. [System.Storage].
[Master! Item] Typical type of article search Type of article Provide all the property data from the article and any parent types. [AcmeCorp.Doc].
[OfficeDoc] The main type of extension search Master! Extension Provides a summary of all extensions in the current article domain. [System.Storage].
[Master ! Extension] A typed extension search type Extension ! extension type Provides all property data for extension . [AcmeCorp.Doc].
[Extension ! StickyNote] The main kind of relationship Master ! Relationship Provides a summary of all relationships in the current article domain. [System.Storage].
[Master ! Relationship] Relationship type Relationship ! relationship name Provides all the data associated with this relationship. [AcmeCorp.Doc].
[Relationship ! AuthorsFrom Document] View View ! view name Provides columns / types based on a schema view definition. [AcmeCorp.Doc].
[View! DocumentTitles]

7. Naming columns

When displaying any object model in the repository, the possibility of naming conflicts arises due to additional information stored in conjunction with the application object. To avoid naming conflicts, all non-type columns (columns that do not map directly to the named property when declaring types) are prefixed with an underscore (_). According to this embodiment, underscores (_) are not permitted as the initial character of any identifier property. In addition, to unify the naming between the CLR and the data warehouse, all properties of the types of the storage platform or schema element (relationships, etc.) must have the first capital letter.

8. Types of search

Views are provided by the storage platform to search for stored content. An SQL view is provided for each type of article and extension. In addition, views are provided to support relationships and views (defined in the Data Model). All kinds of SQL and underlying tables in the storage platform are read-only. Data can be saved or modified using the Update () method of the storage platform API, which is described in more detail below.

Each view specified explicitly in the storage platform scheme (specified by the developer of the scheme and not automatically generated by the storage platform) is available by the name of the SQL type [<schema name>]. [View! <View name>]. For example, a view called "BookSales" in the "AcmePublisher.Books" schema will be available using the name "[AcmePublisher.Books]. [View! BookSales]". Since the output format of the view is adjustable for each view (defined by an arbitrary request provided by the party that sets the view), the columns are directly displayed based on the definition of the type of scheme.

All kinds of SQL searches in the storage platform data warehouse use the following collation for columns:

1. Logical "key" columns of the result of the form, for example, ItemId, ElementId, RelationshipId, ...

2. Typed result metadata information, such as TypeId.

3. Change tracking columns, for example, CreateVersion, UpdateVersion, ...

4. Type-dependent columns (Properties of the declared type).

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

Members of each type family can be searched using a number of article types, and there is one type of article type in the data warehouse.

a) Article

Each type of article search contains a string for each article instance of a particular type or its subtypes. For example, a view for a Document type may return instances of Document, LegalDocument, and ReviewDocument. The types of Articles given in this example can be understood as shown in FIG. 28.

(1) The main type of article search

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

Column Type of Description ItemId ItemId Article Storage Platform Identification _TypeId Typeid Article TypeId - Identifies the exact type of the article and can be used to retrieve type information using the metadata catalog. _RootItemId ItemId The ItemId of the first non-embedded ancestor that controls the lifetime of this article. <global change tracking> ... Global Change Tracking Information <article properties> n / a One column per article type property

(2) Typed Article Search Types

Each type of article also has the form of a search. Although this view is similar to the root article, it also provides access to the article object through the "_Item" column. Each typed type of article search is identified in the data warehouse using the name [ schema name ]. [ Article type name ]. For example [AcmeCorp.Doc]. [OfficeDoc].

Column Type of Description ItemId ItemId Article Storage Platform Identification <type change tracking> ... Type Change Tracking Information <parent properties> <associated with a property> One column per parent property <article properties> <associated with a property> One column per exceptional property of this type _- Item CLR type of article CLR object - type of declared article

b) Article extensions

All article extensions in the WinFS repository are also available using search types.

(1) Main view of extension search

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

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

(2) Typed extension search types

Each type of extension also has the form of a search. Although this view is similar to the main view of the extension, it also provides access to the article object through the _Extension column. Each typed type of extension search [ schema name ]. [ Extension ! extension type name ]. For example [AcmeCorp.Doc]. [Extension! OfficeDocExt].

Column Type of Description ItemId ItemId Identification of the article storage platform this extension is associated with ExtensionId ExtensionId (GUID) ID of this extension instance <type change tracking> ... Type Change Tracking Information <parent properties> <depends on property> One column per parent property <extension properties> <depends on property> One column per exceptional property of this type _{_} Extension Extension Instance CLR Type CLR object - type of extension declared

c) Nested elements

All nested items are stored in copies of articles, extensions, or relationships. Therefore, access to them is carried out by requesting the appropriate type of article search, extension or relationship.

d) Relationships

According to the above, relations form the basic unit of communication between articles in the data warehouse of the storage platform.

(1) The main type of relationship search

Each data warehouse provides the main kind of relationship. This view provides information about all instances of the relationship in the data warehouse. The main relationship type 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) Relationship instance id _RelTypeId RelationshipTypeId RelTypeId relationships — Identifies the instance type of the relationship using the metadata catalog. <global change tracking> ... Global change tracking information. TargetItemReference ItemReference Target Endpoint Identification _Relationship Relationship An instance of the relationship object for this instance.

(2) Types of relationship instance search

Each declared relation also has the form of a search, which returns all instances of a particular relation. Although this view is similar to the main view of a relationship, it also provides named columns for each property of the relationship data. Each instance of the relationship of the search type is identified in the data warehouse using the name [ schema name ]. [Relationship ! relationship name ]. For example, [AcmeCoip.Doc]. [Relationship! DocumentAuthor].

Column Type of Description ItemId ItemId Source Endpoint Identification (ItemId) RelationshipId RelationshipId (GUID) Relationship instance id <type change tracking> ... Type Change Tracking Information TargetItemReference ItemReference Target Endpoint Identification <source name> ItemId Named origin endpoint identification property (alias for ItemId) <target name> ItemReference or derived class Named target endpoint identification property (alias and cast for TargetItemReference) <relationship property> <depends on property> One column per relation definition property _Relationship Relationship Instance CLR Type CLR Object - Declared Relationship Type

9. Updates

All views in the data warehouse storage platform are read-only. To create a new instance of a data model element (article, extension, or relationship) or to update an existing instance, you must use the ProcessOperation or ProcessUpdategram API of the storage platform. The ProcessOperation method is the only stored procedure specified by the data store that consumes an “operation” that details the action to be performed. The ProcessUpdategram method is a stored procedure that accepts an ordered set of operations called an “updategram” that collectively 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 articles:

but. CreateItem (creates a new article in the context of an implementation or support relationship)

b. UpdateItem (updates an existing article)

2. Relationship operations:

but. CreateRelationship (creates an instance of a link or support relationship)

b. UpdateRelationship (updates the relationship instance)

from. DeleteRelationship (deletes relationship instances)

3. Operations on extensions,

but. CreateExtension (adds an extension to an existing article)

b. UpdateExtension (updates an existing extension)

from. DeleteExtension (removes the extension)

10. Track changes and gravestones

Change tracking and gravestone services are provided with a data warehouse, which is discussed in more detail below. This section provides an overview of the change tracking information that is open in the data warehouse.

a) Change tracking

Each type of search provided by the data warehouse contains columns used to provide change tracking information; columns are common across all kinds of articles, extensions, and relationships. Types of storage platform schemas that are explicitly set by schema developers do not automatically provide change tracking information — such information is provided indirectly through the search types on which the view itself is built.

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

(1) Track changes in the “main” types of searches

Information tracking changes in the main types of searches provides information on creating and updating versions of an element, information about which synchronization partner created the element, which synchronization partner last updated the element and version numbers from each partner to create and update. Partners in a synchronization relationship (described below) are identified by the partner key. A single UDT object called _ChangeTrackingInfo of type [System.Storage.Store] .ChangeTrackingInfo contains all this information. The type is specified in the System.Storage schema. _ChangeTrackingInfo is available in all global search types for article, extension and relationship. The type definition for ChangeTrackingInfo is as follows:

<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.Sqllnt64"

Nullable = "False" />

</Type>

These properties contain the following information:

Column Description _CreationLocalTS Creating a Timestamp by a Local Machine _CreatingPartnerKey PartnerKey is the partner who created this entity. If the entity is created locally, this is the PartnerKey of the local machine. _CreatingPartnerTS The timestamp corresponding to the time this entity was created on the partner matching _CreatingPartnerKey. _LastUpdateLocalTS Local timestamp corresponding to the update time on the local machine. _LastUpdatingPartnerKey PartnerKey is the partner who last updated this entity. If the last update of this entity was done locally, this is the PartnerKey of the local machine. _LastUpdatingPartnerTS The timestamp corresponding to the update time of this entity on the partner matching _LastUpdatingPartnerKey.

(2) Tracking changes in typed search types

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

Column Type of Description <global change tracking> ... Global Change Tracking Information _ChangeUnitVersions MultiSet <ChangeUnitVersion> Description of version numbers of change blocks in a specific element _ElementSyncMetadata ElementSyncMetadata Additional version-independent metadata about this article that is only of interest to the synchronization runtime. _VersionSyncMetadata VersionSyncMetadata Additional version-independent metadata about this version that is solely of interest to the synchronization runtime.

b) Tombstones

The data warehouse provides tombstone information for articles, extensions, and relationships. Types of gravestones provide information about both living and buried entities (articles, extensions and relationships) in one place. The tombstone types of the article and the extension do not provide access to the corresponding object, while the tombstone type of the relationship provides access to the relationship object (the relationship object is NULL in the case of a buried relationship).

(1) Tombstones articles

Tombstones of articles are retrieved from the system using the [System.Storage]. [Tombstone! Item] view.

Column Type of Description ItemId ItemId Article Identification _TureID Typeid Type of article <Article Properties> ... Properties set for all articles _RootItemId ItemId ItemId of the first non-embedded article that contains this article. _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this article. _IsDeleted Bit This is a flag that is 0 for live articles and 1 for buried articles. _DeletionWallclock Utcatetime The UTC wall clock date and time corresponding to the partner who deleted the article. Equals NULL if the article is live.

(2) Gravestone extensions

Tombstones of extensions are extracted from the system using the form [System.Storage]. [Tombstone! Extension]. Extension change tracking information is similar to that provided for articles with the ExtensionId property extension.

Column Type of Description ItemId ItemId Identification of the article to which the extension belongs ExtensionId ExtensionId Extension ID for extension _TureID Typeid Extension type _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this extension _IsDeleted Bit This is a flag that is 0 for live articles, and 1 for buried extensions. _DeletionWallclock Utcatetime The UTC wall clock date and time corresponding to the partner who uninstalled the extension. Equals NULL if the extension is live.

(3) Tombstones of a relationship

Tombstones of relationships are retrieved from the system using the [System.Storage]. [Tombstone! Relationship] view. Tombstone relationship information is similar to that provided for extensions. However, additional information is provided about the ItemRef of the relationship instance target. In addition, a relationship object is selected.

Column Type of Description ItemId ItemId Identification of the article that owned the relationship (identification of the source endpoint of the relationship) RelationshipId RelationshipId Relationship id for relationship _TypeID Typeid Relationship type _ChangeTrackingInfo CLR instance of type ChangeTrackingInfo Change tracking information for this relationship _IsDeleted Bit This is a flag that is 0 for live articles, and 1 for buried extensions. _DeletionWallclock Utcatetime The UTC wall clock date and time corresponding to the partner who deleted the relationship. Equals NULL if the relation is live. _Relationship CLR instance for relationship It is a relationship object for a living relationship. Equals NULL for buried relationships. TargetItemReference ItemReference Target Endpoint Identification

(4) Tombstone Cleaning

To avoid unlimited growth of tombstone information, the data warehouse provides the task of cleaning tombstones. This task determines when tombstone information can be discarded. The task calculates the boundary on the local version creation / update, then truncates the tombstone information, discarding all earlier versions of the tombstone.

11. API and helper functions

Basic mapping also provides a number of helper functions. These functions are provided to aid the usual operations on the data model.

a) Function [System.Storage] .GetItem

// Returns the article object specified by ItemId

//

Item GetItem (ItemId ItemId)

b) Function [System.Storage] .GetExtension

// Returns the extension object specified by ItemId and

// ExtensionId

//

Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId)

c) Function [System.Storage] .GetRelationship

// Returns the relationship object specified by ItemId and

// RelationshipId

//

Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)

12. Metadata

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

a) Schema metadata

Schema metadata is stored in the data warehouse as instances of article types from the metascheme.

b) Instance metadata

Instance metadata is used by the application to query the type of article and find the extensions associated with the article. Based on the ItemId for the article, the application can query the global type of the article to return the type of the article and use this value to query the type Meta.Type to return information about the declared type of the article. For example,

// Returns the metadata of the article object for this

// article instance

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

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

1. Overview

According to this embodiment, the degree of fragmentation with which the security policy of the storage platform is defined and applied corresponds to the level of various operations on an article in this data warehouse; it is impossible to ensure the security of parts of the article separately from the whole. The security model affects many principals who can be allowed or denied access to perform these operations on an article through Access Control Lists (ACLs). Each ACL is an ordered collection of access control entries (ACEs).

The security policy for the article can be fully described through a discretionary access control policy and a system access control policy. Each of them is a set of ACLs. The first set (DACL) describes the discretionary access granted to various principals by the owner of the article, while the second set of ACLs are called SACLs (system access control lists) that specify how system auditing is performed when an object is manipulated in certain ways. In addition, each article in the data warehouse is associated with a SID that corresponds to the owner of the article (owner SID).

The main mechanism for organizing articles in the storage platform data warehouse is the inclusion hierarchy mechanism. The inclusion hierarchy is implemented using support relationships between articles. The support relationship between two articles A and B, expressed as “A contains B”, allows article A to influence the life time of article B. In general, an article in the data warehouse cannot exist as long as there is a support relationship from another article to it. A support relationship, in addition to managing the life time of an article, provides the necessary mechanism for distributing security policies for an article.

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

Since the security policy is distributed through a support relationship and can also be substituted for any article, it is necessary to indicate how an effective security policy is defined for the article. According to this embodiment, the entry in the data warehouse enable hierarchy inherits ACLs along each path from the root of the store to the entry.

In a legacy ACL for any given path, ordering the various ACEs in the ACL determines the final security policy that applies. The following notation is used to describe ACE ordering in the ACL. The ordering of an ACE in an ACL that is inherited by an article is determined by the following two rules.

The first rule layers ACEs inherited from various articles on the way to article I from the root of the inclusion hierarchy. ACEs inherited from a closer container take precedence over records inherited from a remote container. From an intuitive point of view, this allows the administrator to replace ACEs inherited from those that are more remote in the inclusion hierarchy. The rule is this:

For all inherited ACL Ls in Article I

For all articles I1, I2

For all ACE A1 and A2 in L,

I1 is the ancestor of I2, and

I2 is the ancestor of I3, and

A1 is an ACE inherited from I1, and

A2 is an ACE inherited from I2

Attracts

A2 precedes A1 in L.

The second rule establishes the position of ACEs that deny access to an article, ahead of ACEs that provide access to an article.

For all inherited ACL Ls in Article I

For all articles I1

For all ACE A1 and A2 in L,

I1 is the ancestor of I2, and

A1 is ACCESS_DENIED_ACE inherited from I1, and

A2 is ACCESS_GRANTED_ACE inherited from I1

Attracts

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 article, and the article has exactly one inherited ACL. In these circumstances, the ACL inherited by the article is the same as the ACL inherited by the file (s) in the existing Windows security model in terms of relative ordering of the ACEs in them.

However, the inclusion hierarchy in the data warehouse is a directed acyclic graph (DAG), since multiple support relationships are allowed for articles. Under these conditions, there are several paths to the article from the root of the inclusion hierarchy. Because the article inherits ACLs along each path, it is associated with a collection of ACLs, not one of them. Note that this is different from the traditional file system model, where exactly one ACL is associated with a file or folder.

There are two aspects to consider when the inclusion hierarchy is a DAG, not a tree. A description is needed of how an effective security policy is computed for an article when it inherits more than one ACL from its parents, and their organization and presentation is directly related to the administration of the security model for the storage platform data warehouse.

The following algorithm evaluates the access rights of a given principal to this article. Throughout this document, the following notation is used to describe the ACLs associated with the article.

Inherited_ACLs (ItemId) - the set of ACLs inherited by the article identified by ItemId from their parents in the repository.

Explicit_ACL (ItemId) - An ACL explicitly set for an article identified by ItemId.

NTSTATUS

ACLAccessCheck (

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

The above procedure returns STATUS_SUCCESS if the requested access was not explicitly denied, and pGrantedAccess determines which of the rights requested by the user were granted by the specified ACL. If any of the access requests was explicitly rejected, the procedure 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, & NurnberOfInheritedAC Ls)

Status = ACLAccessCheck (

pOwnerSid,

pExplicitACL,

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,

pExplicitACL,

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 article covers all descendants of the article in the inclusion hierarchy defined on the data warehouse. For all articles where an explicit policy is specified, as a result, we set a policy that is inherited by all its descendants in the inclusion hierarchy. Effective ACLs inherited by all descendants are obtained by taking each of the ACLs inherited by the article and adding inherited ACEs in the explicit ACL at the beginning of the ACL. This is called the multiple inherited ACLs associated with the article.

In the absence of any explicit security specification in the inclusion hierarchy that has the root of the folder entry, the security specification of the entry applies to all descendants of this entry in the inclusion hierarchy. Thus, each article for which an explicit security policy specification is provided defines an area of equally protected articles, and effective ACLs for all articles in the field form many inherited ACLs for this article. This fully defines the areas when the inclusion hierarchy is a tree. If you associate a number with each area, it will be quite simple to include the area to which the article belongs, together with the article.

However, for inclusion hierarchies that are DAGs, points in the inclusion hierarchy at which the effective security policy changes are defined by two kinds of entries. The first includes articles for which explicit ACLs have been defined. Typically, there are points in the inclusion hierarchy where the administrator explicitly specified the ACL. The second includes articles that have more than one parent, and different security policies are associated with different parents. Typically, these are articles that are the merging points of the security policies defined for the volume and indicate the beginning of a new security policy.

Thanks to this definition, all articles in the data warehouse fall into one of two categories - those that are the root of the equally protected security area, and those that are not. Articles that do not define a security domain belong to exactly one security domain. As with trees, effective security for an article can be specified by specifying the area to which the article belongs, together with the article. This provides a direct model for administering the security of the storage platform data warehouse based on various equally protected areas in the warehouse.

2. Detailed description of the security model

This section describes in detail how to secure articles by describing how individual rights in the security descriptor and the ACLs contained in them affect various operations.

a) Security descriptor structure

Before describing the security model in detail, it is useful to consider security descriptors in a more general way. 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. SIDs for the owner and primary group of the object.

2. DACL, which sets the access rights allowed or denied to specific users or groups.

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

4. Many control bits that specify the value of the security descriptor or its individual elements.

Preferably, applications are not able to 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 the trustees who are allowed or denied access to the protected object. When a process tries to access the protected object, the system checks the ACE in the object's DACL to determine whether to provide access to it. If the object does not have a DACL, the system provides full access to anyone. If the object's DACL does not have ACE, the system rejects all access attempts to the object, since the DACL does not give any access rights. The system sequentially checks the ACEs until it finds one or more ACEs that allow all requested access rights or until any of the requested access permissions are denied.

The system access control list (SACL) allows the administrator to register attempts to access a protected object. Each ACE indicates the types of access attempts by the specified trustee, which causes the system to generate a security event log entry. The ACE in the SACL can generate audit records for a failed access attempt, for a successful access attempt, or in both cases. The SACL can also issue an alarm when an unauthorized user attempts to access an object.

All ACE types contain the following access control information:

1. A security identifier (SID) that identifies the trustee to whom the ACE applies.

2. An access mask that sets access rights under ACE.

3. A flag indicating the type of ACE.

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

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

Type of Description ACE Denying Access Used in the DACL to prohibit access rights for a trustee. ACE allowing access Used in the DACL to authorize access rights for a trustee. ACE System Audit Used by the SACL to generate an audit record when a proxy attempts to use the specified access rights.

(1) Access mask format

All protected objects organize their access rights using the access mask format shown in FIG. In this format, the 16 low-order bits are for object-specific access rights, the next 7 bits are for standard access rights that apply to most types of objects, and the 4 high-order bits are used to indicate the general access rights that each type of object can display in many standard and object-specific rights. The ACCESS_SYSTEM_SECURITY bit corresponds to the access right of the SACL of the object.

(2) General permissions

Common rights are set in the 4 high-order bits of the mask. Each type of protected object maps these bits to its many standard and object-specific access rights. For example, a file object maps the GENERIC_READ bit to standard READ_CONTROL and SYNCHRONIZE access rights and to 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 suitable for this type of object.

General permissions can be used to specify the type of access required when opening a handle to an object. This is usually simpler than setting all the appropriate standard and special rights. The following table lists the constants defined for general permissions.

constant Overall value GENERIC_ALL Read, write, and access to execute GENERIC_EXECUTE Access to execute GENERIC_READ Read access GENERIC_WRITE Write access

(3) Standard access rights

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

Constant Value DELETE The right to delete an object. READ_CONTROL The right to read information in the object's security descriptor, not including information in the SACL. SYNCHRONIZE The right to use the object for synchronization. This allows the thread to wait until the object is in the signaled state. Some types of objects do not support this access right. WRITE_DAC The right to change the DACL in the object's security descriptor. WRITE_OWNER The right to change the owner in the security descriptor of the object.

b) Article-specific rights

In the structure of the access mask shown in FIG. 26, article-dependent rights are placed in the “object-specific rights” section (the lower 16 bits). Since, according to this embodiment, the storage platform opens up two sets of APIs for administering security - Win32 and the storage platform APIs, object-specific file system rights should be considered to motivate the construction of object-specific rights, the storage platform.

(1) Rights depending on the object “file” and “directory”

Consider the following table:

Directory Directory Description File File description Value FILE_LIST_DIRECTORY The right to show the contents of the directory FILE_READ_DATA The right to read the data of the corresponding file 0x0001 FILE_ADD_FILE The right to create a file in a directory FILE_WRITE_DATA The right to write data to a file 0x0002 FILE_ADD_SUBDIRECTORY The right to create a subdirectory FILE_APPEND_DATA The right to attach data to a file 0x0004 FILE_READ_EA The right to read extended file attributes FILE_READ_EA The right to read extended file attributes 0x0008 FILE_WRITE_EA The right to write extended file attributes FILE _{_} WRITE _{_} EA The right to write extended file attributes 0x0010 FILE_TRAVERSE The right to bypass the directory FILE _{_} EXECUTE For an internal code file, the right to execute the file 0x0020 FILE_DELETE_CHILD The right to delete a directory and all files contained in it no no 0x0040 FILE _{_} READ_ATTRIBUTES The right to read directory attributes FILE_READ_ATTRIBUTES The right to read file attributes 0x0080 FILE_WRITE_ATTRIBUTES The right to write file attributes FILE_WRITE_ATTRIBUTES The right to write file attributes 0x0100

According to the table above, we note that file systems make fundamental differences between files and directories, because of the rights related to files and directories that overlap on the same bits. File systems define very fragmented rights that allow applications to control behavior on these objects. For example, they allow applications to distinguish between attributes (FILE_READ / WRITE_ATTRIBUTES), extended attributes, and the data stream associated with a file.

The purpose of the security model of the storage platform according to the present invention is to simplify the assignment model so that applications operating with data storage articles (contacts, email addresses, etc.) generally do not have to make a distinction, for example, between attributes, extended attributes and data streams. However, Win32 fragmentary rights are saved for files and folders and access semantics are set via the storage platform, which allows maintaining compatibility with Win32 applications. This mapping is considered for each of the rights to the article listed below.

The following rights to the article are indicated in conjunction with the corresponding permissible operations. Win32 equivalent rights are also provided that reserve each of these rights to the article.

(2) WinFSItemRead

This right allows read access to all equivalents of an article, including articles related to the article through an implementation relationship. It also allows the listing of articles tied to this article through a support relationship (like displaying a directory). This includes the names of articles linked by link relationships. This right is displayed in

File:

(FILE_READ_DATA | SYNCHRONIZE)

Folder:

(FILE_LIST_DIRECTORY | SYNCHRONIZE)

The semantics are that a security application cannot set WinFSItemReadData and specify a rights mask as a combination of the above file permissions.

(3) WinFSItemReadAttributes

This right allows read access to the main attributes of the article, although file systems make a distinction between the main attributes of a file and data streams. Preferably, these basic attributes are those that are placed in the base article from which all articles are derived. This right is mapped to:

File:

(FILE_READ_ATTRIBUTES)

Folder:

(FILE_READ_ATTRIBUTES)

(4) WinFSItemWriteAttributes

This right allows write access to the main attributes of the article, although file systems make a distinction between the main attributes of a file and data streams. Preferably, these basic attributes are those that are placed in the base article from which all articles are derived. This right is mapped to:

File:

(FILE_WRITE_ATTRIBUTES)

Folder:

(FILE_WRITE_ATTRIBUTES)

(5) WinFSItemWrite

This right allows you to record all the elements of an article, including articles related to implementation relationships. This right also allows you to add embedding relationships to other articles or remove them from there. This right is mapped to:

File:

(FILE_WRITE_DATA)

Folder:

(FILE_ADD_FILE)

In the storage platform data warehouse, no distinction is made between articles and folders, since articles can also have support relationships with other articles in the data warehouse. Therefore, if you have the rights FILE_ADD_SUBDIRECTORY (or FILE_APPEND_DATA), your article may be a source of relations to other articles.

(6) WinFSItemAddLink

This right allows you to add support relationships to articles in the repository. It should be noted that since the security model for multiple support relationships changes the security on the article and the changes can bypass WRITE_DAC if they come from a higher point in the hierarchy, WRITE_DAC is required on the destination article in order to create a relationship to it. This right is mapped to:

File:

(FILE_APPEND_DATA)

Folder:

(FILE_ADD_SUBDIRECTORY)

(7) WinFSItemDeleteLink

This right makes it possible to remove support for an article, even if the right to delete this article is not given to the principal. This is consistent with the file system model and helps clean up. This right is mapped to:

File:

(FILE _{_} DELETE_CHILD) - note that file systems do not have a file equivalent to this right, but we have the concept of articles that have support relationships to others, and therefore transfer this right to non-folders as well.

Folder:

(FILE_DELETE_CHILD)

(8) Rights to delete an article

An article is destroyed when the last support relationship to the article is removed. There is no explicit designation for deleting an article. There is a cleanup operation that removes all support relationships for the article, but it is a higher-level tool, not a system primitive.

Any article specified using the path can be untied if either of the following conditions is met: (1) the parent article on this path gives the subject write access or (2) the standard rights on the article itself give DELETE. When you delete the last relationship, the article disappears from the system. Any article referenced using the ItemID can be untied if the standard rights on the article itself give DELETE.

(9) Rights to copy an article

An article can be copied from the source folder to the destination folder if the subject is given WinFSItemRead on the article and WinFSItemWrite on the destination folder.

(10) Rights to Move Articles

To move a file in the file system, you simply need the DELETE right on the source file and FILE_ADD_FILE on the destination directory, since this saves the ACL on the destination. However, when calling MoveFileEx, you can set the flag (MOVEFILE_COPY_ALLOWED), which allows the application to indicate that this is a case of moving between volumes, it can allow CopyFile semantics. There are 4 potential options for what happens to a move safety handle:

1. The entire ACL is carried with the file - the default semantics of movement within the volume are accepted.

2. The entire ACL is transferred with the file and marked as protected.

3. Only explicit ACEs are migrated and they are re-inherited at the destination.

4. Nothing is transferred and nothing is inherited repeatedly at the destination — the default semantics of moving between volumes are the same as copying a file.

In this security model, if the application sets the MOVEFILE_COPY_ALLOWED flag, the fourth option is implemented for inter- and intra-internal cases. If this flag is not set, the second option is implemented if the destination is in the same security area (i.e., the same inheritance semantics). Moving at the storage platform level implements the fourth option, and also requires READ_DATA on the source, almost like copying.

(11) Rights to view security policy on an article

Security of an article can be viewed if the article gives the subject the standard READ_CONTROL right.

(12) Rights to change security policy on the article

The security of an article can be changed if the article gives the subject standard WRITE_DAC right. However, since the data warehouse provides implicit inheritance, it depends on how security can be changed on hierarchies. The rule is that if the root of the hierarchy gives WRITE_DAC, then the security policy can be changed throughout the hierarchy, regardless of whether specific articles in the hierarchy (or DAG) grant WRITE_DAC to the subject.

(13) Rights not directly equivalent

According to this 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 based on these rights no decisions are made on granting access. As for FILE_READ / WRITE_EA, since the data warehouse articles do not have extended attributes, there is no semantics for this bit. However, the bit remains for compatibility with Win32.

3. Implementation

All articles defining equally protected areas have cells associated with them in the security table. The security table is defined as follows:

Article Identification Ordered article path Explicit ACL Articles ACL paths ACL areas

An “Article Identification” cell is the article identification for the root of an equally protected security area. An Ordered Article Path cell is an ordered path associated with the root of an equally protected security area. An “Explicit Article ACL” cell is an explicit ACL defined for the root of an equally protected security area. In some cases, it may be NULL, for example, when defining a new security area, because the article has several parents belonging to different areas. The “path ACL” cell is the set of ACLs inherited by the article, and the “area ACL” cell is the set of ACLs defined for the equally protected security area associated with the article.

The calculation of effective security for any article in this repository reinforces this table. To determine the security policy associated with the article, obtain the security scope associated with the article and retrieve the ACLs associated with this scope.

When changing the security policy associated with an article, either directly, by adding explicit ACLs, or indirectly by adding support relationships, which leads to the formation of new security areas, the security table is updated, thereby ensuring the suitability of the above algorithm to determine the effective security of the article.

We describe the various changes made to the repository and the corresponding algorithms for maintaining the security table.

a) Create a new article in the container

When creating a new article in a container, it inherits all the ACLs associated with the container. Since the newly created article has exactly one parent, it belongs to the same area as the parent. Thus, there is no need to create a new cell in the security table.

b) Adding an explicit ACL to the article

When you add an ACL to an article, it defines a new security scope for all its descendants in the inclusion hierarchy that belong to the same security scope as the article itself. For all articles that belong to other security domains, but are descendants of this article in the inclusion hierarchy, the security domain remains unchanged, but the effective ACL associated with the domain changes to reflect the addition of a new ACL.

The introduction of this new security area may lead to additional areas for all articles that have multiple support relationships with ancestors that cover the old security area and the newly defined security area. For all such articles, a new security area needs to be defined and the procedure repeats.

27 (a), (b), and (c) show that new equally protected security areas are distinguished from an existing security area by introducing a new explicit ACL. This is indicated by the node indicated by 2. However, the introduction of this new area leads to the creation of additional area 3, since the article has multiple support relationships.

The following sequence of security table updates reflects a split of equally protected security areas.

c) Adding a support relationship to an article

Adding a support relationship to an article provides one of three possibilities. If the goal is a support relationship, i.e. The article in question is the root of the security domain, the effective ACL associated with the domain is changed, and no additional changes to the security table are required. If the security domain of the source of the new support relationship is identical to the security domain of the existing article parents, then no changes are required. If the article currently has parents who belong to other security areas, a new security area is formed, which has this article as the root of the security field. This change applies to all entries in the inclusion hierarchy by changing the security scope associated with the entry. All articles that belong to the same security domain as the article in question and its descendants in the inclusion hierarchy need to be changed. After the change, all articles with multiple support relationships should be checked for the need for further changes. Additional changes may be required if any of these articles has parents in other areas of security.

d) Removing a support relationship from an article

When you remove a support relationship from an article, the security domain may merge with its parent domain if certain conditions are met. In particular, this can occur under the following conditions: (1) if the deletion of the support relationship results in the article having one parent and no explicit ACLs are specified for this article; (2) if the deletion of the support relationship results in all parents of the article belonging to the same security domain and no explicit ACLs are specified for this article. In these circumstances, the security domain can be marked as identical to the parent. This marking must be applied to all articles whose safety areas correspond to the area undergoing the merger.

f) Removing an explicit ACL from an article

When you remove an explicit ACL from an article, it is possible to merge the security domain whose horse this article is with the security domains of its parents. In particular, this happens if deleting an explicit ACL causes the parents of the article in the inclusion hierarchy to belong to the same security area. In these circumstances, the security area can be marked as identical to the parent, and the changes apply to all articles whose security areas correspond to the area being merged.

f) Change in ACL associated with an article

In this scenario, no additions to the security table are required. The effective area-related ACL is updated, and a new change to the ACL extends to the security areas affected by it.

F. Notification and Change Tracking

According to another aspect of the present invention, the storage platform provides a notification capability that allows applications to track data changes. This feature is mainly intended for applications that support a mobile state or execute commercial logic on data change events. Applications register notifications on articles, article extensions, and article relations. Notifications are delivered asynchronously after data changes. Applications can filter notifications by article, extension and type of relationship, as well as by type of operation.

In one embodiment, storage platform API 322 provides two kinds of notification interfaces. In the first application, simple data change events are recorded due to changes in articles, article extensions, and article relations. In the second application, “observer” objects are created to monitor multiple articles, article extensions, and article relationships. The state of the observer object can be saved and re-created after a system failure or after the system has been working offline for an extended period of time. A single notification may reflect multiple updates.

1. Saving change events

This section provides several examples of using the notification interfaces provided by the storage platform API 322.

a) Events

Articles, article extensions, and article relations open data change events that are used by applications to record data change notifications. The following code illustrates the definition of the ItemModified and ItemRemoved event handlers on the base class Item.

// Developments

public event ItemModifiedEventHandler Item ItemModified ;

public event ItemRemovedEventHandler Item ItemRemoved ;

All notifications carry enough data to retrieve the modified article from the data warehouse. The following illustrative code demonstrates the registration of events on an article, article extension, or article relation:

myItem.ItemModified + = new

ItemModifiedEventHandler (this.onItemUpdate);

myItem.ItemRemoved + = new

ItemRemovedEventHandler (this.onItemDelete);

According to this embodiment, the storage platform ensures that applications are notified of changes or deletions of the corresponding article after the last delivery of the notification or in the case of a new registration after the last retrieval from the data warehouse.

b) Observers

According to this embodiment, the storage platform defines observer classes for monitoring objects associated with (1) a folder or folder hierarchy, (2) the context of an article, or (3) a specific article. For each of these three categories, the storage platform provides specific observer classes that track related articles, article extensions, or article relationships, for example, the storage platform provides the corresponding classes FolderItemWatcher, FolderRelationshipWatcher and FolderExtensionWatcher.

To create an observer, an application may request notifications for previously existing articles, i.e. articles, extensions, or relationships. This feature is common for applications that support a private article cache. In the absence of a request, applications receive notifications for all updates that occur after the creation of an observer object.

Together with notification delivery, the storage platform issues a WatcherState object (observer state). WatcherState can be converted to sequential mode and saved to disk. After that, the state of the observer can be used to recreate the corresponding observer after a failure or after reconnecting after a period of autonomous work. The newly recreated observer will re-generate unacknowledged notifications. Applications indicate delivery of a notification by calling the "Exclude" method on the corresponding state of the observer, issuing 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.

By way of example, the following code illustrates the definition of a FolderItemWatcher.

public class FolderItemWatcher: Watcher

{

// Constructors

public FolderItemWatcher_Constructor (Folder folder);

public FolderItemWatcher_Constructor1 (Folder folder,

Type itemType);

public FolderItemWatcher_Constructor2 (ItemContext context,

ItemId folderId);

public FolderItemWatcher_Constructor3 (Folder folder,

Type itemType, FolderItemWatcherOptions options);

public FolderItemWatcher_Constructor4 (ItemContext context,

ItemId folderId, Type itemType);

public FolderItemWatcher_Constructor5 (ItemContext context,

ItemId folderId, Type

itemType, FolderItemWatcherOptions options);

// Properties

public ItemId FolderItemWatcher_FolderId {get;}

public Type FolderItemWatcher_ItemType {get;}

public FolderItemWatcherOptions

FolderItemWatcher_Options (get;}

// Developments

public event ItemChangedEventHandler

FolderItemWatcher_ItemChanged ;

}

The following code illustrates how to create a folder watcher object to monitor the contents of a folder. The observer generates notifications, i.e. events when new music articles are added or existing music articles are updated or deleted. Folder watchers track either a specific folder or all folders in a folder hierarchy.

myFolderItemWatcher = new FolderItemWatcher (myFolder,

typeof (Music));

myFolderItemWatcher.ItemChanged + = new

ItemChangedEventHandler (this.onItemChanged);

2. Change tracking and notification mechanism

The storage platform provides a simple but effective mechanism for tracking data changes and generating alerts. The client retrieves notifications on the same connection that is used to retrieve the data. This, in general, simplifies security checks, eliminates delays and restrictions on possible network configurations. Notifications are retrieved by issuing selection statements. To avoid polling, clients can use the “waitfor” attribute provided by the database engine 314. 13 shows the basic concept of a storage platform notification. This waitfor request can be executed synchronously, in which case the calling thread is blocked until the results are received, or asynchronously, in this case the thread is not blocked, and the results are returned on a separate thread when they are available.

The combination of "waitfor" and "select" is attractive for monitoring data changes that fall within a specific data range, since changes can be tracked by setting the notification block on the corresponding data range. This is supported for many common storage platform scenarios. Changes to individual articles can be effectively tracked by setting notification locks on the appropriate data range. Changes to folders and folder trees can be tracked by setting notification locks on path ranges. Changes to types and their subtypes can be monitored by setting notification locks on type ranges.

In the general case, there are three different phases associated with the processing of notifications: (1) change or even discovery of data, (2) approval of subscriptions, and (3) delivery of notices. 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 negotiation is carried out as part of the update transaction; notifications are inserted into the table tracked by the subscriber;

2) delayed event detection: event detection and subscription approval is carried out after the update transaction; after that, the actual subscriber or intermediary detects events and generates notifications.

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

Delayed event detection eliminates the need to add additional code for update operations. Delayed event detection naturally groups event detection and event delivery and is consistent with the query infrastructure of database engine 314 (e.g., SQL Server).

Deferred event detection relies on a log or trace left by update operations. The storage platform supports many logical timestamps along with tombstones for deleted data items. When scanning a data warehouse for changes, clients issue a time stamp that sets a low watermark to detect changes, and many time stamps to avoid duplicate notifications. Applications can accept notifications for all changes that occur after a time indicated by a low watermark.

More complex applications with access to kernel views can further optimize and reduce the number of SQL statements needed to monitor a potentially large number of articles by creating a private parameter and duplicating filter tables. Applications with special needs, for example, that must support rich views, can use the available change tracking framework to monitor data changes and update their private snapshots.

Therefore, preferably, according to one embodiment, the storage platform implements a delayed event detection approach, which is described in more detail below.

a) Change tracking

All definitions of articles, extensions, and article relations carry a unique identifier. Change tracking supports many logical timestamps for recording the creation, update, and deletion times for all data articles. Tombstone records are used to represent deleted data articles.

Applications use this information to effectively track whether (a) a particular article, article extension, or article relation has been created (o), updated (o), or deleted (o) since the application last accessed the data warehouse. The following example illustrates this mechanism.

create table [item-extension-relationship-table-template] (

identifier uniqueidentifier not null default newid ()

created bigint, not null, - @ @ dbts when created

updated bigint, not null, - @ @ dbts when last updated

...

)

All deleted articles, article extensions, and relationships are recorded in the corresponding gravestone table. Below is a template.

create table [item-extension-relationship-tombstone

table-template] (

identifier uniqueidentifier not null,

deleted bigint not null, - @@ dbts when deleted,

created bigint not null, - @@ dbts when created

upated bigint not null, - @@ dbts when last updated

...

)

For efficiency reasons, the storage platform supports a set of global tables for articles, article extensions, relationships, and path names. These global lookup tables can be used by applications to efficiently monitor a range of data and retrieve the appropriate timestamp and type information.

b) Time stamp management

Logical timestamps are “local” with respect to the database storage, i.e. volume storage platforms. Timestamps are monotonically increasing 64-bit values. To detect whether a data change has occurred since the last connection to the storage platform volume, it is often sufficient to leave one time stamp. However, in most realistic scenarios, you have to leave a few more timestamps to check for duplicates. The reasons for this are explained below.

Relational database tables are logical abstractions that are add-on to many physical data structures, i.e. binary trees, heaps, etc. Assigning a time stamp to a newly created or updated record is not an elementary action. The insertion of this record into the underlying data structures can occur at different points in time, which allows applications to see the records in random order.

On Fig shows two transactions, both of which insert a new record in the same binary tree. Since transaction T3 inserts its record before the scheduled insertion of transaction T2, the application scanning the binary tree can see the records inserted by transaction T3 before the inserted T2. Thus, the reader may incorrectly assume that he saw all the records created before the time "10". To solve this issue, the database engine 314 provides a function that returns a low watermark until which all changes have been made and inserted into the corresponding underlying data structures. In the above example, the returned low watermark has a value of “5” based on the assumption that the reader started before transaction T2 was conducted. The low watermark provided by the database engine 314 allows applications to efficiently determine which articles to ignore when scanning a database or data range for data changes. In general, ACID transactions are supposed to last a very short time, so low watermarks are expected to be very close to the most recently set timestamp. In the presence of long-term transactions, applications must leave individual timestamps to detect and discard duplicates.

c) Data change detection - event detection

By requesting a data warehouse, applications receive a low watermark. Applications then use this watermark to scan the data store for records whose timestamps for creating, updating, or deleting are larger than the returned low watermark. This process is shown in FIG.

To avoid duplicate notifications, applications remember timestamps that are larger than the returned low watermark and use them to filter out duplicates. Applications create local temporary session tables to efficiently process a large number of duplicate timestamps. Before issuing a select statement, the application inserts all duplicate time stamps returned earlier and deletes those that are older than the last returned low watermark, as illustrated below.

delete from $ duplicates where ts <@oldLowWaterMark;

insert into $ duplicates (ts) values (...), ..., (...);

waitfor (select *, getLowWaterMark () as newLowWaterMark

from [global! items]

where updated> = @oldLowWaterMark

and updated not in (select * from $ duplicates))

G. Sync

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

Synchronization between storage platforms occurs in a group of participating copies. For example, according 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 operating on a different computer system. All members of this group need not be known to any given copy at any given time.

Different copies can make changes independently (i.e. at the same time). The synchronization process is defined as informing each copy of changes made by other copies. This synchronization feature is intrinsic to multiple mastering.

The ability to synchronize the present invention allows copies:

- determine what changes another copy knows;

- request information about changes about which this copy is not known;

- transfer information about changes about which another copy is not known;

- determine when two changes conflict with each other;

- apply changes locally;

- Transfer conflict resolution to other copies to ensure convergence;

- resolve conflicts based on predefined policies to resolve conflicts.

1. Synchronization between storage platforms

The main application of the synchronization service 330 of the storage platform of the present invention is to synchronize multiple instances of the storage platform (each of which has its own data store). The synchronization service operates at the level of the storage platform schemes (and not the underlying tables of the database engine 314). So, for example, “scopes” are used to define synchronization sets, which are discussed below.

The synchronization service operates on the basis of the “net change” principle. Instead of recording and transmitting individual operations (as in transactional duplication), the synchronization service transfers the final result of these operations, thus often consolidating the results of multiple operations into a single resultant change.

The synchronization service, in general, does not recognize the boundaries of the transaction. In other words, if two changes are made to the storage platform data warehouse in one transaction, there is no guarantee that these changes are automatically applied to all other copies - one can happen without the other. An exception to this principle is that if two changes are made in the same article in the same transaction, then these changes are guaranteed to be transferred and automatically applied to other copies. Thus, articles are units of consistency for a synchronization service.

a) Synchronization management applications

Any application can connect to a synchronization service and initiate a 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 (SCA) applications.

When synchronizing two instances of the storage platform, synchronization is initiated on one side through the SCA. This SCA informs the local synchronization service for synchronization with the remote partner. On the other hand, the synchronization service is awakened by messages transmitted by the synchronization service from the source machine. It responds based on the stable configuration information (see mappings below) present on the destination machine. The synchronization service can operate on a schedule or in response to events. In these cases, the synchronization service implementing the schedule becomes SCA.

To ensure synchronization, you need to perform two steps. First, the schema designer must annotate the storage platform schema with the proper synchronization semantics (indicating the change blocks described below). Secondly, synchronization must be properly configured on all machines that have a storage platform instance that must participate in synchronization (as described below).

b) Annotation of the scheme

The basic concept of a synchronization service is the concept of a change unit. A change block is the smallest piece of diagram that is individually tracked by the storage platform. For each change block, the synchronization service can determine if it has changed since the last synchronization.

Specifying change blocks in a schema serves several purposes. Firstly, it allows you to determine how informative the synchronization service on the wire. When changes are made in a change block, the entire change block is transferred to other copies, because the synchronization service does not know which part of the change block has undergone a change. Secondly, it allows you to determine the degree of fragmentation of conflict detection. When the same change block undergoes two simultaneous changes (these terms are detailed in the following sections), the synchronization service causes a conflict; if simultaneous changes are made in different blocks of change, the conflict is not excited, and the changes are automatically merged. Thirdly, this greatly affects the amount of metadata supported by the system. A large amount of metadata of synchronization services is stored per block of change; thus, the smaller the change unit, the greater the synchronization overhead.

To set change blocks, you need to find the right compromises. For this reason, the synchronization service allows circuit designers to participate in the process.

According to one embodiment, the synchronization service does not support change units that are larger than an element. However, it does support the ability of schema developers to define change units that are smaller than an element, namely, group multiple attribute attributes of an element into a separate change block. According to this embodiment, the following syntax is used for this:

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

ExtendsType = "Base.Item" Extends Version = "1">

<Field Name = "MeetingStatus" Type = "the storage

platformTypes.uniqueidentifier Nullable = "False" />

<Field Name = "OrganizerName" Type = "the storage

platformTypes.nvarchar (512) "Nullable =" False "/>

<Field Name = "OrganizerEmail" Type = "the storage

platformTypes.nvarchar (512) "

TypeMajorVersion = "1" MultiValued = "True" />

...

<ChangeUnit Name = "CU_Status">

<Field Name = "MeetingStatus" />

</ChangeUnit>

<ChangeUnit Name = "CU_Organizer" />

<Field Name = "OrganizerName" />

<Field Name = "OrganizerEmail" />

</ChangeUnit>

...

</Type>

c) Sync configuration

A group of storage platform partners who want to keep certain parts of their data in sync is called the synchronization community. Although 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 device interaction scenario, it is impractical for peer devices to maintain mapping mappings for all their partners. Instead, the synchronization service takes the approach of setting “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 by an example. If Joe wants to maintain My Documents folders on several of his computers in synchronism, Joe sets up a community folder called, say, JoesDocuments. Then, on each computer, Joe configures the mapping between the hypothetical JoesDocuments folder and the My Documents logical folder. From now on, when Joe's computers are synchronized with each other, they speak in terms of documents in JoesDocuments, rather than their local articles. Thus, all of Joe's computers understand each other without the need to know who the others are - Community Folder becomes lingua franca community synchronization.

Configuring the synchronization service consists of three stages: (1) setting folders between local folders and community folders; (2) setting synchronization profiles that determine what is being synchronized (for example, with whom to synchronize and which subsets to transmit and which to receive); and (3) setting schedules according to which profiles should be started, or starting them manually.

(1) Community Folder - Mappings

Community folder mappings are saved on separate machines as XML configuration files. Each mapping has the following scheme:

/ mappings / community folder

This item gives the name of the community folder for which this mapping is intended. The name obeys the following folder syntax.

/ display / local folder

This item gives the name of the local folder into which the mapping will convert. The name follows the syntax rules for folders. The folder must already exist for the display to be valid. Articles in this folder are considered for synchronization through this display.

/ display / conversion

This element defines how to convert articles from a community folder to a local folder and vice versa. In particular, this means that no IDs are displayed. This configuration is mainly used to create a folder cache.

/ mappings / conversions / mappings ID

This element requires that the newly generated local IDs be assigned to all articles displayed from the community folder, instead of reusing the community ID. The synchronization runtime will support ID mappings for converting articles in two directions.

/ mappings / transforms / local root

This element requires that the root entries in the community folder be made child entries of the specified root.

/ display / act for

This element controls on behalf of which requests for this mapping are processed. If absent, the sender is assumed.

/ display / act for / sender

The presence of this element indicates that it is necessary to act for the sender of messages on this display, and requests processed under his mandate.

(2) Profiles

A synchronization profile is a complete set of parameters necessary to start synchronization. It is passed to the SCA by the synchronization runtime to initiate synchronization. Synchronization profiles for synchronization between storage platforms contain the following information:

- a local folder that serves as the source and destination for changes;

- name of the remote folder with which you want to synchronize - this folder must be published from the remote partner by displaying, as described above;

- direction - the synchronization service supports synchronization of only transmission, only reception and transmission-reception;

- local filter - selects what local information to transmit to the remote partner. Expressed as a storage platform request for a local folder;

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

- conversions - sets how to convert articles to and from a local format;

- local security - indicates whether the changes extracted from the remote endpoint are subject to application by permission of the remote endpoint (spoofed) or the user locally initiating synchronization;

- conflict resolution policy - indicates whether conflicts should be dropped, registered or automatically resolved - in the latter case, it indicates which conflict resolution algorithm to use, as well as configuration parameters for it.

The synchronization service provides a runtime CLR class that allows easy construction of synchronization profiles. Profiles can also be sequentially converted to or from XML files for ease of storage (often next to schemas). However, there is no standard place in the storage platform where all properties are stored; SCAs can build a profile on a spot without even saving it. Note that initiating synchronization does not require a local mapping. All synchronization information can be specified in the profile. However, mapping is required to respond to synchronization requests initiated by the remote side.

(3) Schedules

According to one embodiment, the synchronization service does not provide its own scheduling infrastructure. On the contrary, it relies on another component to perform 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 an SCA and starts synchronization based on the synchronization profile stored in the XML file. This utility makes it very easy to configure the Windows Scheduler to start synchronization, either on schedule or in response to events, such as user input or output.

d) Conflict handling

Conflict handling in the synchronization service is divided into three stages: (1) conflict detection that occurs at the time the change is applied - this stage determines whether the change can be applied safely; (2) automatic resolution and registration of conflicts - at this stage (which takes place immediately after the conflict is detected), consultations with automatic conflict resolution algorithms are carried out to see if the conflict can be resolved - if not, the conflict can be registered optionally; and (3) inspection and resolution of the conflict - this stage takes place if some conflicts have been registered and is carried out outside the context of the synchronization session - at this time the registered conflicts can be resolved and deleted from the journal.

(1) Conflict Detection

According to this embodiment, the synchronization service detects two types of conflicts: based on knowledge and based on restriction.

(a) Knowledge-based conflicts

A knowledge-based conflict occurs when two copies make independent changes in the same change block. Two changes are called independent if they are made without knowledge of each other - in other words, the version of the first is not covered by knowledge of the second and vice versa. The synchronization service automatically detects all such conflicts based on the above knowledge of copies.

It is sometimes useful to consider conflicts as branches in the version history of a change block. If conflicts occur during the life of a change block, its version history is a simple chain - each change occurs after the previous one. In the event of a knowledge-based conflict, two changes occur in parallel, causing the chain to split and turn into a version tree.

(b) Conflict based conflicts

There are times when independent changes violate integrity constraints when used together. For example, such a conflict can occur when two copies create a file with the same name in the same directory.

A conflict based on a constraint involves two independent changes (like a conflict based on knowledge), but they do not belong to the same block of change. On the contrary, they relate to different blocks of change, but with the restriction that exists between them.

The synchronization service detects restrictions violations at the time the change is applied and automatically causes conflicts based on the restriction. To resolve conflicts based on a constraint, special code is usually required that modifies the changes so that they do not violate the constraint. The synchronization service does not provide a universal mechanism for this.

(2) Conflict Handling

When a conflict is detected, the synchronization service can perform one of three actions (at the choice of the initiator of synchronization in the synchronization profile): (1) reject the change by 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 copy. A negative acknowledgment is sent to the sender. This resolution policy is especially useful on headless copies (e.g. file servers), where recording conflicts is not feasible. On the contrary, such copies force others to deal with conflicts, rejecting them.

Sync initiators configure conflict resolution in their synchronization profiles. The synchronization service supports combining multiple conflict resolution algorithms in one profile in the following ways - firstly, by setting a list of conflict resolution algorithms to be tested in turn, until one of them leads to success; and, secondly, linking conflict resolution algorithms to conflict types, for example, directing conflicts based on knowledge between updates to one conflict resolution algorithm, and all other conflicts to a log.

(a) Automatic conflict resolution

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

- local priority: ignore incoming changes if they conflict with locally stored data;

- remote priority: ignore local data if they conflict with incoming changes;

- priority of the last record: choosing a local priority or remote priority for each change block based on the time stamp of the change (note that the synchronization service, in the general case, is not based on the clock values; this conflict resolution algorithm is the only exception to this rule);

- deterministic: the choice of priority in such a way as to ensure that it will be the same on all copies, but will not make sense in other cases - one option for the implementation of synchronization services uses lexicographic comparisons of partner IDs to implement this feature.

In addition, ISVs can implement and install their own conflict resolution algorithms. Specialized conflict resolution algorithms can accept configuration parameters; such parameters should be specified by the SCA in the Conflict Resolution section of the synchronization profile.

When the conflict resolution algorithm processes the conflict, it returns a list of operations that must be performed (instead of conflicting changes) back to the runtime. The synchronization service then applies these operations, appropriately adjusting the remote knowledge to include a solution to the conflict handler.

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

Considering conflicts as branches in the history of the article’s versions, conflict resolution can be considered as connections - the union of two branches with the formation of one point. In this way, conflict resolution translates version histories into DAGs.

(b) Conflict Records

The conflict registration algorithm is a very specific kind of conflict resolution algorithm. The synchronization service registers conflicts as articles of the ConflictRecord type. These entries are linked to conflicting articles (unless the articles themselves have been deleted). Each conflict record contains: an incoming change that caused the conflict; type of conflict: between updates, between updates and deletions, between deletions and updates, between inserts or based on a restriction; and the version of the incoming change and the knowledge of the copy that transmitted it. Registered conflicts are available for inspection and resolution as described below.

(c) Inspection and resolution of conflicts

The synchronization service provides an API for applications to check the conflict log and to offer conflict resolution in it. The API allows the application to list all conflicts or conflicts associated with this Article. It also allows such applications to resolve recorded conflicts in one of three ways: (1) remote priority — accepting the registered change and overwriting the conflicting local change; (2) local priority - ignoring conflicting parts of the registered change; and (3) proposing a new change - when the application offers to absorb what, in its opinion, resolves the conflict. After the application resolves conflicts, the synchronization service removes them from the log.

(d) Convergence of copies and distribution of conflict resolution

In complex synchronization scenarios, the same conflict can be detected on multiple copies. If this occurs, the following may occur: (1) the conflict may be resolved on one copy, and resolution may be directed to another copy; (2) the conflict is automatically resolved on both copies; or (3) a conflict is resolved on both copies manually (through the Conflict Inspection API).

To ensure convergence, the synchronization service transfers conflict resolution to other copies. When a conflict-resolving change arrives at a copy, the synchronization service automatically finds in the log any conflict records that were resolved by this update and excludes them. In this sense, conflict resolution on one copy is linked on all other copies.

If different copies choose different priorities to resolve the same conflict, then the synchronization service applies the principle of conflict resolution binding and automatically selects which of the two resolutions will take priority over the other. The priority solution is chosen in a deterministic way, which is guaranteed to always give the same results (one embodiment uses lexicographic comparisons of copy IDs).

If different copies offer different “new changes” for the same conflict, the synchronization service considers this new conflict as a special conflict and uses the conflict registration block to prevent it from spreading to other copies. This situation usually occurs when resolving conflicts manually.

2. Synchronization with data warehouses not related to the storage platform

According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for ISVs that allow synchronization adapters to be implemented that allow the storage platform to synchronize with well-known systems such as Microsoft Exchange, AD, Hotmail, etc. Synchronization adapters have advantages over many of the synchronization services provided by the synchronization service, as described below.

Despite the name, synchronization adapters do not provide for implementation in the form of modules that are embedded in some architecture of the storage platform. If desired, the “synchronization adapter” can be any application that uses the interfaces of the synchronization service runtime to receive services such as enumerating and applying changes.

To make it easier for others to configure and start synchronization of the database with this machine, synchronization adapter writers are allowed to open the standard interface of the synchronization adapter, which starts the synchronization specified by the synchronization profile described above. The profile provides the adapter with configuration information, part of which the adapters pass to the synchronization runtime to manage the services of the runtime (for example, the folder to be synchronized).

a) Sync services

The synchronization service provides adapter writers with a number of synchronization services. Until the end of this section, it is convenient to name the machine on which the storage platform performs synchronization as “the client”, and the database machine not connected to the storage platform with which the adapter speaks as “the server”.

(1) Listing Changes

Based on the change tracking data supported by the synchronization service, enumeration of changes allows synchronization adapters to easily list the changes that have occurred in the data warehouse folder since the last attempt to synchronize with this partner.

Changes are listed based on the concept of an anchor, an opaque structure that represents information about the latest synchronization. Anchor receives Knowledge from the storage platform, as described in the following sections. Synchronization adapters using change enumeration services fall into two broad categories: using “saved anchors” and using “issued anchors”.

The difference between them is where the information about the last synchronization is stored - on the client or on the server. Adapters often find it easier to store this information on the client - the database machine is often unable to conveniently store this information. On the other hand, if several clients are synchronized with the same database machine, saving this information on the client is inefficient and in some cases incorrect - the client is not aware of the changes that the other client has already pushed to the server. If the adapter wants to use the anchor stored on the server, then the adapter needs to submit it back to the storage platform during the transfer of changes.

In order for the storage platform to support the anchor (for local or remote storage), the storage platform must be notified of changes that have been successfully applied on the server. These and only these changes can be included in the anchor. When enumerating changes, synchronization adapters use an acknowledgment interface to report which changes have been successfully applied. At the end of synchronization, adapters using issued anchors must read the new anchor (which includes all successfully applied changes) and transfer it to their database machine.

Often adapters need to store adapter-specific data in conjunction with the articles 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 together with the returned changes. This, in most cases, eliminates the need for adapters to re-query the database.

(2) Application of changes

Applying changes allows synchronization adapters to apply the changes received from their database machine to the local storage platform. Adapters are expected to translate the changes into a storage platform schema.

The main function of applying changes is automatic conflict detection. As in the case of synchronization between storage platforms, a conflict is defined as overlapping changes made without knowledge of each other. When adapters use the application of changes, they must specify the anchor against which a conflict is detected. The application of changes causes a conflict when it detects an overlapping local change that is not covered by the knowledge of the adapter. By analogy with the enumeration of changes, adapters can use either saved or issued anchors. Applying changes supports efficient storage of adapter-specific metadata. Such data can be connected by the adapter to the applied changes and can be saved by the synchronization service. Data may be returned on the following listing of changes.

(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 passed to the specified conflict handler and resolved (if possible). Conflicts can also be recorded. 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 may still transmit the conflict to the synchronization runtime for resolution according to the policy. In addition, synchronization adapters may require that any conflicts detected by the synchronization service be sent back to them for processing. This is especially useful when the database engine is capable of storing or resolving conflicts.

b) adapter implementation

Although some “adapters” are simply applications that use runtime interfaces, adapters are allowed to implement standard adapter interfaces. These interfaces allow synchronization management applications to: require the adapter to synchronize according to a given synchronization profile; Canceled the ongoing synchronization; Received a progress report (percentage of readiness) of the synchronization in progress.

3. Security

The synchronization service seeks to contribute as little as possible to the security model implemented by the storage platform. Instead of setting new synchronization rights, existing rights are used. In particular:

- anyone who can read the data warehouse article can list the changes to this article;

- anyone who can write to a data warehouse article can apply changes to this article; and

- anyone who can expand a data warehouse article can associate synchronization metadata with this article.

The synchronization service does not support protected authorship information. When a change is made to copy A by user U and transferred to copy B, the fact that the change was originally made to A (or by user U) is lost. If B transfers this change to copy C, this is done on behalf of B, not A. This leads to the following restriction: if the copy is not trusted to make its own changes to the article, it cannot transfer the changes made by others.

When initiating the synchronization service, this makes the synchronization management application. The synchronization service replaces the SCA identification and performs all operations (both locally and remotely) on its behalf. For example, suppose that user U cannot instruct the local synchronization service to retrieve changes from the remote storage platform for articles to which user U does not have read access.

4. Manageability

Monitoring distributed community of copies is challenging. The synchronization service may use the “sweep” algorithm to collect and disseminate information about the status of copies. The properties of the sweeping algorithm ensure that information about all configured copies is ultimately collected and that bad (non-responding) copies are detected.

This community-wide monitoring information is made available to each copy. Monitoring tools can be run on a randomly selected copy to verify this monitoring information and make administrative decisions. Any configuration changes must be made directly to the copies to be changed.

H. Interoperability with traditional file systems

As noted above, the storage platform of the present invention, in at least some embodiments, provides for the implementation as an integral part of the system of the hardware-software interface of a computer system. For example, the storage platform of the present invention can be implemented as an integral part of an operating system, for example, belonging to the Microsoft Windows family of operating systems. In this regard, the storage platform API becomes part of the operating system API through which applications interact with the operating system. Thus, the storage platform becomes the means by which application programs store information on the operating system, so the data model based on the articles of the storage platform replaces the traditional file system of such an operating system. For example, being implemented in the Microsoft Windows family of operating systems, the storage platform can replace the NTFS file system implemented in this operating system. Currently, applications access the NTFS file system services through the Win32 APIs that are open by the Windows operating system family.

Understanding, however, that a complete replacement of the NTFS file system with the storage platform of the present invention would require transcoding of existing Win32-based applications and that such transcoding might not be desirable, it would be useful if the storage platform of the present invention provided some interoperability with existing file systems, e.g. NTFS. According to one embodiment of the present invention, the storage platform allows applications that rely on the Win32 programming model to access the contents of both the storage platform data store and the traditional NTFS file system. For this, the storage platform uses a naming convention, which is a superset of Win32 naming conventions, to facilitate interoperability. In addition, the storage platform supports access to files and directories stored in the volume of the storage platform through the Win32 API.

1. Interaction model

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

1. Folders in the data warehouse can contain both file and non-file articles, thereby representing a single namespace for file and schematized data. In addition, it also provides a universal security, sharing and administration model for all user data.

2. Since file and non-file articles are accessible using the storage platform API and this approach does not provide for the application of any special rules for files, it provides application developers with a clearer programming model for work.

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

Due to this model, according to this embodiment, it may not be possible to search for data sources that do not migrate to the storage platform data warehouse. These include removable media, remote servers, and files on the local drive. A synchronization adapter is provided that announces intermediary articles (abbreviated keyboard commands + advanced metadata) in the storage platform for articles located on third-party file systems. Mediation articles do not attempt to impersonate files either in terms of the hierarchy of the data source namespace or in terms of security.

Symmetry achieved in the namespace and programming model between file and non-file content provides applications with a better way to move content from file systems to more structured articles in the storage platform data warehouse over time. By providing a native type of “file” article in the storage platform data warehouse, applications can transfer file data to the storage platform, while still retaining the ability to manipulate this data through Win32. In the end, applications can go all the way to the storage platform API and structure their data in terms of storage platform articles rather than files.

2. Data Warehouse Features

To provide the desired level of interaction, according to one embodiment, the following features of the storage platform data warehouse are implemented.

a) Not that

The storage platform data warehouse does not open as a separate file system volume. The storage platform leverages NTFS-based file streams. Thus, the “on disk” format is not subject to change, which eliminates the need to open the storage platform as a new file system at the volume level.

Instead, a data warehouse (namespace) is built corresponding to the NTFS volume. The database and file streams that reserve this part of the namespace are located in the NTFS volume that the storage platform data warehouse is associated with. A data warehouse corresponding to the system volume is also provided.

b) Storage structure

The storage structure is best illustrated with an example. Consider, for example, a directory tree on a system volume of a machine called HomeMachine , as shown in FIG. According to the sign of the possibility of interacting with the file system according to the present invention corresponding to c: \ drive, there is a storage platform data store open by the Win32 API via a shared UNC, for example, “WinFSOnC”. This makes the corresponding data store accessible through the following UNC name: \\ HomeMachine \ WinFSOnC.

In this embodiment, files and / or folders must explicitly migrate from NTFS to the storage platform. Therefore, if the user wishes to move the My Documents folder to the storage platform data warehouse in order to take advantage of all the additional search / categorization features provided by the storage platform, the hierarchy will look as shown in FIG. It is important to note that these folders really move in this example. It should also be noted that the namespace moves to the storage platform, the actual streams are renamed as “file streams” with the corresponding pointers connected in the storage platform.

c) Not all files migrate

Files that match user data or that need to be searched / categorized by the storage platform are candidates for migration to the storage platform data warehouse. Preferably, to limit the compatibility of the application with the storage platform, the set of files that migrate to the storage platform of the present invention, in the context of the Microsft Windows operating system, is limited to the files in the MyDocuments, Internet Explorer (IE) Favorites, IE History and Desktop.ini files in the Documents and Settings directory. Preferably, the migration of Windows system files is not allowed.

d) Access from the NTFS namespace to storage platform files

According to an embodiment described herein, it is desirable that files migrating to the storage platform are not accessible through the NTFS namespace even if the actual file streams are stored in NTFS. This avoids the complex blocking and security issues that arise from a multi-headed implementation.

e) The expected namespace / drive letters

Access to files and folders in the storage platform is provided through the UNC name in the form \\ <machine name> \ <shared name Winfs>. For an application class that requires drive letters to operate, the drive letter can be mapped to this UNC name.

I. STORAGE PLATFORM API

As noted above, the storage platform contains an API that allows applications to access the features and capabilities of the storage platform discussed above and access articles stored in the data warehouse. This section describes one embodiment of a storage platform API for a storage platform of the present invention.

FIG. 19 shows a basic architecture of a storage platform API according to this embodiment. The storage platform API uses the SQLClient 1900 to talk to the local data store 302, and can also use the SQLClient 1900 to talk to the remote data store (e.g., data store 340). Local storage 302 can also talk to remote data storage 340 using either DQP (Distributed Request Processor) or through the Sync service of the storage platform described above. Storage platform API 322 also acts as a bridge API for data warehouse notifications by passing application subscriptions to notification engine 332 and routing notifications to the application (e.g., application 350a, 350b or 350c), which is also described above. In one embodiment, storage platform API 322 may also define a limited provider architecture so that it can access data in Microsoft Exchange and AD.

1. Overview

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

Inquiry

According to one embodiment, the storage platform data warehouse is implemented on a relational database engine 314; as a result, the full expressive power of SQL is inherent in the storage platform. High-level query objects provide a simplified model for querying storage, but may not encapsulate the full expressive power of storage.

Navigation

The storage platform data model builds a rich, extensible type system on the abstractions of the underlying database. For the developer, storage platform data is a network of articles. The storage platform API provides navigation from article to article through filtering, relationships, folders, etc. This is a higher level of abstraction than basic SQL queries; at the same time, it allows rich filtering and navigation capabilities for use with familiar CLR coding patterns.

Actions

Storage platform API opens common actions on all articles - Create, Delete, Update; they open as methods on objects. In addition, domain-specific actions like SendMail, CheckFreeBusy, etc. also available as methods. The API structure uses strictly defined patterns that ISVs can use to add value by setting additional actions.

Developments

The data in the storage platform is dynamic. To enable applications to respond to data changes in the repository, the API provides rich opportunities for event generation, subscription and notifications.

2. Naming and scopes

It is useful to distinguish between namespace and naming. The term "namespace", in common use, means the set of all names available on some system. A system can be an XML schema, a program, a network, 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 because it is desirable to uniquely refer to a given element in the namespace. Thus, the term “namespace” is used to mean the set of all names available in all instances of the storage platform in the universe. Articles are called entities in the storage platform namespace. The UNC naming convention is used to ensure that article names are unique. Each article in each repository storage platform repository in the universe is addressed by UNC.

The highest level of organization in the storage platform namespace is the “service” - which is simply an instance of the storage platform. The next level of organization is the “volume”. Tom is the largest standalone article container. Each storage platform instance contains one or more volumes. There are “articles” in the volume. Articles are 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. At a lower level, all such data organization schemes represent the idea of dividing the universal set of our data into named groups. As discussed above, this concept is modeled in the storage platform through the concept of a “folder”. A folder is a special type of folder; There are 2 types of folders: Power Folders and Virtual Folders.

18, an inclusion folder is an article that contains support relationships for other articles and is equivalent to the general concept of a file system folder. Each article is “contained” in at least one inclusion folder.

A virtual folder is a more dynamic way to organize a collection of articles; it’s just the name given to many articles - the set is either listed explicitly or specified by query. A virtual folder itself is an article and can be considered as representing many relationships (not support) to many articles.

Sometimes there is a need to model the idea of closer inclusion; for example, a Word document embedded in an email message, in this sense, is more closely related to its container than, for example, a file contained in a folder. This idea is expressed by the concept of embedded articles. An embedded article has a special kind of relationship that refers to another article; A reference article can be anchored or otherwise manipulated only in the context of the containing article.

Finally, the storage platform provides the concept of categories as a way to classify articles and items. One or more categories may be associated with each article or item in the storage platform. A category, in essence, is simply the name assigned to the article / category. This name can be used in searches. The data model of the storage platform allows you to specify a hierarchy of categories, and thus provide a tree-like classification of data.

The unique name of the article is a triple: (<service name>, <volume ID>, <article ID>). Some articles (in particular folders and virtual folders) are collections of other articles. This makes it possible to identify articles in an alternative way: (<service name>, <volume ID>, <path to article>).

Storage platform names include a service context designation: a service context is a name that maps to a pair (<volume name>, <path>). It identifies an article or many articles - for example, a folder, virtual folder, etc. Thanks to the concept of service contexts, the UNC name for any entry in the storage platform namespace becomes:

\\ <service name> \ <service context> \ <article path>.

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

An ItemContext defines the scope of a query (for example, a Find operation) by restricting the results returned by these articles that exist on the specified path.

3. Storage Platform API Components

20 schematically illustrates various components of a storage platform API according to this embodiment of the invention. The storage platform API consists of the following components: (1) data classes 2002, which represent the types of elements and articles of the storage platform, (2) the structure of the 2004 runtime environment, which regulates the survivability of an 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, in a development environment, a schema author submits a schema document 2010 and code for domain methods 2012 to a toolbox 2008 of a storage platform API development environment. These tools generate client-side data classes 2002 and save the 2014 schema and save the 2016 class definitions for this schema. A “domain” is a specific scheme; for example, we are talking about domain methods, but not about classes in the Contact Scheme, etc. These 2002 data classes are used by the application developer in the runtime in conjunction with the 2006 storage platform API runtime structure classes to manipulate the storage platform data.

In order to illustrate various aspects of the storage platform API of the present invention, examples based on an illustrative Contact Diagram are provided. A graphical representation of this illustrative diagram is shown in FIGS. 21A and 21B.

4. Data classes

According to an aspect of the present invention, each type of article, article and item extension, and also each relation in the storage platform data warehouse has a corresponding class in the storage platform API. Roughly speaking, type fields are mapped to class fields. Each article, article extension, and item in the storage platform is available (o) as an object of the corresponding class in the storage platform API. The developer can make a request to create, modify or delete these objects.

The storage platform contains an initial set of circuits. Each schema defines many types of article and element and many relationships. The following is one embodiment of an algorithm for generating data classes from these schematic entities:

For circuit S:

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

- Overloaded constructors, including constructors that allow you to specify the initial folder and the name of the new article.

- The property of 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 for finding multiple articles matching a filter (for example, a method called "FindAll").

- Overloaded static method to find a single article matching the filter (for example, a method called "FindOne").

- A static method for finding an article by its identifier (for example, a method called "FindByID").

- A static method for finding an article by its name relative to ItemContext (for example, a method called "FindByName").

- A method for saving article changes (for example, a method called "Update").

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

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

- The property of each field in E. If the field is multi-valued, the property will be a collection of the corresponding element type.

For each element E in S, a class called System.Storage.S.Ecollection is generated. This class follows the general guidelines of the structure. NET for a strongly typed collection of classes. For relationship-based item types, this class will also include the following members:

- An overloaded method for finding multiple article objects that correspond to a filter that implicitly includes an article in which the collection plays the role of a source. Overloads include some that can be filtered based on the subtype of the article (for example, a method called "FindAllTargetItems").

- An overloaded method for finding objects of the type of a nested element that correspond to a filter, which implicitly includes an article in which the collection plays the role of a source (for example, a method called "FindAllRelationships").

- An overloaded method for finding objects of the type of a nested element that correspond to a filter, which implicitly includes an article in which the collection acts as a source (for example, a method called "FindAllRelationshipsForTarget").

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

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

For the R relation, a class called System.Storage.S.R is generated in S. This class has one or two subclasses, depending on if the roles of one or more relationships indicate the endpoint field.

Classes are also generated this way for each Article Extension that was created.

Data classes exist in the System.Storage namespace. <Schema name>, where <schema name> is the name of the corresponding schema, for example, Contacts, Files, etc. For example, all classes that correspond to the Contact Schema are in the System.Storage.Contacts namespace.

For example, according to FIGS. 21A and 21B, the contact diagram gives the following classes contained in the System.Storage.Contact namespace:

- Articles: 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 the following example, the detailed structure of the Person type specified in the Contact Scheme is shown below in XML:

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

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

<Field Name = "Birthdate" Type = "the storage

platformTypes.datetime "Nullable =" true "

TypeMajorVersion = "1" />

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

Nullable = "true" MultiValued = "false"

TypeMajorVersion = "1" />

<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 spawns 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

Expiration Date {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 specified in the Contact Scheme is shown below as XML:

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

MajorVersion = "1" MinorVersion = "0"

ExtendsVersion = "1" />

<Field Name = "CountryCode" Type = "the storage

platformTypes.nvarchar (50) "Nullable =" true "

MultiValued = "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 spawns the following class (only public members are shown):

partial public class TelephoneNumber:

System.Storage.Core.EAddress,

System.Windows.Data.IDataUnit

{

public System.Data.SglTypes.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 hierarchy of classes derived from this schema directly reflects the type hierarchy in this schema. For example, consider the article types defined in the Contact Scheme (see FIGS. 21A and 21B). The class hierarchy corresponding to this in the storage platform API will look like this:

Object

DataClass

Elementbase

Rootoottase

Item

Principal

Group

Household

Organization

Person

User

Service

Presence service

ContactService

ADService

Rootootbase

... (element classes)

Another scheme, a scheme that allows you to represent all the audio / video environments in the system (cut into audio files, audio CDs, DVDs, home videos, etc.), allows users / applications to save, organize, search and to manipulate different types of audio / video environments. The basic layout of a multimedia document is general enough to represent any medium, and extensions to this basic layout are designed to handle domain-related properties separately for audio and video environments. It seems that this and many, many other schemes operate directly or indirectly under the Kernel Scheme.

5. The structure of the runtime environment

The main programming model of the storage platform API is object survivability. Application programs (or “applications”) search the store and return objects that represent the data in the store. Applications modify returned objects or create new objects, as a result of which these changes are propagated to the repository. This process is controlled by the ItemContext. Search engines are performed using the ItemSearcher object, and search results are made available through the FindResult object.

a) Runtime structure classes

According to another aspect of the invention, the storage platform API the runtime framework implements a number of classes to support the operation of data classes. These structure classes define a common set of behaviors for data classes and, together with data classes, provide a basic programming model for the storage platform APIs. The classes in the runtime structure belong to the System.Storage namespace. According to this embodiment, the structure classes comprise the following main classes: ItemContext, ItemSearcher, and FindResult. Other elementary classes, enumeration values, and delegates may also be provided.

(1) ItemContext

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

As an object survivability machine, ItemContext provides the following services:

1. Conversion from a sequential view of data read from storage to objects.

2. Maintaining the identification of the object (the same object is used to represent this article regardless of how many times this article is included in the query result).

3. Tracking the status of objects.

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

1. Generates and performs updates of the storage platform necessary to extend the life of the changes.

2. Creates connections to multiple data storages, if necessary, to ensure smooth navigation of link relationships and allow changes and preservation of objects extracted from multi-domain search.

3. Ensures that the articles reserved in the file are properly updated while saving changes to the object (s) representing this article.

4. Manages transactions across multiple connections of the storage platform and, when updating data stored in articles reserved in a file, and properties of file streams, over the file system subjected to the transaction.

5. Carries out operations of creating, copying, moving and deleting articles that take into account the semantics of relations of the storage platform, articles reserved in the file, and typed flow properties.

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

(2) ItemSearcher

The ItemSearcher class supports simple searches that return entire article objects, article object streams, or value streams projected from an article. ItemSearcher encapsulates kernel functionality that is common to: concepts of the target type and parameterized filters that apply to this target type. ItemSearcher also allows you to precompile or prepare search engines in optimization order when the same search is performed for multiple types. Appendix B presents the source code for the ItemSearcher class and several closely related classes according to one embodiment.

(a) Target type

The target search type is specified when constructing the ItemSearcher. The target type is the CLR type that maps to the requested extension by the data warehouse. In particular, it is a CLR type that maps to article types, article relationships and extensions, and schematized views.

When retrieving a search engine using the ItemContext.GetSearcher method, the target type of the search engine is specified as a parameter. When you call the GetSearcher method on the type of the article, relationship or extension of the article (for example, Person.GetSearcher), the target type is the type of the article, relationship, or extension of the article.

The search expressions provided in ItemSearcher (for example, a search filter and options for finding through or defining a projection) always refer to the target type of search. These expressions can specify properties of the target type (including properties of nested elements) and can specify connections with the relation and extensions of the article, as described elsewhere.

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

(b) Filters

ItemSearcher contains a property for defining filters (for example, a property called "Filters" as a collection of SearchExpression objects) that sets the filter used in the search. All filters in the collection are combined using the logical AND operator when performing a search. The filter may contain links to parameters. Parameter values are specified using the Parameters property.

(c) Preparing searches

In situations where the same search is subject to repeated execution, possibly only with a change in parameters, some improvement in performance can be achieved by preliminary compilation or preparation of the search. This is accomplished using a variety of preparation methods on ItemSearcher (for example, a method for preparing Find that returns one or more articles, 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) Find options

There are a number of options that can be applied to a simple search. They can be set, for example, in the 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 option determines whether large binary property values are loaded when the search results are retrieved or whether the load is delayed until a link to them is received. The MaxResults option determines the maximum number of returned results. This is equivalent to specifying TOP in the SQL query. It is most often used in conjunction with sorting.

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

1) scalar property in the target search type;

2) a scalar property in a nested element, achievable from the target search type by traversing unique properties; or

3) the result of the aggregation function with a suitable argument (for example, Max applied to a scalar property in a nested element that is achievable from the target search type by traversing a multi-valued property or relation).

Let, for example, the target search type be System.Storage.Contact.Person:

1. "Birthdate" - suitable, the date of birth is a scalar property of type Person.

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

3. "Count (PersonalNames)" - suitable, the counter for PersonalNames.

4. "Case (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate" - unsuitable, uses a relation and multi-valued properties without an aggregation function.

5. "Max (Cast (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate)" - a suitable, most recent start date for the home email address.

(3) Stream of article results ("FindResult")

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

There are two different methods for retrieving results from a FindResult object: using a reader template specified by IObjectReader (and IAsyncObjectReader) and using an enumerator template specified by IEnumerable and IEnumerator. An enumerator pattern is standard in the 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 because in many cases it allows more efficient processing of the result due to the exclusion of data copying. 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 ();

IAysncResult asyncResult = result.BeginRead (new

AsyncCallback (MyCallback));

void MyCallback (IAsyncResult asyncResult)

{

if (result.EndRead (asyncResult))

{

Person person = (Person) resuIt.Current;

...

}

}

According to this embodiment, FindResult should be closed when it is no longer needed. This can be done by calling the Close method or using language constructs, such as the C # use statement. 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) Runtime structure during work

On Fig shows the structure of the runtime in the process. The runtime structure acts as follows:

1. Application 350a, 350b, or 350c links to an article in a storage platform.

2. Structure 2004 creates an ItemContext 2202 object corresponding to the associated article and returns it to the application.

3. The application passes Find in this ItemContext to obtain a collection of articles; the returned collection is in principle an object graph 2204 (due to a relationship).

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 various examples of how you can use storage platform API structure classes to manipulate articles 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 ItemContext.Open method and providing a path or paths that identify the article domains that will be associated with the ItemContext. Article domains consider search engines using ItemContext, so only one domain article and the articles contained in this article will be searched. Consider the following examples:

Open ItemContext using 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 using article of used storage platform resource

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

Open ItemContext with Multiple Article Domains

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

@ ”\\ jane1 \ My Documents",

@ "\\ jane2 \ My Documents");

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

Explicitly close ItemContext

ItemContext ic = ItemContext.Open ();

...

ic.Close ();

Close using statement with ItemContext

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 allows application developers to query based on various properties of articles in a data warehouse, while the application developer is isolated from the details of the query language of the underlying database machine.

Applications can search the domains specified when opening the ItemContext using the ItemSearcher returned by the ItemContext.GetSearcher method. Access to the search results is carried out using the FindResult object. Assume the following declarations for the examples below:

ItemContext ic = ...;

ItemSearcher searcher = null;

FindResult result = null;

Item item = null;

Relationship relationship = null;

ItemExtension itemExtension = null;

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

Search for all articles of this type

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

result = searcher.FindAll ();

foreach (Person p in result) ...;

Search for articles 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 articles with relationships of this type and satisfying 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 article 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 articles with extensions 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

When performing a search, you can set various options, 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 call 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 one result, especially when setting soft criteria. In addition, it is expected that some searches return only one object, and it is not expected that they will not return a single object.

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 one 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 calls on ItemContext

There are also a number of shortcuts to ItemContext that make search as easy as possible.

Search using the ItemContext.FindAll shortcut

result = ic.FindAll (typeof (Person),

"PersonalNames.Surname = 'Smith'");

foreach (Person p in result) ...;

Search Using the ItemContext.FindOne Shortcut

Person p = ic.FindOne (typeof (Person),

"PersonalNames.Surname = 'Smith'") as Person;

(d) Finding by ID or path

In addition, articles, relationships, and article extensions can be retrieved by providing their identifiers. Articles can also be retrieved using the path.

Retrieving articles, relationships, and article extensions by their identifiers

item = ic.FindItemById (iid);

relationship = ic.FindRelationshipById (iid, rid);

itemExtension = ic.FindItemExtensionById (iid, eid);

Getting articles along the way

// Only one domain

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

// One or more domains

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

foreach (Item I in result) ...;

(f) GetSearcher Template

There are many places in the storage platform API where it is desirable to provide a helper method that searches in the context of another object or with specific parameters. The GetSearcher template provides these scenarios. There are many GetSearcher methods in the API . Each of them returns an ItemSearcher , preconfigured, to perform this search. For example:

searcher = itemContext.GetSearcher ();

searcher = Person.GetSearcher ();

searcher =

EmployeeEmployer.GetSearcherGivenEmployer (organization);

searcher = person.GetSearcherForReports ();

Before performing a search, you can set additional filters:

searcher = person.GetSearcherForReports ();

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

You can choose the type of presentation of the result:

FindResult findResult = searcher.FindAll ();

Person person = searcher.FindOne ();

(3) Storage update

After extracting the object by searching, the application, if necessary, can change it. You can also create new objects and associate them with existing objects. After the application makes all the changes that make up the logical group, the application calls ItemContext.Update to save these changes to the repository. According to another aspect of the storage platform API of the present invention, the API collects the article changes made by the application program, and then organizes them into the correct updates required by the database machine (or storage machine of any kind) on which the data warehouse is implemented. This allows application developers to make changes to the article in memory, leaving the API complex aspects of updating the data warehouse.

Saving changes in one article

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

p.DisplayName = "foo";

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

ic.Update ();

Saving changes to multiple articles

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 a new article

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 a short call ...

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

Person p = new Person ();

p.DisplayName = “foo”;

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

ic.Update ();

Deleting relationships (and possibly the target article)

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 a short call ...

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

f.MemberRelationships.Remove (pid);

ic.Update ();

Adding an article extension

Item item = ic.FindItemById (iid);

MyExtension me = new MyExtension ();

me.Foo = "bar";

item.Extensions.Add (me);

ic.Update ();

Removing Article 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 a short call ...

Item i = ic.FindltemById (iid);

i.Extensions.Remove (typeof (MyExtension));

ic.Update ();

6. Security

According to the previous section II.E (Security), according to this embodiment of the storage platform API, there are five methods available in the context of the article to retrieve and modify the security policy associated with the article in the repository. We list them:

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 article. This ACL is independent of existing article paths and will be in-game independent of the support relationship for which this article is the target. This allows administrators, if desired, to make security independent of existing article paths.

GetPathSecunty and SetPathSecurity provide a mechanism for retrieving and modifying the ACL existing on an article due to a support relationship from another folder. This ACL consists of ACLs of various article ancestors together with the path in question together with an explicit ACL, if any are provided for this path. The difference between this ACL and the ACL in the previous case is that this ACL remains in the game only as long as the support relationship exists, while the explicit ACL of the article does not depend on any support relationship for the article.

ACLs that can be set on an article using SetItemSecurity and SetPathSecurity are limited to inherited and object-specific ACEs. They cannot contain any ACEs marked as inherited.

GetEffectiveItemSecurity retrieves the various path-based ACLs as well as the explicit ACLs on the article. This reflects the authorization policy in essence in this article.

7. Relationship support

According to the above, the storage platform data model defines “relationships” that allow articles to be linked together. When generating data classes for a schema, the following classes are formed for each relationship type:

1. A class that represents a relationship in itself. This class derives from the Relationship Class and contains members that depend on the type of relationship.

2. A strongly typed “virtual” collection class. This class is retrieved from VirtualRelationshipCollection and allows you to create and delete instances of the relationship.

This section describes relationship support in the storage platform API.

a) Basic types of relationships

The storage platform API provides a number of types in the System.Storage namespace that form the basis of the relationship API. Here they are:

1. Relationship - the basic type of all relationship classes

2. VirtualRelationshipCollection - the base type for all relationship collections

3. ItemReference, ItemIdReference, ItemPathReference - represent types of article links; the relationship between these types is shown in Fig.11.

(1) Relationship class

The following is the base class for relationship classes.

public abstract class Relationship: StoreObject

{

// Create using default values.

protected Relationship (ItemIDReference

targetItemReference);

// Tells the relation that it has been added to the collection

// relationships. The object will poll the collection to

// define the source article, article context, etc.

internal AddedToCollection (VirtualRelationshipCollection

collection);

// relationship id.

public Relationshipld RelationshipId {get;}

// ID of the source article.

public Itemld SourceItemId {get;}

// Get the original article.

public Item SourceItem {get;}

// Link to the target article.

public ItemIdReference TargetItemReference {get;}

// Get the target article

// (calls TargetItemReference.GetItem ()).

public Item TargetItem {get;}

// Determines if ItemContext already has a connection to

// domain of the target article (calls

//TargetItemReference.IsDomainConnected).

public bool IsTargetDomainConnected {get;}

// Name of the target article in the namespace. Name must

// be unique across all support relationships

// source article.

public OptionalValue <string> Name {get; set;}

// Determines if it is a support relationship

// or links.

public OptionalValue <boolean> IsOwned {get; set;}

}

(2) ItemReference Class

The following is the base class for article link types.

public abstract class ItemReference: NestedElement

{

// Create using default values.

protected ItemReference ();

// Returns a reference article.

public virtual Item GetItem ();

// Determine if a connection is made to the domain

// reference article.

public virtual bool IsDomainConnected ();

}

ItemReference objects can identify articles that exist in a repository other than where the link to the article is located. Each derived type indicates how the link to the remote store is built and used. The GetItem and IsDomainConnected implementations in the derived classes use multi-domain article context support to load articles from the desired domain and to determine if a connection to the domain has been established.

(3) Class ItemIdReference

The following is the ItemIdRefrence class, a link to an article that uses the article ID to identify the target article.

public class ItemIdReference: ItemReference

{

// Build A New ItemIdReference Using

// default values.

public ItemIdReference ();

// Build a new ItemIdReference for the specified article.

// The domain associated with the article is used as a pointer.

public ItemIdReference (Item item);

// Build a new ItemIdReference with a null pointer and

// and the ID of this target article.

public ItemIdReference (ItemId itemid);

// Build a new ItemIdReference with the given values

// pointer and article id.

public ItemIdReference (string locator, ItemId itemid);

// ID of the target article.

public ItemId ItemId {get; set;)

// Path specifying a WinFS article that contains

// target article in your domain. If empty, then

// the domain containing the article is unknown.

public OptionalValue <string> Locator {get; set;}

// Determine if a connection is made to the domain

// reference article.

public override bool IsDomainConnected ();

// Retrieves the reference article.

public override Item GetItem ();

}

GetItem and IsDomainConnected use multi-domain article context support to download articles from the desired domain and to determine if a connection to the domain has been established. This feature has not yet been implemented.

(4) Class ItemPathReference

The ItemPathReference class is a link to an article that uses the path to identify the target article. Below is the code for this class:

public class ItemPathReference: ItemReference

{

// Build a link to the article along the way using the values

// default.

public ItemPathReference ();

// Build a link to the article along the path without the help of a pointer

// and this path.

public ItemPathReference (string path);

// Build a link to the article along the way using data

// pointer and path.

public ItemPathReference (string locator, string path);

// Path specifying a WinFS article that contains

// target article in your domain.

public OptionalValue <string> Locator {get; set;}

// Path to the target article relative to the domain of the article

// specified by the pointer.

public string Path {get; set;}

// Determine if a connection is made to the domain

// reference article.

public override bool IsDomainConnected ();

// Retrieves the reference article.

public override Item GetItem ();

}

GetItem and IsDomainConnected use multi-domain article context support to download articles from the desired domain and to determine if a connection to the domain has been established.

(5) RelationshipId Structure

The RelationshipId structure encapsulates the GUID of the relationship ID.

public class RelationshipId

{

// Generates a new GUID for the relationship ID.

public static RelationshipId NewRelationshipId ();

// Initialize the relationship ID with the new GUID.

public RelationshipId ();

// Initialize with the specified GUID.

public RelationshipId (Guid id);

// Initialize with the string representation of the GUID.

public RelationshipId (string id);

// Returns a string representation of the GUID of the relationship 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

// instance of System.Guid

public static implicit operator Guid (RelationshipId

relationshipId);

}

This value type encapsulates the GUID so that parameters and properties can be strongly typed as relationship IDs. OptionalValue <RelationshipId> should be used when the relationship ID is nullified. A value of Empty, such as that provided by System.Guid.Empty, does not open. RelationshipId cannot be built using an empty value. When using the default constructor to create the RelationshipId, a new GUID is created.

(6) VirtualRelationshipCollection class

The VirtualRelationshipCollection class implements a collection of relationship objects, which includes objects from the data store, plus new objects added to the collection, but does not include objects deleted from the store. Objects of the specified relationship type with the given ID of the source article are included in the collection.

This is the source article for a relationship collection class that is generated for each type of relationship. This class can be used as a property type in the type of the source article to provide access and ease of manipulation of the relationships of this article.

Enumerating the contents of a VirtualRelationshipCollection requires loading potentially large numbers of relationship objects from the repository. Applications should use the Count property to determine how many relationships can be loaded before they list the contents of the collection. Adding and removing objects to / from the collection does not require loading relationships from the repository.

For efficiency, it is preferable that these applications look for relationships that meet specific criteria, rather than listing all the relationship of the article using the VirtualRelationshipCollection object. Adding relationship objects to the collection creates the presented relationships in the store when ItemContext.Update is called. Removing relationship objects from the collection removes the presented relationship from the store when ItemContext.Update is called. A virtual collection contains the correct set of objects, regardless of whether a relationship object is added / deleted through the Item.Relationships collection or any other relationship collection in this article.

The VirtualRelationshipCollection class is defined by the following code:

public abstract class VirtualRelationshipCollection:

Icollection

{

// The collection will contain relationships of the specified type,

// owned by the article specified by itemId.

protected VirtualRelationshipCollection (ItemContext

itemContext,

ItemId itemId,

Type relationshipType);

// The enumerator will return all objects retrieved

// from the storage minus the object that

// with Deleted state besides objects that have

// state Inserted.

public IEnumerator GetEnumerator ();

// Returns the count of the number of relationship objects,

// to be returned by the enumerator. This counter

// computed without having to retrieve everything

// 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 objects in the repository.

public void Refresh ();

// Adds the specified relation to the collection. An object

// must have the state Constructed or Removed.

// If the state is Constructed, it changes to Added.

// If the state is Removed, it changes to Retrieved or

// changes as needed. ID of the original relationship article

// must match the ID of the source article,

// provided when building the collection.

protected void Add (Relationship relationship);

// Removes the specified relation from the collection. condition

// object must be Added, Retrieved or Modified. If

// the state of the object is Added, it needs to be changed to

// Constructed. If the state of the object is Retrieved or

// Modified, it needs to be changed to Removed.

// The ID of the source relationship article must match the ID

// original article provided

// when building the collection.

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 are retrieved from storage.

// This collection will be empty until listing

// VirtualRelationshipCollection or call Refresh

// (if the value of this property is not

// causes the collection to fill).

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 relationship types

When generating classes for a storage platform schema, a class is generated for each relationship declaration. In addition to the class that represents the relationship itself, a relationship collection class is also generated for each relationship. These classes are used as the type of properties in the classes of the source and target relationship articles.

This section describes the classes that are generated using a number of “prototype” classes. Thus, when a relationship declaration is specified, the class that is generated is described. It is important to note that the names of classes, types, and endpoints in prototype classes are placeholders for the names specified in the schema for the relationship; they should not be taken literally.

(1) Generated Relationship 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>

For this definition of relationship, the classes RelationshipPrototype and RelationshipPrototypeCollection will be generated. The RelationshipPrototype class represents the relationship itself. The RelationshipPrototypeCollection class provides access to RelationshipPrototype instances for which the specified article is the origin endpoint.

(2) RelationshipPrototype class

This is a prototypical relationship class for a support relationship called "HoldingRelationshipPrototype" , where the source endpoint is named "Head" and sets the type of article to "Foo", and the target endpoint is called "Tail" (tail) of and sets the type of article "Bar" . This is set as follows:

public class RelationshipPrototype: Relationship

{

public RelationshipPrototype (Bar tailItem);

public RelationshipPrototype (Bar tailItem, string name);

public RelationshipPrototype (Bar tailItem, string name,

bool IsOwned);

public RelationshipPrototype (Bar tailItem, bool IsOwned);

public RelationshipPrototype (ItemidReference

tailItemReference);

// Get the head article (calls base.SourceItem).

ublic Foo HeadItem {get;}

// Get the tail article (calls base.TargetItem).

public Bar TailItem {get;}

// Represents additional properties declared

// in the schema for the relationship. They are generated simply as

// properties in the article or type of the nested element.

public string SomeProperty {get; set;}

public static ItemSearcher GetSearcher (ItemContext

itemContext);

public static ItemSearcher GetSearcher (Foo headItem);

public static FindResult FindAll (string filter);

public static RelationshipPrototype FindOne (string filter);

public static RelationshipPrototype FindOnly (string

filter);

}

(3) RelationshipPrototypeCollection Class

This is a prototype class generated with the RelationshipPrototype class, which maintains a collection of RelationshipPrototype instance instances owned by the specified article. It is defined as follows:

public class RelationshipPrototypeCollection:

VirtualRelationshipCollection

{

public RelationshipPrototypeCollection (ItemContext

itemContext, ItemId headItemId);

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 (Itemld barItemId);

public void Remove (Relationshipld relationship relationshipId);

public void Remove (string name);

}

c) Relationship support in the class Item

The Item class contains the Relationships property, which provides access to the relationships in which the article is the source of the relationship. The Relationships property is of type RelationshipCollection.

(1) Item class

The following code shows the relationship context properties for the Item class:

public abstract class Item: StoreObject

{

...

// A collection of relationships in which this article is

// source.

public RelationshipCollection Relationships {get;}

...

}

(2) RelationshipCollection class

This class provides access to instances of relationships in which this article is the source of the relationship. It is defined as follows:

public class RelationshipCollection:

VirtualRelationshipCollection

{

public RelationshipCollection (ItemContext itemContext,

ItemId headItemId);

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 (Itemld barItemId);

public void Remove (RelationshipId relationshipId);

public void Remove (string name);

}

d) Relationship support in search expressions

You can specify the relationship between relationships and articles related to relationships in a search expression.

(1) Transition from articles to relationships

When the current context of the search expression is a set of articles, the relationship between the articles and the relationship instances in which the article is the source can be made using the Item.Relationships property. Relationships with relationships of a particular type can be specified using the Cast operator of a search expression.

You can also use strongly typed relationship collections in the search expression (for example, Folder.MemberRelationships). Casting to a relationship type can be implicit.

After defining many relations, the properties of this relation are available for use in predicates or as a projection target. When used to set a projection target, many relationships will be returned. For example, the following statement will find all persons related to the organization where the StartDate property of the relationship had 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 had an EmployerContext property of the EmployeeSideEmployerEmployeeRelationships type (generated for the EmployeeEmployer relationship type), this can be written as:

FindResult result = Person.FindAll (context,

"EmployerRelationships.StartDate> '1/1/2000'”);

(2) Transition from relationship to articles

When the current context of the search expression is a set of relationships, the relationship from the relationship to any endpoint of the relationship can be passed by specifying the name of the endpoint. After defining many articles related by a relation, the properties of these articles are available for use in predicates or as a projection target. When used for projection purposes, many articles will be returned. For example, the following statement will be found for all EmployeeOfOrganization relationships (regardless of organization), where the employee's last name is "Smith":

FindResult result = EmployeeOfOrganization.FindAll (context,

"Employee.PersonalNames [SurName = 'Smith']");

You can use the Cast operator of a search expression to filter the type of endpoint article. For example, to find all instances of the MemberOfFolder relationship, where the member is a Person article with the last name "Smith":

FindResult result = MemberOfFolder.FindAll (context,

"Member.Cast (Contact.Person) .PersonalNames [Surname = 'Smith']");

(3) Combination of circumvention

The two previous patterns, the transition from articles to relationships and from relationships to articles, can be combined to achieve arbitrary complex transitions. For example, to find all organizations with an employee named "Smith":

FindResult result = Organization.FindAll (context,

"EmployeeRelationships." +

"Employee." +

"PersonalNames [SurName = 'Smith']");

In the following example, all Person articles representing people living in a house located in the New York area will be found (TODO: this is no longer supported ... which is an alternative).

FindResult result = Person.FindAll (context,

"Relationships.Cast (Contact.MemberOfHousehold)." +

"Household." +

"Relationships.Cast (Contact.LocationOfHousehold)." +

"MetropolitonRegion = 'New York'”);

e) Examples of using relationship support

The following are examples of how you can use relationship support in a storage platform API to manipulate relationships. For the examples below, suppose the following declarations:

ItemContext ic = ...;

ItemId fid = ...; // folder article id

Folder folder = Folder.FindById (ic, fid);

ItemId sid = ...; // ID of the source article.

Item source = Item.FindById (ic, sid);

ItemId tid = ...; // ID of the target article.

Item target = Item.FindById (ic, tid);

ItemSearcher searcher = null;

(1) Relationship search

You can search for relationships by source or goal. You can use filters to select relationships of the specified type and those to whom property values are given. Filters can also be used to select relationships based on the associated article type or property values. For example, you can perform the following searches:

All relationships where this article is the source

searcher = Relationship. GetSearcher (folder);

foreach (Relationship relationship in searcher.FindAll ()) ...;

All relationships where this article is the source whose name matches "A%"

searcher = Relationship.GetSearcher (folder);

searcher.Filters.Add ("Name like 'A%'");

foreach (Relationship reiationship in searcher.FindAll ()) ...;

All FolderMember relationships where this article is the source

searcher = FolderMember.GetSearcher (folder);

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

All FolderMember relationships, where this article is the source and has a name like 'A%'

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("Name like 'A%'");

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

All FolderMember relationships where the target article is Person

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("MemberItem.Cast (Person)");

foreach (FolderMember folderMember in searcher.FindAll ()) ...;

All FolderMember relationships where the target article is Person with 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 API shown above, each relationship class supports the static FindAll, FindOne, and FindOnly APIs. In addition, the relationship type can be set by calling ItemContext.GetSearcher, ItemContext.FindAll, ItemContext.FindOne or ItemContext.FindOnly.

(2) Navigation from relationship to source and target articles

After retrieving the relationship object through a search, you can “navigate” to the target or source article. The base relationship class provides the SourceItem and TargetItem properties that return an Item. The generated relationship class provides equivalent strongly typed and named properties (for example, FolderMember.FolderItem and FolderMember.MemberItem). For example:

Navigate to source and destination article for relationship named "Foo"

searcher = Relationship.GetSearcher ();

searcher.Filters.Add ("Name = 'Foo'");

foreach (Relationship relationship in searcher.FindAll ())

{

Item source = relationship.SourceItem;

Item target = relationship.TargetItem;

}

Target article navigation

searcher = FolderMember.GetSearcher (folder);

searcher.Filters.Add ("Name like 'A%'");

foreach (FolderMember folderMember in searcher.FindAll ())

{

Item member = folderMember.TargetItem;

...

}

Navigating to the target article works even if the target article is not in the domain where the relationship was found. In such cases, the storage platform API, if necessary, opens a connection to the target domain. Applications can determine if a connection is required before retrieving the target article.

Checking destination article in an unconnected domain

searcher = Relationship.GetSearcher (source);

foreach (Relationship relationship in searcher.FindAll ())

{

if (reltionship.IsTargetDomainConnected)

{

Item member = relationship.TargetItem;

...

}

}

(3) Navigation from source articles to relationships

With this article object, you can navigate to relationships for which the article is the source, without performing an explicit search. This is done using the collection property Item.Relationships or a strongly typed collection property, such as Folder.MemberRelationships. From the relationship, you can navigate to the target article. Such navigation works even if the target article is not in the article domain associated with the ItemContext of the source article, including when the source article is not in the same storage as the target article. For example:

Navigation from source article to relationship and further to target articles

Console.WriteLine ("Item {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);

}

Navigating from a folder article to Foldermember relationships and further to target articles

Console.WriteLine ("Item {0} is the source of the following

relationships: ", folder.ItemId);

foreach (FolderMember folderMember in

folder.MemberRelationships)

{

Item target = folderMember.GetMemberItem ();

Console.WriteLine ("{0} ==> {1}",

folderMember.RelationshipId, target.ItemId);

}

An article can have many relationships, so applications should use caution when listing collections of relationships. In general, searches should be used to identify specific relationships of interest, rather than listing the entire collection. Nevertheless, if the programming model for collection-based relationships is valuable enough and articles with many relationships are rare enough, the risk of committing the wrong action by the developer is justified. Applications can check a number of relationships in a collection and, if necessary, use a different programming model. For example:

Checking the size of a relationship collection

if (folder.MemberRelationships.Count> 1000)

{

Console.WriteLine ("Too many relationships!");

}

else

{

...

}

The relationship collections described above are “virtual” in the sense that they are not actually populated with objects that represent each relationship until the application makes an attempt to list the collection. If the collection is listed, the results reflect what is in the repository, plus what is added by the application, but not yet saved, but not any relationship that was deleted by the application but not saved.

(4) Creating relationships (and articles)

New relationships are created by creating a relationship object, adding it to the relationship collection in the original article, and updating the ItemContext. To create a new article, you need to create a support or implementation relationship. For example:

Adding a new article to an existing old

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 ();

Adding an existing article to an existing folder

folder.MemberRelationships.Add (target, "name");

ic.Update ();

Adding an existing article to a 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 ();

Adding a new article to a 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) Deleting relationships (and articles)

Deleting a Support Relationship

// If the ID of the source article and the relationship 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

As noted above, each storage platform scheme generates many classes. These classes have standard methods, for example, Find *, and also have properties for getting and setting field values. These classes and associated methods form the basis of the storage platform API.

a) Domain Behaviors

In addition to these standard methods, each scheme has many domain-specific methods. We list these domain behaviors. For example, some of the domain behaviors in the Contact Scheme are as follows:

- Is the email address suitable?

- For a given folder, get a collection of all the items in the folder.

- For a given article ID, get the object representing this article.

- For a given person, get his online status.

- The assistant functions to create a new contact or temporary contact.

- Etc.

It is important to note that although we make a distinction between “standard” behaviors (Find *, etc.) and domain behaviors, for a programmer they look just like methods. The difference between these methods is that standard behaviors are automatically generated from the schema files by the tools of the storage platform API development environment, while domain behaviors are encoded in hardware.

By nature, these domain behaviors must be manually defined. This poses a practical problem: the initial version of C # requires that the entire class implementation be in a single file. To do this, you have to edit the self-generated class files to add domain behavior. This in itself can be a problem.

To solve such problems, a feature called partial classes was introduced in C #. Basically, a partial class allows classes to span multiple files. A partial class is the same as a regular class except that its declaration is preceded by the partial keyword:

partial public class Person: DerivedItemBase

{

// implementation

}

Now the domain behavior for Person can be placed in another file, for example, like this:

partial public class Person

{

public EmailAddress PrimaryEmailAddress

{

get {/ * implementation * /}

}

}

b) Add Value Behaviors

Data classes with domain behaviors form the foundation on which a developer builds applications. However, it is both impossible and undesirable for data classes to expose every conceivable behavior related to that data. The storage platform allows the developer to build on the basic functionality provided by the storage platform API. The main template here is to write a class whose methods take one or more data classes of the storage platform as parameters. For example, the add value classes for sending email using Microsoft Outlook or using the Microsoft Windows messaging service might look like this:

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 value adding classes can be registered using the storage platform. Registration data is associated with the metadata of the schema that the storage platform supports for each installed type of storage platform. This metadata is stored as storage platform articles and may be requested.

Registering add value classes is a powerful feature; for example, it allows the following scenario: by right-clicking on the Person object in the shell browser, you can display a set of valid actions from the add classes registered for Person.

c) Value-adding behaviors as service providers

According to this embodiment, the storage platform API provides a mechanism by which value adding classes can be registered as “services” for a given type. This allows the application to set and receive service providers (= value adding classes) of a given type. Value adding classes that want 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 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 define an instance of a service provider, as well as request a specific type of service provider.

To support this interface, the storage platform data class maintains a hash table of service providers, where they are distributed by type. When asked by the service provider, the implementation first looks in the hash table to check whether the service provider of the specified type is specified. If not, the infrastructure of the requested service provider is used to identify the service provider of the specified type. Then an instance of this service provider is created, it is added to the hash table and returned. Note that a shared method on a data class is also possible to query a service provider and transfer the operation to that service provider. For example, this can be used to provide the Send method on a mailing class that uses the email system specified by the user.

9. The structure of the development environment

This section describes how the storage platform diagram obtains the classes converted to the storage platform APIs on the client and UDT classes on the server according to this embodiment of the invention. The diagram in FIG. 24 shows the components used.

24, the types in the schema are contained in an XML file (block 1). This file also contains the field level and article level restrictions associated with the schema. The storage platform class generator (xfs2cs.exe - block 2) takes this file and generates partial classes for the UDT storage (block 5) and partial classes for the client classes (block 3). There are additional methods for each schema domain that we call domain behaviors. There are domain behaviors that make sense on the store (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 complete class implementation for the domain classes of the storage platform APIs. Blocks 3, 4, and 6 are compiled (block 8) to form storage platform API classes — block 11 (in fact, the storage platform API is the result of compiling blocks 3, 4, and 6 obtained from all domains in the initial schema). In addition to domain classes, there are also additional classes that implement value-adding behavior. 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 server UDT classes. Blocks 4, 5 and 7 are compiled (block 9) to form the server-side UDT assembler - block 12 (in fact, the server-side UDT assembler is the result of compiling and adding blocks 4, 5, and 7 obtained from all domains of the initial circuit). The DDL command generator module [YaD?] (Block 13) takes the UDT assembler (block 12) and the schema file (block 1) 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

Being reduced to the basics, the application template when using the storage platform API is: opening ItemContext; Using Find with filter criteria to retrieve the desired objects; manipulation of objects; sending changes back to the repository. This section focuses on the syntax of the filter string.

The filter string provided when retrieving data objects from the storage platform describes what conditions the properties of the objects must satisfy in order to be returned. The syntax used by the storage platform API supports type casting and relationship traversal.

a) Basics of filtration

The filter string is either empty, which indicates the need to return all objects of a given type, or is a logical expression that each returned object must satisfy. The storage platform API runtime knows how these property names are mapped to field names such as the storage platform and, ultimately, to the SQL views supported by the 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 (gender)

// equal to "Male" (male)

FindResult res2 = Person.FindAll (ctx, "Gender = 'Male'")

// Find all people who have a Gender property value,

// equal to "Male", and born in the past millennium.

FindResult res3 = Person.FindAll (

ctx

"Gender = 'Male' And Birthdate <'1/1/2001'”)

You can also use nested property objects in the filter. For example:

// Find all people changed 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 conditions in square brackets. For example:

// Find all people by the name "John" and by the name "Smith"

FindResult res1 = Person.FindAll (

ctx

"PersonalNames [GivenName = 'John' And Surname = 'Smith']")

// Find all people with a real-time address from the provider

// 'x' and with the online status category 'y'

FindResult res2 = Person.FindAll (

ctx

"PersonalRealtimeAddress [ProviderURI = 'x']. BasicPresence." +

"OnlineStatus.Category = 'y'")

The following example lists all people born on 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 indicates the time after 12/31/1999, which is specified by the expression "Birthdate> '12 / 31/1999 '". The execution of the FindAll operation is illustrated in FIG.

b) Type casts

It often happens that the type of value stored in a property is inferred from the declared property type. For example, the PersonalEAddresses property in Person contains a collection of types derived from EAddress, for example, EMailAddress and TelephoneNumber. To filter based on the area code, you must switch from the EAddress type to the TelephoneNumber type:

// Find all people with a phone number that has

// region 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 describes the filter syntax supported by the storage platform 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 | NumericConstatant

StringConstant :: '' '(any Unicode character) *' ''

Note: embedded characters are eliminated 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 CLR type name

FullRelationshipName :: = SchemaName '.' RelationshipName

SchemaName :: = the storage platformName

RelationshipName :: = the storage platformName

the storage platformName :: = specified in [SchemaDef]

11. Remote operations

a) Local / remote transparency in the API

Access to data in the storage platform targets an instance of the local storage platform. The local instance serves as a router if the request (or part of it) refers to remote data. Thus, the API layer provides local / remote transparency: there is no structural difference in the API between local and remote data access. This is solely a function of the requested scope.

The storage platform data warehouse also implements distributed queries; thus, you can connect to an instance of the local storage platform and make a request that includes articles from different volumes, some of which are located on local storage, and some on remote storage. The repository combines the results and presents them to the application. From the point of view of the storage platform API (and, therefore, the application developer), any remote access is completely smooth 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 on the ItemContext. Among other things, the application may wish to provide visual feedback to help user expectations regarding performance, reliability, etc.

b) Implementing remote operations on the storage platform

Storage platform data stores talk to each other using a special OLEDB provider that acts on HTTP (the OLEDB provider uses TDS by default). In one embodiment, a distributed query passes through the OPENROWSET functionality of a relational database engine. For actual remote operations, a special user-defined function (UDF) is provided: DoRemoteQuery (server, queryText).

c) Access to non-storage vaults

According to one embodiment of the storage platform of the present invention, there is no general provider architecture that allows any storage to participate in accessing the storage platform data. However, a limited provider architecture is provided for the specific case of Microsoft Exchange and Microsoft Active Directory (AD). It is assumed 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 access is limited to 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) Relation to DFS

The storage platform property promoter does not advance past installation points. Although the namespace is rich enough to access through the setpoints, requests do not go through them. Storage platform volumes may look like endpoints in a DFS tree.

f) Attitude towards GXA / Indigo

A developer can use the storage platform APIs to open the “GXA head” on top of the data warehouse. Basically, there is no difference from creating any other web service. The storage platform API does not talk to the storage platform data warehouse using GXA. As noted above, the API talks to local storage using TDS; local storage manipulates any remote operations using the synchronization service.

12. Limitations

The storage platform data model allows value restrictions on types. These restrictions are evaluated on the repository automatically, and the process is transparent to the user. Note that restrictions are checked on the server. Sometimes, as noted here, it is advisable to give the developer the flexibility to verify that the input satisfies the constraints without creating a postback overhead to 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 provides this mechanism.

Recall that the storage platform schema is defined in an 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 API development framework framework to automatically generate classes.

The following is partially the text of the XML file used to generate the Contact 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>

Check tags in the above XML set restrictions on the Person type. More than one verification tag may exist. The above limitation is usually checked in the repository. To specify that the constraint can also be explicitly checked by the application, the above XML is modified as follows:

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

Notice the new “InApplication” attribute on the <Check> element, which is set to true. This forces the storage platform API to detect the constraint in the API through a private method on the Person class called Validated. An application can call this method on an object to ensure that the data is usable, preventing the potentially useless return of data to the server. This returns a boolean indicating the results of the check. Note that value restrictions still apply on the server, regardless of whether the client calls the <object> .Validate () method. Here is an example of how to use Validate:

ItemContext ctx = ItemContext.Open ();

// Create a contact in the My Contacts folder of the user.

Folder f = UserDataFolder.FindMyPersonalContactsFolder (ctx);

Person p = new Person (f);

// Set the date of birth of the person.

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 the actual person

}

// save changes

p.Update ();

ctx.Close ();

There are several ways to access storage platform storage — storage platform APIs, ADO.NET, ODBC, OLEDB, and ADO. The question arises of the official verification of restrictions, i.e. how can we guarantee that data written, say, from ODBC goes through the same data integrity restrictions as if the data were written from the storage platform API. Since all restrictions are checked on the repository, the restrictions are now official. Regardless of which API path is used to access the repository, all records in the repository are filtered through checks on the restriction on the repository.

13. Sharing

The shared resource in the storage platform is \\ <DNS name> \ <context service>,

where <DNS name> is the name of the DNS machine, and <context service> is the inclusion folder, virtual folder, or article in the volume on that machine. Suppose, for example, the Johns_Desktop machine has a volume called Johns_Information, and in this volume there is a folder called Contacts_Categories; this folder contains a folder called Work, which contains John’s work contacts:

\\ Johns_Desktop \ Johns_Information $ \ Contacts_Categories \ Work

This can be shared as "WorkContacts". By defining this shared resource, \\ Johns_Desktop \ WorkContacts \ JaneSmith is a valid storage platform name and identifies a Person article called JaneSmith.

a) Presentation of a shared resource

The article type of the shared resource has the following properties: the name of the shared resource and the purpose of the shared resource (this may be an unsupported relationship). For example, the name of the aforementioned shared resource is WorkContacts, and the target is Contacts_Categories \ Work on the Johns_Information volume. The following is a snippet 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 = "1" />

<ReferencedSchema Name = "the storage platformTypes"

MajorVersion = "1” />

<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

Because a shared resource is an article, shared resources can be managed exactly like other articles. A shared resource can be created, deleted, or modified. The shared resource is also protected in the same way as other storage platform articles.

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 when calling the ItemContext.Open () method. ItemContext.Open returns an instance of the ItemContext. Then the storage platform API talks to the local storage platform service (recall that access to the shared resources of the remote storage platform is through the local storage platform). In turn, the local storage platform service talks to the remote storage platform service (for example, WorkContacts). Then, the remote storage platform service translates WorkContacts into Contacts_Categories \ Work and opens it. After that, the request and other operations are carried out like other areas of action.

d) Detectability

According to one embodiment, an application can detect shared resources available under a given <DNS name> in the following ways. According to the first method, the storage platform API accepts the DNS name (for example, Johns_Desktop) as the scope parameter in the ItemContext.Open () method. The storage platform API then contacts the storage platform storage with this DNS name as part of the connection string. Thanks to this connection, the only thing the application can do is call ItemContext.FindAll (typeof (Share)). The storage platform service then combines all the shared resources on all the 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 on a separate article) generally apply to articles (including embedded articles) in this context. Nested elements do not have Find - you cannot search in them regardless of the articles that contain them. This is consistent with the semantics of the desired data model of the storage platform, where the nested elements derive their “identification” from the containing article. To clarify this idea, we give examples of suitable and unsuitable finding operations:

a) Show me all the phone numbers in the system that have the area code 206.

Unsuitable, since the location is carried out on telephone numbers - an element - without a link to the article.

b) Show me all phone numbers in all Person articles with area code 206.

Unsuitable, despite the link to Person (= article), this criterion does not apply this article.

c) Show me all Murali phone numbers (= one single person) with area code 206.

Suitable because there is a search term on an article (a person named "Murali").

Exceptions to this rule are nested element types derived directly or indirectly from the Base.Relationship type. These types can be requested individually through relationship classes. Such queries can be supported because the storage platform implementation uses a “master link table” to store relationship elements instead of embedding them in UDT articles.

15. Storage platform Contacts API

This section provides an overview of the Storage platform API Contacts. The diagram underlying the API Contacts is shown in FIGS. 21A and 21B.

a) System.Storage.Contact Overview

The storage platform API includes a namespace for dealing with articles and items in the Contact Scheme. This namespace is called System.Storage.Contact. This scheme has, for example, the following classes:

- Articles: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location

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

b) Domain Behavior

The following is a list of domain behaviors for Contact Schema. Considering the behavior of a domain from a sufficiently high level, they can be divided into intuitive categories:

- static assistants, for example, Person.CreatePersonalContact () to create a new personal contact;

- instance helpers, for example user.AutoLoginToAllProfiles (), which logs the user (an instance of the User class) into all profiles that are marked as intended for automatic login;

- CategoryGUID, for example, Category.Home, Category.Work, etc .;

- derived properties, for example, emailAddress.Address () - returns a string that combines the user name and domain fields of the given emailAddress (= instance of the EmailAddress class); and

- Derived collections, for example, person.PersonalEmailAddresses - for this instance of the Person class, get his personal email address.

The following table shows, for each class in Contacts that has domain behaviors, a list of these methods and the category to which they belong.

Basicpresence Category URI UnknownCategoryURI, OfflineCategoryURI, BusyCategoryURI, AwayCategoryURI, OnlineCategoryURI Static Helpers ConvertPresenceStateToString - state of the presence of the localized string format (in fact, localization should be added; it just makes the string friendly in English). Category Category GUID Home, Work, Primary, Secondary, Cell, Fax, Pager EmailAddress Derived Properties Address - combines the username and domain Static Helpers IsValidEmailAddress Folder Derived Properties GetChildItemCollection - Creates a collection of articles based on the goals of the FolderMembership. Static Helpers GetKnownFolder - special requests for getting well-known folders AddToPersonalContacts - adds an article to the well-known personal contacts folder Items Static Helpers GetItemFromID - Makes a request based on ID Relationship Instance Helpers BindToTarget - returns an article for the purpose Person Derived Collections PersonalRealtimeAddresses, PersonalEmailAddresses, PersonalTelephoneNumbers Derived Properties OnlineStatus, OnlineStatusIconSource, PrimaryEmailAddress, PrimarySecurityID Static Helpers CreatePersonalContact, CreateTemporaryContact - creates a new face in a well-known folder GetCurrentUser - Gets the user identity of the current session Securityid Derived Properties UserName, DomainName, DomainUserName TelephoneNumber Instance Helpers SetFromUserInputString - decomposes a phone number string into parts Static Helpers ParseNumber - decomposes a phone number string into parts User Instance Helpers AutoLoginToAllProfiles - included in all profiles that are marked as intended for automatic login

16. Storage Platform API File

This section provides an overview of the Storage Platform API File according to one embodiment of the present invention.

a) Introduction

(1) Reflection of an NTFS volume on a storage platform

The storage platform provides a way to index by context on existing NTFS volumes. To do this, (“promoting”) properties are extracted from each file stream or directory in NTFS and these properties are saved as articles in the storage platform.

The storage platform file schema defines two types of articles - File and Directory - for storing advanced file system entities. The Directory type is a subtype of the Folder type; this is the inclusion folder that contains other Directory articles or File articles.

A Directory entry may contain Directory and File entries; it cannot contain any other type of article. As for the storage platform, Directory and File articles are read-only from any data access API. The file system promotion manager (FSPM) service asynchronously promotes changed properties to the storage platform. The properties of the File and Directory articles can be changed through the Win32 API. The storage platform API can be used to read any properties of these articles, including the stream associated with the File article.

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

After the NTFS volume is promoted to the storage platform volume, all the files and directories in it are located in a special part of this volume. This area is read-only in terms of storage platform; FSPM can create new directories and files and / or modify the properties of existing articles.

The rest of the namespace of this volume may contain the usual range of types of storage platform entries - 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 NTFS file system; they are entirely stored in the storage platform. In addition, property changes are visible immediately.

However, the programming model remains the same: they are still read-only in terms of API access to storage platform data. Native files and directories must be updated using the Win32 API. This simplifies the developer’s mental model, which is:

1. Any type of storage platform article can be created anywhere in the namespace (unless, of course, rights prevent this).

2. Any type of storage platform article can be read using the storage platform API.

3. All types of storage platform entries are written using the storage platform APIs, with the exception of File and Directory.

4. The Win32 API is used to record File and Directory articles regardless of where they are in the namespace.

5. Changes to File / Directory entries in the “advanced” namespace can immediately appear on the storage platform; in the "non-advanced" namespace, changes are immediately reflected in the storage platform.

b) File schema

25 shows a diagram on which the File API is based.

c) System.Storage.Files Overview

The storage platform API includes a namespace for working with file objects. This namespace is called System.Storage.Files. The class information elements in System.Storage.Files directly reflect the information stored in the storage of the storage platform; this information is “pushed” from file system objects or can be created internally using the Win32 API. The System.Storage.Files namespace has two classes: FileItem and DirectoryItem. The elements of these classes and their methods are easy to predict by looking at the diagram diagram in FIG. FileItem and DirectoryItem are read-only from the storage platform API. To change them, you need to use the Win32 API or classes in System.IO.

d) Code examples

This section provides three code examples that illustrate the use of the System.Storage.Files classes.

(1) Opening a file and writing to it

This example shows how to perform “traditional” file manipulations.

ItemContext ctx = ItemContext.Open ();

FileItem f = FileItem.FindByPath (ctx,

@ ”\ My Documents \ billg.ppt");

// example of processing file properties is to ensure that

// the file is not read-only

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 advanced property, IsReadOnly, to check if the file is writable. If yes, then in line 9 we use the OpenWrite () method on the FileItem object to get the file stream.

(2) Using queries

Because storage platform storage supports advanced features from the file system, rich queries can easily be made on files. This example lists all the files changed 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 - finding all the recorded files of a certain type (= extension):

// Find all writable files .cs

// 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

According to one embodiment, in addition to standard properties and methods, the file class also has domain behaviors (manually prescribed properties and methods). These behaviors are generally based on methods in the corresponding System.IO classes.

J. Conclusion

According to the foregoing, the present invention relates to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends the concept 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 partially structured data, such as relational (tabular) data, XML and a new data form, the so-called Articles. Due to its common storage foundation and schematized data, the storage platform according to the present invention allows more efficiently developing an application for consumers, IT professionals and enterprises. It provides a rich and extensible application programming interface that not only makes available the features inherent in this data model, but also extends and extends the existing file system and database access methods. It is understood that changes can be made according to the above described embodiments without going beyond the scope of the invention. Accordingly, the present invention is not limited to the specific disclosed embodiments, but is intended to cover all modifications that meet the essence and scope of the invention defined in the attached claims.

From the foregoing, it follows that various systems, methods and aspects of the present invention can be, in whole or in part, implemented in the form of program code (for example, instructions). This program code may be stored on a computer-readable medium, for example, magnetic, electrical or optical storage medium, including, without limitation, a floppy disk, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape , flash memory, hard disk, or any other computer-readable storage medium, and when the program code is loaded into a machine, such as a computer or server, and executed on it, the machine becomes a device for the practical application of the invention. The present invention can also be implemented in the form of program code that is transmitted over a certain transmission medium, for example, via electric wires or cables, through optical fibers, through a network, including the Internet or an intranet, or through any other type of transmission, moreover, when the program code arrives and loaded into a machine, such as a computer or server, and executed on it, the machine becomes a device for the practical application of the invention. When implemented on a general-purpose processor, the program code is combined with the processor to provide a unique device that acts similarly to special logic circuits.

Appendix A

namespace System.Storage

{

abstract class ItemContext: IDisposable, IServiceProvider

{

Create ItemContext and manage items

// Applications cannot directly create objects

// ItemContext and derive classes from ItemContext

interal ItemContext ();

// Create An ItemContext That Can Be Used

// to search the specified paths or, if none

// path not specified, in the default storage

// on the local computer

public static ItemContext Open ();

public static ItemContext Open (string path);

public static ItemContext Open (params string [] paths);

// Return the specified paths when the ItemContext is created

public string [] GetOpenPaths ();

// Create a copy of this ItemContext. Copy will be

// have an independent transaction, caching

// and update status. Cache initially

// will be empty. Usage expected

// cloned ItemContext will be more

// effective than opening a new ItemContext

// using the same article domains.

public ItemContext Clone ();

// Close ItemContext. Any attempt to use

// ItemContext after closing will result

// to ObjectDisposedException.

public void Close ();

void IDisposable.Dispose ();

// True if any domain specified when

// ItemContext was open, resolved on the remote

// computer.

public bool IsRemote {get; }

// Returns an object that can provide

// requested type of service. Returns null

// if the requested service cannot be

// provided. Using a template

// IServiceProvider allows you to allocate an API that

// usually not used and may confuse

// developers, from the ItemContext class. ItemContext

// can provide the following services:

// IItemSerialization, IStoreObjectCache

public object GetService (Type serviceType);

Update related items

// Saves the change represented by the changed

// objects and all objects passed to MarkForCreate

// or MarkForDelete. Can throw away

// UpdateCollisionException when a conflict is detected

// updates.

public void Update ();

// Saves the changes represented by the specified

// objects. Objects must either change or

// passed MarkForCreate or MarkForDelete, otherwise

// throw an ArgumentException. Can throw away

// UpdateCollisionException when a conflict is detected

// updates.

public void Update (object objectToUpdate);

public void Update (IEnumerable objectsToUpdate);

// Updates the content of the specified objects from the repository.

// If the object is modified, the changes are overwritten, and

// the object is no longer considered modified. Throws away

// ArgumentException if anything other than

// object of the article, the extension of the article or relationship.

public void Refresh (object objectToRefresh);

public void Refresh (IEnumerable objectsToRefresh);

// Excited if the update detects that

// data has changed in storage between moments

// retrieve the modified object and try to save

// him. If no event descriptor

// registered, the update throws an exception.

// If an event descriptor is registered, it can

// throw an exception to abort the update,

// force the changed object to overwrite the data in

// store or merge changes made to

// storage and in the object.

public event ChangeCollisionEventHandler

UpdateCollision;

// Excited at various times during processing

// updates to provide progress information

// updates

public event UpdateProgressEventhandler UpdateProgress;

// Asynchronous versions of Update

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 Refresh

public IAsyncResult BeginRefresh (object

objectToRefresh, IAsyncCallback callback,

object state);

public IAsyncResult BeginRefresh (IEnumerable

objectsToRefresh, IAsyncCallback callback,

object state);

public void EndRefresh (IAsyncResult result);

Transaction Related Items

// Starts the transaction from the specified isolation level.

// The default isolation level is ReadCommited. In

// in all cases, a distributed transaction begins,

// since she might need to cover properties

// stream type articles.

public Transaction BeginTransaction ();

public Transaction BeginTransaction (

System.Data.IsolationLevel isolationLevel);

Search related items

// Create An ItemSearcher That Will Implement

// search in this context articles of objects of the specified

// type. Throws an ArgumentException if a type is specified,

// different from the article, relationship or extension of the article.

public ItemSearcher GetSearcher (Type type);

// Find the article by its ID.

public Item FindItemById (ItemId itemId);

// Find the article on this path to it. Path may be

// absolute or relative. If it is relative,

// NotSupportedException will be thrown if, when

// ItemContext was open, multiple were specified

// article domains. Returns null if no such article

// exist. Creates a connection to a part

// \\ machine \ share domain to retrieve the article. Article

// will be associated with this domain.

public Item FindItemByPath (string path);

// Find the article on this path to it. Path refers to

// the specified domain of the article. Creates a connection to

// the specified domain to retrieve the article. Article will be

// linked to this domain. Will return null if such

// article does not exist.

public Item FindItemByPath (string domain, string path);

// Find the relationship by its ID

public Relatioinship FindRelationshipById (ItemId

itemID, RelationshipId relationshipId);

// Find the extension of the article by its ID

public ItemExtension FindItemExtensionById (ItemId

itemId, ItemExtensionId itemExtensionId);

// Find all articles, relationships or article extensions

// of the specified type, optional

// matching this filter. Throws away

// ArgumentException if a type other than these is specified.

public FindResult FindAll (Type type);

public FindResult FindAll (Type type, string filter);

// Find any article, relationship or article extension

// the specified type that satisfies the given

// filter. Throws an ArgumentException if specified

// type different from these. Returns null if such

// object not found.

public object FindOne (Type type, string filter);

// Find an article, relationship or article extension

// the specified type that satisfies the given

// filter. Throws an ArgumentException if specified

// type different from one of them. Throws away

// MultipleObjectsFoundException if more than

// single object.

public object FindOnly (Type type, string filter);

// Returns true if the article, relationship, or

// extensions of the article of the specified type, which

// satisfies the given filter, exists.

// Throws an ArgumentException if a type is specified,

// different from one of them.

public bool Exists (Type type, string filter);

// Indicates how objects returned as a result

// search, refer to identity mapping

// object supported by ItemContext.

public SearchColllisionMode SearchCollisionMode {

get; set;}

// Excited when PreserveModifiedObjects is set

// for ResultMapping. This event allows the application

// selectively update the modified object

// data retrieved through the search.

public event ChangeCollisionEventHandler

SearchCollision;

// Includes an object from another ItemContext in this

// context of the article. If an object representing the same

// the article itself, the relationship or extension of the article, is no longer

// exists, this is an identity mapping

// ItemContext, an object clone is created and added to

// display. If the object exists, it is updated.

// state and content of the specified object in

// according to SearchCollisionMode.

public Item IncorporateItem (Item item);

public Relationship IncorporateRelationship (

Relationship relationship);

public ItemExtension IncorporateItemExtension (

ItemExtension itemExtension);

}

// Descriptor for ItemContext.UpdateCollision and itemSearcher.SearchColIision events

public delegate void ChangeCollisionEventHandler (

object source, ChangeCollisionEventArgs args);

// Arguments for the delegate ChangeCollisionEventHandler

public class ChangeCollisionEventArgs: EventArgs

{

// Modified article object, article extension, or

// relations

public object ModifiedObject {get;}

// Properties from the repository

public IDictionary StoredProperties {get;}

}

// Descriptor for ItemContext.UpdateProgress.

public delegate void UpdateProgressEventHandler (

ItemContext itemContext,

UpdateProgressEventArgs args);

// Arguments for the delegate UpdateProgressEventHandler

public class ChangeCollisionEventArgs: EventArgs

{

// Current update operation

public UpdateOperation CurrentOperation {get; }

// The object currently being updated

public object CurrentObject {get;}

}

// Indicates how the objects returned from the search

// refer to the display of the identification of objects,

// supported ItemContext.

public enum SearchCollisionMode

{

// Specifies how to create and return new ones

// objects. Objects representing the same article

// extension of the article or relation in the display

// identifications are ignored. If this option is specified,

// the SearchCollision event will not be raised.

DoNotMapSearchResults,

// Indicates that the objects from the identity mapping

// must be returned. If the content of the object was

// modified by application, modified object content

// saved. If the item has not been modified, this content

// updated with data returned as a result

// search. An application may provide a descriptor for

// SearchCollision events and selectively update

// desired object.

PreserveModifiedObjects,

// Indicates that the objects from the identity mapping

// must be returned. The content of the object is updated.

// data returned from the search, even if

// the object has been modified by the application. If this option

// set, the SearchCollision event will not be

// get excited.

OverwriteModifiedObjects

}

// Current update operation

public enum UpdateOperation

{

// Provided the first time Update is called.

// CurrentObject will be null.

OverallUpdateStarting,

// Provided just before Update

// returns after a successful update. Currentobject

// will be null.

OverallUpdateCompletedSucessfully,

// Provided just before Update

// throws an exception. CurrentObject will be the exception object.

OverallUpdateCompletedUnsuccessfully,

// Provided when an object update begins.

// CurrentObject will reference the object that

// will be used for updating.

ObjectUpdateStaring,

// Provided when a new connection is needed.

// CurrentObject will be a string that contains the path,

// identifying domain of the article passed

// ItemContext.Open or retrieved from the Location field

// relations.

Openingconnection

}

} Appendix B

namespace System.Storage

{

// Searches for a specific type in the context of the article.

public class ItemSearcher

{

Constructors:

public ItemSearcher ();

public ItemSearcher (Type targetType,

ItemContext context);

public ItemSearcher (Type targetType,

ItemContext context,

params SearchExpression [] filters);

Properties:

// Filters used to identify matching

// objects.

public SearchExpressionCollection Filters {get;}

// ItemContext, which indicates the domains in which

// will be searched.

public ItemContext ItemContext {get; set;}

// Collection of search parameters.

public ParameterCollection Parameters {get;}

// Type with which the search engine will work.

// For simple search engines, this is an object type,

// to be returned.

public Type TargetType {get; set;}

Search methods

// Find TargetType objects that satisfy

// conditions specified by filters. Returns empty

// FindResult if such objects do not 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 the filters.

// Returns null if such an object does not exist.

public object FindOne ();

public object FindOne (FindOptions findOptions);

public object FindOne (params SortOption []

sortOptions);

// Find a TargetType object that satisfies

// conditions specified by filters. Throws away

// ObjectNotFoundException, if such an object

// not found.

public object FindOnly ();

public object FindOnly (FindOptions findOptions);

// Determine if a TargetType exists that

// satisfies the conditions specified by the filters.

public bool Exists ();

// Creates an object that can be used for more

// efficiently perform the same search repeatedly.

public PreparedFind PrepareFind ();

public PreparedFind PrepareFind (FindOptions

findOptions);

public PreparedFind PrepareFind (params SortOption []

sortOptions);

// Retrieves the number of records that will be

// returned by 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);

// Indicates whether fields should be loaded with a delay,

// loaded with a delay.

public bool DelayLoad {get; set;}

// Number of returned matches

public int MaxResults {get; set;}

// Collection of sorting 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);

// parameter name

public string Name {get;}

// Parameter value

public object Value {get; set;}

}

// Collection of parameter name / value pairs

public class ParameterCollection: (Collection

{

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 optimized for repeated

// run

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);

// SearchExpression of the search that identifies

// property to be produced

// sort.

public SearchExpression Expression {get; set;}

// Indicates ascending or descending order

// sort

public SortOrder Order {get; set;}

}

// Collection of sort options objects

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;}

}

// Specifies the sort order using the object

// SortOption

public enum SortOrder

{

Ascending,

Descending

}

} Appendix C

namespace System.Storage

{

public abstract class FindResult: IAsyncObjectReader

{

public FindResult ();

// Moves FindResult to the next position

// as a 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 FindResult contains any

// objects.

public bool HasResults {get;}

// Returns whether FindResult is closed

public bool IsClosed {get;}

// Returns the article type of this FindResult

public Type ObjectType {get;}

// Closes FindResult

public void Closed;

void IDisposable.Dispose ();

// Returns an enumerator over FindResult starting

// from the current position. Promotes any enumerator

// when FindResult promotes all enumerators,

// as well as FindResult itself.

IEnumerator IEnumerable.GetEnumerator ();

public FindResultEnumerator GetEnumerator ();

}

public abstract class FindResultEnumerator: (Enumerator,

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 (16)

1. A storage platform including a processor and a computer-readable storage medium containing instructions recorded thereon which, when executed by a computer, lead to the implementation by the computer of the functions of the operating system, said operating system comprising a kernel including software database management, configured to save data in said file system as file streams, generate elements including metadata for said stream files, and storing said elements using said database management software, said database management software comprising a basic circuit and a mechanism adapted to extend said basic circuit to define a circuit for said data and to divide said data into software defined change elements based on said pattern for said data, said change element being the smallest part of the circuit that paradise can be individually tracked by said software database management, the size changing element is adjustable;
said operating system further includes a synchronization subsystem adapted to synchronize said data stored by said database management software with a remote computer based on changes that are sequentially numbered and tracked with respect to each change element;
wherein
said data is defined in terms of articles, elements and relationships, wherein the article is a unit of data stored in a data warehouse and contains one or more elements, the element being an instance of a type containing one or more fields, and the relation is a relationship between, in at least two articles,
many schemes that define different types of articles, elements and relationships, and
application programming interface containing a class for each of the various articles, elements, and relationships defined in a variety of schemes. 2. The storage platform according to claim 1, in which data can also be stored in a data warehouse as an extension to an existing article type, and in which the application programming interface contains a class for each individual article extension. 3. The storage platform according to claim 1, in which a class for each type of article, element and relationship is generated automatically based on the set of schemes that define each type of article, element and relationship. 4. The storage platform according to claim 1, in which the classes for each type of article, element and relationship define a set of data classes, and in which the application programming interface further comprises a second set of classes that specify a common set of behaviors for data classes. 5. The storage platform according to claim 4, in which the second set of classes contains the first class, which represents the scope of the storage platform and which provides the context for queries on the data warehouse, and the second class, which represents the results of the query on the data warehouse. 6. The storage platform according to claim 1, additionally containing a database machine on which the data warehouse is implemented, and in which different types of articles, elements and relationships in the data warehouse are implemented in the database machine as user-defined types (UDT). 7. The storage platform according to claim 6, in which the application programming interface provides a query model that allows application developers to generate queries based on various properties of articles in the data warehouse, so that the application developer is isolated from the details of the query language of the database machine . 8. A method of providing an application programming interface between an application and a storage platform for storing, organizing, sharing and searching data, the storage platform comprising a data warehouse in which data stored therein is defined in terms of articles, elements and relationships, wherein an article is a unit of data stored in a data warehouse and contains one or more elements, the element being an instance of a type containing one or more fields, and the relation is communicating between at least two articles, the method comprising the steps of:
provide many schemes that define different types of articles, elements and relationships, and
generating, as part of the application programming interface, a class for each of the various articles, elements, and relationships defined in the plurality of schemes;
wherein the storage platform includes a processor and a computer-readable storage medium containing instructions recorded thereon which, when executed by a computer, lead to the implementation of the functions of the operating system by the computer, said operating system comprising a kernel including database management software wherein said database management software is configured to save data in said file system as file streams, a gene walkie-talkies of elements including metadata for said file streams and storing said elements using said database management software, said database management software comprising a basic circuit and a mechanism adapted to extend said basic circuit to define a circuit for said data and dividing said data into programmatically determined change elements based on said scheme for said data, change element is the smallest part of a circuit which may be tracked individually by said software database management, the size changing element is adjustable;
said operating system further includes a synchronization subsystem configured to synchronize said data stored by said database management software with a remote computer based on changes that are sequentially numbered and tracked for each change item. 9. The method of claim 8, in which the data can also be stored in the data warehouse as an extension to the existing type of article and in which the method further comprises generating a class for each individual article extension. 10. The method according to claim 9, in which the generated classes for each type of article, element and relationship define a variety of data classes, and in which the method further comprises providing, as an additional part of the application programming interface, a second set of classes that specify common set of behaviors for data classes. 11. The method of claim 10, wherein the second set of classes comprises a first class that represents the scope of the storage platform and which provides a context for data warehouse queries, and a second class that represents the results of the data warehouse query. 12. The method of claim 8, wherein the storage platform data warehouse is implemented on the database machine and the method further comprises the step of implementing different types of articles, elements and relationships in the data warehouse as user-defined types (UDT) in database machine. 13. A computer system comprising a processor and a computer-readable storage medium containing instructions stored on it, which, when executed by the processor, cause the processor to implement the application programming interface, operating system and data storage, the data storage being configured to store data specified in terms of articles, elements and relationships in which an article is a unit of data stored in a data warehouse and contains one or more elements, the element being an instance p type, containing one or more fields, and the relationship is the relationship between at least two articles, moreover, the application programming interface includes data classes representing an element of the storage platform and article types, a runtime structure configured to control survivability object and support classes support and tools configured
to generate CLR classes from storage platform schemas,
wherein said operating system includes a kernel including database management software for storing data in said file system as file streams, generating elements including metadata for said file streams, and storing said elements using said database management software, wherein said database management software comprises a basic circuit and a mechanism configured to expand said ba a new scheme for determining a scheme for said data and dividing said data into programmatically determined change elements based on said scheme for said data, said change element being the smallest part of a circuit that can be individually tracked by said database management software, and size The item change is adjustable;
said operating system further includes a synchronization subsystem configured to synchronize said data stored by said database management software with a remote computer based on changes that are sequentially numbered and tracked for each change item. 14. The computer system according to item 13, in which data can also be stored in the data warehouse as an extension to the existing type of article, and in which the application programming interface further comprises a class for each individual article extension. 15. The computer system according to item 13, in which the classes for each type of article, element and relationship define a set of data classes, and in which the application programming interface further comprises a second set of classes that specify a common set of behaviors for data classes. 16. The computer system according to clause 15, in which the second set of classes contains the first class, which represents the scope of the storage platform and which provides the context for queries on the data warehouse, and the second class, which represents the results of the query on the data warehouse.

Images