JP2007521532A - System and method for data modeling in an item-based storage platform - Google Patents

Abstract

Various embodiments of the present invention are directed to a data store (302) that includes Items, Elements, and Relationships. Item is a data storage unit in the data store (302), and further includes the element and the relationship. An Element is an instance of a type that includes one or more fields. A Relationship is a link between at least two Items. The data store (302) further includes a Core Schema (340) that defines a collection of Core Items so that the hardware / software interface system can store the collection of Core Items in a predetermined and predictable manner. Understand and process directly. A core Item is derived from a common single basic Item, which is a basic item in the basic schema.

Description

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

  Individual disk capacities have increased at a rate of almost 70% per year over the last decade. Moore's Law accurately predicted a tremendous increase in central processing unit (CPU) power that has continued for many years. Wired and wireless technology has provided tremendous connectivity and bandwidth. Assuming the current trend will continue, within a few years the average laptop computer will have roughly 1 terabyte (TB) of storage and will store millions of files, 500 gigabytes (GB) The drive will become commonplace.

  Consumers primarily use computers to communicate and organize personal information, whether it is traditional Personal Information Manager style data or media such as digital music or photos It doesn't matter. The amount of digital content and the ability to store raw bytes has increased tremendously, but the methods that consumers can use to organize and integrate such data have not been addressed. Knowledge workers spend a great deal of time managing and sharing information, and one study estimates that knowledge workers spend 15-25% of all time on non-productive information-related activities Yes. Other studies estimate that standard knowledge workers spend about 2.5 hours each day searching for information.

  Developers and information technology (IT) departments spend considerable time and money building their own data stores for common storage abstractions that represent people, places, time, and events. Spend. This results in a number of isolated islands of common data that not only duplicate work but also lack a mechanism for common search or sharing of data. Today, consider how many address books can exist on a computer running the Microsoft Windows operating system. Many applications, such as e-mail clients and personal finance programs, store address books individually and there is little sharing between applications of address book data that each such program maintains individually. As a result, finance programs (such as Microsoft Money (registered trademark)) have the recipient's address held in an email contact folder (such as a folder that is included in Microsoft Outlook (registered trademark)). Do not share with address. In fact, many users have multiple devices, logically synchronize their personal data among themselves, and span a variety of additional sources, from mobile phones to commercial services such as MSN and AOL. However, collaboration on shared documents is mostly done by attaching documents to email messages, which is done manually and inefficiently.

  One reason for this lack of collaboration is that traditional approaches to organizing information within a computer system use a file-folder / directory-based system ("file system") to store multiple files. Based on the abstraction of the physical organization of the storage medium used to do this, it functions mainly on organizing a plurality of files into a directory hierarchy of folders. Developed in the 1960s, the first Multitics operating system has gained a reputation for managing files storable units at the operating system level using files, folders, and directories for the first time. In particular, Multics used symbolic addresses within the hierarchy of files (thus introducing the concept of file paths), and the physical addresses of files were not transparent to users (applications and end users). The file system as a whole is unaware of the file format of any individual file, and the relationship between the files is considered insignificant at the operating system level (ie, other than the location of the file in the hierarchy). It was. Since the advent of Multics, storable data has been organized into files, folders, and directories at the operating system level. These files generally include the file hierarchy itself (“directory”) embodied in a special file maintained by the file system. This directory then holds a list of entries corresponding to all other files in the directory and all such nodal locations in the hierarchy (referred to herein as folders). Such a system has been state of the art for about 40 years.

  However, despite realizing a sufficiently reasonable representation of the information located in a computer's physical storage system, a file system is an abstraction of that physical storage system and the use of those files Requires some level of instruction (interpretation) between the user's operations (contextual units, features, and relationships with other units) and the operating system content (files, folders, and directories) And Thus, users (applications and / or end-users), other than forcing a unit of information into a file system structure, even if it is inefficient, inconsistent, or otherwise undesirable in some way There is no choice. In addition, existing file systems have little knowledge of the structure of data stored in individual files, so most of the information remains locked up in files that can only be accessed (understood) by the application that wrote them. It becomes. As a result, this lack of a schematic description of information and a mechanism for managing information creates a data storage location with little data sharing between the individual storage locations. It will be. For example, for many personal computer (PC) users, file organization is a fairly difficult task for PC users, so some level-eg Outlook Contacts, online account addresses, Windows Address Book, Quicken Payes, and Instant There are more than five different stores that store information about the people you interact with in your messaging (IM) buddy list. Most existing file systems use nested folder metaphors for organizing files and folders, so as the number of files increases, the effort required to maintain a flexible and efficient organization scheme can be significant. It will be a thing. In such situations, having multiple classifications of a single file is very beneficial, but using hard or soft links in existing file systems is cumbersome and difficult to maintain.

  In the past, there have been several attempts to eliminate the flaws of the file system, but it has failed. Some of those previous attempts have made use of content addressable memory to provide a mechanism for accessing data by content rather than physical address. However, associative memory has proven useful for small-scale usage by devices such as caches and memory management units, but large-scale usage on devices such as physical storage media is still possible for a variety of reasons As such, these efforts have not been successful, so such a solution simply does not exist. Other attempts have been made using object-oriented database (OODB) systems, but these attempts are characterized by strong database characteristics and good non-file representation, but are not effective in handling file representations and are hard. Nor can it replicate the speed, efficiency, and simplicity of files and folders based on the system level hierarchy of the hardware / software interface. Other efforts, such as attempts to use SmallTalk (and its derivatives), have proven to be very effective in handling file and non-file representations, but make efficient use of the relationships that exist between various data files. It lacked the necessary database functions to organize and use well, and thus the overall efficiency of such a system was unacceptable. In addition, other attempts to use BeOS (and other such operating system studies) have some of the necessary database functionality to handle non-file representations, even though they can represent the files properly. Demonstrated inadequacy-the same drawbacks as the central drawbacks of traditional file systems.

  Database technology is another technical field where similar challenges exist. For example, the relational database model has had great commercial success, but in fact, independent software vendors (ISVs) generally have a few of the features available in relational database software products (such as Microsoft SQL Server). The part is used. Instead, most of the application interaction with such products is in the form of simple “read” and “write”. One of the most important reasons that are often not noticed, such as the lack of a platform or database, is readily apparent, but the database is not necessarily the exact one that a large business application vendor really needs. This means that no abstraction is performed. For example, in the real world, there is a concept of “items” in “customers” or “orders” (along with items within themselves, and “line items” with orders embedded as their own items), but relational databases Only recognizes tables and rows. As a result, it may be desirable for an application to have (for example) item-level integrity, locking, security, and / or triggering aspects, but in general, a database will have these functions in a table / row. It is prepared only at the level. This can work well if each item is mapped to a single row in a table in the database, but for multiple line item orders, the item is actually mapped to multiple tables. There can be a reason, and if that is the case, a simple relational database system will not do the right abstraction at all. As a result, applications must build logic on the database to implement their basic abstraction. This means that the basic relational model requires a certain level of indirection between the application and the storage system, in which case the semantic structure of the data may only be visible within the application in certain cases. The relational model does not provide a sufficient platform to store data that can be easily developed for high-level applications. Some database vendors have built high-level functionality into their products—including object-relational capabilities, new organizeable models, etc.—but none have achieved the necessary kind of comprehensive solution. This is because a truly comprehensive solution is a useful data abstraction ("Item", "Extensions", "Items", "Extensions", “Relationships” and the like).

  With regard to the aforementioned shortcomings in existing data storage and database technology, a new storage platform with increased ability to organize, search and share all types of data in computer systems-data beyond existing file systems and database systems There is a need for a storage platform that is designed to store all types of data that expands and expands the platform. The present invention satisfies this requirement.

  The following description provides an overview of various aspects of the invention. This description is not intended to be an exhaustive description of all important aspects of the invention or to delineate the scope of the invention. Rather, this description is intended to be used as an introduction to the following detailed description and drawings.

  The present invention is directed to a storage platform for data organization, retrieval, and sharing. The storage platform of the present invention extends and extends the concept of data storage over existing file systems and database systems for all types of data, including structured, unstructured, or semi-structured data. Designed to be a store.

  According to one aspect of the present invention, the storage platform of the present invention includes a data store implemented on a database engine. In various embodiments of the present invention, the database engine includes a relational database engine with object-relational extensions. The data store implements a data model that supports data organization, retrieval, sharing, synchronization, and security. A mechanism that extends a set of schemas to define a new type of data (essentially a subtype of the basic type implemented by the schema) where a particular type of data is described in the schema Is provided. The synchronization processing function facilitates sharing of data between users or systems. A file system-like function is provided, which enables data store interoperability with existing file systems without the limitations of such conventional file systems. The change tracking mechanism provides a change tracking function for the data store. The storage platform further comprises a set of application program interfaces for accessing all of the aforementioned functions of the storage platform from the application and accessing the data described in the schema.

  According to another aspect of the invention, a data model implemented by a data store defines a unit of data storage with respect to items, elements, and relationships. An item is a unit of data that can be stored in a data store and can include one or more elements and relationships. An element is an instance of a type that includes one or more fields (also called properties here). A relationship is a link between two items. (As used herein, these and other specific terms may be capitalized in original English to separate them from other terms that are used very closely. However, in English, a capitalized first term is “Item”, and the same term when it is not capitalized in English, for example, “item” is translated into Japanese as an item, but there is no intention to distinguish it. Such distinction should not be assumed or included implicitly).

  According to another aspect of the invention, a computer system provides a plurality of Items, each of which constitutes a discrete storable unit of information that can be manipulated by a hardware / software interface system. A hardware / software interface system for manipulating a plurality of Items, which includes a plurality of Item Folders constituting the organizational structure, and each Item belongs to at least one Item Folder, and may belong to the plurality of Item Folders.

  According to another aspect of the invention, a computer system comprises a plurality of Items, each Item comprising a discrete information unit that can be manipulated by a hardware / software interface system, and the Item or Item properties Some of the values are calculated dynamically as opposed to being obtained from the persistent store. That is, the hardware / software interface system does not need to store the Items, but is given the ability to enumerate the current set of Items or the identifier of the storage platform (described in more detail in the section describing the application programming interface or API) Some operations are supported, such as the ability to retrieve an Item when given-for example, the Item can be the current location of the mobile phone or a temperature reading on a temperature sensor.

  According to another aspect of the present invention, a hardware / software interface system of a computer system that operates a plurality of Items further includes an Item interconnected by a plurality of Relationships managed by the hardware / software interface system. Including. According to another aspect of the present invention, a computer system hardware / software interface system operates a plurality of discrete information units having properties understandable by the hardware / software interface system. / Software interface system. According to another aspect of the present invention, a hardware / software interface system of a computer system is a collection of core Items that the hardware / software interface system understands and can directly process in a predetermined and predictable manner. It has a core schema to define. According to another aspect of the present invention, a plurality of hardware / software interface systems of a computer system comprising interconnecting the Item and a plurality of Relationships and managing the Relationships at a hardware / software interface system level A method of operating a discrete information unit ("Item") of a computer is disclosed.

  According to another aspect of the invention, the storage platform API provides a data class for each item, item extension, and relationship defined in the collection of storage platform schemas. In addition, the application programming interface defines a common set of behaviors for the data class and, together with the data class, implements a set of framework classes that provide the basic programming model of the storage platform API. According to another aspect of the present invention, the storage platform API separates the application programmer from the details of the underlying database engine query language, allowing the application programmer to query based on various properties of the items in the data store. Provide a simplified query model that can be used to form. According to yet another aspect of the storage platform API of the present invention, the API collects changes made to items by application programs and then uses them to create a database engine (or some type of storage) that implements the data store. Organize into the correct updates required by the engine). This allows application programmers to make changes to items in memory while leaving the complex part of data store updates to the API.

  The storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses through a common storage infrastructure and schematized data. This not only makes the functionality specific to the data model available, but also includes a rich and extensible application programming interface that encompasses and extends existing file systems and database access methods.

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

  The foregoing summary, together with the following detailed description of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments of the various aspects of the invention, but the invention is not limited to the specific methods and instrumentalities disclosed. The drawings are described below.

Table of Contents Introduction A. Exemplary Computing Environment B. Conventional file-based storage II. New storage platform for organizing, searching, and sharing data Glossary Overview of storage platform Data model Items
2. Item identification a) Item reference
(1) ItemIDReference
(2) ItemPathReference
b) Reference type hierarchy Item Folders and Categories
4). Schema
a) Base Schema
b) Core Schema
5). Relation a) Declaration of relation b) Retention Relationship
c) Embedding relationship d) Reference relationship e) Rules and constraints f) Ordering of relationships Extensibility a) Item extension b) NestedElement type extension Database engine 1. Implementation of data store using UDT 2. Item mapping Extended mapping 4. Mapping of nested elements Object identification Rules for naming SQL objects 7. Naming rules for columns Search view a) Item
(1) Master item search view
(2) Typed item search view b) Item expansion
(1) Master extended search view
(2) Typed extended search view c) Nested elements d) Relationship
(1) Master relationship search view
(2) Relation instance search view 9. Update 10. Change Tracking & Tombstone a) Change Tracking
(1) Change tracking in the “master” search view
(2) Change tracking in “typed” search view b) Tombstone
(1) Item Tombstone
(2) Extended tombstone
(3) Related tombstones
(4) Tombstone cleanup Helper API and functions a) Function [System. Storage]. GetItem
b) Function [System. Storage]. GetExtension
c) Function [System. Storage]. GetRelationship
12 Metadata a) Schema metadata b) Instance metadata e. Security 1. Overview 2. Detailed description of security model a) Security descriptor structure
(1) Access mask format
(2) General access rights
(3) Standard access rights b) Item-specific rights
(1) Rights specific to file and directory objects
(2) WinFSItemRead
(3) WinFSItemReadAttributes
(4) WinFSItemWriteAttributes
(5) WinFSitemWrite
(6) WinFSitemAddLink
(7) WinFSItemDeleteLink
(8) Right to delete items
(9) Rights to copy items
(10) The right to move items
(11) Right to display the security policy on the item
(12) Right to change the security policy on an item
(13) The right not to have a direct equivalent. Implementation a) Create a new item in the container b) Add an explicit ACL to the item c) Add a retention relationship to the item d) Remove the retention relationship from the item e) Remove the explicit ACL from the item F) Modify the ACL associated with the item. Notification and change tracking Storage change event a) Event b) Watchers
2. Change Tracking and Notification Generation Mechanism a) Change Tracking b) Timestamp Management c) Data Change Detection-Event Detection G. Synchronization 1. Synchronization processing between storage platforms a) Synchronization (sync) control application b) Schema annotation c) Synchronization settings
(1) Community folder-mapping
(2) Profile
(3) Schedule d) Conflict avoidance process
(1) Competition detection
(A) Knowledge base competition
(B) Constraint-based competition
(2) Competitive processing
(A) Automatic conflict resolution
(B) Create conflict log
(C) Conflict inspection and resolution
(D) Replica convergence and contention resolution propagation Non-storage platform data store synchronization a) Synchronization processing service
(1) Change enumeration
(2) Change Application
(3) Conflict Resolution
b) Mounting the adapter Security 4. Manageability H. Interoperability of conventional file systems Model for interoperability Data store functions a) Not a volume b) Store structure c) Not all files are migrated d) Access to storage platform files in the NTFS namespace e) Expected namespace / drive Letters
I. Storage platform API
1. Overview 2. Naming and scope 3. Storage platform API component Data class Runtime framework a) Runtime framework classes
(1) ItemContext
(2) ItemSearcher
(A) Target type
(B) Filter
(C) Preparation for search
(D) Search option
(3) Item result stream (“FindResult”)
b) Running runtime framework c) Common programming pattern
(1) Opening and closing an ItemContext object
(2) Object search
(A) Search option
(B) FindOne and FindOnly
(C) Search for shortcuts on ItemContext
(D) Search by ID or path
(E) GetSearcher pattern
(3) Store update Security 7. Support for relationships a) Basic relationship type
(1) Relation class
(2) ItemReference class
(3) ItemIdReference class
(4) ItemPathReference class
(5) RelationshipId structure
(6) VirtualRelationshipCollection class b) Generated relation type
(1) Generated relation type
(2) RelationshipPrototype class
(3) RelationshipPrototypeCollection
Class c) Relationship support in Item class
(1) Item class
(2) RelationshipCollection class d) Relationship support in search expressions
(1) Traverse from item to relationship
(2) Traverse from relationship to item
(3) Combination of relationship traversal e) Usage example of relationship support
(1) Relationship search
(2) Navigate from relationship to source and target items
(3) Navigate from source item to relationship
(4) Creating relationships (and items)
(5) Delete relationship (and item) "Extension" of storage platform API
a) Domain behavior b) Value-added behavior c) Value-added behavior as a service provider 9. Design time framework 10. Query format (formalism)
a) Basics of filters b) Type conversion c) Filter syntax Remoting a) Local / remote transparency in API b) Storage platform implementation of remoting c) Access to non-storage platform store d) Relationship with DFS e) Relationship with GXA / Indigo Restriction 13. Share a) Share representation b) Share management c) Share access d) Discoverability 14. Meaning of Find 15. Storage Platform Contacts API
a) System. Storage. Outline of Contact b) Domain Behavior 16. Storage platform File API
a) Introduction
(1) Reflection of NTFS volume in the storage platform
(2) Files in the storage platform namespace and
Directory creation b) File schema c) System. Storage. Overview of Files d) Code example
(1) Open and write files
(2) Use of query e) Domain behavior Summary

I. Introduction The subject matter of the present invention is described with specificity to meet legal requirements. However, the description itself is not intended to limit the scope of the invention. Rather, the inventor believes that the claimed subject matter, along with other current or future technologies, includes other steps or combinations of steps that are similar to, but different from, the steps described herein. We considered that the method could also be realized. Furthermore, although the term “step” may be used herein to imply different elements of the method employed, the term explicitly describes the order of the individual steps. Should not be construed as implying a specific order between the various steps disclosed herein.

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

  As shown in FIG. 1, an exemplary general purpose computing system comprises a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. Personal computer 20. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using various bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input / output system 26 (BIOS) including a basic routine for assisting information transmission between elements in the personal computer 20 at the time of startup or the like is stored in the ROM 24. The personal computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk not shown in the figure, a magnetic disk drive 28 for reading from and writing to a removable magnetic disk 29, and a CD-ROM or other device. An optical disk drive 30 is provided for reading from and writing to a removable optical disk 31 such as an optical medium. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, respectively. The drive and associated computer readable storage medium implement non-volatile storage for storing computer readable instructions, data structures, program modules, and other data for the personal computer 20. In the example environment described in the present invention, a hard disk, a removable magnetic disk 29, and a removable optical disk 31 are used. Those skilled in the art will understand that a magnetic cassette, flash memory card, digital video disk, Bernoulli It is understood that other types of computer readable media capable of storing computer accessible data such as cartridges, multiple random access memories (RAM), multiple read only memories (ROM) can be used in this exemplary operating environment. Will do. Similarly, this exemplary environment can further include various types of monitoring devices, such as heat sensors and security or fire alarm devices, and other information sources.

  Many program modules, including operating system 35, one or more application programs 36, other program modules 37, and program data 38, are stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25. Can do. A user can input commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) include a microphone, joystick, game pad, satellite dish, scanner, and the like. These input devices and other input devices are often connected to the processing unit 21 via a serial port interface 46 coupled to the system bus, but may be a parallel port, a game port, or a universal serial bus (USB). It can also be connected through other interfaces. A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. A personal computer usually includes other peripheral output devices (not shown) such as a speaker and a printer in addition to the monitor 47. The exemplary system of FIG. 1 further 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 can operate in a network connection environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, server, router, network PC, peer device, or other common network node, and typically includes many or all of the above-described elements associated with the personal computer 20, but with memory Only the storage device 50 is shown in FIG. The logical connections described in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

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

  As illustrated in the block diagram of FIG. 2, the computer system 200 broadly includes a hardware component 202, a hardware / software interface system component 204, and an application program component 206 (here, context sensitive). Can also be divided into three component groups.

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

  Application program component 206 comprises various software programs, including but not limited to compilers, database systems, word processors, business programs, video games, and the like. Application programs provide a means for utilizing computer resources to solve problems, provide solutions, and process data for various users (machines, other computer systems, and / or end users). Prepare.

  The hardware / software interface system component 204 itself comprises an operating system that includes, in most cases, a shell and a kernel (and may be configured with only such an operating system in some embodiments). 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 further include a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or functional equivalent thereof, or Other such software components may also be included in place of or in addition to the operating system within the computer system. The purpose of the hardware / software interface system is to prepare an environment in which a user can execute an application program. The goal of the hardware / software interface system is not only to make the computer system easier to use, but also to make the computer hardware available in an efficient manner.

  The hardware / software interface system is generally loaded into the computer system at startup and thereafter manages all application programs in the computer system. Application programs interact with the hardware / software interface system by requesting services via an application program interface (API). In some application programs, end users can interact with a hardware / software interface system via a user interface such as a command language or a graphical user interface (GUI).

  A hardware / software interface system conventionally executes various services for an application. In a multitasking hardware / software interface system that can execute multiple programs at the same time, the hardware / software interface system executes which application in any order and how much before switching to the next application for each application. Decide what time you should allow. The hardware / software interface system further manages the sharing of internal memory among multiple applications, and further provides input to and output from connected hardware devices such as hard disks, printers, and dialup ports. To process. The hardware / software interface system further sends a message regarding the status of the operation and any errors that may have occurred to the respective application (and possibly the end user). The hardware / software interface system may also remove the burden of managing batch jobs (eg, printing) and allow the initiating application to be freed from such work and resume other processing and / or operations. it can. In a computer capable of providing a parallel processing function, the hardware / software interface system further manages that the program is divided and executed on a plurality of processors at a time.

  A shell of a hardware / software interface system (referred to herein simply as a “shell”) is an interactive end user interface with a hardware / software interface system. (A shell is also called a “command interpreter” or, in the operating system, an “operating system shell.”) A shell is a hardware / software interface system that is directly accessible by application programs and / or end users. Is the outer layer. In contrast to the shell, the kernel is the innermost layer of the hardware / software interface system that interacts directly with the hardware components.

  Although many embodiments of the present invention are believed to be particularly well suited for computerized systems, this document is in no way intended to limit the invention to such embodiments. Rather, as used herein, the term “computer system” can store and process information and / or use the stored information to perform the behavior or execution of the device itself. It is intended to encompass any and all devices that can be controlled regardless of whether such devices are electronic devices, mechanical devices, logical devices, virtual devices in nature. Yes.

B. Traditional File-Based Storage In most modern computer systems, a “file” is a storable unit of information that can include not only hardware / software interface systems, but also application programs, data sets, and the like. In all modern hardware / software interface systems (Windows®, Unix®, Linux, MacOS, virtual machine systems, etc.), files are information that can be manipulated by the hardware / software interface system ( For example, basic individual (storeable and retrievable) units of data, programs, etc. A group of files is generally organized in units of “folders”. In Microsoft Windows®, Macintosh OS, and other hardware / software interface systems, a folder is a collection of files that can be retrieved, moved, and manipulated by some other means as a single information unit. It is. These folders are then organized in a tree-based hierarchical arrangement called a “directory” (detailed below). In some other hardware / software interface systems, such as DOS, z / OS, and most Unix-based operating systems, the terms “directory” and / or “folder” are used interchangeably. And the previous Apple computer system (eg, Apple IIe) used the term “catalog” instead of directory, but as used herein, these terms are all synonymous. It is considered a word and is interchangeable and is intended to include all other equivalent terms and references to the hierarchical information storage structure and its folder and file components.

  Conventionally, directories (alias, folder directories) have a tree-based hierarchical structure, files are grouped into a plurality of folders, and the folders are further arranged according to relative node positions including the directory tree. For example, as illustrated in FIG. 2A, a base folder (or “root directory”) 212 of a DOS-based file system may include a plurality of folders 214, each folder further including an additional folder ( 216) (as “subfolders” for that particular folder), each of which can contain additional folders, and so on, and so on. Each of these folders can hold one or more files 220, but at the hardware / software interface system level, the individual files within a folder have nothing in common except for their location in the tree hierarchy. . This approach of organizing files into folder hierarchies indirectly involves the physical organization of standard storage media (eg, hard disks, floppy disks, CD-ROMs, etc.) used to store files. It is not surprising to reflect.

  In addition to the above, each folder is a container for its subfolders and its files. That is, each folder owns its subfolders and files. For example, when a folder is deleted by the hardware / software interface system, the subfolders and files of the folder are also deleted (in the case of each subfolder, its own subfolders and files are recursively included). Similarly, each file is generally owned by only one folder. The file is copied and the copy can be placed in a different folder, but the copy of the file is itself a different separate unit that has no direct association with the original (eg changed to the original file) Is not reflected in the copy file at the hardware / software interface system level). In this regard, files and folders are “physical” in nature. This is because folders are treated like physical containers, and files are treated as discrete, separate physical elements within those containers.

II. The present invention is directed to a storage platform for data organization, retrieval, and sharing. The storage platform of the present invention extends and extends the data platform concept beyond existing file systems and database systems of the type described above, and for all types of data, including a new form of data called Item. Designed to be a store.

A. Glossary As used herein and as used in the claims, the following terms have the following meanings.

  An “Item” is a hardware / software interface that, unlike a simple file, is an object that has a basic set of properties that are generally supported across all objects exposed to the end user by a hardware / software interface system shell. A unit of storable information that can access the system. Items also have properties and relationships that are generally supported across all Item types, including the ability to introduce new properties and relationships (detailed later in this document).

  An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. Most operating systems include a shell and a kernel.

  A “hardware / software interface system” is software, or a combination of hardware and software, used as an interface between a computer system running on a computer system and the underlying hardware components of an application. A hardware / software interface system typically comprises an operating system (in some embodiments, it consists only of an operating system). The hardware / software interface system further includes a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or functional equivalent thereof, or a computer system. Other such software components can also be included in place of, or in addition to, the operating system within. The purpose of the hardware / software interface system is to prepare an environment in which a user can execute an application program. The goal of the hardware / software interface system is not only to make the computer system easier to use, but also to make the computer hardware available in an efficient manner.

B. Storage Platform Overview With reference to FIG. 3, a storage platform 300 according to the present invention comprises a data store 302 implemented on a database engine 314. In one embodiment, the database engine includes a relational database engine with object-relational extensions. In one embodiment, the relational database engine 314 includes a Microsoft SQL Server relational database engine.

  The data store 302 implements a data model 304 that supports data organization, retrieval, sharing, synchronization, and security. Certain types of data are described in a schema, such as schema 340, and storage platform 300 includes tools 346 for expanding and extending those schemas, as described in detail below.

  A change tracking mechanism 306 implemented within the data store 302 provides the ability to track changes to the data store. The data store 302 further includes a security function 308 and a promotion / demotion function 310, both described in detail below. The data store 302 further includes a set of application programming interfaces 312 to transfer the functions of the data store 302 to other storage platform components and application programs that utilize the storage platform (eg, application programs 350a, 350b, and 350c). Publish.

  The storage platform of the present invention further allows application programs such as application programs 350a, 350b, and 350c to access all of the aforementioned functions of the storage platform and to access data described in the schema. An interface (API) 322 is provided. The storage platform API 322 can be used in combination with other APIs such as the OLE DB API 324 and the Microsoft Windows (registered trademark) Win32 API 326 by an application program.

  The storage platform 300 of the present invention can provide various services 328 to application programs, including a synchronization processing service 330 that facilitates sharing of data between users or systems. For example, the synchronization processing service 330 may allow interoperability with other data stores having the same format as the data store 302 and access to data stores having other formats. The storage platform 300 further includes a file system function that enables interoperation between the data store 302 and an existing file system such as the Windows (registered trademark) NTFS file system 318.

  In at least some embodiments, the storage platform 300 may also add additional functionality to the application programming to allow manipulation of data and to interact with other systems. These functions can be implemented not only in the form of additional services such as the Info Agent service 334 and the notification service 332 but also in the form of other utilities 336.

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

  The storage platform of the present invention enables consumers, knowledge workers, and businesses to develop more efficient applications through a common storage infrastructure and schematized data. This not only makes the functionality specific to the data model available, but also includes existing file systems and database access methods, and provides a rich and extensible programming surface area.

  In the following description and various figures, the storage platform 300 of the present invention may be referred to as “WinFS”. However, using this name to refer to the storage platform is merely for convenience of explanation and is not intended to be limiting in any way.

C. Data Model The data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data located within the store. In the data model of the present invention, “Item” is a basic unit of storage information. This data model, described in detail below, provides a mechanism for declaring Items and Item extensions, establishing relationships between Items, and organizing Items within Item Folders and Categories.

  The data model relies on two primitive mechanisms: Types and Relationships. Types is a structure that defines a form that controls the form of an instance of Type. The format is represented as an ordered set of Properties. Property is a name for a given Type value or set of values. For example, the USPostAddress type can have properties Street, City, Zip, and State. Among them, Street, City, and State are String types, and Zip is Type Int32. Since the address can have a plurality of values for the Street property, the Street can be a multi-value (that is, a set of values). The system defines several primitive types that can be used in other types of configurations-these include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal, and GUID. Including. Type Properties can be defined using any of the primitive types, or any of the constructed types (although there are some constraints below). For example, a Location Type having Properties Coordinate and Address can be defined, but the Address Property is Type USPostAddress as described above. Properties can also be required or optional.

  Relationships are declared and can represent a mapping between a set of instances of two types. For example, a Relationship between a Person Type and a Location Type called LivesAt that defines which people live in which place can be declared. A Relationship has one name, two endpoints, a source endpoint and a target endpoint. Relationships can also have an ordered set of properties. Both the Source and Target endpoints have Name and Type. For example, a LiveAt Relationship has a Source called Occupant in Type Person and a Target called Dwelling in Type Location, and a property StartDate and a property StartDate that indicate the period in which the occupant lived in the dwelling. Have. Since Person may live in more than one residence in the long run, and there may be more than one inhabitant, the best place to put StartDate and EndDate information is the relationship. Note that it is).

  Relationships defines a mapping between instances that is constrained by a given type as an endpoint type. For example, Lives At Relationship cannot be a relationship in which Automobile is Occupant. This is because Automobile is not Person.

  The data model allows the definition of subtype-supertype relationships between types. A child-to-parent relationship, also referred to as a BaseType relationship, is defined such that if Type A is BaseType for Type B, then all instances of B are also instances of A. Another way of expressing this is that every instance that matches B must also match A. For example, if A has Type String property Name, but B has Type Int16 property Age, then all instances of B must have both Name and Age. The type hierarchy can be thought of as a tree with one supertype at the root. The branch from the root defines the first-level subtype, the branch at this level defines the second-level child type, and so on, is the most leading leaf that has no child type itself Go to the child type. The tree is not constrained to have a uniform depth, but cannot contain cycles. A given Type can have zero or more child types and zero or one parent type. A given instance can conform to a type along with its type's parent type. To put it another way, for an instance given at any level in the tree, that instance can fit into one child type at that level.

  A type is called Abstract if an instance of the type must also be an instance of a child type of that type.

1. Items
An Item, unlike a simple file, is a unit of storable information that is an object with a basic set of properties that are generally supported across all objects exposed to end users or application programs by the storage platform. Items also have properties and relationships that are generally supported across all Item types, including the ability to introduce new properties and relationships, as described below.

  Item is an object for common operations such as copy, delete, move, open, print, backup, restore, and copy. An Item is a unit that can be stored and retrieved, and all forms of storable information manipulated by the storage platform exist as Items, Item properties, or Relationships between Items, each of which is described in detail below. It is stated.

Items are intended to represent units of real-world easily understandable data such as Contacts (every kind), People, Services, Locations, Documents, etc. FIG. 5A is a block diagram illustrating the structure of an Item. The unqualified name of Item is “Location”. The qualified name of Item is “Core.Location”, which indicates that this Item structure is defined as a specific type of Item in Core Schema. (The Core Schema will be described in detail later in this specification.)
The Location Item has multiple properties including EAddresses, MetropolitanRegion, Neighborhood, and PostalAddresses. The specific type of property for each is shown immediately after the property name and separated from the property name by a colon (":"). To the right of the type name is the number of values allowed for that property type, which is shown between square brackets (“[]”), and an asterisk (“*”) to the right of the colon (“:”). ") Indicates an unspecified and / or unlimited number (" many "). A “1” to the right of the colon indicates that there can be one value. A zero ("0") to the left of the colon indicates that the property is optional (may have no value at all). A “1” to the left of the colon indicates that there must be at least one value (the property is mandatory). Neighborhood and MetropolitanRegion are both the type “nvarchar” (or equivalent type), which is a predefined data type or “simple type” (also represented by not capitalization herein). However, EAddresses and PostAddresses are properties of predefined types or “composite types” (represented herein in capital letters) of types EAddress and PostAddress, respectively. A complex type is a type derived from one or more simple data types and / or other complex types. Complex types for Item properties also constitute “nested elements” because the details of the complex type are nested within the Immediate Item to define the property, and the information related to those complex types is: Retained with Items with those properties (within the boundaries of the Item, as described later in this document). These concepts of typing are well known and can be easily understood by those skilled in the art.

  FIG. 5B is a block diagram illustrating the composite property types PostAddress and EAddress. The PostalAddress property type can be expected to have an Item of property type PostAddress having 0 or 1 City value, 0 or 1 CountryCode value, 0 or 1 MailStop value, and any number (0 to many) of PostalAddressTypes, etc. Define as a thing. In this way, the shape of the data for a particular property in the Item is defined. The EAddress property type is similarly defined as shown. Although used optionally in this Application, another way to represent a complex type within a Location Item is to render the Item with the individual properties of the complex type listed therein. FIG. 5C is a block diagram illustrating a Location Item in which the composite type is further described. However, it should be understood that this alternative representation of the Location Item in this FIG. 5C is for the exact same Item as illustrated in FIG. 5A. The storage platform of the present invention can also be subtyped so that one property type can be a child type of the other (where one property type is a property of the other parent property type). Is inherited).

  An Item, similar to a property and its property type, essentially represents its own Item Types that can also be subtyped. That is, in the storage platform in some embodiments of the present invention, an Item can be a child of another Item (so that one Item inherits the properties of the other parent Item). . Further, for the various embodiments of the present invention, all Items are children of the “Item” Item type, which is the first basic Item type found in the Base Schema. (The Base Schema is further described in detail later in this specification.) FIG. 6A illustrates the Item, that is, the Location Item of this Instance, as a child of the Item Item type in the Base Schema. Yes. In this drawing, the arrow indicates that the Location Item (like all other Items) is a child of the Item Item type. The Item Item type has a number of important properties such as ItemId and various timestamps as the underlying Item from which all other Items are derived, thereby allowing the standard properties of all Items to be set in the operating system. Define. In this figure, these properties of type Item Item are inherited by Location and thereby become Location properties.

  Another way to represent a property in a Location Item inherited from an Item Item type is to draw a Location with individual properties of each property type from the parent Item listed there. FIG. 6B is a block diagram illustrating a Location Item in which an inheritance type is described in addition to an immediate property. This Item is the same Item illustrated in FIG. 5A, but in this figure, Location is illustrated with all of its properties, both are immediate—shown in both this figure and FIG. 5A. Note that it is -and inherited--shown in this figure but not shown in FIG. 5A--noticeably (but in FIG. 5A, Location Item is a child of Item Item type) These properties are referenced by an arrow indicating that they are

  Items are stand-alone objects, so deleting an Item deletes all its immediate and inherited properties. Similarly, what is received when an Item is retrieved is the Item and all of its immediate and inherited properties (including information related to complex property types). In some embodiments of the invention, it is possible to request a subset of properties when retrieving a particular Item, but as a default for many such embodiments, immediate when retrieved. And supply all of the inherited properties to the Item. In addition, Item properties can be extended by adding new properties to existing properties of the Item type. These “extensions” are hereafter the real properties of the Item, and its Item child types can automatically include extended properties.

  The “boundary” of an Item is represented by its properties (including complex property types, extensions, etc.). Item boundaries also represent the limits of operations performed on Items such as copy, delete, move, and create. For example, in some embodiments of the present invention, when an Item is copied, everything within that Item's boundary is also copied. For each Item, the boundary includes:

  Item Type of Item, and if Item is a child of another Item (as in some embodiments of the invention where all Items are derived from a single Item and Item Type in Base Schema) , Any applicable child type information (ie information related to the parent Item Type). If the original Item of the copy source is a child type of another Item, the copy can also be a child type of the same Item.

  Item complex properties and extensions, if any. If the original Item has a complex type property (native or extended), its copy can also have the same complex type.

  Item records relating to “ownership”, ie a list of Items themselves of other Items (“Target Item”) owned by this Item (“Owning Item”). This is particularly appropriate with respect to Item Folders, which will be described in detail below, and the rules stipulate that all Items must belong to at least one Item Folder. Further, with respect to embedded items—described in more detail below—embedded items are considered part of an item that is embedded for operations such as copy, delete, etc.

2. Item Identification Items are uniquely identified within a global items space with ItemID. Base. The Item type defines a field ItemID of a type GUID that stores an Item ID. An Item must have exactly one ID in the data store 302.

a) Item Reference An item reference is a data structure that stores information for identifying and identifying an Item. In the data model, an abstract type is defined as having the name ItemReference from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves ItemReference and returns Item. This method is overridden by a concrete child type of ItemReference that implements a function that retrieves the Item given the reference. The Resolve method is invoked as part of the storage platform API 322.

(1) ItemIDReference
ItemIDReference is a child type of ItemReference. This defines the Locator and ItemID fields. The Locator field names (ie identifies) the item area (domain). This is handled by a locator resolution method that can resolve the value of the Locator to an item area. The ItemID field is an ItemID type.

(2) ItemPathReference
ItemPathReference is a specialization of ItemReference that defines Locator and Path fields. The Locator field identifies the item area. This is handled by a locator resolution method that can resolve the value of the Locator to an item area. The Path field contains a (relative) path in the storage platform namespace rooted at the item area given by the Locator.

  This type of reference cannot be used in a set operation. References must generally be resolved through a path resolution process. The Resolve method of the storage platform API 322 has this function.

b) Reference Type Hierarchy The reference form described above is represented through the reference type hierarchy illustrated in FIG. Additional reference types that inherit from these types can be defined in the schema. They can be used in relationship declarations as target field types.

3. Item Folders and Categories
As described in detail below, groups of Items can be organized into special Items called Item Folders (not to be confused with file folders). However, unlike most file systems, an Item can belong to multiple Item Folders, so if an Item is accessed and revised in one Item Folder, this revised Item will be in the other Item folder. Can be accessed directly from. In essence, access to an Item can originate from different Item Folders, but what is actually accessed is in fact the exact same Item. However, an Item Folder does not necessarily own all of its member Items, or can simply co-own an Item with other folders, and deleting an Item Folder will result in the deletion of the Item. Not necessarily done. However, in some embodiments of the present invention, an Item must belong to at least one Item Folder, and thus when an individual Item Folder for a particular Item is deleted, in one embodiment, the Item Is automatically deleted, or in other embodiments, the Item is automatically deleted by default Item Folder (eg, a “similar name folder” with a similar name folder used in various file-folder based systems). Member of “Trash Can” Item Folder).

  Also, as will be described in detail below, an Item may further be: (a) an Item Type (or Types), (b) a specific immediate or inherited property (or properties), or (c) a specific Item property that corresponds to an Item property. It may belong to Categories based on common described characteristics such as value (or values). For example, an Item containing a specific property of personal contact information may automatically belong to the Contact Category, and then an Item containing contact information property will automatically belong to this Category as well. Similarly, an Item having a position property having the value “New York City” can automatically belong to the New York City Category.

  Item Folders can contain items that are not interrelated (ie, have no common described properties), but each Item in a Category can have a common type, property, or Categories have the same meaning as Item Folders in that they have a value ("commonality") and that form the basis of relationships with other Items in the Category, and relationships between other Items. Conceptually different. In addition, an Item's membership to a particular Folder is not compulsory based on the particular aspect of that Item, but in some embodiments, commonality is related to a Category for a category. All Items can be automatically become Category members at the hardware / software interface system level. Conceptually, Categories can be thought of as virtual Item Folders (as defined in the background of the database) whose attribution is based on the results of a particular query, and can also be An Item that satisfies the condition will contain a Category membership.

  FIG. 4 illustrates the structural relationship between Items, Item Folders, and Categories in various embodiments of the invention. A plurality of Items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of various Item Folders 422, 424, 426, 428, and 430. There are also Items that belong to multiple Item Folders. For example, Item 402 belongs to Item Folders 422 and 424. Some Items, for example, Items 402, 404, 406, 408, 410, and 412 are also members of one or more Categories 432, 434, and 436, but for example, Items 414, 416, 418, and 420 Cannot belong to Categories (but this is rarely possible in some embodiments where property ownership automatically implies attribution to Category, and Item is not a member of a category in such embodiments) Would have to be completely featureless). In contrast to the folder hierarchy, both Categories and Item Folders are relatively similar to directed graphs as shown in the figure. In any case, Items, Item Folders, and Categories are all Items (although they are different Item Types).

  In contrast to files, folders, and directories, Item, Item Folders, and Categories of the present invention do not have a concept equivalent to a physical container, and therefore, Items may exist in such multiple locations. Therefore, it has essentially no “physical” characteristics. Items can exist in multiple Item Folder locations, and organized into Categories enhances data manipulation and storage structure capabilities at the hardware / software interface level beyond what is currently available in the art. It has become.

4). Schema
a) Base Schema
To provide a universal foundation for Item creation and use, various embodiments of the storage platform of the present invention comprise Base Schema that establishes a conceptual framework used for Item and property creation and organization. Base Schema defines some special types of Items and properties, and the characteristics of these special base types from which child types can be further derived. By using this Base Schema, a programmer can conceptually distinguish an Item (and each type) from a property (and each type). In addition, in Base Schema, a property that all Items (and their corresponding Item Types) can possess when all Items (and their corresponding Item Types) are derived from this underlying Item (and its corresponding Item Type) in Base Schema. Defines the basic set of

  As illustrated in FIG. 7, and for some embodiments of the present invention, Base Schema defines three top-level types: Item, Extension, and PropertyBase. As shown, the Item type is defined by the properties of this basic “Item” Item type. In contrast, the top-level property type “PropertyBase” has no defined properties and is just an anchor when all derived property types are related to each other, from which all other property types are derived. Only (usually derived from a single property type). The Extension type property defines which items are extended by an extension when an Item can have multiple extensions, and also defines an identification to distinguish one extension from the other. .

  ItemFolder is an Item Item type that features a Relationship that establishes a link to a member (if any) in addition to the properties inherited from Item, but both IdentityKey and Property are children of PropertyBase. It is a type. Similarly, CategoryRef is a child type of IdentityKey.

b) Core Schema
Various embodiments of the storage platform of the present invention further include Core Schema, which provides a top-level Item-type conceptual framework. FIG. 8A is a block diagram illustrating an Item in the Core Schema, and FIG. 8B is a block diagram illustrating a property type in the Core Schema. The distinction between files with different extensions (* .com, * .exe, * .bat, * .sys, etc.) and files with such other criteria in file-folder based systems is the Core Schema function. Is similar. Core Schema understands that an Item-based hardware / software interface system can directly (by an Item type) or indirectly (by an Item child type) understand all Items by an Item-based hardware / software interface system And define a set of core Item types that characterize one or more Core Schema Item types that can be processed directly in a predetermined and predictable manner. Predefined Item types reflect the most common Items within an Item-based hardware / software interface system, and thus some level of efficiency is Item-based hardware that recognizes pre-defined Item types, including Core Schema. / Obtained by software interface system.

  In some embodiments, the Core Schema is not extensible—that is, subtype the additional Item types directly from the Base Schema Item types, except for certain predefined derived Item types that are part of the Core Schema. I can't. Since all subsequent Item types are necessarily child types of the Core Schema Item type, by prohibiting extensions to the Core Schema (ie, prohibiting adding new Items to the Core Schema), the storage platform Requires the use of the Core Schema Item type. This structure sufficiently increases the degree of freedom to define additional Item types while maintaining the advantage of having a predefined set of core Item types.

  For various embodiments of the present invention, and referring to FIG. 8A, specific Item types supported by Core Schema can include one or more of the following.

  Category: This Item Type (and child type derived from it) Item represents a valid Category of an Item-based hardware / software interface system.

  • Commodities: Items that are valuable and identifiable.

  Devices: Items with a logical structure that supports information processing functions.

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

  Events: Items that record any events that occur in the environment.

  Locations: Items that represent physical locations (eg, geographic locations).

  Messages: Items for communication between two or more principals (defined below).

  • Principles: Items with at least one definable ID (eg, identification of people, organizations, groups, households, institutions, services, etc.) as well as ItemIDs.

  Statements: Items with special information about the environment, including but not limited to policies, subscriptions, credentials, etc.

  Similarly, referring to FIG. 8B, certain property types supported by Core Schema may include one or more of the following.

Certificates (derived from the basic PropertyBase type in Base Schema)
・ Principal Identity Keys (derived from IdentityKey type in Base Schema)
-Post Address (derived from Property type in Base Schema)
・ Rich Text (derived from Property type in Base Schema)
・ EAddress (derived from Property type in Base Schema)
・ IdentitySecurityPackage (derived from Relationship type in Base Schema)
-RoleOccupancy (Derived from Relationship type in Base Schema)
-BasicPresence (derived from the Relationship type in Base Schema)
These Items and Properties are further described by the respective properties described in FIGS. 8A and 8B.

5). Relationships Relationships are binary relationships in which one Item is specified as a source and the other Item is specified as a target. The source Item and the target Item are related by this relationship. The source Item generally controls the lifetime of the relationship. That is, when a source Item is deleted, the relationship between those Items is also deleted.

  Relationships are classified into an inclusion relationship Containment and a reference relationship Reference. The containment relationship controls the lifetime of the target Item, but the reference relationship has no meaning for lifetime management. FIG. 12 illustrates how the relationships are classified.

  The Containment relationship type is further classified into a holding relationship Holding and an embedding relationship Embedding. When all retention relationships for an Item are deleted, the Item is also deleted. The retention relationship uses a reference counting mechanism to control the lifetime of the target. Using embedding relationships allows modeling of complex items, which can be considered as exclusive holding relationships. An Item can be the target of one or more retention relationships, while an Item can be the target of exactly one embedding relationship. An Item that is an embedding target cannot be another retention or embedding target.

  The reference relationship does not control the lifetime of the target Item. These may be dangling—the target Item may not exist. Reference relationships can be used to model references to Items anywhere in the global Item namespace (ie, including remote data stores).

  When an Item is fetched, the relationship is not automatically fetched. The application must explicitly request Item relationships. Furthermore, modifying the relationship does not modify the source or target Item, and similarly, adding a relationship does not affect the source / target Item.

a) Declaration of relationship The explicit relationship type is defined by the following elements.

  -The relation name is specified by the Name attribute.

  A relationship type is one of Holding, Embedding, and Reference. This is specified in the Type attribute.

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

  The source endpoint field is generally of type ItemID (not declared) and must refer to an Item in the same data store as the relationship instance.

  For the Holding and Embedding relationships, the target endpoint field must be of type ItemIDReference and must reference an Item in the same store as the relationship instance. For the Reference relationship, the target endpoint may be of any ItemReference type and can reference Items in the data store of other storage platforms.

  Optionally, one or more fields of type scalar or propertybase can be declared. These fields can store data associated with the relationship.

  • Relationship instances are stored in a global relationship table.

  All relationship instances are uniquely identified by a combination (source ItemID, relationship ID). A relation ID is unique within a given source ItemID for all relations sourced from the given Item regardless of its type.

  The source Item is the owner of the relationship. The Item designated as the owner controls the lifetime of the relationship, but the relationship itself is separate from the Item to which it is related. The storage platform API 322 provides a mechanism for publishing relationships associated with Items.

  An example of a relationship declaration is shown below.

  This is an example of a Reference relationship. This relationship cannot be created if there is no person Item referenced by the source reference. Further, when a person item is deleted, the relationship instance between the person and the organization is deleted. However, when the Organization Item is deleted, the relationship is not deleted, and it becomes dangling.

b) Holding Relationship
The retention relationship is used to model reference count based lifetime management of the target Item.
Item can be a source endpoint for zero or more relationships with Item. An Item that is not an embedded Item can be a target in one or more retention relationships.
The target endpoint reference type must be ItemIDReference and must reference an Item in the same store as the relationship instance.

  The retention relationship manages the lifetime of the target end point. The creation of a holding relationship instance and the Item it is targeting is an atomic operation. It is possible to create an additional holding relationship instance that targets the same Item. When the last holding relationship instance having the given Item as the target end point is deleted, the target Item is also deleted.

The type of endpoint Item specified in the relationship declaration is generally enforced when the relationship instance is created. Once the relationship is established, the type of the end item cannot be changed.
Retention relationships play an important role in forming the Item namespace. These include a “Name” property that defines the name of the target Item relative to the source Item. This relative name is unique for all retention relationships that result from a given Item. This ordered list of relative names starting from the root Item and leading to the given Item forms the full name for the Item.

  The holding relationship forms an acyclic directed graph (DAG). When a retention relationship is created, the system ensures that no cycles are created and the Item namespace always forms a DAG.

  The retention relationship controls the lifetime of the target Item, but does not control the consistency of the operation of the target endpoint Item. The target Item is independent of the operation from the Item that owns it through the holding relationship. Copy, Move, Backup, and other operations on an item that is the source of a retention relationship will not affect the item that is the target of the same relationship-for example, if you back up a Folder Item, all Items will be foldered (FolderMember-related target) is not automatically backed up.

  The following is an example of the retention relationship.

  The FolderMembers relationship enables the concept of Folder to be used as a generic collection of Items.

c) Embedding relationship The embedding relationship models the concept of exclusive control of the duration of the target Item. These validate the concept of complex items.

  The creation of an embedded relationship instance and the Item it is targeting is an atomic operation. Item can be zero or more embedded source. However, Item can be the only embedding target. An Item that is an embedding target cannot be a retention target.

The target endpoint reference type must be ItemIDReference and must reference an Item in the same data store as the relationship instance.
The type of endpoint Item specified in the relationship declaration is generally enforced when the relationship instance is created. Once the relationship is established, the type of the end item cannot be changed.
The embedding relationship controls the consistency of the operation of the target end point. For example, an operation that serializes an Item can include not only all embedding relationships that are sourced from that Item, but also all serializations of its target, and all of its embedded by copying the Item Items are also copied.

  The following is an example declaration:

d) Reference relationship The reference relationship does not control the lifetime of the referenced Item. Furthermore, a reference relationship does not guarantee the existence of the target, nor does it guarantee the target type as specified in the relationship declaration. This means that the reference relationship can become dangling. The reference relationship can refer to an Item in another data store. A reference relationship can be considered as a concept similar to a link in a Web page.

  An example of a reference relationship declaration is shown below.

A reference type can be used at the target endpoint. An Item related to a reference relationship can be of any Item type.
Reference relationships are used to model most non-lifetime management relationships between Items. Since the presence of the target is not enforced, the reference relationship is convenient for modeling loosely coupled relationships. Reference relationships can be used to target Items in other data stores, including stores on other computers.

e) Rules and constraints The following additional rules and constraints apply for relationships.
1. Item must be the target of (just one embedding relationship) or (one or more holding relationships). One exception is the root item. Item can be the target of zero or more reference relationships.

    2. The Item that is the target of the embedding relation cannot be the source of the holding relation. This can be the source of a reference relationship.

    3. When an Item is upgraded from a file, it cannot be the source of a retention relationship. This can be the source of embedding and reference relationships.

    4). Items promoted from a file cannot be targeted for embedding.

f) Relationship Ordering In at least one embodiment, the storage platform of the present invention supports relationship ordering. The ordering is performed through a property named “Order” in the basic relationship definition. There is no uniqueness constraint on the Order field. The order of relationships with the same “order” property value is not guaranteed, but it is guaranteed that they can be ordered after a relationship with a low “order” value and before a relationship with a high “order” field value.

  The application can obtain relationships in a predetermined order by ordering combinations (SourceItemID, RelationshipID, Order). All relationship instances that are sourced from a given Item are ordered as a single collection, regardless of the type of relationship within that collection. However, this ensures that all relationships of a given type (eg, FolderMembers) are an ordered subset of the relationship collection for a given Item.

The data store API 312 for manipulating relationships implements a set of operations that support relationship ordering. The following terms are introduced as an aid to describing operations.
RelFirst is the first relationship in the ordered collection with the order value OrdFirst.
RelLast is the last relationship in the ordered collection with the order value OrdLast.
RelX is a given relationship in the collection with the order value OrdX.

RelPrev is the closest relationship with RelX in the collection where the order value OrdPrev is smaller than OrdX.
RelNext is the closest relationship with RelX in the collection where the order value OrdNext is greater than OrdX.
InsertBeforeFirst (SourceItemID, Relationship)
Insert the relationship as the first relationship into the collection. The value of the “Order” property of the new relationship may be less than OrdFirst.
InsertAfterLast (SourceItemID, Relationship)
Insert the relationship into the collection as the last relationship. The value of the “Order” property of the new relationship may be greater than OrdLast.
InsertAt (SourceItemID, ord, Relationship)
Insert a relationship with the specified value for the “Order” property.
InsertBefore (SourceItemID, ord, Relationship)
Insert a relation before a relation with a given order value. The new relationship can be assigned an “Order” value between, but not including, OrdPrev and ord.
InsertAfter (SourceItemID, ord, Relationship)
Insert a relationship after a relationship with a given order value. The new relationship can be assigned an “Order” value between ord and OrdNext, but not including.
MoveBefore (SourceItemID, ord, RelationshipID)
Moves the relationship with the given relationship ID before the relationship with the specified “Order” value. This relationship can be assigned a new “Order” value between, but not including, OrdPrev and ord.
MoveAfter (SourceItemID, ord, RelationshipID)
Move the relationship with the given relationship ID after the relationship with the specified “Order” value. This relationship can be assigned a new order value between ord and OrdNext, but not including.

  As already mentioned, every Item must be a member of Item Folder. With respect to Relationships, every Item must have a relationship with Item Folder. In some embodiments of the invention, specific relationships are represented by Relationships that exist between Items.

  As implemented in various embodiments of the present invention, Relationship provides a directed binary relationship that is “extended” by one Item (source) to the other Item (target). A Relationship is owned by a source Item (an Item that extends it), and thus a Relationship is deleted when the source is deleted (eg, a Relationship is deleted when the source Item is deleted). In addition, in some instances, Relationships can share (jointly own) ownership of the target Item, and such ownership is reflected in the Relationship's IsOwned property (or its equivalent). Is possible (as shown for the Relationship property type in FIG. 7). In these embodiments, creating a new IsOwned Relationship will automatically increment the reference count of the target Item, and deleting such a Relationship will decrement the reference count of the target Item. In these particular embodiments, the Item will continue to exist if the reference count is greater than zero and will be automatically deleted when the count reaches zero. Again, the Item Folder is an Item that has (or can have) a set of Relationships with other Items, and these other Items contain Item Folder membership. Other actual implementations of Relationships are possible, and it is anticipated that the present invention will provide the functionality described herein.

Regardless of the actual implementation, Relationship is a selectable connection from one object to the other. An Item can belong to more than one Item Folder, and can belong to one or more Categories, and whether these Items, Folders, and Categories are public or private Determined by the meaning given to being present (or absent). These logical Relationships are the meanings assigned to the set of Relationships that are specifically employed to implement the functions described herein, regardless of the physical implementation. Logical Relationships are established between an Item and its Item Folder (s) or Categories (and vice versa), because essentially Item Folders and Categories are each a special type of Item. It is. Thus, Item Folders and Categories can act in the same way as other Items—but not limited to, but can be copied, added to an email message, embedded in a document, etc., and Item Folders and Categories can receive In contrast, serialization and deserialization (import and export) can be performed using the same mechanism as for other Items. (For example, in XML, every Item can have a serialized format, which applies equally to Item Folders, Categories, and Items.)
The aforementioned Relationships represent the relationship between an Item and its Item Folder (s), but can be logically extended from Item to Item Folder, from Item Folder to Item, or both. Relationship that logically extends from Item to Item Folder indicates that Item Folder is public to that Item and shares attribution information with that Item, but conversely, from Item to Item Folder logically The absence of Relationship indicates that the Item Folder is private to the Item and does not share attribution information with the Item. Similarly, a Relationship that logically extends from Item Folder to Item indicates that the Item is public and sharable to the Item Folder, but there is no logical Relationship from Item Folder to Item. The item is private and can be shared. Thus, an Item Folder is a “public” Item that is shared in a new context when exported to other systems, and if an Item searches for other sharable Items within that Item Folder, it belongs to “Public” Item Folders that supply information about Items to Items.

  FIG. 9 is a block diagram illustrating Item Folder (which is also Item itself), its Member Item, and the interconnection Relationships between Item Folder and its Member Item. The Item Folder 900 has a plurality of Items 902, 904, and 906 as members. Item Folder 900 is an Item 902 that is public and Item Folder 900, its members 904 and 906, and other Item Folders, Categories, or Items (not shown) that may access Item Folder 900. It has a Relationship 912 from itself to Item 902 indicating that it can be shared. However, there is no Relationship from Item 902 to Item Folder 900 indicating that Item Folder 900 is private to Item 902 and does not share attribution information with Item 902. On the other hand, Item 904 has a Relationship 924 from itself to Item Folder 900 indicating that Item Folder 900 is public and shares attribution information with Item 904. However, Item 904 is private and Item Folder 900, its other members 902 and 906, and other Item Folders, Categories, or Items that may access Item Folder 900 (not shown) There is no Relationship from Item Folder 900 to Item 904, which indicates that it cannot be shared. In contrast to its Relationships to Items 902 and 904 (or their absence), Item Folder 900 has a Relationship 916 from itself to Item 906 and Item 906 has a Relationship 926 that returns to Item Folder 900. Together, Item 906 is public, Item Folder 900, its members 902 and 904, and other Item Folders, Categories, or Items that may access Item Folder 900 (not shown) ) Can be shared, and Item Folder 900 is public and belongs to Item 906 Indicating to share engagement information.

  As already explained, the Items in the Item Folder do not need to share commonality because the Item Folders are not “described”. On the other hand, Categories are described by a commonality common to all of its member Items. Thus, Category membership is inherently limited to Items with the described commonality, and in some embodiments, all Items that meet the Category description are automatically made members of Category. . Thus, in Item Folders, a trivial type structure can be represented by its membership, but in Categories, membership can be based on predefined commonality.

  Of course, the Category description is logical in nature, and thus the Category can be described by a logical representation of types, properties, and / or values. For example, the logical representation of Category may be that the attribution relationship including Item has one or both of two properties. If these described properties for Category are “A” and “B”, the Category membership is an Item with property A but no B, Item with property B but no A, and property A and Items with both B can be included. This logical expression of the property is described by the logical operator “OR”, and the set of members described by the Category is an Item having the property A OR B. Those skilled in the art will recognize that similar logical operands (including but not limited to “AND”, “XOR”, and “NOT”, alone or in combination) can also be used to describe a category. You will understand.

  Despite the distinction between Item Folders (not described) and Categories (described), Category Relationships vs. Items and Item Relationships vs. Categories are described herein for Item Folders and Items in many embodiments of the present invention. Is essentially the same as previously disclosed in the book.

  FIG. 10 is a block diagram illustrating Category (again, Item itself), its Member Item, and the interconnection Relationship between Category and its Member Item. The Category 1000 has multiple Items 1002, 1004, and 1006 as members, all of which are some combination of common properties, values, or types 1008 as described by the Category 1000 (Commonality Description 1008 ') Share Category 1000 is shared to Item 1000, Item Folders, or Items (not shown) that Item 1002 is public and has access to Category 1000, its members 1004 and 1006, and Category 1000 It has a Relationship 1012 from itself to Item 1002, indicating that it is possible. However, there is no Relationship from Item 1002 to Category 1000 indicating that Category 1000 is private to Item 1002 and does not share attribution information with Item 1002. On the other hand, Item 1004 has Relationship 1024 from itself to Category 1000 indicating that Category 1000 is public and shares attribution information with Item 1004. However, for Item 1004 is private and for Category 1000, its other members 1002 and 1006, and other Categories, Item Folders, or Items (not shown) that may access Category 1000 There is no Relationship from Category 1000 to Item 1004 indicating that it is not sharable. In contrast to its Relationships for Items 1002 and 1004 (or the absence thereof), Category 1000 has a Relationship 1016 from itself to Item 1006, and Item 1006 has a Relationship 1026 back to Category 1000, which is In addition, for Item 1006 is public and for Category 1000, its Item members 1002 and 1004, and other Categories, Item Folders, or Items (not shown) that may access Category 1000 Shareable and Category 1000 is public and Item 1 06 to represent to share membership information.

  Finally, in some other embodiments, Categories and Item Folders are themselves Items, so Items have a Relationship to each other, Categories have a Relationship to Item Folders and vice versa, and Categories Folds. , And Items can have Relationships to other Categories, Item Folders, and Items, respectively. However, in various embodiments, the Item Folder structure and / or Category structure is prohibited from including cycles at the hardware / software interface system level. The Item Folder and Category structures are similar to valid graphs, and the embodiment that prohibits cycles is a directed graph in which no path starts and ends at the same vertex, due to the mathematical definition of the field of graph theory. , Similar to acyclic directed graphs (DAGs).

6). Extensibility It is intended to give the storage platform an initial set of schemas (platform schema) 340 as described above. In addition, however, in at least some embodiments, the storage platform allows customers, including independent software vendors (ISVs), to create new schemas 344 (ie, new Item and Nested Element types). This section describes a mechanism for creating such a schema by extending the Item and Nested Element types (or simply the “Element” type) defined in the initial set of schemas (platform schemas) 340. Take up.

The expansion of the initial set of Item and Nested Element types is preferably constrained as follows.
ISV is a new Item type, that is, a child type Base. It is allowed to introduce Item.
The ISV is a new nested element type, that is, a child type Base. It is allowed to introduce a nested element.
ISV is a new extension, that is, a child Base. It is allowed to introduce a nested element. But,
An ISV cannot subtype a type (Item, Nested Element, or Extension type) defined by an initial set of storage platform schema (platform schema) 340.

  The Item type or Nested Element type defined by the initial set of storage platform schemas may not exactly match the requirements of the ISV application, so the ISV side needs to be able to customize the type. This is possible with the concept of Extensions. Extensions are strongly typed instances, but (a) they cannot exist independently and (b) must accompany an Item or a Necessary Element.

  In addition to meeting the need for schema extensibility, Extensions are also intended to solve the “multi-typing” problem. In some embodiments, the storage platform may not support multiple inheritance or duplicate types, so Applications can use Extensions as a way to model duplicate instances (eg, Document is both a legal document and a security document).

a) Item Extension In order to perform Item extension, the data model further includes Base. Define an abstract type named Extension. This is the root type for the extended type hierarchy. In the application, Base. Extensions can be subtyped to create specific extensions.

  Base. The Extension type is defined by Base schema as follows.

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

The extended type structure is similar to the item type structure.
Extended types have fields.
Fields can be primitive or nested element types.
Extended types can be subtyped.

The following constraints apply to extended types:
An extension cannot be the source and target of a relationship.
An extended instance cannot exist independently of an item.
Extended types cannot be used as field types in storage platform type definitions.

There are no restrictions on the type of extension associated with a given Item type. Any extension type can be used to extend the item type. When multiple extension instances are attached to an item, they are independent of each other in both structure and behavior.
Multiple extension instances are stored and accessed separately from the item. All extended type instances are accessible from the global extended view. You can create an efficient query that returns all instances of a given extension type, regardless of the type of the associated item. The storage platform API provides a programming model that can store, retrieve, and modify extensions on items.

Extended types can be subtyped using the storage platform's single inheritance model. Deriving from an extension type creates a new extension type. An extension structure or behavior cannot override or replace an item type hierarchy structure or behavior.
Similar to the Item type, the Extension type instance can be accessed directly through the view associated with the extension type. The extension's ItemID indicates which item it belongs to and can be used to retrieve the corresponding Item object from the global Item view.
Extensions are considered part of an item for behavioral consistency. Copy / Move, Backup / Restore, and other common operations defined by the storage platform can operate on extensions as part of that item.

  Consider the following example: The Contact type is defined in the Windows (registered trademark) Type setting.

  CRM application developers want to attach CRM application extensions to contacts stored in the storage platform. Application developers define CRM extensions that contain additional data structures that can be manipulated on the application side.

  The HR application developer also wants to attach additional data to the Contact. This data is independent of the CRM application data. Again, this application developer can create an extension.

CRMExtension and HRExtension are two independent extensions that can be attached to a Contact item. These are created and accessed independently of each other.
In the above example, CRMExtension type fields and methods cannot override fields or methods in the Contact hierarchy. An instance of the CRMExtension type can be attached to an Item type other than Contact.

When a Contact item is retrieved, the item extension is not automatically retrieved. Given a Contact item, the associated item extension can be accessed by querying the global extension view of the extension with the same ItemId.
All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of which item they belong to. All item extensions for an item share the same item id. In the above example, the Contact item instance and the accompanying CRMExtension and HRExtension instantiate the same ItemID.

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

b) Extension of the NestedElement type The NestedElement type is not extended by the same mechanism as the Item type. Nested element extensions are stored and accessed by the same mechanism as nested element type fields.

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

  The NecessaryElement type inherits from this type. The NestedElement element type further defines a field that is a multiple set of Elements.

The nested element extension differs from the item extension in the following points.
Nested element extensions are not extension types. They are based on Base. It does not belong to the extended type hierarchy whose root is the Extension type.
Nested element extensions are stored with the other fields of the item and are not globally accessible—you cannot create a query that retrieves all instances of a given extension type.

These extensions are stored in the same way that other (item) nested elements are stored. Like other nested sets, NestedElement extensions are stored in the UDT. These are accessible through the Extensions field of the nested element type.
The collection interface used to access multi-valued properties is also used to access and iterate over a set of type extensions.

  The following table is a summary and comparison of Item Extensions and NestedElement extensions.

D. Database Engine As described above, the data store is implemented on the database engine. In the present invention, the database engine includes a relational database engine that implements an SQL query language, such as Microsoft SQL Server, along with object-relational extensions. This section describes the mapping of the data model implemented by the data store to the relational store, and also provides information about the logical API used by the storage platform client according to the present invention. However, it will be appreciated that different mappings can be employed when different database engines are used. Indeed, in addition to implementing the storage platform conceptual data model on a relational database engine, it can also be implemented on other types of databases, such as object-oriented and XML databases.

  An object oriented (OO) database system provides persistence and transactions for programming language objects (eg, C ++, Java). The concept of “items” in the storage platform maps well to “objects” in object-oriented systems, but embedded collections will have to be added to objects. Other storage platform type concepts, such as inherited and nested element types, also map object-oriented systems. Object-oriented systems typically already support object identification, so item identification can be mapped to object identification. Item behaviors (operations) map nicely to object methods. However, an object-oriented system usually lacks functions related to organization and has poor search capability. Also, object oriented systems do not support unstructured and semi-structured data. To support the full storage platform data model described herein, concepts such as relationships, folders, and extensions will need to be added to the object data model. In addition, mechanisms such as promotions, synchronization, notifications, and security will also need to be implemented.

  Similar to object-oriented systems, XML databases are based on XSD (XML Schema Definition) and support a single inheritance based type system. The item type system of the present invention can also be mapped to an XSD type model. XSD also does not support behaviors. The XSD for an item will have to be augmented by an item behavior. An XML database handles a single XSD document and lacks organization and extensive search capabilities. As with object-oriented databases, other concepts such as relationships and folders need to be incorporated into such XML databases to support the data model described herein, Mechanisms such as notifications and security also need to be implemented.

1. Implementing a Data Store Using UDT In an embodiment of the invention, the relational database engine 314, which in one embodiment includes the Microsoft SQL Server engine, supports a built-in scalar type. The built-in scalar types are “native” and “simple”. They are native in that users cannot define their own types and are simple in that they cannot encapsulate composite structures. User-defined types (hereafter UDT) are above and beyond the native scalar type system by allowing users to extend the type system by defining complex structured types. Provides a mechanism for type extensibility. Once the UDT has been defined by the user, it can be used anywhere the built-in scalar type can be used in the type system.

  According to one aspect of the invention, the storage platform schema is mapped to a UDT class in the database engine store. The data store Item is Base. Maps to a UDT class derived from the Item type. Like Items, Extensions are also mapped to UDT classes and use inheritance. The root extension type is Base. Extension, from which all Extension types are derived.

  UDT is a CLR class-it has a state (ie, a data field) and a behavior (ie, a routine). UDT is a managed language-C #, VB. It is defined using NET etc. UDT methods and operators can be called in T-SQL on instances of that type. The UDT can be a type of one column in a row, a parameter type of a T-SQL routine, or a variable type of a T-SQL.

  The following examples illustrate the basics of UDT. MapLib. Assume that dll has an assembly called MapLib. In this assembly, there is a class called Point under the namespace BaseTypes.

  The following T-SQL code binds the class Point to an SQL Server UDT called Point. The first step calls “CreateAssembly”, which loads the MapLib assembly into the database. In the second step, “Create Type” is called to create a user-defined type “Point”, and the managed type BaseTypes. Bind to Point.

  Once created, the “Point” UDT can be used as a column in the table, and the method can be called in T-SQL as shown below.

  Mapping storage platform schema to UDT classes is fairly easy at a high level. In general, the storage platform Schema is mapped to the CLR namespace. The storage platform Type is mapped to the CLR class. The CLR class inheritance reflects the storage platform Type inheritance, and the storage platform Property is mapped to the CLR class property.

  The Item hierarchy illustrated in FIG. 29 is used herein as an example. This is based on Base., Which is the derivation source of all Item types. Item types are shown with a set of derived Item types (eg, Contact.Person and Contact.Employee), and inheritance is indicated by arrows.

2. Item Mapping It is desirable that Items be globally searchable, and with the relational database support of the present invention for inheritance and type substitutability, one possible implementation of Item storage in a database store is all Item of type Base. It is stored in a single table that contains a column of Items. Using type substitutability, it is possible to store items of all types, and use Yukon's “is of (Type)” operator to filter searches by Item and child types Is possible.

  However, in the present invention, due to the overhead concerns associated with such an approach, the Items are divided by the top-level type, and the “family” items of each type are stored in separate tables. . According to this partitioning scheme, Base. One table is created for each Item type that directly inherits from Item. These lower type inheritances are stored in the appropriate type family table using type substitutability as described above. Base. Only the first level of inheritance from Item is specially handled. For example, in the Item hierarchy shown in FIG. 29, the following type family table is obtained as a result.

  A “shadow” table is used to store a globally searchable copy of the properties for all Items. This table can be maintained by the Update () method of the storage platform API that is used when all data changes are made. Unlike type family tables, global Item tables contain only the top-level scalar properties of Items, not complete UDT Item objects. The structure of the global Item table is as follows.

  In the global Item table, it is possible to navigate to the Item object stored in the type family table by publishing the ItemID and TypeID. The ItemID generally uniquely identifies the Item in the data store. A TypeID can be mapped to a view that includes a type name and an Item using metadata not described here.

Finding an Item by its ItemID is a normal operation, and in the context of both the global Item table and some other means, there is a GetItem () function that retrieves an Item object when the ItemID of the Item is specified. . This function has the following declaration:
Base.Item Base.GetItem (uniqueidentifier ItemID)

  In order to simplify access and hide implementation details as much as possible, all queries of an Item can be made against views built on the Item table described above. In particular, a view can be created for each Item type against the corresponding type table. In these type views, all Items of the associated type, including child types, can be selected. For convenience, in addition to UDT objects, those views can expose columns for all of the top-level fields of that type, including inherited fields. The view of the Item hierarchy example shown in FIG. 29 is as follows.

  A view can also be created on the global Item table for completeness. This view can initially expose the same columns as the table.

3. Extension Mapping Extensions are very similar to Items and have some of the same requirements. As another root type that supports inheritance, Extensions are subject to many of the same storage considerations and tradeoffs. For this reason, the similar type family mapping is not a single table approach, but rather applies to Extensions. Of course, in other embodiments, a single table approach can be used.

  In an embodiment of the present invention, an Extension is associated with exactly one Item by ItemID and includes an ExtensionID that is unique in the context of the Item. The Extension table has the following definitions.

  As in the case of Item, it is possible to prepare a function that extracts an extension given an identification, which is a pair of ItemID and ExtensionID. This function has the following declaration:

  A View is created for each Extension type and is similar to an Item type view. Base. Extension, Contact. PersonExtension, Contact. Assume an Extension hierarchy that has a type of EmployeeExtension and is parallel to the Item hierarchy example. You can create the following views:

4). Nested Element Mappings Nested Elements is a type that can be embedded within Items, Extensions, Relationships, or other Nested Elements to form deeply nested structures. Like Items and Extensions, Nested Elements are implemented as UDTs, but are stored within Items and Extensions. Thus, a nested element has no storage mapping beyond its Item and Extension containers. In other words, there is no table in the system that directly stores a nested element type instance, and there is no view dedicated to nested elements.

5). Object identification (Identity)
Each entity in the data model, ie, each Item, Extension, and Relationship, has a unique key value. Item is uniquely identified by ItemID. Extension is uniquely identified by a composite key of (ItemId, ExtensionId). The Relationship is identified by a composite key (ItemId, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.

6). SQL Object Naming Conventions All objects created in the data store can be stored with a SQL schema name derived from the storage platform schema name. For example, a storage platform Base schema (often referred to as “Base”) can generate a type with a “[System.Storage]” SQL schema such as “[System.Storage] .Item”. The generated name is prefixed with a qualifier to eliminate naming conflicts. Where appropriate, exclamation points (!) Are used as dividers for each logical part of the name. The following table outlines the naming convention used for objects in the data store. Each schema element (Item, Extension, Relationship, and View) is listed with a decorated naming convention used to access instances in the data store.

7). Column naming conventions When mapping an object model to a store, additional information is stored with the application object, which can lead to naming conflicts. To avoid naming conflicts, an underscore (_) character is prepended to all non-type specific columns (columns that are not directly mapped to named properties in the type declaration). In the embodiment of the present invention, the underscore (_) character is prohibited as the first character of the identifier property. In addition, all properties of storage platform types or schema elements (such as relationships) must be capitalized in order to unify naming between CLRs and data stores.

8). Search view A view is provided by the storage platform to search stored content. SQL views are prepared for each Item and Extension type. In addition, views are also provided to support Relationships and Views (as defined in the Data Model). All SQL views and underlying tables in the storage platform are read-only. Data can be stored or modified using the Update () method of the storage platform API, as described in detail below.

  Each view that is explicitly defined in the storage platform schema (defined by the schema designer and not automatically generated by the storage platform) is named SQL view [<schema-name>]. [View! <View-name>] is accessible. For example, a view named “BookSales” in the schema “AccumPublisher.Books” is accessible using the name “[AcmePublisher.Books]. [View! BookSales]”. Since the view output format can vary from view to view (defined by any query provided by the party defining the view), the columns are mapped directly based on the schema view definition.

All SQL search views in the storage platform data store use the following ordering rules for the columns:
1. ItemId, ElementId, RelationshipId,. . . The logical “key” column of view results such as
2. Metadata information about the result type, such as TypeId.
3. CreateVersion, UpdateVersion,. . . Change tracking columns such as
4). (Multiple) type-specific columns (property of declared type)
5). Type-specific views (family views) also contain object columns that return objects.

  Members of each type family can be searched using a series of Item views, with one view for each Item type in the data store.

a) Items Each Item search view contains one row for each instance of an item of a particular type or its child types. For example, a view for Document can return an instance of Document, LegalDocument, and ReviewDocument. In this example, the Item view can be conceptualized as shown in FIG.

(1) Master Item Search View Each instance of the storage platform data store defines a special Item view called the Master Item View. This view shows summary information about each Item in the data store. The view shows one column for each Item type property, which describes the Item and multiple column types that are used to provide change tracking and synchronization information. The master item view is identified in the data store using the name “[System.Storage]. [Master! Item]”.

(2) Typed item search view Each Item type further has a search view. Similar to the root Item view, but this view can also access Item objects via the “_Item” column. Each typed item search view has a name [schemaName]. Identified in the data store using [itemTypeName]. For example, [Acme Corp. Doc]. [OfficeDoc].

b) Item Extensions All Item Extensions in the WinFS Store can also be accessed using a search view.

(1) Master Extended Search View Each instance of the data store defines a special Extension view called the Master Extension View. This view shows summary information about each Extension in the data store. The view has one column for each Extension property, which describes the Extension and the types of columns used to provide change tracking and synchronization information. The master extended view is identified in the data store using the name “[System.Storage]. [Master! Extension]”.

(2) Typed Extended Search View Each Extension type further has a search view. Similar to the master extended view, but this view can also access Item objects via the _Extension column. Each typed extended search view has the name [schemaName]. [Extension! It is identified in the data store using extensionTypeName]. For example, [Acme Corp. Doc]. [Extension! OfficeDocExt].

c) Nested elements All nested elements are stored in an Item, Extensions, or Relationship instance. Thus, these are accessed by querying the appropriate Item, Extension, or Relationship probation view.

d) Relationships As mentioned above, Relationships form the basic unit of linking between Items within the storage platform data store.

(1) Master Relationship Search View Each data store provides a Master Relationship View. This view shows information about all relationship instances in the data store. The master relationship view is identified in the data store using the name “[System.Storage]. [Master! Relationship]”.

(2) Relationship Instance Search View Each declared Relationship further has a search view that returns all instances of a particular relationship. Similar to the master relationship view, but this view also shows a named column for each property of the relationship data. Each relationship instance search view has a name [schemaName]. [Relationship! relationName] is identified in the data store. For example, [Acme Corp. Doc]. [Relationship! DocumentAuthor].

9. Update All views in the storage platform data store are read-only. To create a new instance of a data model element (item, extension, or relationship) or update an existing instance, the ProcessOperation or ProcessUpdategram method of the storage platform API must be used. The ProcessOperation method is a single stored procedure defined by the data store that consumes the “operation” that determines the details of the action to be performed. The ProcessUpdategram method is a stored procedure that receives an ordered set of operations called an “updategram” that comprehensively determines the details of the set of actions to be performed.

The operation format is extensible and provides various operations for schema elements. Common operations include the following.
1. Item operations:
a. CreateItem (creates a new item in the context of an embedding or holding relationship)
b. UpdateItem (updates an existing Item)
2. Relationship operation:
a. CreateRelationship (create a reference or retention relationship instance)
b. UpdateRelationship (update relationship instance)
c. DeleteRelationship (delete relationship instance)
3. Extension operation:
a. CreateExtension (adds an extension to an existing Item)
b. UpdateExtension (updates an existing extension)
c. DeleteExtension (delete extension)

10. Change Tracking & Tombstone Change tracking and tombstone services are provided by the data store as detailed below. This section outlines the change tracking information published in the data store.

a) Change Tracking Each search view provided by the data store includes columns that are used to provide change tracking information, and these columns are common across all Item, Extension, and Relationship views. The storage platform's Schema Views is explicitly defined by the schema designer and does not automatically supply change tracking information-such information is supplied indirectly through the search view on which the view itself is built. .

  For each element in the data store, change tracking information is available from two locations—a “master” element view and a “typed” element view. For example, Acme Corp. Document. The change tracking information for the Document Item type includes the master item view “[System.Storage]. [Master! Item]” and the typed item search view [AcmeCorp. Document]. Available from [Document].

(1) Change tracking in the “master” search view The change tracking information in the master search view includes information about the creation and update version of the element, information about the synchronization partner that created the element, and information about the synchronization partner that last updated the element. And the version number from each partner for creation and update. Partners (described later) that are in a synchronous relationship are identified by a partner key. Type [System. Storage. Store]. A single UDT object named _ChangeTrackingInfo in ChangeTrackingInfo stores this information. This type is described in System. It is defined in the Storage schema. _ChangeTrackingInfo is available in all global search debuts for Items, Extensions, and Relationships. The type definition of ChangeTrackingInfo is as follows.

  These properties include the following information:

(2) Change tracking in “typed” search views In addition to providing the same information as the global search views, each typed search view has additional information that records the synchronization status of each element in the synchronization topology. Supply.

b) Tombstone Datastore provides Item, Extensions, and Relationships tombstone information. The tombstone view shows information about both live and tombstoned entities (items, extensions, and relationships) at a location. Item and extended tombstone views do not have access to the corresponding object, but relationship tombstone views have access to the relationship object (the relationship object is NULL for tombstone state relationships) .

(1) Item Tombstone Item Tombstone is a view [System. Storage]. [Tombstone! It is retrieved from the system via [Item].

(2) Extended Tombstone Extended Tombstone is a view [System. Storage]. [Tombstone! It is retrieved from the system using Extension. Extended change tracking information is similar to the information provided for an Item that includes the addition of an ExtensionId property.

(3) Relation Tombstone Relation Tombstone is a view [System. Storage]. [Tombstone! Retrieved from the system via Relationship. The related tombstone information is similar to the information given for Extensions. However, additional information is given on the target ItemRef of the relationship instance. In addition, related objects are also selected.

(4) Tombstone cleanup To prevent endless proliferation of tombstone information, the data store provides a tombstone cleanup task. This task determines when tombstone information can be discarded. This task calculates the limits for the local create / update version and then truncates the tombstone information by discarding all old tombstone versions.

11. Helper APIs and Functions Base mapping also includes a number of helper functions. These functions are provided to assist common operations on the data model.
a) Function [System. Storage]. GetItem
Returns an Item object given ItemId.
//
Item GetItem (ItemId ItemId)
b) Function [System. Storage]. GetExtension
// Returns an extension object given ItemId and ExtensionId. //
Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId)
c) Function [System. Storage]. GetRelationship
// Returns a relationship object given ItemId and RelationshipId.
//
Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)

12 There are two types of metadata represented in the metadata store: instance metadata (such as Item types) and type metadata.
a) Schema metadata Schema metadata is stored in the data store as an Item type instance from the Meta schema.
b) Instance metadata Instance metadata is used by an application to query for the type of Item, thereby finding the extension associated with the Item. Given an ItemId for the Item, the application queries the global item view to return the Item type and uses this value to get the Meta. Queries the Type view and returns information about the declared type of the Item. For example:

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

1. Overview According to embodiments of the present invention, the accuracy with which a storage platform security policy is specified and enforced is at various levels of operation on items in a given data store, securing a portion of an item separately from the whole. There is no function. The security model specifies a collection of principals that can grant or deny someone access to perform these operations on items through an access control list (ACL). Each ACL is an ordered collection of access control entries (ACE).

  Item security policies can be completely described by discretionary access control policies and system access control policies. Each of these is a set of ACLs. The first set (DACL) describes discretionary access rights granted to various principals by the owner of the item, while the second set of ACLs is called SACL (System Access Control List), Specifies how system auditing is performed when an object is manipulated in several ways. In addition to these, each item in the data store is associated with an SID (Owner SID) corresponding to the owner of the item.

  The primary mechanism for organizing items within the storage platform data store is the containment hierarchy mechanism. The containment hierarchy is implemented using retention relationships between items. Due to the holding relationship between the two items A and B represented as “A contains B”, item A can affect the lifetime of item B. In general, an item in a data store cannot exist while there is a retention relationship to the item from another item. In addition to controlling the lifetime of the item, the retention relationship also provides the necessary mechanisms to propagate the item's security policy.

  The security policy specified for each item consists of two parts: the part explicitly specified for the item and the part inherited from the item's parent in the data store. An explicitly defined security policy for an item consists of two parts: a part that manages access to the item under consideration and a part that affects the security policy inherited by all descendants in the containment hierarchy. Security policies inherited by descendants vary depending on explicitly defined policies and inherited policies.

  Since security policies are propagated through retention relationships and can be overridden at any item, it is necessary to specify how an effective security policy for an item is determined. In an embodiment of the invention, an item in a data store containment hierarchy inherits ACLs along all paths from the store root to the item.

  Within the ACL inherited for a given path, the ordering of the various ACEs in the ACL determines the final security policy that is enforced. The following annotations are used to describe the ordering of ACEs in the ACL. The ordering of ACEs in ACLs inherited by items is determined by the following two rules.

The first rule stratifies the ACE inherited from various items in the path from the root of the containment hierarchy to item I. An ACE inherited from a near container takes precedence over an entry inherited from a far container. Intuitively, this allows the administrator to override ACEs that are inherited from farther up in the containment hierarchy. The rules are as follows:
For all inherited ACLs on item I For all items I1, I2 For all ACEs A1 and A2 in L I1 is an ancestor of I2
I2 is the ancestor of I3,
A1 is an ACE inherited from I1,
If A2 is an ACE inherited from I2,
A2 precedes A1 in L

The second rule orders ACEs that deny access to items ahead of ACEs that allow access to items.
For all inherited ACLs on item I For all items I1 For all ACEs A1 and A2 in L I1 is an ancestor of I2
A1 is ACCESS_DENIED_ACE inherited from I1,
If A2 is ACCESS_GRANTED_ACE inherited from I1,
A1 precedes A2 in L

  If the containment hierarchy is a tree, there is exactly one path from the root of the tree to the item, and that item has exactly one inherited ACL. Under these circumstances, the ACL inherited by the item matches the ACL inherited by the file (item) in the existing Windows security model with respect to the relative ordering of the ACEs contained within.

  However, the containment hierarchy in the data store is an acyclic directed graph (DAG) because multiple retention relationships are allowed for items. Under these conditions, there are multiple paths from the root of the containment hierarchy to the item. Since items inherit ACLs along all paths, each item is associated with a collection of ACLs, rather than a single ACL. Note that, unlike the traditional file system model, exactly one ACL is associated with one file or folder.

  Contrary to the tree, there are two aspects that need to be detailed when the containment hierarchy is DAG. It is necessary to explain how to calculate the effective security policy for an item when inheriting multiple ACLs from a parent, and how to organize and express how to manage the security model of the storage platform data store Direct influence.

The following algorithm evaluates the access rights of a given principal for a given item. Throughout this specification, the following notation will be used to describe the ACL associated with an item.
Inherited_ACLs (ItemId) —A set of ACLs inherited by items whose item ID is ItemId from the parent in the store.
Explict_ACL (ItemId) —ACL explicitly defined for an item whose ID is ItemId.

  The routine returns STATUS_SUCCESS if the desired access has not been explicitly denied, and pGrantedAccess determines which of the rights the user wants granted by the specified ACL. If the desired access right is explicitly denied, the routine returns STATUS_ACCESS_DENIED.

  The scope of security policy defined on any item includes all descendants of the item in the containment hierarchy defined on the data store. For all items for which an explicit policy is defined, here we define a policy that is inherited by virtually all descendants in the containment hierarchy. A valid ACL inherited by all descendants is obtained by taking each ACL inherited by the item and adding the inheritable ACE in the explicit ACL to the beginning of the ACL. This is called the inheritable set of ACLs associated with the item.

  If there is no explicit specification of security in the containment hierarchy rooted at a folder item, the security specification for that folder applies to all descendants of that item in the containment hierarchy. Thus, every item given an explicit security policy specification defines an area of the item that is protected in exactly the same way, and a valid ACL for all items within that area is inheritable for that item. It is a set of ACLs. This completely defines the region in the case of an inclusion hierarchy that is a tree. If a number is associated with each region, it would be sufficient to simply include the region to which the item belongs along with the item.

  However, in an inclusion hierarchy that is a DAG, the point of the inclusion hierarchy where the effective security policy changes is determined by two types of items. The first is an item for which an explicit ACL is specified. These are usually points in the containment hierarchy where the administrator has explicitly specified the ACL. The second is an item with multiple parents, which have different security policies associated with them. Typically these are items that are the confluence of the security policies specified for the volume, indicating the start of a new security policy.

  With this definition, all items in the data store are classified into one of two categories, one that is the root of the security realm that is protected in exactly the same way, and one that is not. Items that do not define a security domain belong to exactly one security domain. As in the case of a tree, effective security for an item can be specified by specifying the area to which the item belongs together with the item. This provides a simple model for managing the storage platform data store security based on various exactly the same protected areas in the store.

2. Detailed Description of the Security Model This section details how to secure items by describing how individual rights in the security descriptor and the included ACLs affect various operations.

a) Security descriptor structure Before explaining the details of the security model, it is useful to explain the basics of security descriptors. The security descriptor includes security information associated with the security configurable object. A security descriptor consists of a SECURITY_DESCRIPTOR structure and its associated security information. The security descriptor can include the following security information.
1. The SID for the object owner and primary group.
2. DACL that specifies the access rights that are allowed or denied for a particular user or group.
3. A SACL that specifies the type of access attempt that generates an audit record for the object.
4). A set of control bits that limit the meaning of a security descriptor or its individual members.

  The application preferably cannot directly manipulate the contents of the security descriptor. There are functions for setting and retrieving security information in an object's security descriptor. In addition, there are functions that create and initialize security descriptors for new objects.

  The discretionary access control list (DACL) identifies the trustees who are permitted or denied access to the security configurable object. When a process attempts to access a security-configurable object, the system checks the ACE in the object's DACL to determine whether to grant access to it. If the object does not have DACL, the system grants full access to everyone. If the object's DACL does not have ACE, the system rejects all attempts to access the object because DACL does not grant access. The system will check the ACEs in order until it finds one or more ACEs that grant all the requested access rights or until any of the requested access rights are denied.

  A system access control list (SACL) allows an administrator to log attempts to access a secured object. Each ACE specifies the type of access attempt by a designated trustee that causes the system to generate a record in the security event log. The ACE in the SACL can generate an audit record when the access attempt is unsuccessful, successful, or both. SACL can also generate an alarm when an unauthorized user attempts to gain access to an object.

All types of ACE contain the following access control information:
1. A security identifier (SID) that identifies the trustee to which the ACE applies.
2. An access mask that specifies access rights controlled by the ACE.
3. A flag that indicates the ACE type.
4). A set of bit flags that determine whether a child container or object can inherit ACE from the primary object to which the ACL is attached.

  The following table summarizes the three ACE types supported by all security-configurable objects.

(1) Access mask format All security-configurable objects have their access rights set using the access mask format shown in FIG. In this format, the lower 16 bits are used for object-specific permissions, the next 7 bits are used for standard permissions, which apply to most types of objects, and the upper 4 bits are standard and object for each object type. Used to specify universal access rights that can be mapped to a specific set of rights. The ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the SACL of the object.

(2) General-purpose access right The general-purpose access right is specified by the upper 4 bits in the mask. Each type of security-configurable object maps these bits to its standard and object-specific set of access rights. For example, the file object maps the GENERIC_READ bit to READ_CONTROL and SYNCHRONIZE standard access rights, and FILE_READ_DATA, FILE_READ_EA, and FILE_READ_ATTRIBUTES object specific access rights. Other types of objects map the GENERIC_READ bit to a set of access rights appropriate for that type of object.

  Universal access rights can be used to specify the type of access required to open an object's handle. This is usually simpler than specifying all corresponding standards and specific rights. The following table summarizes the constants defined for universal access rights.

(3) Standard access rights Each type of security-configurable object has a set of access rights corresponding to operations specific to that type of object. In addition to those object-specific permissions, there is a set of standard permissions that correspond to operations common to most types of securable objects. The following table summarizes the constants defined for standard access rights.

b) Item-specific rights In the access mask structure of FIG. 26, the item-specific rights are placed in the “Object Specific Rights” section (lower 16 bits). In embodiments of the present invention, the storage platform exposes two sets of API-Win32 and storage platform API- that manage security, so file system object specific rights are the motivation for designing storage platform specific rights. It must be considered in order to apply.

(1) File and directory object specific rights Consider the following table.

  With reference to the above table, it should be noted that the file system basically distinguishes between files and directories, because the rights of files and directories overlap on the same bit. It is. The file system defines very precise rights that allow the application to control the behavior on those objects. For example, these allow the application to distinguish between Attributes (FILE_READ / WRITE_ATTRIBUTES), extended attributes (Extended Attributes), and DATA streams associated with the file.

  The goal of the storage platform security model of the present invention is to create a rights assignment model so that applications acting on data store items (Contacts, Emails, etc.) generally do not need to differentiate between attributes, extended attributes, and data streams, for example. It is to simplify. However, in the case of files and folders, fine Win32 rights are retained, and the meaning of access through the storage platform is defined so that compatibility with Win32 applications can be realized. This mapping is described with each of the item rights specified below.

  The following item rights are specified along with the associated allowable operations. Equivalent Win32 rights are also provided to support each of these item rights.

(2) WinFSItemRead
Using this right allows read access to all elements of an item, including items that are linked to the item via an embedded relationship. It is also possible to enumerate items linked to this item via a holding relationship (also called directory listing). This includes the name of the item linked through the reference relationship. This right is mapped as follows:
File:
(FILE_READ_DATA | SYNCHRONIZE)
folder:
(FILE_LIST_DIRECTORY | SYNCHRONIZE)

  This means that the security application can set WinFSItemReadData and specify the rights mask as a combination of the file rights specified above.

(3) WinFSItemReadAttributes
This right allows read access to the basic attributes of an Item, just as the file system distinguishes between basic file attributes and data streams. These basic attributes are preferably attributes arranged in the basic item from which all items are derived. This right is mapped as follows:
File:
(FILE_READ_ATTRIBUTES)
folder:
(FILE_READ_ATTRIBUTES)

(4) WinFSItemWriteAttributes
This right allows write access to the basic attributes of an Item, just as the file system distinguishes between basic file attributes and data streams. These basic attributes are preferably placed in the basic item from which all items are derived. This right is mapped as follows:
File:
(FILE_WRITE_ATTRIBUTES)
folder:
(FILE_WRITE_ATTRIBUTES)

(5) WinFSitemWrite
Using this right allows write access to all elements of an item, including items that are linked to the item via an embedded relationship. Using this right, you can also add or delete embedded relationships to other items. This right is mapped as follows:
File:
(FILE_WRITE_DATA)
folder:
(FILE_ADD_FILE)

  In a storage platform data store, there is no difference between an item and a folder, and an item can also have a retention relationship with other items in the data store. Thus, if you have the FILE_ADD_SUBDIRECTORY (or FILE_APPEND_DATA) right, you can make an item the source of Relations with other items.

(6) WinFSitemAddLink
Using this right, you can add retention relationships to items in the store. Multiple retention Relationship security models change the security on an item, and those changes can bypass the WRITE_DAC when coming from a higher point in the hierarchy, so that you can create a Relationship with it Note that the WRITE_DAC is required on the destination item. This right is mapped as follows:
File:
(FILE_APPEND_DATA)
folder:
(FILE_ADD_SUBDIRECTORY)

(7) WinFSItemDeleteLink
With this right, the function of deleting the retained Relationship for an item can be used even if the principal is not granted the right to delete the item. This is consistent with the file system model and is useful for purging. This right is mapped as follows:
File:
(FILE_DELETE_CHILD)-The file system does not have a file corresponding to this right, but there is a concept that the item has a retention relationship with other items, so this right can be conveyed to non-folders as well .
folder:
(FILE_DELETE_CHILD)

(8) Right to delete an item When the last retention relationship with an item disappears, the item is deleted. There is no explicit concept of deleting items. There is a purge operation that deletes all retained Relationships with the item, but is a high-level function and not a system primitive.

  An item specified using a path can be unlinked: (1) the parent item along that path grants write access to that object, or (2) the item's own standard rights This is a case where one of the two conditions for granting DELETE is satisfied. If the last Relationship is deleted, the item disappears from the system. An item specified using ItemID can be unlinked when the standard right of the item itself grants DELETE.

(9) Right to copy an item An item can be copied from a source to a destination folder when the target is given a WinFSItemRead for the item and a WinFSItemWrite for the destination folder.

(10) Rights to move items File moves in the file system hold the ACL on the destination and therefore only require the DELETE right on the source file and the FILE_ADD_FILE on the destination directory. However, the flag can be specified with a MoveFileEx call (MOVEFILE_COPY_ALLOWED) that causes the application to specify that the meaning of CopyFile is acceptable in the case of cross-volume move. There are four possible options for what happens to the security descriptor when moving.
1. Carrying the entire ACL with the file-the meaning of a predefined intra-volume move.
2. The entire ACL is transported with the file and the ACL is marked as protected.
3. Only explicit ACEs are carried between destinations and re-inherited on the destination.
4). Carry nothing, re-inherit on destination-Meaning of default inter-volume move-Same as file copy.

  In the security model of the present invention, when the MOVEFILE_COPY_ALLOWED flag is specified on the application side, the fourth option is executed for both the inter volume and the intra volume. If this flag is not specified, the second option is executed unless the destination is further within the same security realm (ie, the same inheritance semantics). Storage platform level migration also implements the fourth option and requires READ_DATA on the source as in the case of copying.

(11) The right to display the security policy on an item The security of an item can be displayed when the item grants the standard right READ_CONTROL.

(12) The right to change the security policy on an item The security of an item can be changed when the item grants the standard right WRITE_DAC. However, since the data store provides implicit inheritance, this is closely related to how security changes in the hierarchy. If the root of a hierarchy grants WRITE_DAC, the rule is that the security policy is changed throughout the hierarchy regardless of whether a particular item in the hierarchy (or DAG) grants WRITE_DAC.

(13) Right without direct equivalent In the embodiment of the present invention, FILE_EXECUTE (FILE_TRAVERSE of the directory) does not have a direct equivalent in the storage platform. The model retains these for compatibility with Win32, but no access decisions are made for items based on their rights. As in the case of FILE_READ / WRITE_EA, since the data store item does not have the concept of an extended attribute, no meaning is provided for this bit. However, this bit is left for Win32 compatibility.

3. Implementation All items that define areas that are protected in exactly the same way have entries associated with them in the security table. The security table is defined as follows.

  The Item Identity entry is the item identification of the root of the security realm that is protected in exactly the same way. The Item Ordpath entry is the ordpath associated with the root of the security area that is protected in exactly the same way. The Explicit Item ACL entry is an explicit ACL defined for the root of the security domain that is protected in exactly the same way. In some cases, this can be NULL, for example, if a new security area is defined because the item has multiple parents belonging to different areas. A Path ACLs entry is a collection of ACLs inherited by an item, and a Region ACLs entry is a collection of ACLs defined for exactly the same protected security realm associated with the item.

  This table is used to calculate the effective security for items in a given store. In order to determine a security policy associated with an item, a security realm associated with the item is obtained and an ACL associated with the realm is retrieved.

  The security policy associated with an item is changed indirectly by adding an explicit ACL directly or by adding a retention relationship that will form a new security realm, thus ensuring effective security for the item. The security table is kept up-to-date to ensure that the above algorithm to be determined is a valid algorithm.

  The various changes to the store and the accompanying algorithm that maintains the security table are as follows.

a) Creating a new item in the container When an item is newly created in the container, it inherits all ACLs associated with the container. Since the newly created item has exactly one parent, it belongs to the same area as that parent. Therefore, it is not necessary to create a new entry in the security table.

b) Adding an explicit ACL to an item When an ACL is added to an item, this defines a new security realm for all descendants in the containment hierarchy that belong to the same security realm as the given item itself. For all items that belong to other security realms but are not descendants of a given item in the containment hierarchy, the security realm is not changed, but the valid ACL associated with that realm is the addition of a new ACL Is changed to reflect.

  The introduction of this new security domain can trigger further domain definitions for all items that have multiple retention relationships with ancestors that straddle the old security domain and the newly defined security domain. For all such items, a new security area needs to be defined and the procedure is repeated.

  FIGS. 27 (a), (b), and (c) show a new, exactly the same protected security area that is cut out from the existing security area by introducing a new explicit ACL. This is indicated by the node marked 2. However, as a result of introducing this new area, an additional area 3 is created because the item has a plurality of holding Relationships.

  The following series of updates in the security table reflects a factorization of the security area that is protected in exactly the same way.

c) Adding a retention relationship to an item When a retention relationship is added to an item, one of three possibilities arises. If the retention Relationship target, i.e., the item under consideration, is the root of a security realm, the effective ACL associated with that realm is changed and no further modifications need to be made to the security table. If the security area of the new retention Relationship's source is the same as the security area of the item's existing parent, no change is necessary. However, if an item does not have a parent that belongs to a different security area, a new security area is formed and the given item is held as the root of the security area. This change is propagated to all items in the containment hierarchy by modifying the security realm associated with that item. All items that belong to the same security area as the item under consideration and their descendants in the containment hierarchy need to be changed. After a change is made, all items with multiple holding Relationships must be examined to determine if further changes are needed. If any of these items have different security domain parents, further changes may be necessary.

d) Deleting a retained relationship from an item If a retained relationship is deleted from an item, the security region can be reduced along with its parent region if some conditions are met. More precisely, this means that (1) deleting a retained relationship will result in an item with one parent, and no explicit ACL is specified for that item, and (2) deleting the retained relationship will cause all parents to It can be performed under the condition that an item is in the same security realm and no explicit ACL is defined for that item. Under these circumstances, the security area can be marked to be the same as the parent. This marking must be applied to all items corresponding to the area where the security area is reduced.

e) Deleting an explicit ACL from an item When an explicit ACL is deleted from an item, it is possible to reduce the security area rooted at that item along with its parent area. More precisely, this can be done when deleting an explicit ACL results in an item whose parent in the containment hierarchy belongs to the same security realm. Under these circumstances, the security area can be marked to be the same as the parent, and the change is applied to all items corresponding to the area where the security area is reduced.

f) Modify the ACL associated with the item In this scenario, there is no need to make a new addition to the security table. The valid ACL associated with that area is updated and new ACL changes are propagated to the affected security area.

F. Notification and Change Tracking According to another aspect of the present invention, the storage platform comprises a notification function that allows an application to track data changes. This functionality is primarily for applications that maintain volatile state or execute business logic for data change events. The application registers notifications about items, item extensions, and item relationships. Notifications are sent asynchronously after the data changes are committed. On the application side, notifications can be filtered by item, extension, and relation type as well as the type of operation.

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

1. Storage Change Events This section lists some examples of using the notification interface provided by the storage platform API 322.

a) Events Item, ItemExtensions, and ItemRelationships expose data change events that are used by applications to register for data change notifications. The following code sample shows the definition of ItemModified and ItemRemoved event handlers on the base Item class.

  All notifications can carry enough data to retrieve the changed item from the data store. The following code sample shows how to register an event on Item, ItemExtension, or ItemRelationship.

  In an embodiment of the present invention, the storage platform allows an application to run when each item has been modified or deleted since the last delivery of the notification, or when there was a new registration since the last fetch from the data store. Guarantee to be notified.

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

  When creating a watcher, the application can request notification of pre-existing items, ie items, extensions, or relationships. This option is mostly for applications that maintain a private item cache. If not requested, the application receives notification of all updates that occur after the watcher object is created.

  Along with delivering the notification, the storage platform provides a “WatcherState” object. The WatcherState can be serialized and saved on disk. Each watcher can then be recreated using the watcher state after a failure or when reconnecting after going offline. The newly recreated watcher regenerates the unacknowledged notification. The application indicates delivery of the notification by calling an “Exclude” method in each watcher state that provides a reference to the notification.

  The storage platform delivers a separate copy of the watcher state to each event handler. In the watcher state received in a later call of the same event handler, it assumes delivery of all notifications that have already been received.

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

  The following code sample shows how to create a folder watcher object that monitors the contents of a folder. The watcher generates a notification or event when a new music item is added or an existing music item is updated or deleted. A folder watcher monitors a specific folder or all folders in a folder hierarchy.

2. Change Tracking and Notification Generation Mechanism The storage platform provides a simple but efficient mechanism for tracking data changes and generating notifications. The client retrieves the notification on the same connection used to retrieve the data. This greatly simplifies security checks and eliminates latency and constraints on possible network configurations. Notifications are retrieved by issuing a select statement. To prevent polling, the client can use the “waitfor” function provided by the database engine 314. FIG. 13 illustrates the basic storage platform notification concept. When this waitfor query is executed synchronously, the calling thread is blocked until a result is obtained, and when executed asynchronously, the thread is not blocked, and if the result is prepared, it is returned.

  Since changes can be monitored by setting a notification lock on each data range, the combination of “waitfor” and “select” is attractive for monitoring data changes that fall within a specific data range. This is true for many common storage platform scenarios. Changes to individual items can be efficiently monitored by setting notification locks to their respective data ranges. Changes to folders and folder trees can be monitored by setting notification locks to path ranges. Changes to a type and its child types can be monitored by setting the notification lock to the type range.

In general, notification processing involves three different phases: (1) data change or equality detection, (2) subscription matching, and (3) notification delivery. Except for synchronous notification delivery, that is, notification delivery as part of a transaction that performs data changes, the storage platform can implement two forms of notification delivery:
1) Immediate event detection: Event detection and subscription matching are performed as part of an update transaction. Notifications are inserted into a table monitored by the subscriber.
2) Delayed event detection: Event detection and subscription matching are performed after the update transaction is committed. The actual subscriber or mediator then detects the event and generates a notification.

  Immediate event detection requires additional code to be executed as part of the update operation. Thereby, it is possible to capture all events of interest including events indicating relative state changes.

  Late event detection eliminates the need to add additional code to the update operation. Event detection is performed by the ultimate subscriber. Delayed event detection, of course, batches event detection and event delivery and fits well into the query execution infrastructure of the database engine 314 (eg, SQL server).

  Late event detection relies on logs or traces left by update operations. The storage platform maintains a set of logical time stamps along with tombstones for deleted data items. When scanning the data store for changes, the client supplies a timestamp that defines a low watermark for detecting changes and a set of timestamps to prevent duplicate notifications. The application receives notification of all changes that have occurred since the time indicated by the low watermark.

  Advanced applications that have access to the core view can also optimize and reduce the number of SQL statements needed to monitor the set of items that can potentially grow by creating private parameter and duplicate filter tables. it can. Applications with special needs that must support rich views can use the available change tracking framework to monitor data changes and refresh their private snapshots.

  Accordingly, in one embodiment, the storage platform preferably implements a delayed event detection approach, as described in more detail below.

a) Change Tracking All item, extension, and item relationship definitions carry a unique identifier. Change tracking maintains a set of logical timestamps that record the creation, update, and deletion times of all data items. Tombstone entries are used to represent deleted data items.

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

  All deleted items, item extensions, and relationships are recorded in the corresponding tombstone table. The template is shown below.

  For efficiency reasons, the storage platform maintains a collection of global tables of items, item extensions, relationships, and path names. These global lookup tables can be used by applications to efficiently monitor data ranges and retrieve assigned timestamp and type information.

b) Timestamp management A logical time stamp is “local” to the database, ie, a storage platform volume. The time stamp is a monotonically increasing 64-bit value. Maintaining a single time stamp is often sufficient to detect whether a data change has occurred since the last connection to the storage platform volume. However, in the most realistic scenario, it is necessary to keep some more time stamps for duplicate checking. The reason will be described below.

  A relational database table is a logical abstraction built on a collection of physical data structures, ie, B-Tree, heap, and the like. Assigning a timestamp to a newly created or updated record is not an atomic action. Inserting that record into the underlying data structure can occur at different times, and therefore it appears to the application that the records come out of order.

  FIG. 14 shows that two transactions both insert a new record into the same B-Tree. Since transaction T3 inserts a record before the insertion of transaction T2 is scheduled, the application scanning the B-Tree may see a record inserted by transaction T3 before a record inserted by T2. is there. Thus, the reader may mistakenly assume that he has seen all records created up to time “10”. To solve this problem, the database engine 314 provides a function that returns all the updates committed to the low watermark inserted into the respective underlying data structure. In the above example, it is assumed that the returned low watermark is “5” and the leader started before transaction T2 was committed. The low watermark provided by the database engine 314 allows the application to efficiently determine which items to ignore when scanning the database or data range for data changes. In general, ACID transactions are assumed to last for a very short time, and a low watermark is expected to be very close to the most recently distributed timestamp. If there are long-lasting transactions, the application may have to keep individual timestamps to detect and discard duplicates.

c) Data Change Detection-Event Detection When executing a data store query, the application gets a low watermark. The application then uses the watermark to scan the data store for entries that are larger than the low watermark that returned the create, update, or delete timestamp. FIG. 15 illustrates this process.

  To prevent duplicate notifications, the application stores timestamps that are larger than the returned low watermark and uses them to eliminate duplicates. Applications create session level temporary tables to efficiently handle large sets of duplicate timestamps. As shown below, before issuing the select statement, the application inserts all duplicate timestamps that have already been returned and deletes those older than the last low watermark that was returned.

G. Synchronization According to another aspect of the invention, the storage platform allows (i) multiple instances of the storage platform (each with its own data store 302) to synchronize its content portions according to a flexible set of rules. (Ii) provide a synchronization service 330 comprising a third party infrastructure for synchronizing the storage platform data store of the present invention with other data sources implementing a dedicated protocol.

  Synchronization between storage platforms is performed in a group of participating replicas. For example, referring to FIG. 3, the storage platform 300's data store 302 and other remote data stores 338 may be under the control of other instances of the storage platform, possibly running on different computer systems. It may be desirable to synchronize. The overall membership of this group is not necessarily known to a given replica at a given time.

  Different replicas can make changes independently (ie, simultaneously). The process of synchronization is defined as making all replicas aware of changes made by other replicas. This synchronization processing function is essentially multi-master.

In the synchronization function of the present invention, the replica can be as follows.
Determine what changes other replicas will recognize.
Request information about changes not recognized by this replica.
Communicate information about changes that are not recognized by other replicas.
Determine when two changes conflict with each other.
• Apply changes locally.
Communicate competing solutions to other replicas to ensure convergence.
-Resolve the conflict condition based on the specified policy for conflict resolution.

1. Synchronization Processing Between Storage Platforms The main application of the storage platform synchronization processing service 330 of the present invention is to synchronize multiple instances of the storage platform (each with its own data store). The synchronous processing service operates at the schema level of the storage platform (not the underlying table of the database engine 314). Thus, for example, “Scopes” is used to define synchronization as described below.

  The synchronous processing service operates on the principle of “pure change”. Synchronous processing services do not record and send individual operations (such as by transactional replication), but send the final results of those operations, resulting in a single change that results in multiple operations. Often integrated.

  Synchronous processing services generally do not consider transaction boundaries. That is, if two changes are made to the storage platform data store in a single transaction, it is not guaranteed that those changes will be applied to all other replicas as a granular unit-one appears without the other There is. An exception to this principle is that if two changes are made to the same Item in the same transaction, they are sent and guaranteed to be applied as a minimum unit to other replicas. Thus, Item is the consistency unit of the synchronous processing service.

a) Synchronization Control Application Any application can connect to the synchronization processing service and initiate a synchronization processing operation. Such an application provides all the parameters necessary to execute the synchronization process (see sync profile below). Such an application is referred to herein as a synchronous control application (SCA).

  When synchronizing two storage platform instances, sync is initiated on one side by the SCA. The SCA notifies the local synchronization service that it will synchronize with the remote partner. On the other side, the synchronization service is awakened by a message sent by the synchronization service from the originating machine. This responds based on persistent configuration information (see mapping below) present on the destination machine. The synchronous processing service can be executed according to a schedule or in response to an event. In these cases, the synchronous processing service that executes the schedule is the SCA.

  Two steps need to be performed to enable the synchronization process. First, the schema designer must annotate the appropriate sync meaning in the storage platform schema (specify Change Units as described below). Second, the synchronization process must be properly configured on all machines that have storage platform instances involved in the synchronization process (as described below).

b) Schema annotation
The basic concept of the synchronous processing service is the concept of Change Unit. The Change Unit is the smallest piece of a schema that is tracked individually by the storage platform. For all Change Units, the synchronization processing service can determine whether it has changed since the last sync or not.

  Specifying Change Units in the schema is used for multiple purposes. First, it determines how busy the synchronization service is on the line. When a change is made in the Change Unit, the synchronization processing service does not know which part of the Change Unit has been changed, so the entire Change Unit is sent to the other replicas. Second, it determines the accuracy of conflict detection. If two simultaneous changes (these terms are defined in detail in later sections) are made to the same change unit, the synchronous processing service issues a conflict notification, while the change units have different simultaneous changes. Will not be notified of the conflict and changes will be merged automatically. Third, this has a strong impact on the amount of metadata held by the system. Most of the metadata of the synchronization processing service is held for each Change Unit. Therefore, if Change Units is reduced, the overhead of sync is increased.

  To define Change Units, we need to find the right tradeoff. For that reason, using a synchronous processing service allows the schema designer to participate in the process.

  In one embodiment, the synchronization processing service does not support Change Units larger than the element. However, it does support that the schema designer specifies a change unit that is smaller than the element—that is, grouping multiple attributes of an element into one independent Change Unit. In that embodiment, this is done using the following syntax:

c) Synchronization settings A group of storage platform partners that wants to keep certain parts of the data synchronized, is called the sync community. If community members want to stay in sync, they don't necessarily represent the data in exactly the same way, i.e. the sync partner can convert the data being synchronized.

  In a peer-to-peer scenario, it is impractical for a peer to maintain a transformation mapping for all of its partners. Instead, the synchronization processing service takes an approach of defining “community folders”. A community folder is an abstraction that represents a virtual “shared folder” in which all community members are synchronized.

  This concept is best understood with an example. When Joe wants to synchronize My Documents folders on multiple computers, Joe defines, for example, a community folder called Joes Documents. Next, on all computers, Joe configures a mapping between the virtual Joe Documents folder and the local My Documents folder. From this point on, if Joe's computers synchronize with each other, they will interact with the document in JoesDocuments, not its local items. In this way, all Joe's computers understand each other without knowing who they are—the community folder is the common language of the sync community.

  The configuration of the synchronization processing service consists of (1) defining the mapping between the local folder and the community folder, (2) what is synchronized (eg, what to synchronize with, the subset to be transmitted, and what to receive). It consists of three steps: defining a sync profile to determine (kimono), and (3) defining a schedule on which different sync profiles are executed or executing manually.

(1) Community folder-mapping Community folder mapping is stored as an XML configuration file on each machine. Each mapping has the following schema.
/ mappings / communityFolder
This element specifies the name of the community folder that is the target of this mapping. The name follows the folder syntax rules.
/ mappings / localFolder
This element specifies the name of the local folder to which this mapping is converted. The name follows the folder syntax rules. The folder must already exist for the mapping to be valid. Items in this folder are considered for synchronization according to this mapping.
/ mappings / transformations
This element defines how to convert an item from a community folder to a local folder and vice versa. If it does not exist or is empty, no conversion is performed. In particular, this means that no ID is mapped. This configuration is mainly used when creating a folder cache.
/ mappings / transformations / mapIDs
This element requires that the newly generated local ID is assigned to all of the mapped items from the community folder, rather than reusing the community ID. Sync Runtime holds ID mapping for performing item conversion and reverse conversion.
/ mappings / transformations / localRoot
This element requires that all root items in the community folder be children of the specified root.
/ mappings / runAs
This element controls the authority with which requests for this mapping are processed. If not present, a sender is assumed.
/ mappings / runAs / sender
If this element is present, the sender of the message to this mapping is impersonated and the request must be processed according to its credentials.

(2) Profile The synchronization profile is a set of parameters necessary for kicking off synchronization. This is supplied by the SCA to Sync Runtime to start the synchronization process. The synchronization profile for synchronizing storage platforms includes the following information.
• Local Folder, used as a change source and destination.
Remote Folder name to synchronize-This Folder must be published from the remote partner using the mapping as defined above.
Direction-synchronization service supports transmission only, reception only, and transmission / reception synchronization.
Local Filter—Selects local information to send to the remote partner. Expressed as a storage platform query for local folders.
Remote Filter—Select remote information to retrieve from remote partner—Represented as a storage platform query for community folders.
Transformations—Defines how to convert items in local format.
Local security-specifies whether changes retrieved from the remote endpoint are applied with the permission of the remote endpoint (impersonation) or with the permission of the user who initiated the synchronization locally.
Conflict resolution policy-specifies whether conflicts are rejected, logged or automatically resolved-in the latter case, specify the configuration parameters for it along with the conflict resolver to use.

  The synchronization processing service provides a runtime CLR class that allows simple construction of synchronization profiles. Profiles can also be serialized with XML files for easy storage (often with schedules). However, there is no standard place in the storage platform where all profiles are stored, and the SCA is hopeless because it can build profiles on the fly without persisting it. Note that there is no need to provide a local mapping to initiate synchronization. All synchronization information can be specified in the profile. However, mapping is necessary to respond to synchronization requests initiated on the remote side.

(3) Schedule In one embodiment, the synchronization processing service does not provide its own scheduling infrastructure. Instead, it relies on other components to perform this task-using the Windows (R) Scheduler that comes with the Microsoft Windows (R) operating system. The synchronization processing service comprises a command line utility that operates as an SCA and triggers synchronization based on a synchronization profile stored in an XML file. Using this utility, Windows® Scheduler can be very easily configured to perform a synchronization process according to a schedule or in response to an event such as a user logging on or off.

d) Conflict Handling
The conflict avoidance processing in the synchronous processing service is (1) Conflict detection executed at the time of applying the change-in this step, it is determined whether the change can be safely applied. (2) Automatic conflict resolution and logging. Run immediately after a conflict is detected), the auto-conflict resolver can be queried to resolve the conflict, optionally log the conflict, and (3) conflict checking and resolution-this step is Runs if any conflicts are logged, and runs outside the status of the sync session, at which time the logged conflicts can be resolved and removed from the log Divided into three stages.

(1) Conflict detection In the embodiment of the present invention, the synchronization processing service detects two types of conflicts, knowledge base and constraint base.

(A) Knowledge Base Conflict Knowledge base conflict occurs when two replicas make independent changes to the same Change Unit. Two changes are called independently if they are made without knowing each other's changes-that is, the first version is not subject to knowledge of the second version and vice versa. I can say that. The synchronization processing service automatically detects all such conflicts based on replica knowledge, as described above.

  It may be useful to think of a conflict as a branch point in the version history of a change unit. If no conflicts occur during the lifetime of the change unit, its version history is a simple chain—each change occurs after the previous change. In the case of knowledge base conflicts, the two changes occur in parallel, so the chain is split into a version tree.

(B) Constraint-based conflicts Independent changes may violate integrity constraints when applied together. For example, if two replicas try to create a file with the same name in the same directory, such a conflict may occur.

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

  The synchronization processing service detects constraint violations when applying changes and automatically issues constraint-based conflict notifications. Resolving constraint-based conflicts usually requires custom code that modifies changes in a way that does not violate the constraints, but synchronous processing services provide a general-purpose mechanism for doing so. Absent.

(2) Conflict processing
When a conflict is detected, the synchronization processing service can either (1) reject the change and send it back to the sender, (2) the action to record the conflict in the conflict log, or (3) automatically resolve the conflict. One of the three actions to be performed (selected by the synchronization initiator in the synchronization profile) can be performed.

  If the change is rejected, the synchronization processing service behaves as if the change did not reach the replica. A negative response is sent back to the caller. This resolution policy can be used primarily with headless replicas (such as file servers) where conflict logging is not possible. Instead, such replicas force other replicas to handle the conflict by rejecting.

  The synchronization initiator configures conflict resolution with the synchronization profile. The synchronous processing service supports the combination of multiple conflict resolvers in a single profile as follows-first, specify a list of conflict resolvers that will be tried one after the other until one succeeds; First, associate a conflict resolver with a type of conflict, for example, direct knowledge-based conflicts between updates to one resolver and all other conflicts to the log.

(A) Automatic conflict resolution The synchronization processing service includes a number of default conflict resolvers. This list includes:
Local-wins: discard changes received when there is a conflict with locally stored data.
Remote-wins: Discard local data if there is a conflict with the received change.
Last-writer-wins: select either local-wins or remote-wins according to the change unit based on the timestamp of the change (note that the synchronization processing service is generally independent of the clock value. This contention The resolver is the only exception to that rule).
Deterministic: Selects the winner in a way that is guaranteed to be the same on all replicas, but otherwise has no meaning—in one embodiment of the synchronization processing service, a partner is required to implement this functionality. Use ID lexicographic comparison.

  In addition, ISVs can implement and install their own competitive resolvers. A custom conflict resolver can accept configuration parameters, and such parameters must be specified by the SCA in the Conflict Resolution section of the synchronization profile.

  When the conflict resolver handles the conflict, it returns to the runtime a list of operations that need to be performed (instead of changing the conflict). After that, the synchronous processing service appropriately adjusts the remote knowledge so as to include the content considered by the contention handler side, and then applies those operations.

  Other conflicts may be detected while applying the solution. In such cases, the new conflict must be resolved before the original process resumes.

  Considering a conflict as a branch in an item's version history, the conflict resolution can be considered as combining—combining two branches to form a point. Thus, conflict resolution changes the version history to DAG.

(B) Conflict logging
There is a Conflict Logger as a very special competitive resolver. The synchronization processing service logs the conflict as an Item of type ConflictRecord. These records are again related to the item in conflict (unless the item itself has been deleted). Each conflict record contains the received change that caused the conflict, the type of conflict, update-update, update-delete, delete-update, insert-insert, or constraint, and the version of the received change and the replica that sends it. Includes knowledge. Logged conflicts can be used for inspection and resolution, as described below.

(C) Conflict inspection and resolution The synchronization processing service includes an API for examining the contention log on the application side and proposing the resolution of the contention therein. This API allows an application to enumerate all conflicts or conflicts related to a given Item. This further allows such applications to: (1) accept remote changes—overwrite conflicting local changes to resolve logged conflicts, ( 2) local wins--ignore the conflicting part of the logged change, and (3) suggest new change--optionally proposes a merge that resolves the conflict, one of three ways One can be used. After the conflicts are resolved by the application, the synchronous processing service deletes them from the log.

(D) Replica Convergence and Conflict Resolution Propagation In complex synchronization scenarios, the same conflict may be detected by multiple replicas. When such a situation occurs, the following events occur. (1) the conflict can be resolved at one replica and the resolution sent to the other replica, or (2) the conflict is automatically resolved on both replicas, or ( 3) Conflicts are resolved manually on both replicas (through a conflict check API).

  In order to ensure convergence, the synchronization processing service forwards the conflict resolution to the other replicas. When changes that resolve the conflict arrive at the replica, the synchronization processing service automatically finds the conflict records contained in the log resolved by this update and deletes them. In this sense, conflict resolution at one replica becomes binding on all other replicas.

  When different winners are selected by different replicas for the same conflict, the synchronization service applies the principle of binding conflict resolution, picking one of the two solutions and automatically acquiring the other. The winner is chosen in a deterministic manner that ensures that the same result is always obtained (in one embodiment, a replica ID lexicographic comparison is used).

  If different “new changes” are proposed by different replicas for the same conflict, the sync service will treat this new conflict as a special conflict and use Conflict Logger to prevent it from propagating to other replicas. . Such a situation typically occurs in manual conflict resolution.

2. Non-Storage Platform Data Store Synchronization Processing According to another aspect of the storage platform of the present invention, the storage platform implements Sync Adapters that allow the ISV to synchronize the storage platform with legacy systems such as Microsoft Exchange, AD, and Hotmail. An architecture for Sync Adapters use many Sync Services provided by the synchronization processing service, as will be described later.

  Despite its name, Sync Adapters do not need to be implemented as plug-ins in any storage platform architecture. If desired, the “sync adapter” can simply be an application that utilizes a synchronous processing service runtime interface to obtain services such as change enumeration and applications.

  To make it easy to configure and execute synchronization with a given backend, Sync Adapter authors can use standard Sync to perform synchronization processing when given a synchronization profile as described above. You are encouraged to publish the Adapter interface. With this profile, configuration information is communicated to the adapter, which passes a portion of it to the Sync Runtime that controls the runtime service (eg, the Folder to be synchronized).

a) Synchronization processing service The synchronization processing service provides a number of synchronization processing services to the adapter creator. For the remainder of this section, it is convenient to call the machine on which the storage platform is performing the synchronization process as the “client” and the non-storage platform backend with which the adapter communicates as the “server”.

(1) Change enumeration
Using Change Enumeration, based on the change tracking data maintained by the sync processing service, the sync processing adapter can easily enumerate the changes that have occurred since the last attempt to synchronize with this partner for the data store folder. can do.

  Changes are enumerated based on the concept of “anchors” —hidden structures that represent information about the last synchronization. Anchors take the form of storage platform knowledge, as described in the previous section. Synchronous processing adapters that use the change enumeration service fall into two broad categories: those that use “stored anchors” and those that use “supplied anchors”.

  This distinction is based on where the information about the last synchronization is stored-the client or the server. The adapter is often easy to store this information on the client-the back end often cannot easily store this information. On the other hand, when multiple clients synchronize with the same backend, storing this information on the client is inefficient and in some cases incorrect-one client has already pushed the other client to the server. Do not notice the changes that are up. If you want to use a server stored anchor on the adapter side, the adapter must be sent back to the storage platform when enumerating changes.

  In order for the storage platform to hold an anchor (either local storage or remote storage), it is necessary to make the storage platform aware of changes that have been successfully applied on the server side. These changes and only these changes can be included in the anchor. During change enumeration, Sync Adapters uses the Acknowledgment interface to report successfully applied changes. At the end of synchronization, adapters that use the supplied anchor need to read the new anchor (which incorporates all successfully applied changes) and send it to the backend.

  In many cases, Adapters need to store adapter-specific data along with items to insert into the storage platform data store. Common examples of such data include remote ID and remote version (time stamp). Synchronous processing services provide a mechanism for storing this data, and Change Enumeration provides a mechanism for receiving this additional data along with the returned changes. This eliminates the need for the adapter to re-query the database in most cases.

(2) Change Application
Using Change Application, changes received from the back end on the Sync Adapters side can be applied to the local storage platform. The adapter is expected to convert changes to the storage platform schema.

  The main function of change application is to automatically detect conflicts. As in the case of storage platform-to-storage platform synchronization, contention is defined as two overlapping changes made without knowledge of each other. If the adapter uses Change Application, the adapter must specify an anchor as to which conflict detection is performed. Change Application issues a conflict notification when an overlapping local change that is not subject to adapter knowledge is detected. Similar to Change Enumeration, adapters can use either stored anchors or supplied anchors. Change Application supports efficient storage of adapter-specific metadata. Such data can be attached to the applied changes by the adapter and can also be stored by a concurrent processing service. Data could be returned at the next change enumeration.

(3) Conflict Resolution
The Conflict Resolution mechanism described above (logging and automatic resolution options) can also be used with the synchronous processing adapter. The synchronous processing adapter can specify a conflict resolution policy when applying changes. If specified, the conflict can be passed to the specified conflict handler and resolved (if possible). Conflicts can also be logged. The adapter may detect conflicts when attempting to apply local changes to the backend. In such cases, the adapter can still pass the conflict to Sync Runtime and resolve according to policy. In addition, the synchronous processing adapter may request that conflicts detected by the concurrent processing service be sent back for processing. This is useful when the backend can store or resolve conflicts.

b) Adapter implementation If some "adapter" is simply an application that uses a runtime interface, it is encouraged to implement a standard adapter interface on the adapter side. By using these interfaces, Sync Controlling Applications requests that the adapter perform synchronization processing according to a given synchronization profile, cancels ongoing synchronization processing, and reports on ongoing synchronization (completed). Rate).

3. Security Synchronous processing services attempt to introduce as little as possible into the security model implemented by the storage platform. Rather than defining new rights for the synchronization process, existing rights are used. In particular,
• Anyone who can read an item in the data store can enumerate changes to that item,
Anyone who can write to an item in the data store can apply changes to that item,
Anyone who can extend a DataStore Item can associate synchronization metadata with that item.

  The synchronous processing service does not hold copyright information protected by security. If a change is made at replica A by user U and forwarded to replica B, the fact that the change was originally made at A (or by U) is lost. If B forwards this change to Replica C, this is performed under B's authority instead of A's authority. This creates a restriction that changes made by others cannot be transferred if the replica is not trusted to make its own changes to the item.

  When the synchronization processing service is started, it is executed by Sync Controlling Application. The synchronous processing service impersonates the SCA identity and performs all operations (both local and remote) under that identity. For illustration purposes, user U observes that the local synchronization processing service cannot have changes retrieved from the remote storage platform for items for which user U does not have read access.

4). Manageability Monitoring a distributed community of replicas is a complex issue. The synchronous processing service can use a “sweep” algorithm to collect and distribute information about the status of the replica. The nature of the sweep algorithm ensures that information about all configured replicas is eventually collected and that failed (non-response) replicas are detected.

  This community-wide monitoring information is available to all replicas. A monitoring tool can be run on an arbitrarily selected replica, and this monitoring information can be examined to make administrative decisions. Configuration changes must be made directly at the affected replica.

H. Conventional File System Interoperability As described above, the storage platform of the present invention is embodied as an integral part of the hardware / software interface system of a computer system, at least in some embodiments. Is intended. For example, the storage platform of the present invention may be embodied as an important part of an operating system, such as the Microsoft Windows® family of operating systems. In its adaptability, the storage platform API becomes part of the operating system API that application programs use to interact with the operating system. As such, the storage platform becomes a means used by application programs to store information about the operating system, and thus the Item-based data model of the storage platform is an alternative to the traditional file system of such operating system. For example, as embodied in the operating system of the Microsoft Windows (registered trademark) family, the storage platform can also replace the NTFS file system implemented in the operating system. Currently, the application program accesses the NTFS file system service through the Win32 API published by the Windows (registered trademark) family of operating systems.

  However, to fully replace the NTFS file system with the storage platform of the present invention, it is necessary to recode existing Win32-based application programs and understand that such recoding is undesirable. It would be beneficial to achieve some interoperability with existing file systems such as NTFS with the storage platform of the present invention. Thus, in one embodiment of the present invention, in a storage platform, an application program that relies on the Win32 programming model can access the contents of both the storage platform data store and the traditional NTFS file system. For this purpose, the storage platform uses a naming convention that is a superset of the Win32 naming convention that enhances simple interoperability. In addition, the storage platform supports access to files and directories stored in the storage platform volume through the Win32 API.

1. Model for Interoperability According to this aspect of the invention, in the exemplary embodiment described above, the storage platform implements a single namespace that can organize non-file items and file items. Using this model, the following advantages are obtained:
1. Folders in the data store can contain both file items and non-file items, thereby presenting a single namespace for files and schematized data. It also implements a uniform security, sharing, and management model for all user data.
2. Both file and non-file items are accessible using the storage platform API, and this approach does not apply any special rules to the file, presenting a cleaner programming model involving the application developer.
3. All namespace operations go through the storage platform and are therefore handled synchronously. It is important to note that while deep property promotion (evicted from file content) still occurs asynchronously, synchronous operations provide a fairly predictable environment for users and applications.

  As a result of this model, embodiments of the present invention cannot provide a search function for data sources that are not migrated in the storage platform data store. This includes removable media, remote servers, and files on local disks. A synchronization adapter is provided that reveals proxy items (shortcut + promoted metadata) in the storage platform for items that reside in the external file system. Proxy items do not attempt to mimic files with respect to the namespace hierarchy or security of the data source.

  The symmetry implemented on the namespace and programming model between files and non-file content allows applications to migrate content from the file system to more structured items in the storage platform data store over time A better path can be obtained. By implementing the native file item type in the storage platform data store, the application program can manipulate this data via Win32 while migrating file data into the storage platform. Eventually, application programs will be able to fully migrate to the storage platform API and structure their data in terms of storage platform items rather than files.

2. Data Store Functions To achieve the desired level of interoperability, in one embodiment, the following data store functions of the storage platform are implemented:

a) Not a volume The storage platform data store is not exposed as an independent file system volume. The storage platform uses FILESTREAM hosted directly on NTFS. Thus, there is no change in the on-disk format, thereby eliminating the need to expose the storage platform as a new file system at the volume level.

  Instead, a data store (name space) is constructed corresponding to the NTFS volume. The database and FILESTREAM that assist this part of the namespace are located on the NTFS volume with which the storage platform data store is associated. A data store corresponding to the system volume is also prepared.

b) Store structure The structure of the store is best seen in the examples. For example, consider a directory tree on the system volume of a machine named HomeMachine, as illustrated in FIG. With the file system interoperability function of the present invention, there is a storage platform data store corresponding to c: \ drive, for example, called “WinFSOnC”, which is exposed to Win32 API via UNC sharing. This makes it possible to access the associated data store via UNC name \\ HomeMachine \ WinFSOnC.

  In this embodiment, files and / or folders need to be explicitly migrated from NTFS to the storage platform. Thus, if the user wants to move the My Documents folder into the storage platform's data store in order to take advantage of all the additional search / classification features provided by the storage platform, the hierarchy is as shown in FIG. Will look. It is important to note that these folders are actually moved in this example. Another point to note is that the namespace is moved into the storage platform, the actual stream is renamed FILESTREAM, and an appropriate pointer is tied in the storage platform.

c) Not all files are migrated Files that correspond to user data or that require search and classification capabilities provided by the storage platform are candidates for migration to the storage platform data store. In order to limit compatibility issues between application programs and storage platforms, the set of files migrated to the storage platform of the present invention is a Documents and in a situation where the Microsoft Windows (registered trademark) operating system is used. MyDocuments folder in the Settings directory, Internet Explorer (IE) Fabites, IE History, and Desktop. It is preferably limited to files in the ini file. Migrating Windows® system files is preferably not allowed.

d) Accessing storage platform files in the NTFS namespace In the embodiment described herein, files migrated to the storage platform are not included in the NTFS name, even if the solid file stream is stored in NTFS. It is desirable not to be accessed through space. This avoids the complex locking and security issues that arise from multi-faceted implementations.

e) Expected Namespace / Drive Letter Access to files and folders in the storage platform is performed via UNC names in the form of \\ <machine name> \ <WinfsShareName>. For classes of applications that require a drive letter for operation, the drive letter can be mapped to this UNC name.

I. Storage platform API
As described above, the storage platform includes an API that can be used on the application program side to access the functions and capabilities of the storage platform described above and to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform of the present invention.

  FIG. 19 illustrates the basic architecture of the storage platform API, according to one embodiment of the invention. The storage platform API can interact with the local data store 302 using SQL Client 1900 and can interact with a remote data store (eg, data store 338) using SQL Client 1900. The local store 302 can also interact with the remote data store 338 using a DQP (distributed query processor) or through the storage platform synchronization service (“Sync”) described above. The storage platform API 322 further functions as a bridge API for data store notifications, passing application subscriptions to the notification engine 332 and routing notifications to applications (eg, applications 350a, 350b, or 350c) as described above. To do. In one embodiment, the storage platform API 322 may further define a “provider” architecture that is restricted to allow access to data with Microsoft Exchange and AD.

1. Overview The data access mechanism of this embodiment of the storage platform API of the present invention handles four areas: query, navigation, action, and event.

Query In one embodiment, the storage platform data store is implemented on the relational database engine 314 so that the full expressive power of the SQL language is inherent in the storage platform. Higher level query objects provide a simplified model for querying the store, but cannot encapsulate the full expressive power of storage.

The navigation storage platform data model builds a rich extensible system on top of the underlying database abstraction. For developers, storage platform data is a spider web item. Using the storage platform API allows item-to-item navigation through filtering, relationships, folders, and the like. This is a higher level of abstraction than the basic SQL query, while at the same time rich filtering and navigation functions can be used with familiar CLR coding patterns.

Action The storage platform API exposes common actions—Create, Delete, Update—for all items, which are exposed as methods on the object. Furthermore, domain-specific actions such as SendMail and CheckFreeBusy can also be used as methods. The API framework uses a well-defined pattern that can be used by ISVs to add values by defining additional actions.

Data in the event storage platform is dynamic. The API exposes rich eventing, subscriptions, and notifications to developers to react to applications when data in the store changes.

2. Naming and scope It is convenient to distinguish namespaces from naming. The term namespace refers to the set of all names available in a system in the usual usage. The system can be an XML schema, program, Web, a collection of all ftp sites (and their content), and so on. Naming is a process or algorithm used to assign unique names to all entities of interest in a namespace. Thus, naming is important because it is desirable to explicitly refer to a given unit within the namespace. Thus, as used herein, the term “namespace” refers to the collection of all names that are available on all storage platform instances in a universe. An item is a named entity in the storage platform namespace. Use the UNC naming convention to ensure uniqueness of item names. All items in the data store of all storage platforms in the universe can be addressed by UNC name.

  The highest organizational level within the storage platform namespace is a service, which is simply an instance of a storage platform. The next level of organization is volume. A volume is the largest autonomous container of items. Each storage platform instance includes one or more volumes. There are items in the volume. An item is a data atom in the storage platform.

  Real-world data is almost always organized according to some system that makes sense within a given domain. Underlying all such data organization schemes is the concept of dividing our universe of data into multiple named groups. As mentioned above, this concept is modeled in the storage platform by the Folder concept. Folder is a special type of Item, and there are two types of Folders: Continent Folder and Virtual Folder.

  Referring to FIG. 18, the Containment Folder is an item including retention Relationships with other Items, and is equivalent to a common concept of a folder in a file system. Each Item is “included” in at least one inclusion folder.

  A Virtual Folder is a more dynamic way of organizing a collection of Items, where a set of Items is simply a name given—this set is explicitly enumerated or specified by the query. The Virtual Folder is itself an Item, and is considered to represent a (non-retaining) Relationship with a set of Items.

  Sometimes it is necessary to model a tighter concept of containment, for example, Word documents embedded within an email message are in some ways closer to the container than, for example, files stored in folders. Bound to This concept is represented by the concept of an Embedded Item. An Embedded Item has a special kind of relationship that references other Items, and the referenced Item can be bound or otherwise manipulated only within the context of the containing Item.

  Finally, the storage platform implements the concept of categories as a classification method for Items and Elements. Every Item or Element in the storage platform can be associated with one or more categories. A category is essentially just a name tagged Item / Element. This name can be used in searches. The storage platform's data model allows the category hierarchy to be defined and thus the data can be classified in a tree format.

  The unambiguous name of the item is a triple (<serviceName>, <volumeID>, <ItemID>). Some items (especially Folders and Virtual Folders) are collections of other items. This provides an alternative means for identifying the item (<serviceName>, <volumeID>, <itemPath>).

  The storage platform name includes the concept of service context, and the service context is a name mapped to a pair (<volumeName>, <path>). This identifies an item or collection of items--for example, a folder, a virtual folder, etc. Using the service context concept, the UNC name for an item in the storage platform namespace is \\ <serviceName> \ <serviceContext> \ <itemPath>.

The user can create and delete service contexts. Also, the root directory in each volume has a predefined context volume-name $.
ItemContext sets the scope of a query (eg, Find operation) by limiting the results returned to Items that persist in the specified path.

3. Storage Platform API Component FIG. 20 represents an overview of the various components of the storage platform API according to this embodiment of the invention. The storage platform API includes (1) a data class 2002 representing storage platform elements and item types, (2) a runtime framework 2004 that manages object persistence and provides support classes 2006, and (3) a storage platform schema. Each component of the tool 2008 used to generate a CLR class from

  According to one aspect of the invention, at design time, the schema creator submits the schema document 2010 and code for the domain method 2012 to a collection of storage platform API design time tools 2008. These tools generate a client side data class 2002 and a store schema 2014 and store a class definition 2016 corresponding to the schema. “Domain” refers to a specific schema, and means, for example, a domain method for a class in the Contacts schema. These data classes 2002 are used at run time by application developers in response to the storage platform API runtime framework class 2006 to manipulate storage platform data.

  For purposes of illustrating various aspects of the storage platform API of the present invention, an example is presented based on an exemplary Contacts schema. A schematic representation of this exemplary schema is shown in FIGS. 21A and 21B.

4). Data Classes According to one aspect of the present invention, each Item, Item Extension, and Element type in the storage platform data store has a corresponding class in the storage platform API along with its respective Relationship. Roughly speaking, a field of that type is mapped to a field of that class. Each item, item extension, and element in the storage platform can be used as a corresponding class of object in the storage platform API. Developers can query, create, modify, or delete those objects.

The storage platform includes an initial set of schemas. Each schema defines a set of Item and Element types, and a set of Relationships. The following is one embodiment of an algorithm for generating data classes from these schema entities.
For each schema S
For each Item I in S, System. Storage. S. A class named I is created. This class has the following members:
An overloaded constructor that contains a constructor used to specify the initial folder and name for the new item.
• Properties of each field in I. If the field is multi-valued, the property is a corresponding Element type collection.
An overloaded static method that finds multiple items that match the filter (eg, a method named “FindAll”).
An overloaded static method that finds a single item that matches the filter (eg, a method named “FindOne”).
A static method that finds an item given an id (eg, a method named “FindByID”).
A static method that finds an item named for an ItemContext (eg, a method named “FindByName”).
A method that saves changes to the item (eg, a method named “Update”).
An overloaded static Create method that creates a new instance of the item. By using these methods, the initial folder of items can be specified in various ways.

For each Element E in S, System. Storage. S. A class named E is created. This class has the following members:
• Properties of each field in E. If the field is multi-valued, the property is a corresponding Element type collection.

For each Element E in S, System. Storage. S. A class named ECollection is generated. This class is general for strongly typed collection classes. Follow NET Framework guidelines. For Relationship-based element types, this class also includes the following members:
An overloaded method that finds multiple Item objects that match a filter whose collection implicitly contains items that appear in the source role. These overloads include those that can be filtered based on the Item child type (eg, a method named “FindAllTargetItem”).
An overloaded method that finds a single Item object that matches a filter whose collection implicitly contains items that appear in the source role. These overloads include those that can be filtered based on the Item child type (eg, a method named “FindOneTargetItem”).
An overloaded method (eg, a method named “FindAllRelationships”) that finds a nested element type object that matches a filter whose collection implicitly contains items that appear in the source role.
An overloaded method that finds a nested element type object that matches a filter whose collection implicitly includes items that appear in the source role (eg, a method named “FindAlIRlationshipsForTarget”).
Overloaded methods that find a single object of a nested element type that matches a filter whose collection implicitly includes items that appear in the source role (eg, a method named “FindOneRelationship”).
An overloaded method that finds a single object of a nested element type that matches a filter whose collection implicitly includes items that appear in the source role (eg, a method named “FindOneRelationshipForTarget”).

For Relationship R in S, see System. Storage. S. A class named R is created. This class has one or two subclasses depending on whether one or both relationship roles specify one endpoint field.
The class is further generated in this way for each created Item Extension.

  The data class is System. Storage. <SchemaName> exists in the namespace, where <schemaName> is the name of the corresponding schema such as Contacts, Files, etc. For example, all classes corresponding to the Contacts schema are System. Storage. It is in the Contacts namespace.

For example, referring to FIGS. 21A and 21B, System. Storage. It can be seen that the following classes included in the Contact namespace are obtained.
Item: Item, Folder, WellKnownFolder, LocalMachineDataFolder, UserDataFolder, Principal, Service, GroupService, PersonService, Presence, GroupService, PersonService, PersonService.
· Elements: NestedElementBase, NestedElement, IdentityKey, SecurityID, EAddress, ContactEAddress, TelephoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, Windows (registered trademark) Presence, Relationship, TemplateRelationship, LocationRelationship, FamilyEventLocationRelationship, HouseHoldLocationRelationship , RoleOccupancy, EmployeeData, GroupMemberShip, OrganizationLocationRelationship, HouseHoldMemberData, FamilyData, SpouseData, ChildData

  Further, for example, the detailed structure of the Person type as defined in the Contacts schema is represented by the following XML.

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

  In yet another embodiment, the detailed structure of the TelephoneNumber type, as defined in the Contacts schema, is shown in the following XML.

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

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

  With other schemas, that is, schemas that can represent all audio / video media in the system (ripped audio files, audio CDs, DVDs, home videos, etc.), users / applications can have different types of audio / video Media storage, organization, retrieval, and manipulation can be performed. This basic media document schema is versatile enough to represent any media, and this basic schema extension is designed to handle domain-specific properties separately for audio and video media. This schema, and many others, are assumed to work directly or indirectly under the Core Schema.

5). Runtime Framework The basic storage platform API programming model is object persistence. An application program (or “application”) performs a search on the store and retrieves an object representing the data in the store. The application modifies the retrieved object or creates a new object and then propagates the change into the store. This process is managed by an ItemContext object. The search is performed using the ItemSearcher object, and the search results are accessible via the FindResult object.

a) Runtime Framework Classes According to another aspect of the storage platform API invention, the runtime framework implements a number of classes that support the operation of data classes. These framework classes define a common set of behaviors for the data class and, together with the data class, implement the basic programming model of the storage platform API. The classes in the runtime framework are System. It belongs to the Storage namespace. In this embodiment, the framework classes include ItemContext, ItemSearcher, and FindResult as the main classes. Other small classes, enum values, and delegates can also be provided.

(1) ItemContext
The ItemContext object represents (i) a set of item domains to be searched by an application program, (ii) holds state information of each object representing the state of data retrieved from the storage platform, and (iii) interacts with the storage platform When managing file systems that are interoperable with the transaction and storage platforms used.

ItemContext provides the following services as an object persistence engine.
1. Deserialize data read from the store into multiple objects.
2. Holds the object ID (when an item is given, it represents the item using the same object no matter how many times the item is included in the query results).
3. Track object state.

ItemContext also performs a number of services specific to the storage platform.
1. Generate and execute the storage platform updategram operations necessary to make the changes permanent.
2. You can create connections to multiple data stores as needed to allow seamless navigation of reference relationships, modify and save objects retrieved from multi-domain searches.
3. An item backed by a file is guaranteed to be properly updated when changes to the object (s) representing that item are saved.
4). When updating transactions across multiple storage platform connections, and updating data and file stream properties stored in items backed by files, the file system in which the transaction takes place is managed.
5). Perform item creation, copy, move, and delete operations that take into account the meaning of storage platform relationships, items backed by files, and stream typing properties.

  Appendix A lists the source code listing of the ItemContext class, according to one embodiment.

(2) ItemSearcher
The ItemSearcher class supports simple searches and returns an entire Item object, a stream of Item objects, or a stream of values projected from an Item. ItemSearcher encapsulates the core functionality common to all of these, namely the concept of a target type and a parameterized filter applied to the target type. Also, by using ItemSearcher, the searcher can be precompiled, that is, prepared as an optimization when the same search is executed in a plurality of types. Appendix B lists the source code listing of the ItemSearcher class and multiple closely related classes, according to one embodiment.

(A) Target type The search target type is set when an ItemSearcher is constructed. The target type is mapped to an extent that can be queried by the data store. In particular, this is a CLR type that is mapped to items, relationships, and item extension types with a schematized view.

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

  A search expression (eg, “search filter and through find” option or projection definition) given in ItemSearcher always relates to its search target type. These expressions can specify target type properties (including nested element properties) and can specify associations to relationships and item extensions as described elsewhere.

  The search target type is made available via a read-only property (eg, ItemSearcher.Type property).

(B) Filter ItemSearcher includes a property (for example, a property named “Filters” as a collection of SearchExpression objects) that specifies a filter that defines the filter used in the search. All filters in this collection are combined using logic and operators when the search is performed. The filter can include parameter references. The parameter value is specified through the Parameters property.

(C) Preparation for search In a situation where the same search is repeatedly executed by changing only the parameters in some cases, it is possible to improve the performance to some extent by pre-compiling, that is, preparing the search. This is done with a set of prepare methods on ItemSearcher (eg, a method that prepares a Find that returns one or more Items named “PrepareFind”, and a Find that returns a projection named “PrepareProject”. Method to prepare). For example, it is as follows.

(D) Search options There are many options that can be applied to simple searches. These can be specified by, for example, a FindOptions object and passed to the Find method. For example, it is as follows.

  Conveniently, reordering options can also be passed directly to the Find method.

  The DelayLoad option determines whether a large binary property value is loaded when a search result is retrieved or is loaded until it is referenced. The MaxResults option determines the maximum number of results returned. This is equivalent to specifying TOP in the SQL query. Most often used with sorting.

A series of SortOption objects can be specified (eg, using the FindOptions.SortOptions property). The search results are sorted as specified by the first SortOption object, then sorted as specified by the second SortOption object, and so on. In SortOption, a search expression indicating a property used for sorting is designated. This expression specifies one of the following:
1. A scalar property of the search target type,
2. 2. a scalar property in a nested element that is reachable from the search target type by traversing a single value property, or The result of an aggregate function with valid arguments (eg, Max applied to a scalar property in a nested element that is reachable from the search target type by traversing a multi-value property or relationship).

For example, if the search target type is System. Storage. Contact. Assuming that it is Person,
1. “Birthdate” —Valid, birthdate is a scalar property of the Person type.
2. “PersonalNames.Surname” —Invalid, PersonalNames is a multi-valued property and no aggregation function is used.
3. "Count (PersonalNames)"-Valid, PersonalNames count.
4). “Case (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate” —Invalid, use relations and multivalued properties without an aggregate function.
5). “Max (Cast (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate)” — Valid, most recent home email address start date.

(3) Item result stream (“FindResult”)
ItemSearcher (eg, through the FindAll method) returns an object that can be used to access the object returned by the search (eg, “FindResult” object). Appendix C lists the source code listing of the FindResult class and several closely related classes, according to one embodiment.

  There are two different ways to get results from a FindResult object: using the reader pattern defined by IObjectReader (and IAsyncObjectReader) and using the enumerator pattern as defined by IEnumerable and IEnumerator. Enumerator patterns are standard in CLR and support language syntax such as C # foreach. For example, it is as follows.

  The leader pattern is supported because it can increase the processing efficiency of the result, possibly by eliminating data copying. For example, it is as follows.

  In addition, the leader pattern supports asynchronous operations.

  In this embodiment, FindResult must be closed when no longer needed. This can be done by calling the Close method or by using a language syntax such as C # that uses a statement. For example, it is as follows.

b) Runtime framework in operation FIG. 22 illustrates the runtime framework in operation. The runtime framework works as follows.
1. Applications 350a, 350b, or 350c bind to items in the storage platform.
2. The framework 2004 creates an ItemContext object 2202 corresponding to the bound item and returns it to the application.
3. The application submits Find on this ItemContext to obtain a collection of Items, and the returned collection is conceptually an object graph 2204 (depending on the relationship).
4). The application changes, deletes, and inserts data.
5). The application saves the changes by calling the Update () method.

c) Common Programming Patterns This section gives various examples of how to manipulate items in a data store using the storage platform API framework classes.

(1) Opening and closing an ItemContext object An application can be, for example, a static ItemContext. Obtain an ItemContext object that is used to interact with the data store by calling Open and supplying one or more paths that identify the item domain associated with the ItemContext. The item domain sets a search executed using ItemContext as a scope so that only the domain item and the items included in the item are searched. Examples are as follows.

  Open ItemContext using the DefaultStore storage platform share on the local computer

与えられたストレージプラットフォーム共有を使用してＩｔｅｍＣｏｎｔｅｘｔを開く

Open an ItemContext using the given storage platform share

ストレージプラットフォーム共有の下のアイテムを使用してＩｔｅｍＣｏｎｔｅｘｔを開く

Open ItemContext using an item under Storage Platform Sharing

複数のアイテムドメインを使用してＩｔｅｍＣｏｎｔｅｘｔを開く

Open an ItemContext using multiple item domains

The ItemContext must be closed when it is no longer needed.
Explicitly close ItemContext

ＩｔｅｍＣｏｎｔｅｘｔを使用してｕｓｉｎｇステートメントを閉じる

Use itemContext to close the using statement

(2) Object Search In accordance with another aspect of the present invention, the storage platform API is based on various properties of items in the data store without the application programmer having to worry about the details of the underlying database engine query language. A simplified query model that can be used to form a query.

  The application is ItemContext. A search can be performed between the specified domains when the ItemContext is opened using the ItemSearcher object returned by the GetSearcher method. Use the FindResult object to access the search results. The following example assumes the following declaration:

The basic search pattern entails using an ItemSearcher object retrieved from the ItemContext by calling the GetSearcher method.
Find all items of a given type

フィルタ条件を満たす与えられた型のアイテムを検索する

Search for items of the given type that satisfy the filter condition

フィルタ文字列内でパラメータを使用する

Use parameters in filter strings

与えられた型を持ち、フィルタ条件を満たす関係を検索する

Search for a relationship that has the given type and satisfies the filter condition

与えられた型を持ち、フィルタ条件を満たす関係を持つアイテムを検索する

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

与えられた型を持ち、フィルタ条件を満たすアイテム拡張を検索する

Search for item extensions that have the given type and satisfy the filter criteria

与えられた型を持ち、フィルタ条件を満たすアイテム拡張を持つアイテムを検索する

Search for items with the given type and item extensions that meet the filter criteria

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

結果カウントを制限する

Limit result count

(B) FindOne and FindOnly
Sometimes it may be useful to retrieve only the first result, especially when a sort condition is specified. In addition, certain searches are expected to return only one object and are not expected to return any objects.
Search for one object

常に存在することが予期される単一オブジェクトを検索する

Find a single object that is expected to always exist

(C) Retrieving ItemContext shortcuts There are also a number of shortcut methods on ItemContext that make performing a simple search as simple as possible.
ItemContext. Search using the FindAll shortcut

ＩｔｅｍＣｏｎｔｅｘｔ．ＦｉｎｄＯｎｅショートカットを使用して検索する

ItemContext. Search using the FindOne shortcut

(D) Search by ID or path In addition, items, relationships, and item extensions can be retrieved by giving their id (s). Items can also be removed by pass.
Get item, relationship, and item extension given id (s)

パスを与えてアイテムを取得する

Get an item by giving a path

(E) GetSearcher pattern There are many places in the storage platform API where it is desirable to provide helper methods to perform searches in the context of other objects or with specific parameters. These scenarios are possible by using the GetSearcher pattern. The API provides a number of GetSearcher methods. Each returns an ItemSearcher that is preconfigured to perform the given search. For example, it is as follows.

検索を実行する前に追加フィルタを付加することができる。

Additional filters can be added before performing the search.

結果をどのような形で望むかを選択することができる。

You can choose how you want the results.

(3) Store update After an object is retrieved by searching, it can be modified by an application as needed. You can also create new objects and associate them with existing objects. After making all the changes that make up the logical group, the application changes the ItemContext. Call Update to make changes to the store permanent. According to yet another aspect of the storage platform API of the present invention, the API collects changes made to items by the application program and then stores them in the database engine (or some kind of storage). Organize into the correct updates required by the engine). This allows application programmers to make changes to items in memory while leaving the complex part of data store updates to the API.
Save changes to a single item

複数アイテムへの変更を保存する

Save changes to multiple items

新しいアイテムを作成する

Create a new item

関係（および可能ならターゲットアイテム）を削除する

Delete relationship (and target item if possible)

アイテム拡張を追加する

Add item extensions

アイテム拡張を削除する

Remove item extensions

6). Security Section II. Referring to E (security), in this embodiment of the storage platform API, there are five methods that can be used on the Item Context to retrieve and modify security policies associated with items in the store. These are as follows.
1. GetItemSecurity,
2. SetItemSecurity,
3. GetPathSecurity,
4). SetPathSecurity,
5). GetEffectiveItemSecurity.

  GetItemSecurity and SetItemSecurity provide a mechanism to retrieve and modify the explicit ACL associated with an item. This ACL is independent of the existing path to the item, and operates regardless of the holding relationship having this item as a target. Thus, an administrator can infer about item security when he wants to do so, regardless of the existing path to the item.

  Since GetPathSecurity and SetPathSecurity have a retention relationship from other folders, they have a mechanism for extracting and correcting ACLs existing on items. This ACL is configured with an explicit ACL if prepared for the path from the ACLs of various ancestors to the item along the path under consideration. The difference between this ACL and the ACL in the previous case is that this ACL operates as long as there is a corresponding holding relationship, although the explicit item ACL is independent of the holding relationship to the item.

  ACLs that can be set on items with SetItemSecurity and SetPathSecurity are restricted to inheritable, object-specific ACEs. They cannot contain ACEs that are marked as inherited.

  GetEffectiveItemSecurity retrieves explicit ACLs on items as well as various path-based ACLs. This reflects a permission policy that affects a given item.

7). Relationship Support As mentioned above, the storage platform data model defines "relationships" that allow items to be related to each other. When a schema data class is generated, the following classes are generated for each type of relationship.
1. A class that represents the relationship itself. This class is derived from the Relationship class and contains members specific to its relation type.
2. A strongly typed “virtual” collection class. This class is derived from VirtualRelationshipCollection, which allows creation and deletion of relationship instances.

  This section describes support for relationships within the storage platform API.

a) Basic Relational Type The storage platform API is the System. Provides a number of types in the Storage namespace. These are as follows.
1. Relationship-the basic type of all relationship classes 2. VirtualRelationshipCollection-the basic type of all relationship collections. ItemReference, ItemIdReference, ItemPathReference—represents an item reference type, and the relationship between these types is illustrated in FIG.

(1) Relation class The following is the base class of relation classes.
public abstract class Relationship: StoreObject
{
// Create with default values.
protected Relationship (ItemIDReference targetItemReference);
// Notify the relationship that it has been added to the relationship collection. The object queries the collection to determine the source item, item context, etc.
internal AddedToCollection (VirtualRelationshipCollection collection);
// Relationship id.
public RelationshipId RelationshipId {get;}
// Source item id.
public ItemId SourceItemId {get;}
// Get the source item.
public Item SourceItem {get;}
// Reference to the target item.
public ItemIdReference TargetItemReference {get;}
// Get the target item (call TargetItemReference.GetItem ()).
public Item TargetItem {get;}
// Determine whether the ItemContext already has a connection with the target item's domain (call TargetItemReference.IsDomainConnected).
public bool IsTargetDomainConnected {get;}
// Name of the target item in the namespace. The name must be unique across all source item retention relationships.
public OptionalValue <string> Name {get; set;}
// Determine if this is a retention or reference relationship.
public OptionalValue <bool> IsOwned {get; set;}

(2) ItemReference class The following is an item reference type base class.
public abstract class ItemReference: NestedElement
{
// Create with default values.
protected ItemReference ();
// Return the referenced item.
public virtual Item GetItem ();
// Determine if connection to the domain of the referenced item has been established.
public virtual bool IsDomainConnected ();
}

  The ItemReference object can identify items that exist in a store different from the store in which the item reference itself is located. Each derived type specifies how to build and use a reference to a remote store. The implementation of GetItem and IsDomainConnected in a derived class uses ItemContext's multi-domain support to load items from the required domain and determine whether a connection with the domain has already been established.

(3) ItemIdReference class The following is an ItemIdReference class-an Item reference that uses an item id to identify a target item.
public class ItemIdReference: ItemReference
{
// Construct a new ItemIdReference with default values.
public ItemIdReference ();
// Construct a new ItemIdReference for the specified item. The domain associated with the Item is used as a locator.
public ItemIdReference (Item item);
// Construct a new ItemIdReference using a NULL locator and the given target item id.
public ItemIdReference (Itemld itemId);
// Construct a new ItemIdReference using the given locator and item id value.
public ItemIdReference (string locator, ItemId itemId);
// id of the target item.
public ItemId ItemId {get; set;}
// Path that identifies the WinFS item that contains the target item in the domain. In the case of NULL, the domain containing the item is not known.
public OptionalValue <string> Locator {get; set;}
// Determine if connection to the domain of the referenced item has been established.
public override bool IsDomainConnected ();
// Retrieve the referenced item.
public override Item Getitem ();
}

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

(4) ItemPathReference class The ItemPathReference class is an item reference that identifies a target item using a path. The code for this class is as follows:
public class ItemPathReference: ItemReference
{
// Construct an item path reference with default values.
public ItemPathReference ();
// Construct an item path reference with the given path without a locator.
public ItemPathReference (string path);
// Construct an item path reference with the given locator and path.
public ItemPathReference (string locator, string path);
// Path that identifies the WinFS item that contains the target item in the domain.
public OptionalValue <string> Locator {get; set;}
// The target item path for the item domain specified by the locator.
public string Path {get; set;}
// Determine if connection to the domain of the referenced item has been established.
public override bool IsDomainConnected ();
// Retrieve the referenced item.
public override Item GetItem ();
}

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

(5) RelationshipId structure The RelationshipId structure encapsulates the relation id GUID.
public class RelationshipId
{
// Create a new relation id GUID.
public static RelationshipId NewRelationshipId ();
// Initialize with new relationship id GUID.
public RelationshipId ();
// Initialize with the specified GUID.
public RelationshipId (Guid id);
// Initialize with GUID string representation.
public RelationshipId (string id);
// Return the string representation of the relation id GUID.
public override string ToString ();
// System. Convert a Guid instance to a RelationshipId instance.
public static implicit operator RelationshipId (Guid guid);
// RelationshipId instance to System. Convert to a Guid instance.
public static implicit operator Guid (RelationshipId relationshipId);
}

  This value type wraps the GUID so that parameters and properties can be strongly typed as relation ids. If the relationship id is nullable, then the OptionalValue <RelationshipId> must be used. System. Guid. Null values as given by Empty are not exposed. RelationshipId cannot be constructed with an empty value. When creating a RelationshipId using the default constructor, a new GUID is created.

(6) VirtualRelationshipCollection class The VirtualRelationshipCollection class implements a collection of relationship objects that includes objects from the data store plus any new objects that have been added to the collection, but do not include objects that have been removed from the store. Objects of the specified relationship type with the given source item id are included in the collection.

  This is the base class for the relation collection class that is generated for each relation type. That class can be used as a property type in the source item type to access and manipulate the relationship of a given item.

  To enumerate the contents of a VirtualRelationshipCollection, a potentially large number of relationship objects need to be loaded from the store. An application should use the Count property to determine how many relationships can be loaded before enumerating the contents of the collection. Adding objects to the collection and removing objects from the collection does not require the relationship to be loaded from the store.

  In order to increase efficiency, it is preferable to search on the application side for a relationship that satisfies a specific criterion instead of enumerating all the item relationships using the VirtualRelationshipCollection object. Adding a relationship object to the collection causes ItemContext. The relationship expressed when Update is called is created in the store. When a relationship object is deleted from the collection, ItemContext. The relationship expressed when Update is called is deleted in the store. The virtual collection is the Item. Contains the correct set of objects regardless of whether the relationship objects are added / removed through the Relationships collection or other relationship collections.

The following code defines the VirtualRelationshipCollection class.
public abstract class VirtualRelationshipCollection: ICollection
{
// The collection contains a specified type of relationship owned by the item identified by itemId.
protected VirtualRelationshipCollection (ItemContext itemContext, ItemId itemId, Type relationshipType);
// The enumerator returns all objects retrieved from the store except for objects with state Deleted in addition to objects with state Inserted.
public IEnumerator GetEnumerator ();
// Returns a count of the number of related objects that will be returned by the enumerator. This count is calculated without retrieving all objects from the store.
public int Count {get;}
// Always return false.
public bool ICollection.lsSynchronized () {get;}
// Always return this object.
public object ICollection.SyncRoot {get;}
// Search for the required object in the store.
public void Refresh ();
// Add the specified relationship to the collection. The object must have the state Constructed or Removed. If the state is Constructed, the state is changed to Added. If the state is Removed, the state is appropriately changed to Retrieved or Modified. The source item id of this relationship must be the same as the source item id given when the collection was constructed.
protected void Add (Relationship relationship);
// Remove the specified relationship from the collection. The state of the object must be Added, Retrieved, or Modified. If the state of the object is Added, this is set to Constructed. If the state of the object is Retrieved or Modified, this is set to Removed. The source item id of this relationship must be the same as the source item id given when the collection was constructed.
protected void Remove (Relationship relationship);
// Object removed from collection.
public ICollection RemovedRelationships {get;}
// An object added to the collection.
public ICollection AddedRelationships {get;}
// Object retrieved from the store. This collection is empty until VirtualRelationshipCollection is enumerated or Refresh is called (getting the value of this property does not write the collection).
public ICollection StoredRelationships {get;}
// Asynchronous method.
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 Relational Type When creating a storage platform schema class, one class is created for each relational declaration. In addition to the classes representing the relationships themselves, relationship collection classes are also generated for each relationship. These classes are used as the types of properties in the relationship's source or target item class.

  This section describes a class that is generated using a number of "prototype" classes. That is, a class that is generated when a specified relationship declaration is given will be described. Note that the class, type, and endpoint names used in the prototype class are placeholders for the names specified in the schema for the relationship and should not be interpreted literally.

(1) Generated relational types This section describes the classes generated for each relational type. For example, it is as follows.

  Given this relationship definition, RelationshipPrototype and RelationshipPrototypeCollection classes are generated. The RelationshipPrototype class represents the relationship itself. The RelationshipPrototypeCollection class provides access to a RelationshipPrototype instance that has an item specified as the source endpoint.

(2) RelationshipPrototype class This is a prototype relationship class for a holding relationship named “HoldingRelationshipPrototype”, the source endpoint has the name “Head”, the “Foo” item type is specified, and the target endpoint is “Tail” Has a name and specifies the “Bar” item type. This is defined as follows:

（３）ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅＣｏｌｌｅｃｔｉｏｎクラス
これは、指定されたアイテムにより所有されるＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅ関係インスタンスのコレクションを保持する、ＲｅｌａｔｉｏｎｓｈｉｐＰｒｏｔｏｔｙｐｅクラスで生成された、プロトタイプクラスである。これは以下のように定義される。

(3) RelationshipPrototypeCollection class This is a prototype class generated by the RelationshipPrototype class that holds a collection of RelationshipPrototype relationship instances owned by a specified item. This is defined as follows:

c) Relationship support in the Item class The Item class includes a Relationships property that allows the item to access the relationship that is the source of the relationship. The Relationships property has the type RelationshipCollection.

(1) Item class The following code shows the related context properties of the Item class.

(2) RelationshipCollection class This class allows access to a relationship instance where a given item is the source of the relationship. This is defined as follows:

d) Relationship support in search expressions In a search expression, it is possible to specify traversals of joins between items associated with relationships.

(1) Traversing from Item to Relationship If the current context of the search expression is a set of items, the connection between the item from which the item is the source and the relationship instance is Item. This can be done using the Relationships property. Bindings to specific types of relationships can be specified using the search expression Cast operator.

  Strongly typed relationship collections (eg, Folder.MemberRelationships) can also be used in the search expression. Type conversions to relational types are implicit.

  After the set of relationships is established, the properties of the relationship can be used in the predicate or can be used as a projection target. When used to specify a projection target, a set of relationships is returned. For example, the following statement finds all persons associated with an organization whose relationship's StartDate property had a value greater than “1/1/2000”:

  If the Person type had a property EmployeeContext of type EmployeeSideEmployeeEmployeeRelationships (as generated for the EmployeeEmployee relationship type), this could be written as:

(2) Traversing from relationship to item If the current context of the search expression is a set of relationships, the connection from the relationship to any endpoint of the relationship can be traversed by specifying the name of the endpoint. After the set of related items is established, the properties of those items can be used in predicates or as projection targets. When used to specify a projection target, a set of items is returned. For example, the following statement finds all EmployeeOfOrganization relationships (regardless of organization) where the employee's last name is “Smith”.

  The search expression Cast operator can be used to filter the type of endpoint item. For example, to find all MemberOfFolder relationship instances whose members are Person items with the surname "Smith":

(3) Combinations of relationship traverses Any number of complex traverses can be obtained by combining two patterns before traversing from item to relationship and from relationship to item. For example, to find all organizations that include an employee whose surname is “Smith”:

  In the following example, find all Person items that represent members of households residing in the “New York” area (TODO: this is no longer supported ... alternative).

e) Example usage of relationship support The following shows an example usage of relationship support in the storage platform API for manipulating relationships. The following example assumes the following declaration:

(1) Relationship search It is possible to search a source or target relationship. By using a filter, it is possible to select a relationship having a specified type and given a property value. Also, by using filters, relationship-based related item types or property values can be selected. For example, the following search can be performed.
All relationships where the given item is the source

与えられたアイテムが「Ａ％」とマッチする名前を持つソースであるすべての関係

All relationships where the given item is a source with a name that matches "A%"

与えられたアイテムがソースであるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係

All FolderMember relationships whose source is the given item

与えられたアイテムがソースであり、名前が「Ａ％」のような名前であるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係

All FolderMember relationships where the given item is the source and the name is something like "A%"

ターゲットアイテムがＰｅｒｓｏｎであるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係

All FolderMember relationships where the target item is Person

ターゲットアイテムが姓「Ｓｍｉｔｈ」を持つＰｅｒｓｏｎであるすべてのＦｏｌｄｅｒＭｅｍｂｅｒ関係

All FolderMember relationships where the target item is Person with the surname "Smith"

  In addition to the GetSearcher API shown above, each relationship class supports static FindAll, FindOne, and FindOnly APIs. Furthermore, the relation type is ItemContext. GetSearcher, ItemContext. FindAll, ItemContext. FindOne, or ItemContext. Can be specified when FindOnly is called.

(2) Navigating from relationship to source and target item After a relationship object is retrieved through a search, it is possible to “navigate” to the target or source item. The base relationship class has a SourceItem and TargetItem property that returns an Item object. The generated relationship class has equivalent strongly-typed named properties (eg, FolderMember.FolderItem and FolderMember.MemberItem). For example, it is as follows.
Navigate to the source and target items for the relationship with the name “Foo”

ターゲットアイテムにナビゲートする

Navigate to the target item

Navigating to a target item works even if the target item is not in the domain where the relationship was found. In such a case, the storage platform API opens a connection to the target domain as needed. The application can determine whether a connection is required before retrieving the target item.
Check target items in unconnected domains

(3) Navigating from a source item to a relationship Given an item object, it is possible to navigate to the relationship in which the item is the source without performing an explicit search. This is the same as Folder. Item Relations such as MemberRelationships. Implemented using Relationships collection properties or strongly typed collection properties. From the relationship, it is possible to navigate to the target item. Such navigation works even when the target item is not in the item domain associated with the Item Context of the source item, including when the target item is not in the same store as the target item. For example, it is as follows.
Navigate to the relationship from the source item to the target item

ＦｏｌｄｅｒアイテムからターゲットアイテムへのＦｏｌｄｅｒｍｅｍｂｅｒ関係にナビゲートする

Navigate to the Foldermember relationship from the Folder item to the target item

Items can have a large number of relationships, so applications should be careful when enumerating relationship collections. In general, searches should be used to identify specific relationships of interest rather than enumerating the entire collection. In addition, having a collection-based programming model for relationships is well worth it, there are items that are rare enough for many relationships, and the risk of misuse by developers is justified. The application can check the number of relationships in the collection and use different programming models if necessary. For example, it is as follows.
Check the size of the relationship collection

  The relationship collection described above is “virtual” in the sense that unless the application attempts to enumerate the collection, the objects representing the respective relationships are not actually embedded as initial values. When a collection is enumerated, the results reflect what was added by the application but not yet saved, in addition to what is in the store, but for relationships that were deleted by the application but not saved do not do.

(4) Creating a relationship (and item) A new relationship is created by creating a relationship object, adding it to the relationship in the source item, and updating the ItemContext. To create a new item, you must create a hold or embed relationship. For example, it is as follows.
Add a new item to an existing folder

既存のアイテムを既存のフォルダに追加する

Add an existing item to an existing folder

既存のアイテムを新しいフォルダに追加する

Add an existing item to a new folder

新しいアイテムを新しいフォルダに追加する

Add new items to a new folder

(5) Deleting relationships (and items) Deleting retention relationships

8). "Extension" of storage platform API
As described above, the result of all storage platform schemas is a set of classes. These classes have standard methods such as Find * and also provide 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, every schema has a set of domain specific methods for it. These are called domain behaviors. For example, the following is an example of a domain behavior in the Contacts schema.
• Is your email address valid?
• Given a folder, get a collection of all members of that folder.
-When an item ID is given, an object representing this item is acquired.
• If a Person is given, get its online status.
-Helper function to create new or temporary contacts.
・ Others.

  It distinguishes between “standard” behaviors (such as Find *) and domain behaviors, but it is important to note that these appear simply to the programmer as methods. The distinction between these methods is in the fact that the domain behavior is hard-coded, but the standard behavior is automatically generated from the schema file by the storage platform API design time tool.

  Due to their nature, these domain behaviors must be handmade. For this reason, in the initial version of C #, there arises a practical problem that the entire class implementation needs to be contained in one file. Therefore, this forces the automatically generated class file to be edited in order to add domain behavior. Naturally, this can be a problem.

  A function called partial class was introduced in C # because of such problems. Basically, by using partial classes, class implementations can span multiple files. The partial class is the same as the regular class except that the keyword partial is added before the declaration.

  Thus, domain behavior for Person can be put into different files in this way.

b) Value-added behaviors Data classes with domain behaviors form the basis for application developers. However, it is not possible or desirable for a data class to expose all possible behaviors related to that data. In the storage platform, the developer can use the basic functions provided by the storage platform API as a scaffold. Here, the basic pattern is that the method creates a class that takes one or more of the storage platform data classes as parameters. For example, the value added classes for sending e-mail using Microsoft Outlook or using Microsoft Windows® messenger can be as follows:

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

  Value-added class registration is a powerful feature, for example, when you right-click a Person object in a Shell explorer, you can derive a set of allowed actions from the value-added class registered for Person. The scenario is possible.

c) Value Added Behavior as a Service Provider In an embodiment of the present invention, the storage platform API includes a mechanism that allows a value added class to be registered as a “service” for a given type. Thereby, the application can set and acquire a given type of service provider (= value added class). Value added classes that want to use this mechanism should implement well-known interfaces, for example:

  All storage platform API data classes implement the ICachedServiceProvider interface. This interface is similar to the System. Extends the ISServiceProvider interface.

  Using this interface, an application can request a specific type of service provider in addition to setting a service provider instance.

  In order to support this interface, the storage platform data class maintains a service provider hash table keyed by type. When a service provider is requested, this implementation first looks in the hash table to see if a service provider of the specified type has been set up. If not set, the registered service provider infrastructure is used to identify the specified type of service provider. An instance of this provider is then created, added to the hash table, and returned. Note also that shared methods on the data class can request a service provider and forward operations to that provider. For example, it could be used to provide a Send method on a mail message class that uses an email system specified by the user.

9. Design Time Framework This section describes how a storage platform Schema changes to a storage platform API class on the client and a UDT class on the server, according to embodiments of the present invention. The diagram of FIG. 24 shows the components involved.

  Referring to FIG. 24, the types in the schema are included in the XML file (box 1). This file also includes field level and item level constraints associated with the schema. The storage platform class generator (xfs2cs.exe-box 2) takes this file and generates a partial class for the store UDT (box 5) and a partial class for the client class (box 3). There is an additional method for each schema domain, which is called a domain behavior. There are meaningful domain behaviors in the store (box 7), client (box 6), and both locations (box 4). The codes in boxes 4, 6, and 7 are handwritten (not automatically generated). The partial classes in boxes 3, 4 and 6 together form a complete class implementation of the storage platform API domain class. Boxes 3, 4, and 6 are compiled (box 8) to form the storage platform API class-box 11 (in fact, the storage platform API is derived from all initial schema domains, boxes 3, 4, and 6 is the result of compiling 6). In addition to domain classes, there are also additional classes that implement value-added behaviors. These classes use one or more classes within one or more schema domains. This is represented by box 10. The partial classes in boxes 4, 5, and 7 together form a complete class implementation of the server UDT class. Boxes 4, 5, and 7 are compiled (box 9) to form the server side UDT assembly-box 12 (in practice, the server side UDT assembly is derived from all initial schema domains, box 4, 5, And 7 is a compiler-plus-ing result). The DDL command generator module (box 13) takes the UDT assembly (box 12) and the Schema file (box 1) and stores them on the data store. This process involves, among other things, the generation of tables and views for the types in each schema.

10. Query formalism
When reduced to basic, the application pattern is that when using the storage platform API, opening an ItemContext, using Find with a filter condition, retrieving the desired object, performing operations on the object, and storing changes To send it back to. This section concerns the syntax of what goes into the filter string.

  The filter string provided when finding a storage platform data object describes the conditions that the object's properties must meet in order to be returned. The syntax used in the storage platform API supports type conversion and relation traversal.

a) Filter Basics The filter string is empty and indicates that all objects of the specified type are returned or is a logical expression that each returned object must satisfy. This expression refers to the object property. The storage platform API runtime knows how these property names are mapped to storage platform type field names and ultimately to the SQL view maintained by the storage platform store.

  Consider the following example.

  Nested object properties can also be used in filters. For example, it is as follows.

  For collections, members can be filtered using conditions in square brackets. For example, it is as follows.

  The following example creates a list of all people born after 12/31/1999.

  The first line creates a new ItemContext object that accesses “Work Contacts” on the storage platform share of the local computer. In the third and fourth lines, as specified by the expression “Birthdate> '12 / 31/1999 '”, a collection of Person objects whose Birthdate property specifies a date more recent than 12/31/1999 is specified. get. The execution of this FindAll operation is shown in FIG.

b) Type Casts
Often, the type of the value stored in a property is derived from the property declaration type. For example, the PersonalEAddresses property in Person includes a collection of types derived from EAddress, such as EMailAddress and TelephoneNumber. In order to perform filtering based on the telephone area code, it is necessary to convert the type from the EAddress type to the Telephone Number type.

c) Filter Syntax The following describes the filter syntax supported by the storage platform API, according to one embodiment.

11. Remoting a) Local / Remote Transparency in API Storage platform data access is targeted to the local storage platform instance. A local instance is used as a router when a query (or part of it) references remote data. Therefore, the API layer has local / remote transparency, and there is no structural difference in API between local data access and remote data access. This is purely a function of the requested scope.

  The storage platform data store also implements distributed queries, so it connects to instances on the local storage platform and executes queries that contain items from different volumes, one on the local store and the other on the remote store Is possible. The store merges the results and presents them to the application. From the perspective of the storage platform API (and therefore the application developer), any remote access is completely seamless and transparent.

  By using the storage platform API, the application can use a given ItemContext object (as returned by the ItemContext.Open method) using the IsRemote property-which is a property on the ItemContext object-or Whether to represent a remote connection can be determined. In particular, an application may want to provide visual feedback to help set user expectations for performance, reliability, etc.

b) Remoting storage platform implementation The storage platform data stores interact with each other using a special OLEDB provider running over HTTP (the default OLEDB provider uses TDS). In one embodiment, the distributed query is applied the default OPENROWSET function of the relational database engine. A special user-defined function (UDF) and DoRemoteQuery (server, queryText) are prepared to execute actual remoting.

c) Access to non-storage platform stores In one embodiment of the storage platform of the present invention, there is no general provider architecture that allows the store to participate in storage platform data access. However, a limited provider architecture is provided for the specific cases of Microsoft Exchange and Microsoft Active Directory (AD). This means that the developer can access the data in AD and Exchange using the storage platform API, just as it is in the storage platform, but the accessible data is schematized in the storage platform. Means restricted to type. Thus, the address book (= personal collection of storage platforms) is supported by AD, and mail, calendar, and contacts are supported for Exchange.

d) Relationship to DFS The storage platform property promoter does not upgrade past mount points. Even if the namespace is rich enough to be accessed through mount points, the query will not pass through them. Storage platform volumes can appear as leaf nodes in the DFS tree.

e) Relationship with GXA / Indigo Developers can publish “GXA head” on top of a data store using the storage platform API. Conceptually, this is no different from creating other web services. The storage platform API does not interact with the storage platform data store using GXA. As described above, the API interacts with the local store using TDS, and any remoting is handled by the local store using a synchronization service.

12 Constraints The storage platform data model can have value constraints on types. Those constraints are automatically evaluated on the store, and this process is transparent to the user. Note that the constraints are checked on the server side. With this in mind, it is sometimes desirable to provide the developer with the flexibility to confirm that the input data meets the constraint conditions without incurring the overhead of a round trip to the server. This is essentially useful in interactive applications where the end user enters data that is used to embed in the object. The storage platform API realizes this function.

  Note that the storage platform Schema used by the storage platform to generate the appropriate database objects that represent the schema is specified in the XML file. This is also used by the storage platform API design time framework to automatically generate classes.

  The following is a partial listing of an XML file used to generate a Contacts schema.

  The Check tag in the above XML specifies a constraint on the Person type. There can be multiple check tags. The above constraints are generally checked in the store. To specify that the constraint can be further explicitly checked by the application, the XML is modified as follows.

  Note the new “InApplication” attribute on the <Check> element that is set to true. As a result, the storage platform API reveals restrictions on the API through an instance method on the Person class called Validate (). An application can call this method on an object to verify that the data is valid and eliminate any potentially useless interaction with the server. This returns a Boolean value indicating the result of the validation. The value constraint condition is that the client sets <object>. Note that it is applied to the server as is, regardless of whether the Validate () method is called. An example of using Validate is shown below.

  There are multiple access paths to the storage platform store-storage platform API, ADO. NET, ODBC, OLEDB, and ADO. This raises the question of whether it is a reliable constraint check--that is, for example, which data written from the ODBC is subject to the same data integrity constraints as the data written from the storage platform API. Can you guarantee? Since all constraints are checked on the store side, the constraints are reliable. Regardless of what API path is used to reach the store, all writes to the store are filtered through constraint checks at the store.

13. Sharing Storage platform sharing

の形式であり、ただし、＜ＤＮＳ Ｎａｍｅ＞はマシンのＤＮＳ名、＜Ｃｏｎｔｅｘｔ Ｓｅｒｖｉｃｅ＞は、そのマシン上の包含フォルダ、仮想フォルダ、またはボリューム内のアイテムである。例えば、マシン「Ｊｏｈｎｓ＿Ｄｅｓｋｔｏｐ」は、Ｊｏｈｎｓ＿Ｉｎｆｏｒｍａｔｉｏｎというボリュームを持ち、このボリューム内には、Ｃｏｎｔａｃｔｓ＿Ｃａｔｅｇｏｒｉｅｓというフォルダが存在し、このフォルダは、Ｗｏｒｋというフォルダを含み、これには、Ｊｏｈｎの仕事用連絡先

Where <DNS Name> is the DNS name of the machine and <Context Service> is an item in the containing folder, virtual folder, or volume on that machine. For example, the machine “Johns_Desktop” has a volume called “Johns_Information”, and a folder called “Contacts_Categories” exists in this volume.

が入っている。これは、「ＷｏｒｋＣｏｎｔａｃｔｓ」として共有することができる。この共有の定義では、＼＼Ｊｏｈｎｓ＿Ｄｅｓｋｔｏｐ＼ＷｏｒｋＣｏｎｔａｃｔｓ＼ＪａｎｅＳｍｉｔｈは、有効なストレージプラットフォーム名であり、ＰｅｒｓｏｎアイテムＪａｎｅＳｍｉｔｈを識別する。

Is included. This can be shared as “WorkContacts”. In this share definition, \\ Johns_Desktop \ WorkContacts \ JaneSmith is a valid storage platform name and identifies the Person item JaneSmith.

a) Representation of a share A shared item type has properties of a share name and a share target (which may be a non-retaining link). For example, the share name described above is WorkContacts and the target is Contacts_Categories \ Work on the volume Johns_Information. The Share type schema fragment is shown below.

b) Sharing management Since sharing is an item, sharing can be managed just like any other item. Shares can be created, deleted, and modified. Sharing is further secured in the same way as other storage platform items.

c) Shared access application is ItemContext. Access the remote storage platform share by passing the share name (eg, \\ Johns_Desktop \ WorkContacts) to the storage platform API in the Open () method call. ItemContext. Open returns an ItemContext object instance. The storage platform API then interacts with the local storage platform service (note that access to the remote storage platform share is through the local storage platform). The local storage platform service then interacts with the remote storage platform service (eg, on the machine Johns_Desktop) using the given share name (eg, WorkContacts). The remote storage platform service then translates WorkContacts to Contacts_Categories \ Work and opens it. Thereafter, queries and other operations are performed just like any other scope.

d) Discoverability In one embodiment, an application program can discover available shares on a given <DNS Name> as follows. According to the first method, the storage platform API sets the DNS name (eg, Johns_Desktop) to ItemContext. Accepted as a scope parameter of the Open () method. The storage platform API then connects to the storage platform store using this DNS name as part of the connection string. With this connection, the only thing an application can do is use ItemContext. Call FindAll (typeof (Share)). The storage platform service then merges all shares on all connected volumes and returns a collection of shares. According to the second method, on the local machine, the administrator can specify a specific volume by FindAll (typeof (Share)) or by FindAll (typeof (Share), “Target (ShareDestination) .Id = folderId”). Shares on folders can be easily found.

14 Find Meaning The Find * method (whether called on an ItemContext object or on an individual item) generally applies to Items (including embedded items) within a given context. . Nested elements do not have a Find-they cannot be searched regardless of the containing Item. This is consistent with the desired meaning in the storage platform data model, where the nested element derives its “identity” from the containing item. To make this concept clearer, examples of valid and invalid find operations are given below.
a) Display all phone numbers in the system with area code 206?
Invalid, because find is performed on a phone number-element without referring to the item.
b) Display all phone numbers in all Persons with area code 206?
Even if invalid, Person (= item) is referred to, the search condition does not include the item.
c) Display all phone numbers of all Murali (= 1 person) with area code 206?
Valid, because there is a search condition for Item (Person named “Murali”).

  An exception to this rule is Base. For nested element types that are derived directly or indirectly from Relationship types. These types can be individually queried through relational classes. Such a query can be supported because the storage platform implementation uses a “master link table” to store the Relationship element instead of embedding it in the item UDT.

15. Storage Platform Contacts API
This section outlines the storage platform Contacts API. The schema behind the Contacts API is shown in FIGS. 21A and 21B.

a) System. Storage. Contact Overview The storage platform API includes a namespace for handling items and elements in the Contacts schema. This namespace is System. Storage. It is called Contact.

This schema has the following classes, for example.
Item: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location
-Elements: Profile, PostAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupe.

b) Domain Behaviors The following is a list of domain behaviors in the Contacts schema. When viewed from a sufficiently high level, domain behaviors fall into the following appropriately recognizable categories:
A static helper, eg Person. For creating new personal contacts. CreatePersonalContact (),
An instance helper, for example, user.login that logs a user (an instance of the User class) into all profiles marked for automatic login. AutoLoginToAllProfiles (),
-Category GUIDs, for example, Category. Home, Category. Work etc.
Derived properties, for example emailAddress. Address () —A derived collection that returns a string that combines the username and domain fields of a given emailAddress (= an instance of the EmailAddress class), eg, person. If an instance of the PersonalEmailAddress-Person class is given, its personal email address is acquired.

  The following table summarizes the list of methods and the categories to which they belong, for each class in Contacts with domain behavior.

16. Storage platform File API
This section provides an overview of the storage platform File API according to one aspect of the present invention.

a) Introduction (1) Reflection of NTFS volume in storage platform The storage platform includes means for creating an index on the contents in an existing NTFS volume. This is done by extracting (“upgrading”) properties from each file stream or directory in NTFS and storing those properties as Items in the storage platform.

  The storage platform File schema defines two item types—File and Directory—to store promoted file system entities. The Directory type is a child type of the Folder type and is an inclusion folder including other Directory items or File items.

  Directory items can include Directory and File items, but cannot include any other type of item. As far as the storage platform is concerned, the Directory and File items are read-only from any of the data access APIs. The File System Promotion Manager (FSPM) service asynchronously promotes changed properties into the storage platform. The properties of File and Directory items can be changed by the Win32 API. The storage platform API can be used to read the properties of those items, including streams associated with File items.

(2) Creation of files and directories within the storage platform namespace When an NTFS volume is promoted to a storage platform volume, all files and directories within it become a specific part of the volume. This area is read-only from the storage platform perspective, and FSPM can create new directories and files and / or modify the properties of existing items.

  The remainder of the volume's namespace can include the normal range of storage platform item types—Principal, Organization, Document, Folder, etc. The storage platform can also create multiple files and directories in a portion of the storage platform namespace. These “native” files and directories do not have a corresponding one on the NTFS file system side, and are stored entirely in the storage platform. In addition, changes to properties appear immediately.

However, the programming model remains the same, that is, as far as the storage platform data access API is concerned, it is read-only. The “native” File and Directory must be updated using the Win32 API. This simplifies the developer's mental model as follows:
1. You can create storage platform item types anywhere in the namespace (unless of course prohibited by permissions).
2. Storage platform item types can be read using the storage platform API.
3. All storage platform item types can be written using the storage platform API, with the exception of File and Directory.
4). Use the Win32 API to write to File and Directory items regardless of where they are in the namespace.
5). Changes to File / Directory in a “promoted” namespace may not appear immediately in the storage platform, but in a “non-promoted” namespace, changes are immediately reflected in the storage platform The

b) File Schema FIG. 25 illustrates a schema based on the File API.

c) System. Storage. Overview of Files The storage platform API includes a namespace for handling file objects. This namespace is System. Storage. Called Files. System. Storage. The data members of the Files class directly reflect the information stored in the storage platform store, which can be “upgraded” from the file system object or created natively using the Win32 API. be able to. System. Storage. The Files namespace has two classes: FileItem and DirectoryItem. The members of these classes and their methods can be easily guessed by looking at the schema diagram of FIG. FileItem and DirectoryItem are read-only from the storage platform API. To modify them, use the Win32 API or use System. It is necessary to use the IO class.

d) Code Example In this section, System. Storage. Take three code examples that illustrate the use of classes within Files.

(1) Opening and writing a file This embodiment shows a "conventional" file operation method.

  In line 3, the file is opened using the FindByPath method. Line 7 indicates that the promoted property IsReadOnly is used to check whether the file is writable. If it is writable, the file stream is acquired by using OpenWrite () on the FileItem object in the ninth line.

(2) Use of queries The storage platform store holds properties promoted from the file system, so that rich queries can be easily executed on files. In this embodiment, a list of all files modified within the last three days is displayed.

  Below is another example of the use of a query-this finds all writable files of a certain type (= extension).

e) Domain Behavior In one embodiment, the file class has domain behavior (handwritten coding properties and methods) in addition to the standard properties and methods. These behaviors are generally described in the corresponding System. Based on methods in the IO class.

J. et al. Summary As illustrated above, the present invention is directed to a storage platform for organizing, retrieving, and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file and database systems, and includes structures such as relational (tabular) data, XML, and new data forms called Items. Designed to be a store for all types of data, including structured, unstructured, or semi-structured data. The storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses through a common storage infrastructure and schematized data. This not only makes the functionality specific to the data model available, but also includes a rich and extensible application programming interface that encompasses and extends existing file systems and database access methods. It will be understood that modifications may be made to the embodiments described above without departing from the broad concepts of the present invention. Accordingly, the invention is not limited to the specific embodiments disclosed, but is intended to cover all modifications within the spirit and scope of the invention as defined by the appended claims.

  As will be apparent from the foregoing, all or some of the various systems, methods, and aspects of the present invention may be embodied in the form of program code (ie, instructions). The program code includes, but is not limited to, a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or other machine-readable storage medium. Can be stored on a computer readable medium, such as a magnetic, electrical, or optical storage medium, and when the program code is loaded and executed in a machine such as a computer or server, the machine is adapted to practice the invention. It becomes a device. The invention is further embodied in the form of program code transmitted in some transmission medium, such as electrical or cable wiring, the use of optical fibers, networks including the Internet or Intranet, or via other forms of transmission. When the program code is received, read and executed by a machine such as a computer, the machine becomes an apparatus for carrying out the present invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

  Appendix A

ＩｔｅｍＣｏｎｔｅｘｔ作成および管理メンバ
//アプリケーションは、ＩｔｅｍＣｏｎｔｅｘｔオブジェクトを直接作成できず、またＩｔｅｍＣｏｎｔｅｘｔからクラスを派生させることもできない。
interal ItemContext();
//指定されたパス、またはパスが指定されていない場合には、ローカルコンピュータ上の既定のストアを検索するために使用できるＩｔｅｍＣｏｎｔｅｘｔを作成する。
public static ItemContext Open();
public static ItemContext Open(string path);
public static ItemContext Open(params string[] paths);
//ＩｔｅｍＣｏｎｔｅｘｔが作成された場合に指定されたパスを返す。
public string[] GetOpenPaths();
//このＩｔｅｍＣｏｎｔｅｘｔのコピーを作成する。コピーは、独立のトランザクション、キャッシュ、および更新状態を持つ。キャッシュは、最初は空になる。クローン作成されたＩｔｅｍＣｏｎｔｅｘｔを使用することは、同じ（複数の）アイテムドメインを使用して新しいＩｔｅｍＣｏｎｔｅｘｔを開くことよりも効率的であると予想される。
public ItemContext Clone();
//ＩｔｅｍＣｏｎｔｅｘｔを閉じる。閉じられた後にＩｔｅｍＣｏｎｔｅｘｔを使用しようとすると、ＯｂｊｅｃｔＤｉｓｐｏｓｅｄＥｘｃｅｐｔｉｏｎが発生する。
public void Close();
void IDisposable.Dispose();
//ＩｔｅｍＣｏｎｔｅｘｔが開かれたときに指定されたドメインがリモートコンピュータに解決する場合にＴｒｕｅ。
public bool IsRemote {get;}
//要求されたサービス型を供給することができるオブジェクトを返す。要求されたサービスを提供できない場合にはＮＵＬＬを返す。ＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒパターンを使用すると、通常は使用されない、また使用すれば開発者を混乱させる可能性のあるＡＰＩをＩｔｅｍＣｏｎｔｅｘｔクラスから取り除くことができる。ＩｔｅｍＣｏｎｔｅｘｔは、サービスＩＩｔｅｍＳｅｒｉａｌｉｚａｔｉｏｎ、ＩＳｔｏｒｅＯｂｊｅｃｔＣａｃｈｅを提供することができる。
public object GetService(Type serviceType);
関係するメンバを更新する
//修正されたすべてのオブジェクトおよびＭａｒｋＦｏｒＣｒｅａｔｅまたはＭａｒｋＦｏｒＤｅｌｅｔｅに渡されるすべてのオブジェクトにより表される変更を保存する。更新競合が検出された場合にはＵｐｄａｔｅＣｏｌｌｉｓｉｏｎＥｘｃｅｐｔｉｏｎをスローすることがある。
public void Update();
//指定されたオブジェクトにより表される変更を保存する。オブジェクトは、修正されたか、またはＭａｒｋＦｏｒＣｒｅａｔｅまたはＭａｒｋＦｏｒＤｅｌｅｔｅに渡されていなければならないが、そうでなければＡｒｇｕｍｅｎｔ−Ｅｘｃｅｐｔｉｏｎがスローされる。更新競合が検出された場合にはＵｐｄａｔｅＣｏｌｌｉｓｉｏｎＥｘｃｅｐｔｉｏｎをスローすることがある。
public void Update(object objectToUpdate);
public void Update(IEnumerable objectsToUpdate);
//ストアからの指定されたオブジェクトの内容をリフレッシュする。オブジェクトが修正されている場合、変更は上書きされ、オブジェクトはもはや修正されたとみなされない。アイテム、アイテム拡張、または関係オブジェクト以外のものが指定されている場合、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public void Refresh(object objectToRefresh);
public void Refresh(IEnumerable objectsToRefresh);
//修正されたオブジェクトが取り出されたときから、それを保存しようとしたときまでの間にストア内でデータが変更されたことを更新で検出した場合に発生する。イベントハンドラが登録されていないない場合、更新は例外をスローする。イベントハンドラが登録されている場合、例外をスローし、更新を中断することができ、それにより、修正されたオブジェクトはストア内のデータを上書きするか、またはストアおよびオブジェクト内で加えられた変更をマージする。
public event ChangeCollisionEventHandler UpdateCollision;
//更新処理中の様々な時点において発生し、更新進捗情報を供給する。
public event UpdateProgressEventhandler UpdateProgress;
//Ｕｐｄａｔｅの非同期バージョン
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);
//Ｒｅｆｒｅｓｈの非同期バージョン
public IAsyncResult BeginRefresh(object objectToRefresh, IAsyncCallback callback, object state);
public IAsyncResult BeginRefresh(IEnumerable objectsToRefresh, IAsyncCallback callback, object state);
public void EndRefresh(IAsyncResult result);
関係メンバのトランザクション処理
//指定された孤立レベルを持つトランザクションを開始する。既定の孤立レベルはＲｅａｄＣｏｍｍｉｔｅｄである。すべての場合において、分散トランザクションが開始されるが、それは、変更ストリーム型付きアイテムプロパティを包含しなければならない場合があるからである。
public Transaction BeginTransaction();
public Transaction BeginTransaction(System.Data.IsolationLevel isolationLevel);
関係メンバを検索する
//指定された型のオブジェクトについてこのアイテムコンテクスト内で検索するＩｔｅｍＳｅａｒｃｈｅｒを作成する。アイテム、関係、またはアイテム拡張以外の型が指定されている場合、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public ItemSearcher GetSearcher(Type type);
//ｉｄを与えられているアイテムを見つける。
public Item FindItemById(ItemId itemId);
//パスを与えられているアイテムを見つける。パスは絶対パスでも相対パスでもよい。相対パスであれば、ＩｔｅｍＣｏｎｔｅｘｔが開かれたときに複数のアイテムドメインが指定されている場合、ＮｏｔＳｕｐｐｏｒｔｅｄＥｘｃｅｐｔｉｏｎがスローされる。そのようなアイテムが存在しない場合には、ＮＵＬＬを返す。アイテムを取り出すために＼＼ｍａｃｈｉｎｅ＼ｓｈａｒｅへの接続をドメインの一部として作成する。アイテムは、そのドメインに関連付けられる。
public Item FindItemByPath(string path);
//パスを与えられているアイテムを見つける。パスは、指定されたアイテムドメインに相対的である。アイテムを取り出すために指定されたドメインへの接続を作成する。アイテムは、そのドメインに関連付けられる。そのようなアイテムが存在しない場合には、ＮＵＬＬを返す。
public Item FindItemByPath (string domain, string path);
//パスを与えられているアイテムの集合を見つける。パスは、ＩｔｅｍＣｏｎｔｅｘｔが開かれたときに指定されたアイテムドメインに相対的である。そのようなアイテムが存在しない場合には、空を返す。
public FindResult FindAllItemsByPath(string path);
//ｉｄを与えられている関係を見つける。
public Relatioinship FindRelationshipById(ItemId itemID, RelationshipId relationshipId);
//ｉｄを与えられているアイテム拡張を見つける。
public ItemExtension FindItemExtensionById(ItemId itemId, ItemExtensionId itemExtensionId);
//与えられたフィルタ条件をオプションにより満たす指定された型のすべてのアイテム、関係、またはアイテム拡張を見つける。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public FindResult FindAll(Type type);
public FindResult FindAll(Type type, string filter);
//与えられたフィルタ条件を満たす指定された型の任意のアイテム、関係、またはアイテム拡張を見つける。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。そのようなオブジェクトが見つからない場合、ＮＵＬＬを返す。
public object FindOne(Type type, string filter);
//与えられたフィルタ条件を満たす指定された型のアイテム、関係、またはアイテム拡張を見つける。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。そのようなオブジェクトが見つからない場合、ＯｂｊｅｃｔＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。複数のオブジェクトが見つからなかった場合、ＭｕｌｔｉｐｌｅＯｂｊｅｃｔｓＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。
public object FindOnly(Type type, string filter);
//与えられたフィルタ条件を満たす指定された型のアイテム、関係、またはアイテム拡張が存在する場合、ｔｒｕｅを返す。これら以外の型が指定されていれば、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎをスローする。
public bool Exists(Type type, string filter);
//検索により返されるオブジェクトがＩｔｅｍＣｏｎｔｅｘｔにより保持されるオブジェクト識別マップにどのように関係するかを指定する。
public SearchCollisionMode SearchCollisionMode {get; set;}
//ＲｅｓｕｌｔＭａｐｐｉｎｇについてＰｒｅｓｅｒｖｅＭｏｄｉｆｉｅｄＯｂｊｅｃｔｓが指定されている場合に発生する。このイベントにより、アプリケーションは、検索により取り出されたデータとともに修正されたオブジェクトを選択的に更新することができる。
public event ChangeCollisionEventHandler SearchCollision;
//他のＩｔｅｍＣｏｎｔｅｘｔからのオブジェクトをこのアイテムコンテクストに組み込む。同じアイテム、関係、アイテム拡張を表すオブジェクトがすでに存在しているわけではない場合、このＩｔｅｍＣｏｎｔｅｘｔの識別マップ、オブジェクトのクローンが作成され、マップに追加される。オブジェクトが存在する場合、これは、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎＭｏｄｅと一致する方法で指定されたオブジェクトの状態および内容とともに更新される。
public Item IncorporateItem(Item item);
public Relationship IncorporateRelationship(Relationship relationship);
public ItemExtension IncorporateItemExtension(ItemExtension itemExtension);
}
//ＩｔｅｍＣｏｎｔｅｘｔ．ＵｐｄａｔｅＣｏｌｌｉｓｉｏｎおよびＩｔｅｍＳｅａｒｃｈｅｒ．ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントのハンドラ。
public delegate void ChangeCollisionEventHandler(object source, ChangeCollisionEventArgs args);
//ＣｈａｎｇｅＣｏｌｌｉｓｉｏｎＥｖｅｎｔＨａｎｄｌｅｒデリゲートの引数。
public class ChangeCollisionEventArgs : EventArgs
{
//修正されたアイテム、アイテム拡張、または関係オブジェクト。
public object ModifiedObject {get;}
//ストアからのプロパティ。
public IDictionary StoredProperties {get;}
}
//ＩｔｅｍＣｏｎｔｅｘｔ．ＵｐｄａｔｅＰｒｏｇｒｅｓｓのハンドラ。
public delegate void UpdateProgressEventHandler(ItemContext itemContext, UpdateProgressEventArgs args);
//ＵｐｄａｔｅＰｒｏｇｒｅｓｓＥｖｅｎｔＨａｎｄｌｅｒデリゲートの引数。
public class ChangeCollisionEventArgs : EventArgs
{
//現在の更新オペレーション。
public UpdateOperation CurrentOperation {get;}
//現在更新中のオブジェクト。
public object CurrentObject {get;}
}
//検索により返されるオブジェクトがＩｔｅｍＣｏｎｔｅｘｔにより保持されるオブジェクト識別マップにどのように関係するかを指定する。
public enum SearchCollisionMode
{
//新しいオブジェクトを作成し、返さなければならないことを示す。識別マップ内の同じアイテム、アイテム拡張、または関係を表すオブジェクトは無視される。このオプションが指定されている場合、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントは発生しない。
DoNotMapSearchResults,
//識別マップからのオブジェクトを返さなければならないことを示す。オブジェクトの内容がアプリケーションにより修正された場合、修正されたオブジェクトの内容は保存される。オブジェクトが修正されていなかった場合、その内容は検索により返されたデータとともに更新される。Ａｐｐｌｉｃａｔｉｏｎは、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントに対するハンドラを用意し、必要に応じてオブジェクトを選択的に更新することができる。
PreserveModifiedObjects,
//識別マップからのオブジェクトを返さなければならないことを示す。オブジェクトの内容は、そのオブジェクトがアプリケーションにより修正されていたとしても、検索により返されたデータとともに更新される。このオプションが指定されている場合、ＳｅａｒｃｈＣｏｌｌｉｓｉｏｎイベントは発生しない。
OverwriteModifiedObjects
}
//現在の更新オペレーション。
public enum UpdateOperation
{
//Ｕｐｄａｔｅが最初に呼び出されたときに与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔはｎｕｌｌとなる。
OverallUpdateStarting,
//更新が成功した後、Ｕｐｄａｔｅが戻る直前に与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔはＮＵＬＬとなる。
OverallUpdateCompletedSucessfully,
//Ｕｐｄａｔｅが例外をスローする直前に与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔは、例外オブジェクトとなる。
OverallUpdateCompletedUnsuccessfully,
//オブジェクトの更新が開始したときに与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔは、更新に使用されるオブジェクトを参照する。
ObjectUpdateStarting,
//新しい接続が必要な場合に与えられる。ＣｕｒｒｅｎｔＯｂｊｅｃｔは、ＩｔｅｍＣｏｎｔｅｘｔ．Ｏｐｅｎに渡されるようなアイテムドメインを識別するパスを含む文字列となる。関係のＬｏｃａｔｉｏｎフィールドから開くか、または取り出す。
OpeningConnection
}
}
付録Ｂ
namespace System.Storage
{
//アイテムコンテクスト内の特定の型について検索を実行する。
public class ItemSearcher
{
コンストラクタ

ItemContext creation and management member
// Applications cannot create ItemContext objects directly, nor can they derive classes from ItemContext.
interal ItemContext ();
// Create an ItemContext that can be used to search the default store on the local computer if the specified path or path is not specified.
public static ItemContext Open ();
public static ItemContext Open (string path);
public static ItemContext Open (params string [] paths);
// Returns the specified path when an ItemContext is created.
public string [] GetOpenPaths ();
// Make a copy of this ItemContext. The copy has an independent transaction, cache, and update state. The cache is initially empty. Using a cloned ItemContext is expected to be more efficient than opening a new ItemContext using the same item domain (s).
public ItemContext Clone ();
// Close ItemContext. If you try to use ItemContext after it is closed, ObjectDisposedException occurs.
public void Close ();
void IDisposable.Dispose ();
// True if the specified domain resolves to the remote computer when the ItemContext is opened.
public bool IsRemote {get;}
// Returns an object that can supply the requested service type. If the requested service cannot be provided, NULL is returned. The ISServiceProvider pattern can be used to remove APIs from the ItemContext class that are not normally used and that would otherwise confuse developers. ItemContext can provide services IIItem Serialization and IStoreObjectCache.
public object GetService (Type serviceType);
Update related members
// Save the changes represented by all modified objects and all objects passed to MarkForCreate or MarkForDelete. If an update conflict is detected, UpdateCollationException may be thrown.
public void Update ();
// Save the changes represented by the specified object. The object must have been modified or passed to MarkForCreate or MarkForDelete, otherwise an Object-Exception is thrown. If an update conflict is detected, UpdateCollationException may be thrown.
public void Update (object objectToUpdate);
public void Update (IEnumerable objectsToUpdate);
// Refresh the contents of the specified object from the store. If the object has been modified, the changes are overwritten and the object is no longer considered modified. If an item other than an item, item extension, or related object is specified, an ObjectException is thrown.
public void Refresh (object objectToRefresh);
public void Refresh (IEnumerable objectsToRefresh);
// Occurs when the update detects that the data has changed in the store between when the modified object was retrieved and when it was about to save it. If the event handler is not registered, the update throws an exception. If an event handler is registered, it can throw an exception and abort the update, so that the modified object overwrites the data in the store or changes made in the store and the object. Merge.
public event ChangeCollisionEventHandler UpdateCollision;
// Occurs at various points during the update process and supplies update progress information.
public event UpdateProgressEventhandler UpdateProgress;
// Asynchronous version 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 version 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 processing of related members
// Start a transaction with the specified isolation level. The default isolation level is ReadCommitted. In all cases, a distributed transaction is initiated because it may be necessary to include a change stream typed item property.
public Transaction BeginTransaction ();
public Transaction BeginTransaction (System.Data.IsolationLevel isolationLevel);
Search related members
// Create an ItemSearcher that searches within this item context for objects of the specified type. If a type other than item, relationship, or item extension is specified, it throws ArgumentException.
public ItemSearcher GetSearcher (Type type);
// Find the item given id.
public Item FindItemById (ItemId itemId);
// Find the item given the path. The path may be absolute or relative. If it is a relative path, NotSupportedException is thrown if multiple item domains are specified when the ItemContext is opened. If no such item exists, NULL is returned. Create a connection to \\ machine \ share as part of the domain to retrieve items. An item is associated with its domain.
public Item FindItemByPath (string path);
// Find the item given the path. The path is relative to the specified item domain. Create a connection to the specified domain to retrieve the item. An item is associated with its domain. If no such item exists, NULL is returned.
public Item FindItemByPath (string domain, string path);
// Find the set of items given the path. The path is relative to the item domain specified when the ItemContext is opened. If no such item exists, return empty.
public FindResult FindAllItemsByPath (string path);
// Find the relationship given id.
public Relatioinship FindRelationshipById (ItemId itemID, RelationshipId relationshipId);
// Find the item extension given id.
public ItemExtension FindItemExtensionById (ItemId itemId, ItemExtensionId itemExtensionId);
// Find all items, relationships, or item extensions of the specified type that optionally meet the given filter criteria. If a type other than these is specified, an ArrangementException is thrown.
public FindResult FindAll (Type type);
public FindResult FindAll (Type type, string filter);
// Find any item, relationship, or item extension of the specified type that satisfies the given filter criteria. If a type other than these is specified, an ArrangementException is thrown. Returns NULL if no such object is found.
public object FindOne (Type type, string filter);
// Find an item, relationship, or item extension of the specified type that meets the given filter criteria. If a type other than these is specified, an ArrangementException is thrown. If no such object is found, throw ObjectNotFoundException. If multiple objects are not found, MultipleObjectsFoundException is thrown.
public object FindOnly (Type type, string filter);
// Returns true if an item, relationship, or item extension of the specified type that satisfies the given filter condition exists. If a type other than these is specified, an ArrangementException is thrown.
public bool Exists (Type type, string filter);
// Specifies how the object returned by the search is related to the object identification map held by the ItemContext.
public SearchCollisionMode SearchCollisionMode {get; set;}
// Occurs when PreserveModifiedObjects is specified for ResultMapping. This event allows the application to selectively update the modified object with the data retrieved by the search.
public event ChangeCollisionEventHandler SearchCollision;
// Incorporate objects from other ItemContexts into this item context. If an object representing the same item, relationship, or item extension does not already exist, this ItemContext identification map, a clone of the object, is created and added to the map. If the object exists, it is updated with the state and content of the object specified in a manner consistent with SearchCollectionMode.
public Item IncorporateItem (Item item);
public Relationship IncorporateRelationship (Relationship relationship);
public ItemExtension IncorporateItemExtension (ItemExtension itemExtension);
}
// ItemContext. UpdateCollation and ItemSearcher. Handler for SearchCollision event.
public delegate void ChangeCollisionEventHandler (object source, ChangeCollisionEventArgs args);
// ChangeCollationEventHandler handler argument.
public class ChangeCollisionEventArgs: EventArgs
{
// Modified item, item extension, or relationship object.
public object ModifiedObject {get;}
// Property from the store.
public IDictionary StoredProperties {get;}
}
// ItemContext. UpdateProgress handler.
public delegate void UpdateProgressEventHandler (ItemContext itemContext, UpdateProgressEventArgs args);
// Argument for UpdateProgressEventHandler delegate.
public class ChangeCollisionEventArgs: EventArgs
{
// Current update operation.
public UpdateOperation CurrentOperation {get;}
// The object currently being updated.
public object CurrentObject {get;}
}
// Specifies how the object returned by the search is related to the object identification map held by the ItemContext.
public enum SearchCollisionMode
{
// Indicates that a new object should be created and returned. Objects that represent the same item, item extension, or relationship in the identity map are ignored. When this option is specified, the Search Collation event does not occur.
DoNotMapSearchResults,
// Indicates that an object from the identification map should be returned. When the content of the object is modified by the application, the modified content of the object is saved. If the object has not been modified, its contents are updated with the data returned by the search. Application prepares a handler for the SearchCollision event and can selectively update the object as necessary.
PreserveModifiedObjects,
// Indicates that an object from the identification map should be returned. The contents of the object are updated with the data returned by the search even if the object has been modified by the application. When this option is specified, the Search Collation event does not occur.
OverwriteModifiedObjects
}
// Current update operation.
public enum UpdateOperation
{
// Given when Update is first called. CurrentObject is null.
OverallUpdateStarting,
// Given immediately after the update is successful, just before Update returns. CurrentObject becomes NULL.
OverallUpdateCompletedSucessfully,
// Provided immediately before Update throws an exception. CurrentObject is an exception object.
OverallUpdateCompletedUnsuccessfully,
// Given when an object update starts. CurrentObject refers to the object used for the update.
ObjectUpdateStarting,
// given when a new connection is needed. CurrentObject is an ItemContext. A character string including a path for identifying the item domain as passed to Open. Open or retrieve from the relationship's Location field.
OpeningConnection
}
}
Appendix B
namespace System.Storage
{
// Perform a search for a specific type in the item context.
public class ItemSearcher
{
constructor

プロパティ
//マッチするオブジェクトを識別するために使用されるフィルタ。
public SearchExpressionCollection Filters {get;}
//検索されるドメインを指定するＩｔｅｍＣｏｎｔｅｘｔ。
public ItemContext ItemContext {get; set;}
//検索パラメータコレクション。
public ParameterCollection Parameters {get;}
//サーチャーが動作する型。単純検索では、これは、返されるオブジェクトの型である。
public Type TargetType {get; set;}
検索メソッド
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅのオブジェクトを見つける。そのようなオブジェクトが存在しない場合には、空のＦｉｎｄＲｅｓｕｌｔを返す。
public FindResult FindAll();
public FindResult FindAll(FindOptions findOptions);
public FindResult FindAll(params SortOption[] sortOptions);
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅの１つのオブジェクトを見つける。
//そのようなオブジェクトが存在しない場合、ＮＵＬＬを返す。
public object FindOne();
public object FindOne(FindOptions findOptions);
public object FindOne(params SortOption[] sortOptions);
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅのオブジェクトを見つける。
//そのようなオブジェクトが見つからない場合、ＯｂｊｅｃｔＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。複数のオブジェクトが見つからなかった場合、ＭｕｌｔｉｐｌｅＯｂｊｅｃｔｓＦｏｕｎｄＥｘｃｅｐｔｉｏｎをスローする。
public object FindOnly();
public object FindOnly(FindOptions findOptions);
//Ｆｉｌｔｅｒｓにより指定された条件を満たすＴａｒｇｅｔＴｙｐｅのオブジェクトが存在するかどうかを判別する。
public bool Exists();
//同じ検索を繰り返し効率よく実行するために使用することができるオブジェクトを作成する。
public PreparedFind PrepareFind();

The property
// A filter used to identify matching objects.
public SearchExpressionCollection Filters {get;}
// An ItemContext that specifies the domain to be searched.
public ItemContext ItemContext {get; set;}
// Search parameter collection.
public ParameterCollection Parameters {get;}
// The type on which the searcher operates. For simple searches, this is the type of object returned.
public Type TargetType {get; set;}
Search method
// Find a TargetType object that satisfies the conditions specified by Filters. If no such object exists, an empty FindResult is returned.
public FindResult FindAll ();
public FindResult FindAll (FindOptions findOptions);
public FindResult FindAll (params SortOption [] sortOptions);
// Find one object of TargetType that satisfies the conditions specified by Filters.
// If no such object exists, return NULL.
public object FindOne ();
public object FindOne (FindOptions findOptions);
public object FindOne (params SortOption [] sortOptions);
// Find a TargetType object that satisfies the conditions specified by Filters.
// If no such object is found, throw ObjectNotFoundException. If multiple objects are not found, MultipleObjectsFoundException is thrown.
public object FindOnly ();
public object FindOnly (FindOptions findOptions);
// Determine whether there is a TargetType object that satisfies the condition specified by Filters.
public bool Exists ();
// Create an object that can be used to perform the same search repeatedly and efficiently.
public PreparedFind PrepareFind ();

Appendix C
namespace System.Storage
{
public abstract class FindResult: IAsyncObjectReader
{
public FindResult ();
// Move FindResult to the next position in the result.
public bool Read ();
public IAsyncResult BeginRead (AsyncCallback callback, object state);
public bool EndRead (IAsyncResult asyncResult);
// Current object.
public object Current {get;}
// Return whether FindResult contains an object.
public bool HasResults {get;}
// Return whether FindResult is closed.
public bool IsClosed {get;}
// Returns the type of items in this FindResult.
public Type ObjectType {get;}
// Close FindResult.
public void Close ();
void IDisposable.Dispose ();
// Returns an enumerator on FindResult starting from the current position. By advancing the enumerator on the FindResult, not only all the enumerators advance, but also the FindResult itself.
IEnumerator IEnumerable.GetEnumerator ();
public FindResultEnumerator GetEnumerator ();
}
public abstract class FindResultEnumerator: IEnumerator, IDisposable
{
public abstract object Current {get;}
public abstract bool MoveNext ();
public abstract void Reset ();
public abstract void Close ();
void IDisposable.Dispose ();
}
}
namespace System
{
// Common interface to iterate over objects
public interface IObjectReader: IEnumerable, IDisposable

And FIG. 7 is a block diagram illustrating a computer system in which aspects of the present invention may be incorporated. FIG. 2 is a block diagram illustrating a computer system divided into three component groups: a hardware component, a hardware / software interface system component, and an application program component. FIG. 3 illustrates a conventional tree-based hierarchical structure of files grouped into multiple folders in a directory in a file-based operating system. 1 is a block diagram illustrating a storage platform according to the present invention. FIG. 4 illustrates a structural relationship between Items, Item Folders, and Categories in various embodiments of the invention. It is a block diagram which illustrates the structure of Item. FIG. 5B is a block diagram illustrating a complex property type of Item in FIG. 5A. FIG. 6 is a block diagram illustrating a “Location” Item in which a composite type is further described (explicitly listed). It is a figure which illustrates Item as a child type of Item in Base Schema. FIG. 6B is a block diagram illustrating the child type Item of FIG. 6A with inherited types explicitly listed (in addition to immediate properties). FIG. 3 is a block diagram illustrating a Base Schema, Item and PropertyBase including two top level class types, and an additional Base Schema type derived therefrom. It is a block diagram which illustrates Item in Core Schema. It is a block diagram which illustrates the property type in Core Schema. FIG. 6 is a block diagram illustrating Item Folder, its Member Items, and the Relationship Relationships between the Item Folder and its Member Items. FIG. 6 is a block diagram illustrating Category (also Item itself), its Member Item, and the interconnection Relationship between Category and its Member Item. FIG. 6 illustrates a reference type hierarchy of a storage platform data model according to the present invention. FIG. 6 illustrates a method for classifying relationships according to one embodiment of the present invention. FIG. 6 illustrates a notification mechanism according to an embodiment of the present invention. FIG. 6 is a diagram illustrating an embodiment in which two transactions both insert a new record into the same B-Tree. FIG. 3 illustrates a data change detection process according to one embodiment of the invention. FIG. 3 illustrates an example directory tree. FIG. 6 illustrates an example in which an existing folder of a directory-based file system is moved to a storage platform data store according to an aspect of the present invention. It is a figure which shows the concept of Containment Folders by one aspect | mode of this invention. It is a figure which illustrates the basic architecture of storage platform API. FIG. 2 is a schematic diagram representing various components of a storage platform API stack. FIG. 4 is a relationship diagram of an exemplary Contacts schema (Item and Elements). FIG. 4 is a relationship diagram of an exemplary Contacts schema (Item and Elements). FIG. 3 illustrates a runtime framework of a storage platform API according to an aspect of the present invention. FIG. 6 illustrates execution of a FindAll operation according to one embodiment of the present invention. FIG. 6 illustrates a process for generating a storage platform API class from a storage platform Schema, according to one aspect of the invention. FIG. 4 illustrates a schema on which a File API is based, according to another aspect of the present invention. FIG. 6 illustrates an access mask format used for data security purposes according to an embodiment of the present invention. FIG. 3 illustrates a new, exactly the same protected security area that is cut from an existing security area, according to one embodiment of one aspect of the present invention. FIG. 6 illustrates the concept of an Item search view according to one embodiment of one aspect of the present invention. FIG. 4 illustrates an exemplary Item hierarchy according to one embodiment of the invention.

Claims (91)

A data store including at least one of Item, Element, and Relationship,
The Item is a unit of data that can be stored in a data store, and further includes the Element and the Relationship.
The Element is an instance of a type that includes one or more fields,
The relationship is a link between at least two items.   The data store of claim 1, wherein the data store further comprises a plurality of Items, the plurality of Items comprising an Item Folder and at least one other Item that is a member of the Item Folder. A data store characterized by containing.   2. The data store of claim 1, wherein the data store further includes a plurality of Items, the plurality of Items including one Category and at least one other Item that is a member of the Category. A data store characterized by   The data store of claim 1, wherein a Relationship between two Items is automatically established by a hardware / software interface system.   The data store according to claim 1, wherein the Element is understandable by a hardware / software interface system.   The data store according to claim 1, wherein the data store further includes a second Element, and the Relationship includes the second Element.   The data store of claim 1, wherein the data store further includes a Core Schema that defines a collection of Core Items, whereby the hardware / software interface system is in a predetermined, predictable manner, A data store that understands and directly processes the set of Core Items.   The data store of claim 7, wherein each Item from the set of Core Items is derived directly or indirectly from a Common Single Base Item.   8. The data store according to claim 7, wherein the common single base item is a basic item in the base schema.   A computer readable storage medium for storing computer readable instructions for a data store including at least two Items, wherein each of the Items includes at least one Element, and each of the Items is associated with at least one other Item. A computer-readable storage medium characterized by sharing a Relationship. The computer readable storage medium of claim 10, wherein the computer readable storage medium comprises:
Instructions for the data store to store at least one of an Item, an Element, and a Relationship;
An instruction in which the Item further includes the Element and the Relationship along with the data store;
An instruction in which the Element includes one or more field types;
The computer-readable storage medium further comprising instructions for forming a Relationship between the two items. A computer system,
A plurality of elements, each of the plurality of elements constituting an instance of a type including one or more fields; and
A plurality of Items, each of the Items comprising a discrete unit of information that can be manipulated by a hardware / software interface system, wherein each Item is at least one A plurality of Items, including Elements;
A plurality of Relationships, each of the plurality of Relationships being a link between at least two Items; and
A data store comprising the plurality of Items, the plurality of Elements, and the plurality of Relationships;
A computer system comprising: a storage platform for managing the data store and operating the plurality of Items.   Each Item of the plurality of Items may belong to at least one Item Folder of the plurality of Item Folders, and each of the Items may belong to a plurality of Item Folders of the plurality of Item Folders. The computer system according to claim 12.   14. The computer system according to claim 13, wherein the item is not automatically deleted even if the item folder is deleted.   14. The computer system according to claim 13, wherein the Item is automatically deleted when it no longer belongs to any Item Folder.   14. The computer system according to claim 13, wherein the Item is a member of only one Item Folder, and is automatically deleted when the Item Folder is deleted.   14. The computer system of claim 13, wherein the Item dynamically becomes a member of a default Item Folder.   14. The computer system according to claim 13, wherein the Item is a member of only one Item Folder and automatically becomes a member of a default Item Folder when the Item Folder is deleted.   A method for organizing Items within a data store, wherein the Items are (a) discrete units of information that can be manipulated by the operating system, (b) at least one Element, and (c) at least one other Item. The method may include a Relationship, and the method may make the Item a member of at least two Item Folders, but the Item is not owned by any of the Item Folders, and any of the Item Folders may be deleted. A method comprising preventing the Item from being automatically deleted.   20. The method of claim 19, wherein the Item is a member of the Item Folder, but is not owned by the Item Folder, and the Item is not automatically deleted when the Item Folder is deleted. .   21. The method of claim 20, wherein the Item is automatically deleted when it no longer belongs to any Item Folder.   21. The method of claim 20, wherein the Item automatically becomes a member of a default Item Folder when it no longer belongs to any Item Folder.   21. The method of claim 20, wherein the Item is a member of only one Item Folder and is automatically deleted when the Item Folder is deleted.   21. The method of claim 20, wherein the Item is a member of only one Item Folder and automatically becomes a member of a default Item Folder when the Item Folder is deleted. A computer system,
A plurality of Items including at least one Item, each of which constitutes a discrete unit capable of storing information that can be operated by a hardware / software interface system; and ,
A plurality of Item Folders including at least one Item Folder, wherein the plurality of Item Folders constitute a knitting structure for the Item; and
A hardware / software interface system for operating the plurality of Items, wherein each of the plurality of Items belongs to at least one of the plurality of Item Folders, and each of the plurality of Items is the plurality of the plurality of Items. A computer system comprising: a hardware / software interface system that can belong to a plurality of Item Folders of Item Folders.   26. The computer system according to claim 25, wherein the Item is a member of the Item Folder, but is not owned by the Item Folder, and the Item is not automatically deleted even if the Item Folder is deleted. .   26. The computer system according to claim 25, wherein an Item is automatically deleted when it no longer belongs to any Item Folder.   26. The computer system of claim 25, wherein the Item is a member of only one Item Folder, and is automatically deleted when the Item Folder is deleted.   26. Each Item is a member of at least one Item Folder, but is not owned by the Item Folder, and even if the Item Folder is deleted, the Item is not automatically deleted. The computer system described in 1.   26. The computer system according to claim 25, wherein the computer system further includes a plurality of categories including at least one category, and the plurality of categories constitute an organization structure of the item. system.   The computer system according to claim 30, wherein the Category is defined by an Item property.   One of the plurality of Categories is defined by an Item property, and only one Item including an Item property for a specific Category among the plurality of Categories can be a member of the specific Category. 32. A computer system as claimed in claim 31 characterized in that:   The computer system according to claim 30, wherein each of the plurality of Categories is defined by an Item property.   Each of the plurality of Categories is defined by an Item property, and only an Item including an Item property for a specific Category among the plurality of Categories can be a member of the specific Category. 34. The computer system according to 33.   A hardware / software interface system capable of manipulating Items, said Item comprising a discrete unit of information including a basic set of properties normally supported on objects exposed by the operating system shell. A hardware / software interface system comprising:   36. The hardware / software interface system of claim 35, wherein the Item is a basic unit of information operated by an operating system.   The hardware / software interface system according to claim 36, wherein the Item is a member of an Item Folder.   38. The hardware / software interface system according to claim 37, wherein the Item is not owned by the Item Folder, and even if the Item Folder is deleted, the Item is not automatically deleted.   39. The hardware / software interface system according to claim 38, wherein the Item is automatically deleted when it no longer belongs to any Item Folder.   39. The hardware / software interface system according to claim 38, wherein the Item is a member of only one Item Folder, and is automatically deleted when the Item Folder is deleted.   A computer readable storage medium storing computer readable instructions for an Item, the Item comprising discrete units of information operable by a hardware / software interface system. A computer readable storage medium storing computer readable instructions for a hardware / software interface system, the operating system comprising:
Means for manipulating a plurality of Items including at least one Item, each of the plurality of Items constituting a discrete unit of information that can be manipulated by a hardware / software interface system Means for operating
Means for operating a plurality of Item Folders including at least one Item Folder, the plurality of Item Folders comprising means for operating a plurality of Item Folders constituting a knitting structure for the Items;
Each of the plurality of Items may belong to at least one of the plurality of Item Folders, and each of the plurality of Items may belong to a plurality of Item Folders of the plurality of Item Folders. A readable storage medium.   A computer readable storage medium storing computer readable instructions for a hardware / software interface system of a computer system, the hardware / software interface system operating a plurality of discrete units of information that are Items, Item is a computer-readable storage medium characterized by being interconnected by a plurality of Relationships managed by the hardware / software interface system.   44. The computer-readable storage medium of claim 43, wherein the first Item has a Relationship from itself to the second Item.   45. The computer-readable storage medium of claim 44, wherein the first Item is an Item Folder.   46. The computer readable storage medium of claim 45, wherein the second Item is an Item Folder.   46. The computer-readable storage medium of claim 45, wherein the second Item is a Category.   The computer-readable storage medium of claim 45, wherein the second Item is an Item that is not an Item Folder or Category.   46. The computer readable storage medium of claim 45, wherein each Item from the Item has a Relationship to at least one other Item.   The computer-readable storage medium of claim 45, wherein the subset of Items includes Item Folder.   The computer-readable storage medium of claim 45, wherein the subset of Items includes a Category.   46. The computer-readable storage medium of claim 45, wherein the subset of Items includes Items that are not Item Folders or Categories.   A computer readable storage medium storing computer readable instructions for a hardware / software interface system of a computer system, wherein the hardware / software interface system is an Item, understandable by the hardware / software interface system A computer readable storage medium characterized by operating a plurality of discrete units of information having properties.   54. The computer readable storage medium of claim 53, wherein the hardware / software interface system includes a basic schema that defines at least one of Items and at least one of properties.   At least one of the items in the basic schema is a basic item, which constitutes a basic item type from which all other items that operate in the hardware / software interface system are derived. 55. The computer readable storage medium of claim 54, wherein:   The computer-readable storage medium of claim 55, wherein the basic Item type includes a property that references at least zero Categories of which the Item is a member.   56. The computer readable storage medium of claim 55, wherein the basic Item type includes a property that uniquely identifies the Item within a hardware / software interface system.   At least one of the properties in the basic schema is a basic property, which constitutes a basic property type from which all other properties used in the hardware / software interface system are derived 55. The computer readable storage medium of claim 54, wherein: At least one of the items in the basic schema is a basic item, which constitutes a basic item type from which all other items that operate in the hardware / software interface system are derived. And
At least one of the properties in the basic schema is a basic property, which constitutes a basic property type from which all other properties used in the hardware / software interface system are derived 55. The computer readable storage medium of claim 54, wherein:   The basic schema further includes a second Item derived from the basic Item type of the first Item, the second Item constituting the basic Item type of the Item Folder, and the second Item 60. The computer readable storage medium of claim 59, wherein an Item of the item represents a Relationship with the first Item.   The basic schema further includes a second property derived from the basic property type of the first property, wherein the second property constitutes the basic type of an idunit key property. 60. The computer readable storage medium of claim 59.   62. The base schema of claim 61, wherein the base schema further includes a third property derived from the second property, wherein the third property comprises the base type for a Category reference. Computer readable storage medium.   The basic schema further includes a second property derived from the basic property type of the first property, wherein the second property constitutes the basic property type of Category. 60. The computer readable storage medium of claim 59.   A computer readable storage medium storing computer readable instructions for a hardware / software interface system of a computer system, wherein the hardware / software interface system is an Item, understandable by the hardware / software interface system A computer readable storage medium characterized by operating a plurality of discrete units of information having properties.   The hardware / software interface system comprises a core schema that defines a set of core Items that the hardware / software interface system understands and can directly process in a predetermined and predictable manner. Item 65. The computer-readable storage medium according to Item 64.   66. The computer-readable storage medium of claim 65, wherein each Item from the set of core Items is common and is derived directly or indirectly from a single base Item.   68. The computer-readable storage medium of claim 66, wherein the common and single basic Item is a basic Item in a basic schema.   68. The computer-readable medium of claim 67, wherein the core schema further defines a set of core properties that can be understood by the hardware / software interface system and processed directly in a predetermined and predictable manner. Possible storage medium.   69. The computer-readable storage medium of claim 68, wherein each property from the set of core Items is derived directly or indirectly from at least one base property.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for a device.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for an event.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for a commodity.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for a message.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for a principal.   70. The computer readable storage medium of claim 69, wherein the core schema includes an Item for a location.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for a document.   70. The computer readable storage medium of claim 69, wherein the core schema includes an Item for a statement.   70. The computer-readable storage medium of claim 69, wherein the core schema includes an Item for a contact.   70. The computer readable storage medium of claim 69, wherein the core schema includes properties for a certificate.   The computer-readable storage medium of claim 69, wherein the core schema includes properties for a primary idunit key.   70. The computer readable storage medium of claim 69, wherein the core schema includes properties for a postal address.   70. The computer readable storage medium of claim 69, wherein the core schema includes properties for rich text elements.   The computer-readable storage medium of claim 69, wherein the core schema includes properties for electronic addresses.   The computer-readable medium of claim 69, wherein the core schema includes properties for an idunit security package.   70. The computer-readable storage medium of claim 69, wherein the core schema includes a Relationship that occupies a role between two Contacts.   70. The computer readable storage medium of claim 69, wherein the core schema includes properties for basic presence.   A method of operating a plurality of discrete information units in a hardware / software interface system of a computer system, wherein the method interconnects the Item and a plurality of Relationships, and the hardware / software Managing the Relationship at the interface system level.   88. Each Relationship of the plurality of Relationships comprises a mapping between a pair of Items interconnected by the Relationship at the level of the hardware / software interface system. Interface system.   90. The interface system of claim 88, wherein each Relationship has properties.   90. The interface system of claim 89, wherein each Relationship includes a property for identification of a target Item of the Relationship. The interface system of claim 90, wherein each Relationship further includes a property for ownership of the Target Item of the Relationship.

Images