Systems and methods for data modeling in an item-based storage platform
Abstract
This record has no abstract on file.
Term
Term ended
Expired 21 August 2023, 3.1 years ago.
- Priority and filed
- Granted
- Expired
- Today
14 claims: 7 independent, 7 dependent
- 1データストアを管理する方法であって、コンピュータに格納されたプログラムに含まれるコンピュータ実行可能命令を前記コンピュータが実行することによって実施される該方法は、前記データストアが、 前記 データストアに格納可能なデータのユニットであり、 少なくとも1つの型または子型を有するアイテム(Item)と、 前記アイテムに含まれ、 1つまたは複数のフィールドを含む型のインスタンスであ る要素(Element)と、 前記アイテムに含まれ、 少なくとも2つの アイテム 間のリンクであ り、包含関係及び参照関係を含む複数の関係(Relationship)であって、前記包含関係は、前記アイテムの存続期間を制御し、さらに保持関係または埋め込み関係として分類され、前記アイテムは、前記保持関係が削除されると削除される複数の関係と、 各アイテムを作成かつ編成し、プロパティの基礎的な集合を規定するフレームワークを確立する基本スキーマ(Base Schema)と、 コア型の集合を定義するコアスキーマであって、前記各アイテムは、前記アイテムの型または子型に基づいて少なくとも1つのコア型に特徴付けられるコアスキーマ(Core Schema)と を備えるように前記データストアを編成するステップを含む ことを特徴とする 方法。
- 2前記データストアは、複数の アイテム を含み、前記複数の アイテム は 、アイテムフォルダ(Item Folder) 、および、 該アイテムフォルダ のメンバである少なくとも1つの他の アイテム を含むことを特徴とする 請求項1に記載の方法 。
- 3前記データストアは、複数の アイテム を含み、前記複数の アイテム は 、カテゴリ(Category) 、および、 該カテゴリ のメンバである少なくとも1つの他の アイテム を含むことを特徴とする 請求項1に記載の方法 。
- 4前記データストアは、第2の 要素 を含み、前記 関係 は、前記第2の 要素 を含むことを特徴とする 請求項1に記載の方法 。
- 5コアアイテムの集合からのそれぞれの アイテム は、 共通であり単一の基本アイテム(Common Single Base Item) から派生 す ることを特徴とする請求項 1 に記載の 方法 。
- 6前記 共通であり単一の基本アイテム は、 前記基本スキーマ 内の基礎的な アイテム であることを特徴とする請求項 1 に記載の 方法 。
- 7データストアを管理する方法を実施するためのコンピュータ実行可能命令が記憶されたコンピュータ読取り可能記憶媒体であって、前記方法は、 前記データストアが、 前記データストアに格納可能なデータのユニットであり、少なくとも1つの型または子型を有するアイテム(Item)と、 前記アイテムに含まれ、1つまたは複数のフィールドを含む型のインスタンスである要素(Element)と、 前記アイテムに含まれ、少なくとも2つのアイテム間のリンクであり、包含関係及び参照関係を含む複数の関係(Relationship)であって、前記包含関係は、前記アイテムの存続期間を制御し、さらに保持関係または埋め込み関係として分類され、前記アイテムは、前記保持関係が削除されると削除される複数の関係と、 各アイテムを作成かつ編成し、プロパティの基礎的な集合を規定するフレームワークを確立する基本スキーマ(Base Schema)と、 コア型の集合を定義するコアスキーマであって、前記各アイテムは、前記アイテムの型または子型に基づいて少なくとも1つのコア型に特徴付けられるコアスキーマ(Core Schema)と を備えるように前記データストアを編成するステップを含むことを特徴とするコンピュータ読取り可能記憶媒体。
- 8前記データストアは、複数のアイテムを含み、前記複数のアイテムは、アイテムフォルダ(Item Folder)、および、該アイテムフォルダのメンバである少なくとも1つの他のアイテムを含むことを特徴とする請求項7に記載のコンピュータ読取り可能記憶媒体。
- 9前記データストアは、複数のアイテムを含み、前記複数のアイテムは、カテゴリ(Category)、および、前記カテゴリのメンバである少なくとも1つの他のアイテムを含むことを特徴とする請求項7に記載のコンピュータ読取り可能記憶媒体。
- 10前記データストアは、第2の要素を含み、前記関係は、前記第2の要素を含むことを特徴とする請求項7に記載のコンピュータ読取り可能記憶媒体。
- 11データストアを管理する方法を実施するコンピュータシステムであって、前記方法は、 前記データストアが、 前記データストアに格納可能なデータのユニットであり、少なくとも1つの型または子型を有するアイテム(Item)と、 前記アイテムに含まれ、1つまたは複数のフィールドを含む型のインスタンスである要素(Element)と、 前記アイテムに含まれ、少なくとも2つのアイテム間のリンクであり、包含関係及び参照関係を含む複数の関係(Relationship)であって、前記包含関係は、前記アイテムの存続期間を制御し、さらに保持関係または埋め込み関係として分類され、前記アイテムは、前記保持関係が削除されると削除される複数の関係と、 各アイテムを作成かつ編成し、プロパティの基礎的な集合を規定するフレームワークを確立する基本スキーマ(Base Schema)と、 コア型の集合を定義するコアスキーマであって、前記各アイテムは、前記アイテムの型または子型に基づいて少なくとも1つのコア型に特徴付けられるコアスキーマ(Core Schema)と を備えるように前記データストアを編成するステップを含むことを特徴とするコンピュータシステム。
- 12前記データストアは、複数のアイテムを含み、前記複数のアイテムは、アイテムフォルダ(Item Folder)、および、該アイテムフォルダのメンバである少なくとも1つの他のアイテムを含むことを特徴とする請求項11に記載のコンピュータシステム。
- 13前記データストアは、複数のアイテムを含み、前記複数のアイテムは、カテゴリ(Category)、および、前記カテゴリのメンバである少なくとも1つの他のアイテムを含むことを特徴とする請求項11に記載のコンピュータシステム。
- 14前記データストアは、第2の要素を含み、前記関係は、前記第2の要素を含むことを特徴とする請求項11に記載のコンピュータシステム。
Independent claims14
721 paragraphs, as filed
The present invention generally relates to the field of information storage and retrieval, and more specifically to active storage platforms for organizing, retrieving, and sharing various types of data in computerized systems.
Individual disk capacity has increased at a rate of almost 70% per year over the last decade. Moore's Law accurately predicted the tremendous increase in central processing unit (CPU) power that has been going on for many years. Wired and wireless technologies have provided incredible connectivity and bandwidth. Assuming the current trend continues, within a few years, the average laptop computer will have approximately 1 terabyte (TB) of storage and millions of files, 500 gigabytes (GB). Drive will be the norm.
Consumers use computers primarily for communication and organization of personal information, whether this is traditional Personal Information Manager style data or media such as digital music or photographs. It doesn't matter. The amount of digital content and the ability to store raw bytes has grown tremendously, but the methods consumers can use to organize and consolidate such data have not been addressed. Knowledge workers spend enormous amounts of time managing and sharing information, and one study estimates that knowledge workers spend 15-25% of their total time on unproductive information-related activities. There is. Other studies estimate that standard knowledge workers spend about 2.5 hours daily searching for information.
Developers and information technology (IT) departments have considerable time and money to build their own data stores for common storage abstractions that represent people, places, times, events, and more. Are spending. This not only duplicates the work, but also creates a number of isolated islands of common data without a mechanism for common retrieval or sharing of data. Consider how many address books can exist on a computer running the Microsoft Windows® operating system today. Many applications, such as email clients and personal finance programs, store their address books individually, and there is little sharing of address book data between applications that each such program holds individually. As a result, the finance program (a program like Microsoft Money®) will give the recipient's address to the email contact folder (Microsoft). Do not share with addresses held in (folders such as those provided by Outlook®). In fact, many users have multiple devices, logically syncing their personal data between themselves, and across a variety of additional sources, from mobile phones to commercial services such as MSN and AOL. Most of the collaboration of shared documents is done by attaching the document to an email message, which means that it is done manually and inefficiently.
One reason for this lack of collaboration is that the traditional approach of organizing information within a computer system uses a file-folder / directory-based system (the "file system") to store multiple files. It functions primarily to organize multiple files into a folder directory hierarchy, based on an abstraction of the physical organization of the storage medium used to do this. For the first time, the Multics operating system, developed in the 1960s, has been acclaimed for using files, folders, and directories to manage data storable units at the operating system level. In particular, Multics used symbolic addresses within the file hierarchy (thus introducing the concept of file paths), and the physical addresses of files were not transparent to users (applications and end users). This file system as a whole is unaware of the file format of any individual file, and the relationships between files are considered insignificant at the operating system level (that is, other than the location of the files 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 contain the file hierarchy itself (the "directory") embodied in the special files held by the file system. This directory then holds a list of entries corresponding to all other files in the directory and the nodal location of such files in the hierarchy (referred to here as folders). Such a system has been state-of-the-art for about 40 years.
However, despite providing a sufficiently reasonable representation of the information contained within the computer's physical storage system, the file system is an abstraction of that physical storage system and the use of those files. Requires some level of instruction (interpretation) between what the user is doing (units with context, features, and relationships with other units) and what the operating system has (files, folders, and directories). And. Therefore, other than forcing users (applications and / or end users) to have a file system structure on the unit of information, even if doing so is inefficient, inconsistent, or otherwise undesirable. There is no choice. In addition, existing file systems know little about the structure of the 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 data storage locations with little sharing of data between 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 at some level-for example, Outlook Contacts, online account addresses, Windows® Address Book, Quicken. Payees, and Instant Messaging (IM) Companion List-have more than five different stores that store information about the people you interact with. Most existing file systems use a nested folder metaphor for organizing files and folders, so as the number of files grows, the effort required to maintain a flexible and efficient organization is quite daunting. It becomes a thing. In such situations, it is very beneficial to have multiple classifications of a single file, but using hard or soft links within an existing file system is cumbersome and difficult to maintain.
In the past, there have been several attempts to eliminate the shortcomings of filesystems, but they have failed. Some of those previous attempts are content addressable memory. Using memory), we tried to realize a mechanism that allows data to be accessed by its contents instead of its physical address. However, while associative memory has proven useful for small-scale use by devices such as caches and memory management units, large-scale use by devices such as physical storage media is still possible for a variety of reasons. Since not, these efforts have not been successful, and therefore 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 ineffective and hard to handle file representation. Nor can it reproduce the speed, efficiency, and brevity of files and folders based on the system-level hierarchical structure of the ware / software interface. Other efforts, such as attempts to use SmallTalk (and its derivatives), have proven to be extremely effective in handling files and non-file representations, but streamline the relationships that exist between various data files. It lacked the database functionality needed to organize and utilize it well, and therefore the overall efficiency of such a system was unacceptable. In addition, other attempts to use BeOS (and other such operating system studies) have some required database functionality to properly represent files, but to handle non-file representations. Demonstrated improperness-the same drawbacks as the core drawbacks of traditional file systems.
Database technology is another area of technology that presents similar challenges. For example, relational database models have had great commercial success, but in reality, independent software vendors (ISVs) are generally relational database software products (Microsoft SQL). It uses a small part of the functions provided by (Server, etc.). Instead, most of the application's interactions with such products are in the form of simple "reads" and "writes." One of the most obvious reasons for this-not knowing the platform or database-but often unnoticed is that databases aren't always exactly what big business application vendors really need. It means no abstraction. For example, in the real world, there is the concept of "customers" or "orders" (with items within themselves, and with embedded "line items" of orders as their own items) "items", but in relational databases. Only knows about tables and rows. As a result, applications may want to have (eg) item-level integrity, locking, security, and / or trigger aspects, but in general, databases provide these features in tables / rows. It is prepared only at the level of. This can work well if each item is mapped to a single row in a table in the database, but for orders with multiple line items, the item is actually mapped to multiple tables. There can be a reason, and in that case, a simple relational database system does not provide the correct abstraction at all. As a result, the application must build logic on top of the database to achieve those basic abstractions. That is, the basic relational model requires some level of indirectness 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 makes it easy to develop high-level applications. Some database ben Da has incorporated a high level of functionality into its products-with object-relational capabilities, new organizeable models, etc.-but none of them provide the kind of comprehensive solution they need. After all, a truly comprehensive solution is a data model abstraction ("Item", "Extensions", etc.) that is both useful for useful domain abstractions ("Persons", "Locations", "Events", etc.). This is because it realizes "Relationships").
<p> With respect to the aforementioned shortcomings in existing data storage and database technologies, a new storage platform that enhances the ability to organize, retrieve, and share all types of data in computer systems-data beyond existing file and database systems. You need a storage platform that is designed to store all types of data that extends and expands the platform. The present invention satisfies this requirement.</p>
<p> The following description outlines various aspects of the invention. This description is not intended to exhaustively describe all of the important aspects of the invention or to define the scope of the invention. Rather, this description is intended to be used as an introduction to the following detailed description and drawings.</p><p> 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 for all types of data, including structured, unstructured, or semi-structured data. Designed to be a store.</p><p> According to one aspect of the invention, the storage platform of the invention includes a data store implemented on a database engine. In various embodiments of the 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 in which a particular type of data is described in the schema and the platform extends the set of schemas to define new types of data (essentially the subtypes of the basic types realized by the schema). To be equipped. The synchronous processing function facilitates the sharing of data between users or systems. File system-like features are provided that allow data store interoperability with existing file systems without the limitations of such traditional file systems. The change tracking mechanism has the ability to track changes to the data store. The storage platform further comprises a set of application program interfaces for accessing all of the above-mentioned functions of the storage platform from the application and accessing the data described in the schema.</p><p> According to another aspect of the invention, the data model implemented by the 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 contain one or more elements and relationships. An element is an instance of a type that contains one or more fields (also called a property here). A relationship is a link between two items. (As used herein, these terms and certain other terms may be capitalized in the original English to separate them from other terms that are used very closely. However, in English, the term with a capital letter at the beginning is, for example, "Item", and the same term in English, for example, "item" is translated into Japanese to be an item, but there is no intention to distinguish it. Such a distinction should not be assumed or implicitly included).</p><p> According to another aspect of the invention, a computer system relates to a plurality of Items, said Item, each of which constitutes a discrete storable unit of information that can be manipulated by a hardware / software interface system. It has multiple Item Folders that make up the organizational structure, and a hardware / software interface system for operating multiple Items, each of which belongs to at least one Item Folder and may belong to multiple Item Folders.</p><p> According to another aspect of the invention, a computer system comprises a plurality of Items, each of which constitutes a discrete information unit that can be manipulated by a hardware / software interface system and is a property of the Item or Item. Some of the values are calculated dynamically as opposed to being calculated from the persistent store. That is, the hardware / software interface system does not need to store the Item, but is given the ability to enumerate the current set of Items or the storage platform identifier (more on this in the Application Programming Interface or API section). Several operations are supported, such as the ability to retrieve an Item when it is done-for example, an Item can be the current position of a mobile phone or a temperature reading on a temperature sensor.</p><p> According to another aspect of the present invention, a hardware / software interface system of a computer system that operates a plurality of items further comprises items interconnected by a plurality of relationships managed by the hardware / software interface system. Including. According to another aspect of the present invention, the hardware / software interface system of a computer system is the hardware of the computer system that operates a plurality of discrete information units having properties that can be understood by the hardware / software interface system. / Software interface system. According to another aspect of the invention, the hardware / software interface system of a computer system is a set of core items that the hardware / software interface system can understand and process directly in a predetermined 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, including interconnecting the Item with a plurality of relationships and managing the relationships at the hardware / software interface system level. A method of manipulating the discrete information unit (Item) of is disclosed.</p><p> According to another feature of the invention, the storage platform API provides a data class for each item, item extension, and relationship defined in a set of storage platform schemas. In addition, the application programming interface defines a common set of behaviors for the data classes and, along with the data classes, implements a set of framework classes that provide the basic programming model for the storage platform API. According to another feature of the invention, the storage platform API separates the application programmer from the query language details of the underlying database engine, allowing the application programmer to query based on various properties of the items in the data store. It has a simplified query model that can be used to form. According to yet another aspect of the storage platform API of the present invention, this API collects changes made to items by application programs and then puts them into a database engine (or some kind of storage) in which the datastore is implemented. Organize to the correct update required by the engine). This allows application programmers to make changes to items in memory while leaving the complex parts of datastore updates to the API.</p><p> The storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses through a common storage infrastructure and graphical data. It provides a feature-rich, extensible application programming interface that not only makes available features specific to the data model, but also embraces and extends existing file systems and database access methods.</p><p> Other features and advantages of the invention will become apparent from the following detailed description and accompanying drawings of the invention.</p><p> The above outline can be well understood by reading with reference to the accompanying drawings, along with the following detailed description of the invention. For purposes of exemplifying the invention, the drawings show examples of various aspects of the invention, but the invention is not limited to the particular methods and means disclosed. The drawings are described below.</p>
table of contents I. Introduction A. An exemplary computing environment B. Traditional file-based storage II. New storage platform for data organization, retrieval, and sharing A. Glossary B. Storage Platform Overview C. Data model 1.Items 2. Item identification a) Item reference (1) ItemIDReference (2) ItemPathReference b) Reference type hierarchy 3.Item Folders and Categories 4.Schemas a) Base Schema b) Core Schema 5. Relationship a) Declaration of relationship b) Retention Relationship c) Embedded relationship d) Reference relationship e) Rules and constraints f) Relationship ordering 6. Extensibility a) Item expansion b) Extension of NestedElement type D. Database engine 1. Implementing a datastore using UDT 2. Item mapping 3. Extended mapping 4. Mapping of nested elements 5. Object identification 6. SQL object naming convention 7. Column naming convention 8. Search view a) Item (1) Master item search view (2) Typed item search view b) Item expansion (1) Master extended search view (2) Typed extended search view c) Nested elements d) Relationship (1) Master relationship search view (2) Relationship instance search view 9. Update 10. Change Tracking & Tombstone a) Change tracking (1) Track changes in the "master" search view (2) Track changes in "typed" search view b) Tombstone (1) Item Tombstone (2) Extended tombstone (3) Relationship tombstone (4) Tombstone cleanup 11. 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 the security model a) Security descriptor structure (1) Access mask format (2) General-purpose access right (3) Standard access right 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 item (9) Right to copy items (10) Right to move items (11) Right to view security policy on item (12) Right to change security policy on item (13) Right not to have a direct equivalent 3. 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 retained Relationship from the item e) Remove the explicit ACL from the item f) Modify the ACL associated with the item F. Notification and change tracking 1. 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. Sync 1. Synchronous processing between storage platforms a) Sync control application b) Schema annotation c) Sync settings (1) Community folder-mapping (2) Profile (3) Schedule d) Conflict avoidance processing (1) Conflict detection (a) Knowledge base conflict (b) Constraint-based contention (2) Conflict processing (a) Automatic conflict resolution (b) Conflict log creation (c) Conflict inspection and resolution (d) Replica convergence and conflict resolution propagation 2. Synchronous processing of non-storage platform datastore a) Synchronous processing service (1) Change Enumeration (2) Change Application (3) Conflict Resolution b) Adapter mounting 3. Security 4. Ease of management H. Traditional file system interoperability 1. Model for interoperability 2. Data store function a) Not a volume b) Store structure c) Not all files are migrated d) Accessing storage platform files in the NTFS namespace e) Expected namespace / drive characters (letters) I. Storage Platform API 1. Overview 2. Naming and scope 3. Storage platform API component 4. Data class 5. Runtime framework a) Runtime framework class (1) ItemContext (2) ItemSearcher (a) Target type (b) Filter (c) Search preparation (d) Search options (3) Item result stream ("FindResult") b) Running runtime framework c) Common programming pattern (1) Open and close the ItemContext object (2) Object search (a) Search options (b) FindOne and FindOnly (c) Search for shortcuts on ItemContext (d) Search by ID or path (e) GetSearcher pattern (3) Store update 6. Security 7. Relationship support a) Basic relation type (1) Relationship 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 within the 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 related traverses e) Example of using relationship support (1) Search for relationships (2) Navigate from relationships to source and target items (3) Navigate from source item to relationship (4) Creating relationships (and items) (5) Delete relationships (and items) 8. "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 form (formalism) a) Filter basics b) Type conversion c) Filter syntax 11. Remoting a) Local / remote transparency in API b) Remoting storage platform implementation c) Access to non-storage platform stores d) Relationship with DFS e) Relationship with GXA / Indigo 12. Constraints 13. Share a) Shared representation b) Managing shares c) Shared access d) Discoverability 14. Meaning of Find 15. Storage Platform Contacts API a) Overview of System.Storage.Contact b) Domain behavior 16. Storage Platform File API a) Introduction (1) Reflection of NTFS volumes in the storage platform (2) Files and files in the storage platform namespace Creating a directory b) File schema c) Overview of System.Storage.Files d) Code example (1) Open the file and write (2) Use of queries e) Domain behavior J. 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 argues that the alleged subject matter, along with other current or future techniques, includes other steps or combinations of steps that are similar to but different from those described herein. We considered that it can be embodied by the method. In addition, the term "step" may be used herein to imply different elements of the method adopted, but the term explicitly describes the order of the individual steps. It should not be construed as suggesting a particular order between the various steps disclosed herein.
A. An exemplary computing environment Many embodiments of the invention can be performed on a computer. FIG. 1 and the following description are intended to be a concise and general description of a suitable computing environment in which the present invention can be implemented. Although not necessary, various aspects of the invention can be described in the general context of computer-executable instructions, such as program modules, executed by computers such as client workstations or servers. In general, a program module includes routines, programs, objects, components, data structures, etc. that perform a particular task or implement a particular abstract data type. In addition, the invention can be implemented using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable home appliances, network PCs, minicomputers, mainframe computers, and the like. The present invention can also be implemented in a distributed computing environment in which tasks are executed by remote processing devices linked through a communication 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, system memory 22, and a system bus 23 that connects various system components, including system memory, to processing unit 21. Includes personal computer 20. The system bus 23 may be any of several bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus that uses various bus architectures. System memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. The basic input / output system 26 (BIOS), which includes basic routines that help transmit information between elements in the personal computer 20 at boot time, is stored in the ROM 24. The personal computer 20 further includes a hard disk drive 27 for reading and writing to a hard disk (not shown), a magnetic disk drive 28 for reading and writing to a removable magnetic disk 29, and a CD-ROM or other. It includes an optical disk drive 30 for reading and writing to and from a removable optical disk 31 such as an optical medium. The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are connected to the system bus 23 by the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical disk drive interface 34, respectively. The drive and associated computer-readable storage media provide a non-volatile storage device for storing computer-readable instructions, data structures, program modules, and other data for the personal computer 20. The environment examples described in the present invention use a hard disk, a removable magnetic disk 29, and a removable optical disk 31, but those skilled in the art may use magnetic cassettes, flash memory cards, digital video disks, and Bernoulli. Cartridge, multiple random access You will find that other types of computer-readable media that can store computer-accessible data, such as memory (RAM) and multiple read-only memories (ROMs), can also be used in this exemplary operating environment. Similarly, this exemplary environment can further include various types of surveillance devices such as heat detectors and security or fire alarms, and other sources of information.
Many program modules, including operating system 35, one or more application programs 36, other program modules 37, and program data 38, shall be stored on a hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25. Can be done. The user can enter commands and information into the personal computer 20 through input devices such as the keyboard 40 and the pointing device 42. Other input devices (not shown) include microphones, joysticks, gamepads, satellite dishes, scanners, and more. These input devices and other input devices are often connected to the processing unit 21 via a serial port interface 46 that is coupled to the system bus, but by a parallel port, game port, or universal serial bus (USB). It can also be connected by other interfaces such as. The monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as the video adapter 48. In addition to the monitor 47, a personal computer typically includes other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 further includes a host adapter 55, a SCSI (Small Computer System Interface) bus 56, and an external storage device 62 connected to the SCSI bus 56.
The personal computer 20 can operate in a networked environment using a logical connection to one or more remote computers, such as the 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-mentioned elements associated with the personal computer 20, but memory. Only the storage device 50 is shown in Figure 1. The logical connections described in Figure 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are common in offices, enterprise-scale 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 comprises other means for establishing communication over a wide area network 52 such as a modem 54 or 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 networked environment, the program modules shown for personal computer 20 or parts thereof may be stored in remote memory storage devices. It will be appreciated that the network connections shown in the figure are exemplary and other means can be used to establish communication links between computers.
As illustrated in the block diagram of FIG. 2, the computer system 200 is broadly defined as a hardware component 202, a hardware / software interface system component 204, and an application program component 206 (as is contextual herein). It can be divided into three component groups (also called "user components" or "software components").
In various embodiments of computer system 200, referring again to FIG. 1, hardware component 202 includes processing unit (CPU) 21, memory (both ROM24 and RAM25), basic input / output system (BIOS) 26, and keyboard. It can be equipped with various input / output (I / O) devices such as 40, mouse 42, monitor 47, and / or printer (not shown). Hardware component 202 provides the basic physical infrastructure for computer system 200.
Application program component 206 includes a variety of software programs, including, but not limited to, compilers, database systems, word processors, business programs, video games, and the like. Application programs provide a means to use computer resources to solve problems, provide solutions, and process data for a variety of users (machines, other computer systems, and / or end users). Be prepared.
The hardware / software interface system component 204 itself in most cases comprises an operating system that includes a shell and a kernel (and, in some embodiments, it may consist solely of such an operating system). 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 also includes a virtual machine manager (VMM), common language runtime (CLR) or its functional equivalent, a Java® virtual machine (JVM) or its functional equivalent, or It can also include other such software components that replace or add to the operating system within the computer system. The purpose of the hardware / software interface system is to provide an environment in which users can execute application programs. The goal of a 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 way.
The hardware / software interface system is generally loaded into the computer system at boot time and subsequently manages all application programs within the computer system. An application program interacts with a hardware / software interface system by requesting services through an application program interface (API). In some application programs, the end user can interact with the hardware / software interface system through a user interface such as a command language or graphical user interface (GUI).
A hardware / software interface system has traditionally provided various services to an application. In a multitasking hardware / software interface system that can run multiple programs at the same time, how long does the hardware / software interface system run which applications in what order and before switching to the next application for each application? Decide if you should allow your time. The hardware / software interface system also manages the sharing of internal memory between multiple applications, and also provides inputs and outputs to connected hardware devices such as hard disks, printers, and dial-up ports. To process. The hardware / software interface system also sends a message to each application (and possibly the end user) about the status of the operation and any errors that may have occurred. The hardware / software interface system can also remove the burden of managing batch jobs (eg, printing), freeing the starting application from such work and allowing other operations and / or operations to resume. it can. In computers that can have parallel processing capabilities, the hardware / software interface system also manages to split the program and run it on multiple processors at once.
A hardware / software interface system shell (referred to herein simply as a "shell") is an interactive end-user interface with a hardware / software interface system. (The shell is also called the "command interpreter" or, in the operating system, the "operating system shell.") The shell is a hardware / software interface system that is directly accessible to application programs and / or end users. The outer layer of. In contrast to the shell, the kernel is the innermost layer of the hardware / software interface system that interacts directly with the hardware components.
While many embodiments of the invention are considered particularly well suited for computerized systems, the present specification is not intended to limit the invention to such embodiments at all. On the contrary, as used herein, the term "computer system" can store and process information and / or use the stored information to perform behaviors or executions of the device itself. It is intended to include any device that can be controlled, whether by its very nature an electronic device, a mechanical device, a logical device, or a virtual device. There is.
B. Traditional file-based storage In most modern computer systems, a "file" is a unit of storable information that can contain not only hardware / software interface systems, but also application programs, datasets, and so on. 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 (storable and retrievable) units of data, programs, etc. A group of files is generally organized in "folder" units. Microsoft Windows®, Macintosh In the operating system 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 unit of information. These folders are then organized in a tree-based hierarchical array called "directories" (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" should be used interchangeably. And earlier Apple computer systems (eg, Apple IIe) used the term "catalog" instead of a directory, but as used herein, all of these terms are synonymous. It is considered to be a term and interchangeable and is intended to include all other equivalent terms and references to the hierarchical information storage structure and its folder and file components.
Traditionally, directories (also known as folder directories) have a tree-based hierarchy in which files are grouped into multiple folders, which are further arranged according to their relative node location, including the directory tree. For example, as illustrated in Figure 2A, the base folder (or "root directory") 212 of a DOS-based file system can contain multiple folders 214, each of which is also an additional folder (or an additional folder ("root directory"). It can contain 216 (as a "subfolder") of that particular folder, each of which can also contain additional folders, and so on, indefinitely. Each of these folders can hold one or more files 220, but at the hardware / software interface system level, the individual files in a folder have nothing in common other than their location in the tree hierarchy. .. This approach of organizing files into a folder hierarchy indirectly configures the physical configuration of standard storage media (eg, hard disks, floppy disks, CD-ROMs, etc.) used to store files. It's 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 that folder are also deleted (each subfolder recursively includes its own subfolders and files). Similarly, each file is generally owned by only one folder. A file is copied and the copy can be placed in a different folder, but the copy of the file is itself a different unit that has no direct association with the original (eg, change 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 essentially "physical" in nature. That's because folders are treated like physical containers, and files are treated as discrete, separate physical elements within those containers.
II. New storage platform for data organization, retrieval, and sharing 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 a data platform beyond the existing file and database systems of the types described above, for all types of data, including new forms of data called Items. It is designed to be a store of.
A. Glossary As used herein and in the claims, the following terms have the following meanings:
A hardware / software interface, unlike a simple file, is an object that has a basic set of properties that are generally supported across all objects exposed to end users by the system shell. A unit of storable information that can access the system. Item also has properties and relationships that are generally supported across all Item types, including the ability to introduce new properties and relationships (detailed later herein).
An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. The operating system most often includes a shell and kernel.
A "hardware / software interface system" is software, or a combination of hardware and software, used as an interface between the underlying hardware components of a computer system and application running on the computer system. A hardware / software interface system usually comprises an operating system (in some embodiments, it consists only of an operating system). Hardware / software interface systems are also virtual machine managers (VMMs), common language runtimes (CLRs) or their functional equivalents, Java® virtual machines (JVMs) or their functional equivalents, or computer systems. It can also include other such software components that replace or add to the operating system within. The purpose of the hardware / software interface system is to provide an environment in which users can execute application programs. The goal of a 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 way.
B. Storage Platform Overview Referring to FIG. 3, the storage platform 300 according to the invention comprises a datastore 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.
Datastore 302 implements a data model 304 that supports data organization, retrieval, sharing, synchronization, and security. Specific types of data are described in schemas such as Schema 340, and Storage Platform 300 provides tools 346 for deploying and extending those schemas, as described in detail below.
The change tracking mechanism 306 implemented within the datastore 302 has the ability to track changes to the datastore. Datastore 302 also includes security function 308 and promotion / demotion function 310, both of which are detailed below. The datastore 302 also includes a set of application programming interfaces 312 to extend the functionality of the datastore 302 to other storage platform components and application programs that utilize that 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 features of the storage platform and access data described in the schema. It has an interface (API) 322. The storage platform API322 can be used with other APIs such as OLE DB API324 and Microsoft Windows® Win32 API326 by application programs.
The storage platform 300 of the present invention can provide application programs with various services 328, including a synchronization processing service 330 that facilitates the sharing of data between users or systems. For example, the synchronization processing service 330 can enable interoperability with other data stores having the same format as the data store 302, as well as access to data stores having other formats. Storage Platform 300 also has file system capabilities that allow data store 302 to interoperate with existing file systems such as the Windows® NTFS File System 318.
In at least some embodiments, the storage platform 300 can also add additional functionality to application programming to allow manipulation of data and interaction with other systems. These functions can be embodied not only in the form of additional services such as Info Agent service 334 and notification service 332, but also in the form of other utilities 336.
In at least some embodiments, the storage platform is embodied or forms an integral part of the hardware / software interface system of the computer system. For example, but not limited to, the storage platforms of the invention are operating systems, virtual machine managers (VMMs), common language runtimes (CLRs) or their functional equivalents, or Java® virtual machines (JVMs) or their. It can be embodied in a functional equivalent or form an integral part thereof.
The storage platform of the present invention allows consumers, knowledge workers, and businesses to develop more efficient applications through a common storage infrastructure and schematized data. It not only enables features specific to the data model, but also embraces existing file systems and database access methods and provides a feature-rich programming surface area to extend.
In the following description and in various figures, the storage platform 300 of the present invention can be referred to as "WinFS". However, the use of this name to refer to a storage platform is for convenience of explanation only and is by no means intended to be limited.
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, an "Item" is a basic unit of storage information. This data model, as detailed below, provides a mechanism for declaring Item 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 the format that controls the form of an instance of Type. Its format is represented as an ordered set of Properties. Property is the name for a given Type value or set of values. For example, the USPostalAddress type can have properties Street, City, Zip, State, in which Street, City, State are of type String and Zip is of Type. Int32. Since an address can take multiple values for a Street property, Street can be multi-valued (ie, a set of values). The system defines some primitive types that can be used in other type configurations-these are String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal, and GUID. Including. The Properties of a Type can be defined using one of the primitive types or one of the configured types (with some restrictions below). For example, a Location Type with Properties Coordinate and Address can be defined, but Address Property is Type US Postal Address as described above. Properties can also be mandatory or optional.
Relationships can be declared and represented as a mapping between a set of instances of two types. For example, you can declare a relationship between a Person Type and a Location Type called LivesAt that defines which people live in which place. Relationship has one name and two end points: source end point and target end point. Relationships can also have an ordered set of properties. Both the source and target endpoints have a Name and a Type. For example, LivesAt Relationship is a Source called Occupant of Type Person, and Type. It has a Target called Dwelling for the Location, and also has properties StartDate and EndDate that indicate how long the occupant has lived in the dwelling. A person may live in multiple dwellings in the long run, and a dwelling may have multiple dwellers, so the best place to put StartDate and EndDate information is a relationship. ) It should be noted that it is itself.
Relationships define mappings between instances constrained by the type given as the end type. For example, LivesAt Relationship cannot be a relationship where Automobile is Occupant. That's because Automobile isn't a Person.
The data model allows the definition of subtype-supertype relationships between types. A child-parent relationship, also known as a BaseType relationship, is defined as if Type A is a BaseType relative to Type B, then every instance of B is also an instance of A. Another way to express this is that every instance that fits B must also fit A. For example, A has a Type String property Name, but B has a Type. If you have the property Age of Int16, then every instance of B must have both Name and Age. A 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, and so on, which is the most advanced leaf that does not have its own child type. Proceed to child type. The tree is not constrained to be of uniform depth, but cannot contain cycles. A given Type can have 0 or more child types and 0 or 1 parent type. A given instance can fit into a type along with the parent type of that type. In other words, 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 an Abstract when 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 is generally supported across all objects exposed by the storage platform to end users or application programs. Item also has properties and relationships that are generally supported across all Item types, including features that can 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 duplicate. 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 detailed below. Described.
Item is intended to represent a unit of easily understandable real-world data such as Contacts, People, Services, Locations, Documents (of any kind). FIG. 5A is a block diagram illustrating the structure of the Item. The unqualified name of the Item is "Location". The qualified name of the Item is "Core.Location", which indicates that this Item structure is defined as a particular type of Item in the Core Schema. (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 given 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 square brackets ("[[ ] ), And the asterisk (*) to the right of the colon (:) indicates an unspecified and / or unlimited number (many). The "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 (it may have no value at all). A "1" to the left of the colon indicates that there must be at least one value (property required). Both Neighborhood and Metropolitan Region are of type "nvarchar" (or equivalent type), which are defined data types or "simple types" (also represented herein by non-capitalization). However, EAddresses and PostalAddresses are properties of the predefined or "composite" types of types EAddress and PostalAddress, respectively (expressed in uppercase here). Complex types are types derived from one or more simple data types and / or other complex types. The complex type for the property of the Item also constitutes a "nested element" because the details of the complex type are nested within the Immediate Item to define that property, and the information related to those complex types is It is held with an Item that has those properties (within the boundaries of the Item, as described later in this specification). These concepts of typing are well known and easily understood by those skilled in the art.
FIG. 5B is a block diagram illustrating the composite property types PostalAddress and EAddress. The PostalAddress property type can be expected that an Item of property type PostalAddress will have 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 within the Item is defined. The EAddress property type is similarly defined as shown. As an option in this Application, another way to represent a complex type within a Location Item is to draw the Item with the individual properties of the complex type listed there. FIG. 5C is a block diagram illustrating a Location Item in which the complex type is further described. However, the location in this Figure 5C It should be understood that this alternative representation of Item is for the exact same Item as illustrated in Figure 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 (although one property type is a property of the other parent's property type). Inherit).
An item similar to a property and its property type essentially represents its own Item Types that can also be subtyped. That is, the storage platform in some embodiments of the present invention allows an Item to be a child of another Item (so that one Item inherits the properties of the other parent Item). .. Further, for various embodiments of the present invention, all Items are child types of the "Item" Item type, which is the first basic Item type found in the Base Schema. (The Base Schema will be described in more detail later in this specification.) Figure 6A illustrates an Item, the Location Item of this Instance, as a child of the Item Item type in the Base Schema. There is. In this drawing, the arrows indicate that the Location Item (like all other Items) is a child of the Item Item type. Item Item The 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 defining the standard properties of all Items in the operating system. To do. In this figure, these properties of type Item Item are inherited by Location, which makes them Location properties.
Another way to represent a property in a Location Item inherited from an Item Item type is to draw a Location on an individual property 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 the immediate property. This Item is the same Item as illustrated in Figure 5A, but in this figure Location is illustrated with all of its properties and both are immediate-shown in both this figure and Figure 5A. Note that-and inherited-shown in this figure but not in Figure 5A-and should be understood (but in Figure 5A, the Location Item is a child type of the Item Item type. Those properties are referenced by the arrows indicating that).
Items are standalone objects, so deleting an Item also deletes all of those Item's immediate and inherited properties. Similarly, when you retrieve an Item, you receive all of the Item and its immediate and inherited properties, including information related to the complex property type. In some embodiments of the invention, it is possible to request a subset of properties when retrieving a particular Item, but as many defaults in such embodiments, when retrieved, it is immediate. And supply all of the inherited properties to Item. In addition, Item properties can be extended by adding new properties to existing properties of that Item type. These "extensions" are hereafter real properties of the Item, and child types of that Item type 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 that can be performed on an Item, such as copy, delete, move, and create. For example, in some embodiments of the invention, when an Item is copied, everything within the boundaries of that Item is also copied. For each item, the boundaries include:
If the Item Type of the Item and the Item are child types of other Items (as in some embodiments of the invention where all Items are derived from a single Item and Item Type in the Base Schema) , Any applicable child type information (that is, information related to the parent Item Type). If the original Item from which you are copying is a child of another Item, that copy can also be a child of that 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.
A record of an Item related to "ownership", that is, a list of the Item itself of another Item ("Target Item") owned by this Item ("Owning Item"). This is particularly relevant for Item Folders, which will be discussed in more detail below, and the rules stipulate below that all Items must belong to at least one Item Folder. Further, with respect to embedded items-more in detail below-the embedded items are considered part of the items that are embedded for operations such as copy and delete.
2. Item identification Items are uniquely identified within the global items space with the ItemID. The Base.Item type defines the field ItemID of the type GUID that stores the ID of the Item. Item must have exactly one ID in datastore 302.
a) Item reference An item reference is a data structure that stores information for identifying and identifying an Item. In the data model, abstract types are 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 the ItemReference and returns an Item. This method is overridden by a specific child type of ItemReference that implements the function that retrieves the item given the reference. The Resolve method is called as part of the storage platform API322.
(1) ItemIDReference ItemIDReference is a child type of ItemReference. It defines the Locator and ItemID fields. The Locator field names (that is, identifies) the item domain. This is handled by a locator resolution method that can resolve the Locator value to the item area. The ItemID field is of type ItemID.
(2) ItemPathReference ItemPathReference is a specializaiton of ItemReference that defines the Locator and Path fields. The Locator field identifies the item area. This is handled by a locator resolution method that can resolve the Locator value to the item area. The Path field contains the (relative) path in the storage platform namespace rooted in the item area given by the Locator.
This type of reference cannot be used in a set operation. References generally have to be resolved through the path resolution process. The Resolve method of the storage platform API 322 provides this functionality.
b) Reference type hierarchy The above-mentioned reference form 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 the type of target field.
3.Item Folders and Categories As described in detail below, groups of items can be organized into special items called Item Folders (which should not 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. It can be accessed directly from. In essence, access to an Item can come from different Item Folders, but what is actually accessed is, in fact, exactly the same Item. However, the Item Folder does not necessarily own all of its member Items, or it can simply co-own an Item with other folders, and deleting an Item Folder will result in the deletion of the Item as well. It is not always done. However, in some embodiments of the invention, the Item is at least one Item. Must belong to a Folder, and therefore when a single Item Folder for a particular Item is deleted, the Item is automatically deleted in some embodiments, or the Item is automatic in other embodiments. It becomes a member of the default Item Folder (for example, "Trash Can" Item Folder, which is conceptually similar to the similar name folder used in various files-folder-based systems).
Also detailed below, an Item is also a specific item that corresponds to (a) Item Type (or Types), (b) a particular immediate or inherited property (or properties), or (c) Item property. It may belong to Categories based on common described properties such as value (or multiple values). For example, an Item containing a particular property of personal contact information may automatically belong to the Contact Category, and an Item containing the contact information property will automatically belong to this Category as well. Similarly, any Item for which a position property with the value "New York City" is set can automatically belong to the New York City Category.
Item Folders can contain items that are not related to each other (that is, they do not have common described properties), but each Item in a Category has a common type, property, or that is described for that Category. Categories is associated with Item Folders in that it has a value (commonality) and is the basis for relationships with other Items in the Category, and between other Items. Conceptually different. Moreover, the membership of an Item to a particular Folder is not compulsory based on that particular aspect of that Item, but in some embodiments the commonality is related to the Category for the category. All Items can be automatically members of the Category at the hardware / software interface system level. Conceptually, Categories is a virtual Item whose attribution is based on the result of a particular query (as in the case of a database background). Items that can be thought of as Folders and that satisfy this query (defined by Category commonality) will contain Category attribution.
FIG. 4 illustrates the structural relationships between Items, Item Folders, and Categories in various embodiments of the present invention. Multiple Items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of various Item Folders 422, 424, 426, 428, and 430. Some Items belong to multiple Item Folders, for example Item 402 is Item It belongs to Folders 422 and 424. Some Items, such as Items 402, 404, 406, 408, 410, and 412, are also members of one or more Categories 432, 434, and 436, but which are, for example, Items 414, 416, 418, and 420. It also cannot belong to Categories (although this is unlikely in some embodiments where property ownership automatically means attribution to Category, and Items are not members of categories in such embodiments. Would have to be completely featureless). In contrast to the hierarchical structure of folders, 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 (despite different Item Types).
In contrast to files, folders, and directories, there is no concept of physical containers for Items, Item Folders, and Categories of the present invention, and therefore Items can reside in such multiple locations. Therefore, it does not have the characteristic of "physical" in nature. The ability of Items to exist in multiple Item Folder locations, as well as being organized into Categories, enhances and enhances data manipulation and storage structure capabilities at the hardware / software interface level beyond what is currently available in the industry. It has become.
4.Schemas a) Base Schema To provide a universal basis for the creation and use of Items, various embodiments of the storage platform of the present invention include a Base Schema that establishes a conceptual framework used to create and organize items and properties. The Base Schema defines some special types of Items and properties, as well as the characteristics of these special base types from which they can be further derived. This Base Schema allows programmers to conceptually distinguish Items (and their respective types) from properties (and their respective types). In addition, in the Base Schema, properties that all Items can own when they derive from this underlying Item (and its corresponding Item Type) in the Base Schema. Defines the basic set of.
As illustrated in Figure 7, and for some embodiments of the invention, the Base Schema defines three top-level types: Item, Extension, and PropertyBase. As shown in the figure, the Item type is defined by the properties of this basic "Item" Item type. In contrast, the top-level property type "PropertyBase" has no predefined properties and is just an anchor when all derived property types are interrelated, from which all other property types are derived. Not too much (usually derived from a single property type). The Extension type property defines which Item is extended by the extension when the Item may have multiple extensions, and also defines the identification to distinguish one extension from the other. ..
ItemFolder is a child type of Item Item 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 a Core Schema that provides a conceptual framework for top-level Item type structures. 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 a Core Schema function. Similar to. Core Schema understands all Items directly (by Item type) or indirectly (by Item child type) in Item-based hardware / software interface systems by Item-based hardware / software interface systems. And one or more Core Schemas that can be processed directly in a given predictable way Define a set of core Item types that characterize the Item type. Predefined Item types reflect the most common Items in Item-based hardware / software interface systems, and therefore item-based hardware that recognizes predefined Item types, including Core Schema, with a certain level of efficiency. / Obtained by software interface system.
In some embodiments, the Core Schema is not extensible-that is, to subtype additional Item types directly from the Base Schema Item type, except for certain predefined derived Item types that are part of the Core Schema. Can't. Since all subsequent Item types are always child types of the Core Schema Item type, by prohibiting extensions to the Core Schema (that is, by prohibiting the addition of new Items to the Core Schema), the storage platform Mandatory to use the Core Schema Item type. This structure gives you plenty of freedom to define additional Item types, while retaining the advantage of having a predefined set of core Item types.
For various embodiments of the invention, with reference to FIG. 8A, the particular Item type supported by the Core Schema can include one or more of the following:
· Categories: Items of this Item Type (and its derived child types) represent valid Categories for Item-based hardware / software interface systems.
· Commodities: Items that are valuable and identifiable.
-Devices: Items with a logical structure that supports information processing functions.
-Documents: Items that are not interpreted by the Item-based hardware / software interface system, but instead have content that is interpreted by the application program that supports the document type.
-Events: An Item that records something that happens in the environment.
-Locations: Items that represent physical locations (for example, geographical locations).
· Messages: Item of communication between two or more principals (defined below).
Principals: Items that have at least one definitive provable ID in addition to the Item ID (eg, identification of people, organizations, groups, households, institutions, services, etc.).
· Statements: Items that have, but are not limited to, special information about the environment, including policies, subscriptions, credentials, and so on.
Similarly, referring to Figure 8B, certain property types supported by the Core Schema can include one or more of the following:
-Certificates (derived from the basic PropertyBase type in the Base Schema) -Principal Identity Keys (derived from Identity Key type in Base Schema) -Postcard 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 Relationship type in Base Schema) These Items and Properties are further described by the respective properties described in FIGS. 8A and 8B.
5. Relationship Relationships are binary relations in which one Item is specified as the source and the other Item is specified as the target. The source Item and the target Item are related by this relationship. The source Item generally controls the lifetime of the relationship. In other words, when the source items are deleted, the relationships between those items are also deleted.
Relationships are classified into containment relationship Containment and reference relationship Reference. Inclusion relationships control the lifetime of the target Item, but reference relationships have no meaning in lifetime management. Figure 12 illustrates how relationships are categorized.
Containment relation types are further classified into holding relation Holding and embedding relation Embedding. When all retention relationships for an Item are deleted, that Item is also deleted. Retention relationships use a reference counting mechanism to control the lifetime of a target. Embedded relationships allow the modeling of compound items, which can be thought of as exclusive retention relationships. Item can be the target of one or more retention relationships, while Item can be the target of exactly one embedding relationship. An Item that is the target of an embedding relationship cannot be the target of any other retention or embedding relationship.
Reference relationships do 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 somewhere in the global Item namespace (that is, including remote datastores).
Fetching an Item does not automatically fetch the relationship. The application must explicitly request the Item relationship. Furthermore, modifying the relationship does not modify the source or target Item, and adding a relationship does not affect the source / target Item as well.
a) Declaration of relationship Explicit relation types are defined by the following elements:
-Relationship name is specified by Name attribute.
-One of Holding, Embedding, and Reference as a relation type. This is specified in the Type attribute.
-Source and target endpoints. Each end point specifies the name and type of the referenced Item.
The source end field is generally of type ItemID (not declared) and must reference an Item in the same datastore as the related instance.
-For Holding and Embedding relationships, the target end field must be of type ItemIDReference and must refer to an Item in the same store as the relationship instance. For the Reference relationship, the target end point can be any ItemReference type, and can refer to Items in the datastore of other storage platforms.
-Optionally, you can declare one or more fields of type scalar or PropertyBase. These fields can store the data associated with the relationship.
-Relationship instances are stored in the global relationship table.
-All relationship instances are uniquely identified by the combination (source ItemID, relationship ID). The relationship ID is unique within the given source ItemID for all relationships sourced from the given Item, regardless of its type.
The source Item is the owner of the relationship. The Item specified as the owner controls the lifetime of the relationship, but the relationship itself is separate from the Item with which it is associated. Storage platform API 322 provides a mechanism for exposing relationships associated with Items.
An example of the relationship declaration is shown below.
<tables num="1"><img file="JP4394643B2_D0001.tif" /></tables>
This is an example related to Reference. This relationship cannot be created if the person Item referenced by the source reference does not exist. In addition, if the person Item is deleted, the relationship instance between the person and the organization is deleted. However, if the Organization Item is deleted, the relationship is not deleted and it becomes dangling.
b) Holding Relationship Retention relationships are used to model reference-count-based lifetime management for target items. Item can be the source endpoint for zero or more relationships with Item. Items that are not embedded items can be targeted in one or more retention relationships. The target endpoint reference type must be an ItemIDReference and must reference an Item in the same store as the related instance.
The retention relationship manages the duration of the target end point. Creating a retention relationship instance and the Item it targets is an atomic operation. It is possible to create an additional retention relationship instance targeting the same Item. When the last holding relationship instance with the given Item as the target end point is deleted, the target Item is also deleted.
The type of the endpoint Item specified in the relationship declaration is generally enforced when the relationship is instantiated. After the relationship is established, the type of the endpoint 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 arise from a given Item. This ordered list of relative names, starting with the root Item and ending with the given Item, forms the full name for the Item.
Retention relationships form a non-circulating directed graph (DAG). When a retention relationship is created, the system ensures that no cycles are created and that the Item namespace always forms a DAG.
The retention relationship controls the lifetime of the target Item, but not the integrity of the behavior of the target endpoint Item. The target Item is behaviorally independent of the Item that owns it through the retention relationship. Copy, Move, Backup, and other operations on the item that is the source of the retention relationship do not affect the item that is the target of the same relationship-for example, backing up a Folder Item will still put all the items in a folder. It does not automatically back up in (FolderMember related target).
The following is an example of a retention relationship.
<tables num="2"><img file="JP4394643B2_D0002.tif" /></tables>
The FolderMembers relationship makes the Folder concept available as a generic collection of Items.
c) Embedding relationship Embedded relationships model the concept of exclusive control over the lifetime of a target Item. These enable the concept of compound items.
Creating an embedded relationship instance and the Item it targets is an atomic operation. Item can be a source of 0 or more embedded relationships. However, Item can be the only target for embedded relationships. Item, which is the target of the embedded relationship, cannot be the target of the retention relationship.
The target endpoint reference type must be an ItemIDReference and must reference an Item in the same datastore as the relationship instance. The type of the endpoint Item specified in the relationship declaration is generally enforced when the relationship is instantiated. After the relationship is established, the type of the endpoint Item cannot be changed. The embedded relationship controls the integrity of the behavior of the target endpoint. For example, an operation that serializes an Item can include all serializations of that target, as well as all embedded relationships that source that Item, and by copying the Item, all of its embedded relationships. Item is also copied.
The following is an example declaration.
<tables num="3"><img file="JP4394643B2_D0003.tif" /></tables>
d) Reference relationship Reference relationships do not control the lifetime of the referenced Item. Furthermore, the reference relationship does not guarantee the existence of the target, nor does it guarantee the type of the target as specified in the relationship declaration. This means that the reference relationship can be dangling. In addition, the reference relationship can refer to an Item in another data store. Reference relationships can be thought of as a concept similar to links in web pages.
An example of the reference relationship declaration is shown below.
<tables num="4"><img file="JP4394643B2_D0004.tif" /></tables>
Reference types can be used at the end of the target. The Item related to the reference relationship can be any Item type. Reference relationships are used to model most non-lifetime management relationships between Items. Reference relationships are useful for modeling loosely coupled relationships, as the existence of targets is not enforced. Reference relationships can be used to target items in other datastores, including stores on other computers.
e) Rules and constraints The following additional rules and constraints apply to relationships. 1.Item must be the target of (exactly one embed relationship) or (one or more retention relationships). One of the exceptions is the root Item. Item can be the target of zero or more reference relationships.
2. The Item that is the target of the embedded relationship cannot be the source of the retained relationship. This can be the source of the reference relationship.
3.Item cannot be the source of retention when upgraded from a file. It can be the source of embedded and reference relationships.
4. Items upgraded from a file cannot be targeted for embedding relationships.
f) Relationship ordering In at least one embodiment, the storage platform of the present invention supports relationship ordering. Ordering is performed through a property named "Order" in the basic relationship definition. There are no unique constraints 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 relationships with low "order" values and before relationships with high "order" field values.
The application can get the relationships in the default order by ordering the combinations (SourceItemID, RelationshipID, Order). All relationship instances 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 datastore API 312 that manipulates relationships implements a set of operations that support relationship ordering. The following terms are introduced as an aid to describe the operation. RelFirst is the first relationship in an ordered collection with the ordered value OrdFirst. RelLast is the last relationship in an ordered collection with the ordered value OrdLast. RelX is a given relationship in a collection with the sequence value OrdX.
RelPrev is the closest relationship to RelX in the collection, where the order value OrdPrev is smaller than OrdX. RelNext is the closest relationship to RelX in the collection, where the order value OrdNext is greater than OrdX. InsertBeforeFirst (SourceItemID, Relationship) Insert the relationship as the first relationship in the collection. The value of the "Order" property of the new relationship may be less than the OrdFir st. InsertAfterLast (SourceItemID, Relationship) Insert the relationship as the last relationship in the collection. The value of the "Order" property of the new relationship may be higher than OrdLast. InsertAt (SourceItemID, ord, Relationship) Inserts a relationship with the specified value for the "Order" property. InsertBefore (SourceItemID, ord, Relationship) Insert a relationship before a relationship with a given sequence value. New relationships can be assigned an "Order" value between OrdPrev and ord that does not include it. InsertAfter (SourceItemID, ord, Relationship) Insert a relationship after a relationship with a given sequence value. New relationships can be assigned an "Order" value between ord and OrdNext, but not including it. MoveBefore (SourceItemID, ord, RelationshipID) Moves a relationship with the given relationship ID before the relationship with the specified "Order" value. This relationship can be assigned a new "Order" value between OrdPrev and ord that does not include it. MoveAfter (SourceItemID, ord, Relationship ID) Moves a relationship with the given relationship ID after the relationship with the specified "Order" value. This relationship can be assigned a new sequence value between ord and OrdNext, but not including it.
As mentioned earlier, all Items must be members of the Item Folder. For Relationships, all Items must have a relationship with the Item Folder. In some embodiments of the invention, the relationships that exist between the Items represent a particular relationship.
As implemented in various embodiments of the present invention, Relationships implement a directed binary relation that is "extended" by one Item (source) to the other Item (target). Relationships are owned by the source Item (an item that extends it), so Relationships are deleted when the source is deleted (for example, Relationships are deleted when the source Item is deleted). In addition, in some instances, the Relationship can share (co-own) ownership of the Target Item, and such ownership will be reflected within the Relationship's IsOwned property (or its equivalent). Is possible (as shown in Figure 7 for the Relationship property type). In these embodiments, the new IsOwned Creating a relationship automatically increments the reference count of the target item, and removing such a relationship decrements the reference count of the target item. In these particular embodiments, the Item will continue to exist if the reference count is greater than 0 and will be automatically deleted when the count reaches 0. Again, an Item Folder is an Item that has (or can have) a set of relationships with other Items, and those other Items contain the Attribution of the Item Folder. Other practical implementations of Relationships are possible and are expected to implement the functionality described herein by the present invention.
Regardless of the actual implementation, a relationship is a selectable connection from one object to the other. An Item can belong to multiple Item Folders, as well as one or more Categories, and whether these Items, Folders, and Categories are public or private is an Item-based structure. Determined by the meaning given to being (or not being) within. These logical relationships are the meanings assigned to a set of relationships that are not related to physical implementation and are specifically adopted to realize the functions described herein. Logical Relationships are established between an Item and its Item Folder (s) or Categories (and vice versa), because in essence Item Folders and Categories are special types of Items, respectively. Is. Therefore, Item Folders and Categories work like any other Item-but not limited to copying, adding to email messages, embedding in documents, etc.-and for Item Folders and Categories, You can serialize and deserialize (import and export) 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 Relationships mentioned above 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 is Item Indicates that the Folder is public to the Item and shares the attribution information with the Item, but conversely, the absence of a logical relationship from the Item to the Item Folder means that the Item Folder is for that Item. Indicates that it is private and does not share attribution information with the Item. Similarly, a relationship that logically extends from an Item Folder to an Item indicates that the Item is public and sharable to that Item Folder, but the absence of a logical Relationship from an Item Folder to an Item means that there is no logical relationship from the Item Folder to the Item. Indicates that the Item is private and non-shareable. Therefore, an Item Folder is a "public" Item that is shared in the new context when exported to another system, and if an Item searches for other sharable Items within that Item Folders, it belongs to the sharable. "Public" Item Folders that supply Items with information about the Item.
FIG. 9 is a block diagram illustrating the Item Folder (which is also the Item itself), its member Items, and the interconnection relationships between the Item Folder and its member Items. Item Folder 900 has multiple Items 902, 904, and 906 as members. Item Folder 900 goes to Item Folder 900, its members 904 and 906, and other Item Folders, Categories, or Items (not shown) where Item 902 is public and may access Item Folder 900. On the other hand, it has a relationship 912 to Item 902 from itself, which indicates that it can be shared. However, there is no relationship from Item 902 to Item Folder 900 that indicates that Item Folder 900 is private to Item 902 and does not share attribution information with Item 902. On the other hand, Item 904 is Item It has a Relationship 924 from itself to Item Folder 900, which represents that Folder 900 is public and shares attribution information with Item 904. However, Item 904 is private and can access Item Folder 900, its other members 902 and 906, and Item Folder 900 other Item Folders, Categories, or Items (not shown) There is no relationship from Item Folder 900 to Item 904, which indicates that it is not sharable. 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 back to Item Folder 900, Together, Item 906 is public and Item Folder Being sharable to 900, its members 902 and 904, and other Item Folders, Categories, or Items (not shown) that may access Item Folder 900, and Item Folder 900 Represents being public and sharing attribution information with Item 906.
As mentioned earlier, the Items in the Item Folder do not need to share commonality because the Item Folders are not "descripted". Categories, on the other hand, are described by commonality that is common to all of its member Items. Therefore, Category attribution is essentially limited to Items with the commonality described, and in some embodiments, all Items that satisfy the Category description are automatically made members of Category. .. Therefore, in Item Folders, trivial type structures can be represented by their attribution, but in Categories, attribution can be based on defined commonality.
Of course, Category descriptions are logical in nature, so Categories can be described by logical representations of types, properties, and / or values. For example, the logical representation of Category can be such that the attribution involving the Item has one or both of the two properties. If these described properties for a Category are "A" and "B", then the Categories attribution is an Item with property A but no B, an Item with property B but no A, and property A and Can contain Items with both B's. This logical representation of a property is described by the logical operator "OR", and the set of members described by Category is an Item with property A OR B. Any person skilled in the art can use similar logical operands (including, but not limited to, "AND", "XOR", and "NOT" alone or in combination) to describe a category. You will understand.
Despite the distinction between Item Folders (not described) and Categories (described), Categories Relationship vs. Item and Item Relationship vs. Categories are described herein for Item Folders and Items in many embodiments of the invention. It is essentially the same as that previously disclosed in the book.
FIG. 10 is a block diagram illustrating the Category (again, the Item itself), its member Items, and the Relationships of the interconnections between the Category and its member Items. Category 1000 has multiple Items 1002, 1004, and 1006 as members, all of which are any combination of common properties, values, or types 1008 as described by Category 1000 (commonality description 1008'). Share. Category 1000 is shared with Category 1000, its members 1004 and 1006, and other Categories, Item Folders, or Items (not shown) where Item 1002 is public and may access Category 1000. It has a Relationship 1012 from itself to Item 1002, which represents it is possible. However, Category 1000 is private to Item 1002 and Item There is no Relationship from Item 1002 to Category 1000, which means that it does not share attribution information with 1002. Item 1004, on the other hand, has a relationship 1024 from itself to Category 1000, indicating that Category 1000 is public and shares attribution information with Item 1004. However, for Category 1000, its other members 1002 and 1006, and other Categories, Item Folders, or Items (not shown) that are private and may access Category 1000. There is no Category 1000 to Item 1004 relationship that indicates that it is not sharable. In contrast to its Relationships (or its absence) to Items 1002 and 1004, Category 1000 has a Relationship 1016 from itself to Item 1006, and Item The 1006 has a Relationship 1026 that returns to Category 1000, together with Item 1006 being public, Category 1000, its Item members 1002 and 1004, and other Categories, Item Folders that may access Category 1000. , Or that it can be shared with an Item (not shown), and that Category 1000 is public and shares attribution information with Item 1006.
Finally, in some other embodiments, Categories and Item Folders are themselves Items, so Items have a relationship with each other, Categories has a relationship to Item Folders and vice versa, Categories, Item Folders. , 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 cycle-prohibiting embodiment is a directed graph in which any path begins and ends at the same vertex, by mathematical definition in 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. However, in addition, 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 provides a mechanism for creating such schemas by extending the Item and Nested Element types (or simply the "Element" types) defined within the initial set of schemas (Platform Schema) 340. I will pick it up.
The extension of the initial set of Item and Nested Element types is preferably constrained as follows. ISVs are allowed to introduce a new Item type, the child Base.Item. ISVs are allowed to introduce a new Nested Element type, the child Base.Nested Element. ISVs are allowed to introduce new extensions, the child Base.NestedElement. But, ISVs cannot subtype the types (Item, Nested Element, or Extension types) defined by the initial set of storage platform schemas (Platform Schema) 340.
The Item or Nested Element types defined by the initial set of storage platform schemas may not exactly match the requirements of the ISV application, so the ISV must be able to customize the type. This is made possible by the concept of Extensions. Extensions are strongly typed instances, but (a) they cannot exist independently and must (b) be attached to an Item or Nested Element.
In addition to meeting the need for schema extensibility, Extensions is also intended to eliminate the "multi-type" problem. In some embodiments, the storage platform may not support multiple inheritance or duplicate child types, so Extensions can be used on the application side as a means of modeling duplicate instances (eg,). , Document is both a legal document and a security document).
a) Item expansion To do the Item extension, the data model also defines an abstract type named Base.Extension. This is the root type for the dilated hierarchy. Applications can subtype Base.Extension to create specific extensions.
The Base.Extension type is defined in the Base schema as follows.
<tables num="5"><img file="JP4394643B2_D0005.tif" /></tables>
The ItemID field contains the ItemID of the item with the associated extension. Item with this ItemID must exist. Extensions cannot be created if the item with the given ItemID does not exist. When an Item is deleted, all extensions with the same Item ID are deleted. Tuples (ItemID, ExtensionID) uniquely identify an extension instance.
The dilated structure is similar to the item structure. The extended type has a field. The field can be a primitive or nested element type. Dilated can be subtyped.
The following constraints apply to dilated types. Extensions cannot be the source and target of relationships. An extended instance cannot exist independently of an item. Dilated 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 dilated type can be used to extend an item type. When multiple extension instances are attached to an item, they are independent of each other in terms of both structure and behavior. Multiple extended instances are stored and accessed separately from the item. All extended instances are accessible from the global extended view. Regardless of the type of the associated item, you can create an efficient query that returns all instances of the given extension type. The Storage Platform API provides a programming model that allows you to store, retrieve, and modify extensions on items.
Dilated types can be subtyped using the storage platform's single inheritance model. Derivation from dilated creates new dilated. Extension structures or behaviors cannot override or replace item type hierarchy structures or behaviors. Like the Item type, Extension type instances can be accessed directly through the view associated with the extension type. The extension's ItemID indicates which item it belongs to, which can be used to retrieve the corresponding Item object from the global Item view. Extensions are considered part of the item for consistent behavior. 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® Type settings.
<tables num="6"><img file="JP4394643B2_D0006.tif" /></tables>
CRM application developers want to attach CRM application extensions to contacts stored on the storage platform. The application developer defines a CRM extension that contains additional data structures that can be manipulated on the application side.
<tables num="7"><img file="JP4394643B2_D0007.tif" /></tables>
HR application developers also want to attach additional data to Contact. This data is independent of CRM application data. Again, this application developer can create extensions.
<tables num="8"><img file="JP4394643B2_D0008.tif" /></tables>
The CRM Extension and HR Extension 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, fields and methods of type CRMExtension cannot override fields or methods in the Contact hierarchy. An instance of CRMExtension type can be attached to Item type other than Contact.
When a Contact item is retrieved, the item extension is not retrieved automatically. Given a Contact item, the associated item extension can be accessed by querying the extension's global extension view with the same ItemId. All CRMExtension extensions in the system can be accessed through a CRMExtension type view, regardless of which item they belong to. All item extensions of 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 table below summarizes the similarities and differences between the Item, Extension, and NestedElement types.
<tables num="9"><img file="JP4394643B2_D0009.tif" /></tables>
b) Extension of 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 route for a nested element type named Element.
<tables num="10"><img file="JP4394643B2_D0010.tif" /></tables>
The NestedElement type inherits from this type. The NestedElement element type also defines a field that is a multiset of Elements.
<tables num="11"><img file="JP4394643B2_D0011.tif" /></tables>
The NestedElement extension differs from the item extension in the following ways: Nested element extensions are not dilated. They do not belong to the dilated hierarchy rooted in the Base.Extension type. Nested element extensions are stored with other fields in the item and are not globally accessible-you cannot create a query that retrieves all instances of a given extension.
These extensions are stored in the same way that other nested elements (of items) are stored. Like other nested sets, NestedElement extensions are stored in UDTs. These are accessible through nested element type Extensions fields. The collection interface used to access multi-valued properties is also used to access and iterate over a set of type extensions.
The table below summarizes and compares Item Extensions and Nested Element extensions.
<tables num="12"><img file="JP4394643B2_D0012.tif" /></tables>
D. Database engine As mentioned above, the datastore is implemented on the database engine. In the present invention, the database engine includes a relational database engine that implements a SQL query language such as Microsoft SQL Server, as well as an object relational extension. 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 invention. However, it will be understood that different mappings can be adopted when different database engines are used. In fact, in addition to implementing the conceptual data model of the storage platform on a relational database engine, it can also be implemented on other types of databases, such as object-oriented and XML databases.
Object-oriented (OO) database systems provide persistence and transactions for programming language objects (eg, C ++, Java®). The concept of "items" in storage platforms 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 usually already support object identification, so item identification can be mapped to object identification. Item behaviors (operations) are nicely mapped to object methods. However, object-oriented systems usually lack the ability to organize and have poor search capabilities. Object-oriented systems also do not support unstructured and semi-structured data. Concepts such as relationships, folders, and extensions will need to be added to the object data model to support the full storage platform data model described herein. In addition, mechanisms such as promotion, synchronization, notification, and security will need to be implemented.
Like 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. Also, XSD does not support behaviors. The XSD for the item will have to be enhanced by the item behavior. XML databases handle a single XSD document and lack organizational 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, and synchronization, Mechanisms such as notification and security also need to be implemented.
1. Implementing a datastore using UDT In an embodiment of the invention, a relational database engine 314, including the Microsoft SQL Server engine in one embodiment, supports a built-in scalar type. Built-in scalar types are "native" and "simple". They are native in that users cannot define their own types, and they are simple in that they cannot encapsulate composite structures. User-defined types (hereafter UDT) are on and beyond the native scalar type system by allowing users to extend the type system by defining composite structure types. , Provides a mechanism for type scalability. After being defined by the user, the UDT can be used anywhere a built-in scalar type is available in the type system.
According to one aspect of the invention, the storage platform schema is mapped to UDT classes in the database engine store. The datastore Item is mapped to a UDT class that derives from the Base.Item type. Like Item, 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 states (that is, data fields) and behaviors (that is, routines). UDT is defined using managed languages-C #, VB.NET, etc. UDT methods and operators can be called in T-SQL for instances of that type. UDT can be the type of one column in a row, the type of a T-SQL routine parameter, or the type of a T-SQL variable.
The following examples illustrate the basics of UDT. Suppose MapLib.dll has an assembly called MapLib. In this assembly, under the namespace BaseTypes, there is a class called Point.
<tables num="13"><img file="JP4394643B2_D0013.tif" /></tables>
The following T-SQL code binds the class Point to a SQL Server UDT called Point. The first step is to call "CreateAssembly", which loads the MapLib assembly into the database. In the second step, we call "Create Type" to create a user-defined type "Point" and bind it to the managed BaseTypes.Point.
<tables num="14"><img file="JP4394643B2_D0014.tif" /></tables>
Once created, the "Point" UDT can be used as a column in a table and the method can be called in T-SQL as shown below.
<tables num="15"><img file="JP4394643B2_D0015.tif" /></tables>
Mapping the storage platform schema to UDT classes is fairly easy at a high level. Generally, the storage platform Schema is mapped to the CLR namespace. The storage platform Type is mapped to the CLR class. CLR class inheritance reflects storage platform Type inheritance, and storage platform Property is mapped to CLR class properties.
The Item hierarchy illustrated in FIG. 29 is used herein as an example. It shows the Base.Item type from which all Item types are derived, along with a set of derived Item types (eg Contact.Person and Contact.Employee), and inheritance is indicated by arrows.
2. Item mapping Given that Items should be globally searchable, and with the relational database support of the invention for inheritance and type substitutability, one possible implementation of Item storage in the database store would be for all Items. Store in a single table containing columns of type Base.Item. Type substitutability allows you to store Items of all types, and use Yukon's "is of (Type)" operator to filter searches by Item type and child types. Becomes possible.
However, in the present invention, due to concerns about the overhead associated with such an approach, Items are split by the top-level type, and the "family" Items of each type are stored in separate tables. .. According to this partitioning scheme, one table is created for each Item type that inherits directly from Base.Item. The type inheritance below these is stored in the appropriate type family table using type substitutability, as described above. Only the first level of inheritance from Base.Item is treated specially. For example, in the Item hierarchy shown in FIG. 29, this results in the following type family table:
<tables num="16"><img file="JP4394643B2_D0016.tif" /></tables>
A "shadow" table is used to store a globally searchable copy of the property for all Items. This table can be maintained by the Update () method of the Storage Platform API, which is used when all data changes are made. Unlike the type family table, the global Item table is not a complete UDT Item object, but contains only the top-level scalar property of the Item. The structure of the global Item table is as follows.
<tables num="17"><img file="JP4394643B2_D0017.tif" /></tables>
In the global Item table, you can navigate to the Item object stored in the type family table by exposing the ItemID and TypeID. ItemID generally uniquely identifies an Item in a data store. The TypeID can be mapped to a view containing the type name and Item using metadata not described here.
Finding an Item by its ItemID is a normal operation, so in the context of both the global Item table and some other means, there is a GetItem () function that retrieves an Item object when you specify the ItemID of the Item. .. This function has the following declaration: Base.Item Base.GetItem (uniqueidentifier ItemID)
For easy access and hiding implementation details as much as possible, all queries for an Item can be made to the view built on the Item table described above. In particular, the view can be created for each Item type against the corresponding type family table. In these type views, you can select all Items of the associated type, including child types. For convenience, in addition to UDT objects, those views can expose columns for all top-level fields of that type, including inherited fields. The view of the Item hierarchy example shown in FIG. 29 is as follows.
<tables num="18"><img file="JP4394643B2_D0018.tif" /></tables>
For completeness, you can also create a view on top of the global Item table. This view can initially expose the same columns as its table.
<tables num="19"><img file="JP4394643B2_D0019.tif" /></tables>
3. Extended 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 trade-off relationships with storage considerations. For this reason, similar type mappings apply to Extensions rather than the single table approach. Of course, in other embodiments it is possible to use a single table approach.
In an embodiment of the invention, the 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.
<tables num="20"><img file="JP4394643B2_D0020.tif" /></tables>
As in the case of Item, it is possible to prepare a function that retrieves the extension given the identification, which consists of a pair of ItemID and ExtensionID. This function has the following declaration:
<tables num="21"><img file="JP4394643B2_D0021.tif" /></tables>
View is created for each Extension type and is similar to Item type view. Assume an Extension hierarchy parallel to the Item hierarchy example, with the types Base.Extension, Contact.PersonExtension, and Contact.EmployeeExtension. You can create the following views.
<tables num="22"><img file="JP4394643B2_D0022.tif" /></tables>
4. Mapping of nested elements Nested Elements are types 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. Therefore, Nested Elements has no storage mapping beyond its Item and Extension containers. That is, there is no table on the system that directly stores instances of type NestedElement, and there is no dedicated view for Nested Elements.
5. Object Identity Each entity in the data model, that is, each Item, Extension, and Relationship, has a unique key value. Item is uniquely identified by ItemID. Extension is uniquely identified by the composite key of (ItemId, ExtensionId). Relationships are identified by compound keys (ItemId, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.
6. SQL object naming convention All objects created in the datastore can be stored with a SQL schema name derived from the storage platform schema name. For example, the storage platform Base schema (often referred to as "Base") can be typed with a "[System.Storage]" SQL schema such as "[System.Storage] .Item". The generated name is prefixed with a qualifier to eliminate naming conflicts. As appropriate, an exclamation mark (!) Is used as a divider for each logical part of the name. The following table outlines the naming conventions used for objects in the datastore. Each schema element (Item, Extension, Relationship, and View) is listed with a decorated naming convention used to access the instances in the datastore.
<tables num="23"><img file="JP4394643B2_D0023.tif" /></tables>
7. Column naming convention When mapping an object model to a store, naming conflicts can occur because additional information is stored with the application objects. To avoid naming conflicts, prefix all non-type specific columns (columns that are not directly mapped to a named Property in a type declaration) with an underlined (_) character. In the embodiment of the present invention, the underlined (_) 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 have a capitalized first letter to ensure a unified nomenclature between the CLR and the datastore.
8. Search view Views are provided by the storage platform to search for stored content. SQL views are provided for each Item and Extension type. 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 detailed below.
Each view explicitly defined in the storage platform schema (defined by the schema designer and not automatically generated by the storage platform) is a named SQL view [<schema-name>]. [View! < It can be accessed by view-name>]. For example, a view named "BookSales" in the schema "AcmePublisher.Books" can be accessed using the name "[AcmePublisher.Books]. [View! BookSales]". Since the output format of a view can be changed on a per-view basis (defined by any query given 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's datastore use the following ordering rules for columns. 1. (Multiple) logical "key" columns of view results such as ItemId, ElementId, RelationshipId, .... 2. Metadata information about the resulting type, such as TypeId. 3. Change tracking columns such as CreateVersion, UpdateVersion, ... 4. Type-specific columns (property of the declared type) 5. A type-specific view (family view) also contains an object column that returns an object.
Members of each type family can be searched using a set of Item views, and there is one view for each Item type in the data store.
a) Item 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 on a Document can return instances of Document, LegalDocument, and ReviewDocument. In this example, the Item view can be conceptualized as shown in Figure 28.
(1) Master item search view Each instance of the storage platform's datastore defines a special Item view called the Master Item View. This view provides summary information about each Item in the data store. The view shows one column for each Item type property, which describes the type of the Item and multiple columns used to provide change tracking and synchronization information. The master item view is identified in the datastore using the name "[System.Storage]. [Master! Item]".
<tables num="24"><img file="JP4394643B2_D0024.tif" /></tables>
(2) Typed item search view Each Item type also has a search view. Similar to the root Item view, but this view also has access to the Item object through the "_Item" column. Each typed item search view is identified within the datastore using the name [schemaName]. [ItemTypeName]. For example, [AcmeCorp.Doc]. [OfficeDoc].
<tables num="25"><img file="JP4394643B2_D0025.tif" /></tables>
b) Item expansion All Item Extensions in the WinFS Store can also be accessed using the search view.
(1) Master extended search view Each instance of the datastore defines a special Extension view called the Master Extension View. This view provides summary information about each Extension in the datastore. The view has one column for each Extension property, which describes the Extension and multiple column types used to provide change tracking and synchronization information. The master extension view is identified in the datastore using the name "[System.Storage]. [Master! Extension]".
<tables num="26"><img file="JP4394643B2_D0026.tif" /></tables>
(2) Typed extended search view Each Extension type also has a search view. Similar to the master extension view, but this view also has access to the Item object via the _Extension column. Each typed extended search view is identified within the datastore using the name [schemaName]. [Extension! ExtensionTypeName]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt].
<tables num="27"><img file="JP4394643B2_D0027.tif" /></tables>
c) Nested elements All nested elements are stored within an Item, Extensions, or Relationships instance. Therefore, they can be accessed by querying the appropriate Item, Extension, or Relationship prosecution view.
d) Relationship As mentioned above, Relationships form the basic unit of linking between Items within the data store of the storage platform.
(1) Master relationship search view Each data store gives a Master Relationship View. This view shows information about all related instances in the datastore. Master relationship views are identified within the datastore using the name "[System.Storage]. [Master! Relationship]".
<tables num="28"><img file="JP4394643B2_D0028.tif" /></tables>
(2) Relationship instance search view Each declared Relationship also 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 is identified within the datastore using the name [schemaName]. [Relationship! RelationshipName]. For example, [AcmeCorp.Doc]. [Relationship! Document Author].
<tables num="29"><img file="JP4394643B2_D0029.tif" /></tables>
9. Update All views in the storage platform's datastore 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 a datastore that consumes an "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. The common operations are as follows. 1.Item operation: a.CreateItem (creates a new item in the context of an embedded or retained relationship) b. UpdateItem 2. Relationship operation: a.CreateRelationship b. Update Relationship c.DeleteRelationship 3. Extension operation: a.CreateExtension b. Update Extension c.DeleteExtension
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 within the data store.
a) Change tracking Each search view provided by the data store contains columns used to provide change tracking information, which are common among all Item, Extension, and Relationship views. The Storage Platform's Schema Views are explicitly defined by the Schema Designer and do not automatically provide change tracking information-such information is indirectly provided through the search view in which the view itself is built. ..
For each element in the data store, change tracking information is available in two locations-the "master" element view and the "typed" element view. For example, change tracking information for the AcmeCorp.Document.Document Item type is available from the master item view "[System.Storage]. [Master! Item]" and the typed item search view [AcmeCorp.Document]. [Document].
(1) Track changes in the "master" search view The change tracking information in the master search view is information about the creation and update version of the element, information about the sync partner who created the element, information about the sync partner who last updated the element, and the version number from each partner about creation and update. Is shown. Partners in a synchronous relationship (described later) are identified by the partner key. A single UDT object named _ChangeTrackingInfo of type [System.Storage.Store] .ChangeTrackingInfo stores this information. This type is defined in the System.Storage schema. _ChangeTrackingInfo is available for all global search debuts for Items, Extensions, and Relationships. The type definition of ChangeTrackingInfo is as follows.
<tables num="30"><img file="JP4394643B2_D0030.tif" /></tables>
These properties include the following information:
<tables num="31"><img file="JP4394643B2_D0031.tif" /></tables>
(2) Track changes in "typed" search view In addition to providing the same information as the global search view, each typed search view provides additional information that records the synchronization state of each element in the synchronization topology.
<tables num="32"><img file="JP4394643B2_D0032.tif" /></tables>
b) Tombstone The datastore provides tombstone information for Items, Extensions, and Relationships. 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 their corresponding objects, but relational tombstone views have access to relational objects (relationship objects are null for tombstone state relationships). ..
(1) Item Tombstone Item Tombstones are retrieved from the system via the view [System.Storage]. [Tombstone! Item].
<tables num="33"><img file="JP4394643B2_D0033.tif" /></tables>
(2) Extended tombstone Extended tombstones are retrieved from the system using the view [System.Storage]. [Tombstone! Extension]. The extended change tracking information is similar to the information given for an Item, including the addition of the ExtensionId property.
<tables num="34"><img file="JP4394643B2_D0034.tif" /></tables>
(3) Relationship tombstone Relationships Tombstones are retrieved from the system via the view [System.Storage]. [Tombstone! Relationship]. The relevant tombstone information is similar to the information given about Extensions. However, additional information is given on the target ItemRef of the relationship instance. In addition, related objects are also selected.
<tables num="35"><img file="JP4394643B2_D0035.tif" /></tables>
(4) Tombstone cleanup To prevent the endless proliferation of tombstone information, the data store provides a tombstone cleanup task. This task determines when the tombstone information can be destroyed. This task calculates the limits for local created / updated versions and then truncates the tombstone information by destroying all older tombstone versions.
11. Helper API and functions Base mapping also includes a number of helper functions. These functions are provided to assist in common operations on the data model. a) Function [System.Storage] .GetItem Returns the Item object given the ItemId. // // Item GetItem (ItemId ItemId) b) Function [System.Storage] .GetExtension // Returns the extension object given the ItemId and ExtensionId. // // Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId) c) Function [System.Storage] .GetRelationship // Returns the relationship object given the ItemId and RelationshipId. // // Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)
12. Metadata There are two types of metadata represented by the store: instance metadata (such as Item type) and type metadata. a) Schema metadata Schema metadata is stored in the datastore as an instance of type Item from the Meta schema. b) Instance metadata Instance metadata is used by the application to query the type of the Item, thereby finding the extensions associated with the Item. Given an ItemId for an Item, the application queries the global item view, returns the type of the Item, and uses this value to query the Meta.Type view to declare the Item. Returns information about the type. For example:
<tables num="36"><img file="JP4394643B2_D0036.tif" /></tables>
E. Security This section describes the security model of the storage platform of the present invention according to one embodiment.
1. Overview According to an embodiment of the present invention, the accuracy with which a security policy of a storage platform is specified and enforced is at various levels of operation for an item in a given data store, and is a function of securing a part of the item separately from the whole. There is no. The security model specifies a collection of principals who can grant or deny someone access to perform those operations on an item through an access control list (ACL). Each ACL is an ordered collection of access control entries (ACEs).
Item security policies can be fully described by discretionary access control policies and system access control policies. Each of these is a set of ACLs. The first set (DACL) describes the discretionary access rights granted to various principals by the owner of the item, while the second set of ACLs is called a SACL (system access control list). Specifies how system audits are performed when objects are manipulated in several ways. In addition to these, each item in the data store is associated with a SID (Owner SID) that corresponds to the owner of the item.
The primary mechanism for organizing items within the storage platform's datastore is the containment hierarchy mechanism. Inclusion hierarchies are implemented using retention relationships between items. Due to the retention relationship between the two items A and B, represented as "A contains B", item A can affect the duration of item B. In general, an item in a data store cannot exist while there is a retention relationship from another item to that item. In addition to controlling the lifetime of an item, the retention relationship also provides the necessary mechanism to propagate the item's security policy.
The security policy specified for each item consists of two parts: the part explicitly specified for that item and the part inherited from the item's parent in the datastore. An explicitly defined security policy for an item consists of two parts: one that controls access to the item under consideration and one that affects the security policy inherited by all offspring in the containment hierarchy. The security policy inherited by offspring depends on the explicitly defined policy and the inherited policy.
Security policies are propagated through retention relationships and can be overridden at any item, so you need to specify how a valid security policy for an item is determined. In an embodiment of the invention, an item in the containment hierarchy of a data store inherits an ACL along all paths from the root of the store to that item.
Within the inherited ACL for a given path, the ordering of the various ACEs in the ACL determines the final security policy to be enforced. Use the following annotations to describe the ordering of the ACEs in the ACL. The ordering of ACEs in ACLs inherited by items is determined by two rules:
The first rule is to layer the ACEs inherited from the 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 distant container. Intuitively, this allows the administrator to override ACEs that are inherited from farther up in the containment hierarchy. This rule is as follows. For L of all inherited ACLs on item I About all items I1 and I2 For A1 and A2 of all ACEs in L I1 is the ancestor of I2, I2 is an ancestor of I3, A1 is an ACE inherited from I1 A2 is an ACE inherited from I2 If that holds, A2 precedes A1 in L
The second rule orders the ACEs that deny access to the item before the ACEs that allow access to the item. For L of all inherited ACLs on item I For all item I1 For A1 and A2 of all ACEs in L I1 is the ancestor of I2, A1 is ACCESS_DENIED_ACE inherited from I1 A2 is ACCESS_GRANTED_ACE inherited from I1 If that holds, 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 an item matches the ACL inherited by a file (item) in the existing Windows® security model with respect to the relative ordering of the ACEs contained therein.
However, the containment hierarchy within the datastore is a non-circular directed graph (DAG) because multiple retention relationships are allowed for the item. Under these conditions, there are multiple paths from the root of the containment hierarchy to the item. Items inherit ACLs along all paths, so each item is associated with a collection of ACLs rather than a single ACL. Note that this is different from the traditional file system model, where exactly one ACL is associated with one file or folder.
Contrary to the tree, if the inclusion hierarchy is a DAG, there are two aspects that need to be detailed. It is necessary to explain how to calculate a valid security policy for an item when inheriting multiple ACLs from a parent, and how to organize and represent it in managing the security model of the storage platform's datastore. Directly affect.
The following algorithm evaluates the access rights of a given principal to a given item. Throughout this specification, the ACLs associated with items are described using the following notations: Inherited_ACLs (ItemId)-A collection of ACLs inherited by an item whose item ID is an ItemId from a parent in the store. Explicit_ACL (ItemId)-An ACL that is explicitly defined for an item whose ID is ItemId.
<tables num="37"><img file="JP4394643B2_D0037.tif" /></tables>
The routine returns STATUS_SUCCESS if the desired access is not explicitly denied, and pGrantedAccess determines which of the rights the user desires was granted by the specified ACL. If the desired access is explicitly denied, the routine returns STATUS_ACCESS_DENIED.
<tables num="38"><img file="JP4394643B2_D0038.tif" /></tables>
The scope of a security policy defined on any item includes all offspring of the item in the containment hierarchy defined on the datastore. For all items for which an explicit policy is defined, we here define a policy that is inherited by virtually all offspring in the containment hierarchy. A valid ACL inherited by all offspring is obtained by taking each of the ACLs inherited by the item and prepending the inheritable ACE in the explicit ACL. This is called the set of inheritable ACLs associated with the item.
If there is no explicit security specification 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. Therefore, all items given an explicit security policy specification define an area of the item that is protected in exactly the same way, and valid ACLs for all items within that area are inheritable for that item. A set of ACLs. It fully defines the area in the case of an inclusion hierarchy, which is a tree. Given that each area is associated with a number, it would be sufficient to simply include the area to which the item belongs along with the item.
However, in the inclusion hierarchy, which is a DAG, the points of the inclusion hierarchy for which the effective security policy changes are 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 for which the administrator has explicitly specified an ACL. The second is an item with multiple parents, who have different security policies associated with them. These are typically items that are the confluence of specified security policies for a volume and indicate the start of a new security policy.
By this definition, all items in the data store fall into one of two categories, one that is the root of the security area protected in exactly the same way and one that is not. Items that do not define a security area belong to exactly one security area. Effective security for an item, as in the case of a tree, can be specified by specifying the area to which the item belongs along with the item. This provides a simple model for managing the security of a storage platform's datastore based on various exactly the same protected areas within the store.
2. Detailed description of the security model This section details how items can be secured by describing how the individual rights in the security descriptor and the ACLs they contain affect various operations.
a) Security descriptor structure Before discussing the details of the security model, it is helpful to explain the basics of security descriptors. Security descriptors contain security information associated with security-configurable objects. A security descriptor consists of a SECURITY_DESCRIPTOR structure and its associated security information. The security descriptor can include the following security information: 1. SID for the object owner and primary group. 2. A DACL that specifies permissions that are granted or denied to a particular user or group. 3. A SACL that specifies the type of access attempt that produces an audit record for the object. 4. A set of control bits that limits the meaning of a security descriptor or its individual members.
It is preferable that the application cannot directly manipulate the contents of the security descriptor. There is a function that sets and retrieves security information in the object's security descriptor. In addition, there is a function that creates and initializes a security descriptor for a new object.
Discretionary access control lists (DACLs) identify trustees who are allowed or denied access to security-configurable objects. 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 everyone full access. If the object's DACL does not have an ACE, the system rejects all attempts to access the object because the DACL does not grant access. The system in turn checks the ACEs until it finds one or more ACEs that grant all the requested permissions, or one of the requested permissions is denied.
System access control lists (SACLs) allow administrators to log attempts to access secure objects. 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 if the access attempt fails, succeeds, or both. SACLs can also raise an alarm when an unauthorized user attempts to gain access to an object.
All types of ACEs 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 the access rights controlled by the ACE. 3. A flag that indicates the type of ACE. 4. A set of bit flags that determine whether a child container or object can inherit the ACE from the primary object to which the ACL is attached.
The table below summarizes the three ACE types supported by all security-configurable objects.
<tables num="39"><img file="JP4394643B2_D0039.tif" /></tables>
(1) Access mask format All security-configurable objects set their access rights using the access mask format shown in Figure 26. In this format, the lower 16 bits are used for object-specific permissions and the next 7 bits are used for standard permissions, which applies to most types of objects, with the upper 4 bits being standard and object for each object type. Used to specify generic access rights that can be mapped to a unique set of rights. The ACCESS_SYSTEM_SECURITY bit corresponds to the right to access the object's SACL.
(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 permissions. For example, a file object maps the GENERIC_READ bit to READ_CONTROL and SYNCHRONIZE standard permissions, and to FILE_READ_DATA, FILE_READ_EA, and FILE_READ_ATTRIBUTES object-specific permissions. Other types of objects map the GENERIC_READ bit to the appropriate set of permissions for that type of object.
Generic permissions can be used to specify the type of access required when opening a handle on an object. This is usually simpler than specifying all the corresponding standards and specific rights. The table below summarizes the constants defined for generic access rights.
<tables num="40"><img file="JP4394643B2_D0040.tif" /></tables>
(3) Standard access right Each type of security-configurable object has a set of permissions that correspond 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 security-configurable objects. The table below summarizes the constants defined for standard access rights.
<tables num="41"><img file="JP4394643B2_D0041.tif" /></tables>
b) Item-specific rights In the access mask structure of Figure 26, item-specific rights are placed in the "Object Specific Rights" section (lower 16 bits). In the embodiment of the present invention, the storage platform exposes two sets of APIs for managing security-Win32 and the storage platform API-so that the file system object-specific rights are the motivation for designing the storage platform-specific rights. Must be considered in order to attach.
(1) Rights specific to file and directory objects Consider the table below.
<tables num="42"><img file="JP4394643B2_D0042.tif" /></tables>
With reference to the table above, 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. Is. The file system defines very precise rights that allow an application to control the behaviors on those objects. For example, these allow an application to distinguish between attributes (FILE_READ / WRITE_ATTRIBUTES), extended attributes, and the DATA stream associated with a file.
The goal of the security model of the storage platform of the present invention is to ensure that applications acting on datastore items (Contacts, Emails, etc.) generally do not need to distinguish between attributes, extended attributes, and data streams, for example. 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 to be compatible with Win32 applications. This mapping is described with each of the item rights specified below.
The following item rights are specified along with the associated authorized operations. Equivalent Win32 rights are also provided to support each of these item rights.
(2) WinFSItemRead This right allows read access to all elements of an item, including items that are linked to the item through an embedded relationship. It is also possible to enumerate the items linked to this item via a retention relationship (also known as directory listing). This includes the name of the item linked via 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 file rights specified above.
(3) WinFSItemReadAttributes This right allows read access to the basic attributes of an Item in the same way that the file system distinguishes between basic file attributes and data streams. These basic attributes are preferably attributes that are placed within 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, much like the file system distinguishes between basic file attributes and data streams. These basic attributes are preferably placed within the base item from which all items are derived. This right is mapped as follows: File: (FILE_WRITE_ATTRIBUTES) folder: (FILE_WRITE_ATTRIBUTES)
(5) WinFSItemWrite This right allows you to perform write access to all elements of an item, including items that are linked to the item through an embedded relationship. This right also allows you to add or remove embedded relationships to other items. This right is mapped as follows: File: (FILE_WRITE_DATA) folder: (FILE_ADD_FILE)
In a storage platform datastore, there is no difference between an item and a folder, and an item can also have a retention relationship with other items in the datastore. Therefore, if you have the FILE_ADD_SUBDIRECTORY (or FILE_APPEND_DATA) right, you can make an item a source of relationships with other items.
(6) WinFSItemAddLink This right allows you to add retention relationships to items in your store. The security model for multiple retention relationships changes the security on the item, and if those changes come from a higher point in the hierarchy, it can bypass WRITE_DAC, so to be able to create a relationship with it. Note that WRITE_DAC is required on the destination item. This right is mapped as follows: File: (FILE_APPEND_DATA) folder: (FILE_ADD_SUBDIRECTORY)
(7) WinFSItemDeleteLink This right allows the ability to delete a retention relationship for an item to be used even if the principal does not have 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 equivalent to this right, but the concept is that an item has a retention relationship with other items, so this right can be communicated to non-folders as well. .. folder: (FILE_DELETE_CHILD)
(8) Right to delete item The item is deleted when the last retention relationship with the item disappears. There is no explicit concept of deleting an item. Removes all retention relationships with items, but has a purge operation that is a high level feature and not a system primitive.
A path can be used to unlink a specified item by either (1) the parent item along the path grants write access to the target, or (2) the standard right of the item itself. When one of the two conditions for granting DELETE is met. The item disappears from the system when the last Relationship is deleted. You can unlink a specified item using the ItemID if the standard right of the item itself grants DELETE.
(9) Right to copy items Items can be copied from the source to the destination folder if the target is granted WinFSItemRead for the item and WinFSItemWrite for the destination folder.
(10) Right to move items Moving files within the file system only requires DELETE rights on the source file and FILE_ADD_FILE on the destination directory, as it retains ACLs on the destination. However, the flag can be specified with a MoveFileEx call (MOVEFILE_COPY_ALLOWED) that lets the application specify that the meaning of CopyFile is acceptable in the case of a cross-volume move. There are four possible choices about what happens to the security descriptor when you move. 1. Carry the entire ACL with the file-meaning the default intra-volume move. 2. Carry the entire ACL with the file and mark the ACL as protected. 3. Carry only explicit ACEs between destinations and re-inherit them on the destination. 4. Do not carry anything and re-inherit on the destination-meaning the default intervolume move-same as copying a file.
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 intervolume and the intravolume. If this flag is not specified, the second option will be executed unless the destination is further within the same area of security (ie, meaning the same inheritance). Moving at the storage platform level also implements a fourth option, requiring READ_DATA on the source, as with copying.
(11) Right to view security policy on item The security of an item can be displayed if the item grants the standard right READ_CONTROL.
(12) Right to change security policy on item The security of an item can be changed if the item grants the standard right WRITE_DAC to the target. However, this is closely related to how security changes are made in the hierarchy, as data stores provide implicit inheritance. If the root of the hierarchy grants WRITE_DAC, the rule is that the security policy changes across the hierarchy regardless of whether a particular item in the hierarchy (or DAG) grants WRITE_DAC.
(13) Right not to have a direct equivalent In embodiments of the invention, FILE_EXECUTE (directory FILE_TRAVERSE) has no direct equivalent within the storage platform. The model retains these for compatibility with Win32, but no access decisions are made to the item based on those rights. As with FILE_READ / WRITE_EA, datastore items do not have the concept of extended attributes, so there is no meaning for this bit. However, this bit is left for Win32 compatibility.
3. Implementation Every item that defines an area that is protected in exactly the same way has an entry associated with them in the security table. The security table is defined as follows.
<tables num="43"><img file="JP4394643B2_D0043.tif" /></tables>
The Item Identity entry is the item identification of the root of the security area 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. An Explicit Item ACL entry is an explicit ACL defined for the root of a security area 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. Path ACLs entries are a collection of ACLs inherited by an item, and Region ACLs entries are a collection of ACLs that are defined for exactly the same protected security areas associated with an item.
Use this table to calculate the effective security for items in a given store. To determine the security policy associated with an item, the security area associated with the item is obtained and the ACL associated with that area is retrieved.
The security policy associated with an item can be modified indirectly by adding an explicit ACL directly or by adding a retention relationship that will form a new area of security, thus ensuring the effective security of the item. The security table is kept up-to-date to ensure that the above algorithm to be determined is a valid algorithm.
The accompanying algorithms for maintaining various changes to the store and security tables are:
a) Create a new item in the container When a new item is created inside a container, it inherits all ACLs associated with the container. A newly created item has exactly one parent and therefore belongs to the same area as that parent. Therefore, there is no need to create a new entry in the security table.
b) Add an explicit ACL to the item When an ACL is added to an item, it defines a new security area for all offspring in the containment hierarchy that belong to the same security area as the given item itself. For all items that belong to another security area but are not descendants of a given item in the containment hierarchy, the security area does not change, but the valid ACLs associated with that area add new ACLs. Is changed to reflect.
The introduction of this new area of security can trigger further area definitions for all items that have multiple retention relationships with their ancestors that straddle the old and newly defined security areas. A new area of security needs to be defined for all such items, and the procedure is repeated.
Figures 27 (a), (b), and (c) show the new exactly the same protected security area that is cut out of 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, additional area 3 is created because the item has multiple retention relationships.
The following series of updates in the security table reflects the factorization of security areas that are protected in exactly the same way.
c) Add a retention relationship to the item When a retention relationship is added to an item, one of three possibilities arises. If the target of the retention relationship, that is, the item under consideration, is the root of the security area, the valid ACLs associated with that area will change and no further modifications to the security table will be required. If the security area of the source of the new retention relationship is the same as the security area of the item's existing parent, no changes are needed. However, if an item no longer has a parent belonging to a different security area, a new security area is formed and has the given item as the root of the security area. This change is propagated to all items in the containment hierarchy by modifying the security area 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 modified. After the change has been made, all items with multiple retention relationships must be examined to determine if further changes are needed. Further changes may be required if any of these items have parents in different areas of security.
d) Remove the retained Relationship from the item When a retention relationship is removed from an item, the security area can be shrunk along with its parent area, provided some conditions are met. To be more precise, this means that (1) deleting a retention relationship results in an item with one parent and no explicit ACL is specified for that item, (2) deleting a retention relationship causes all parents to do so. It can be executed under the condition that an item occurs within the same security area 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 should be applied to all items that correspond to the area where the security area is reduced.
e) Remove the explicit ACL from the item If an explicit ACL is removed from an item, it is possible to shrink the security area rooted at that item along with its parent area. More precisely, this can be done if removing an explicit ACL results in items whose parents in the containment hierarchy belong to the same security area. Under these circumstances, the security area can be marked to be the same as the parent, and the changes apply to all items that correspond to the area where the security area is reduced.
f) Modify the ACL associated with the item In this scenario, you don't need to make any new additions to the security table. The valid ACLs associated with that area are updated and new ACL changes are propagated to the affected security area.
F. Notification and change tracking According to another aspect of the invention, the storage platform includes a notification feature that allows an application to track data changes. This feature is primarily intended for applications that maintain a volatile state or execute business logic regarding data change events. The application registers notifications about items, item extensions, and item relationships. Notifications are sent asynchronously after the data changes have been committed. On the application side, notifications can be filtered by item, extension, and relational type as well as the type of operation.
In 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 a 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 an extended period of time. A single notification may reflect multiple updates.
1. Storage change event This section covers some use cases of the notification interface provided by the storage platform API 322.
a) Event Item, ItemExtensions, and ItemRelationships expose data change events used by the application to register data change notifications. The following code sample shows the definition of the ItemModified and ItemRemoved event handlers on the base Item class.
<tables num="44"><img file="JP4394643B2_D0044.tif" /></tables>
All notifications can carry enough data to retrieve the modified item from the data store. The following code sample shows how to register an event on an Item, ItemExtension, or ItemRelationship.
<tables num="45"><img file="JP4394643B2_D0045.tif" /></tables>
In an embodiment of the invention, the storage platform allows the application to modify or delete each item since it last delivered the notification, or if there was a new registration since it was last fetched 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 its respective FolderItemWatcher, FolderRelationshipWatcher, and FolderExtensionWatcher classes. To do.
When creating a watcher, an application can request notification of pre-existing items, that is, 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 supplies a "WatcherState" object. WatcherState can be serialized and saved on disk. You can then use the watcher state to recreate each watcher after a failure or when you reconnect after going offline. The newly recreated watcher will regenerate the non-receipt confirmation notice. The application indicates delivery of the notification by calling the "Exclude" method in each watcher state that supplies a reference to the notification.
The storage platform delivers a separate copy of the watcher state to its respective event handler. The watcher state received in a call after the same event handler assumes delivery of all notifications already received.
For example, the following code sample shows the definition of FolderItemWatcher.
<tables num="46"><img file="JP4394643B2_D0046.tif" /></tables>
The following code sample shows how to create a folder watcher object that monitors the contents of a folder. Watchers generate notifications, or events, when new music items are added, or existing music items are updated or deleted. The folder watcher monitors a specific folder or all folders in the folder hierarchy.
<tables num="47"><img file="JP4394643B2_D0047.tif" /></tables>
2. Change tracking and notification generation mechanism The storage platform has 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 avoid polling, the client can use the "wait for" feature of the database engine 314. Figure 13 illustrates the basic storage platform notification concept. If this waitfor query is executed synchronously, the calling thread will be blocked until a result is obtained, if it is executed asynchronously, the thread will not be blocked, and if the result is available, it will be in another thread. returned.
The combination of "wait for" and "select" is attractive for monitoring data changes that fall within a particular data range, as you can monitor changes by setting notification locks on each data range. This holds for many common storage platform scenarios. Changes to individual items can be efficiently monitored by setting notification locks in their respective data ranges. Changes to folders and folder trees can be monitored by setting notification locks in the path range. Changes to a type and its child types can be monitored by setting a notification lock on the type range.
In general, the processing of notifications involves three different phases: (1) data modification or equality detection, (2) subscription matching, and (3) notification delivery. With the exception of synchronous notification delivery, that is, notification delivery as part of a transaction that performs data changes, storage platforms can implement two forms of notification delivery: 1) Immediate event detection: Event detection and subscription matching are performed as part of the update transaction. Notifications are inserted into the table monitored by the subscriber. 2) Delayed event detection: Event detection and subscription matching is performed after the update transaction has been 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. This allows you to capture all events of interest, including events that indicate relative state changes.
Delayed event detection eliminates the need to add additional code to the update operation. Event detection is performed by the final subscriber. Delayed event detection, of course, batches event detection and event delivery and fits nicely into the query execution infrastructure of a database engine 314 (eg, SQL Server).
Delayed event detection relies on logs or traces left by the update operation. The storage platform maintains a set of logical timestamps with tombstones for deleted data items. When scanning the datastore for changes, the client supplies a set of time stamps that define low watermarks to detect changes and time stamps to prevent duplicate notifications. The application receives notification of all changes that have occurred since the time indicated by its low watermark.
Advanced applications with access to the core view can also optimize and reduce the number of SQL statements needed to monitor a potentially large collection of items by creating private parameter and duplicate filter tables. it can. Applications with special needs, such as those that need to support rich views, can use the available change tracking framework to monitor data changes and refresh their private snapshots.
Therefore, in one embodiment, the storage platform preferably implements a delayed event detection approach, as described in more detail below.
a) Change tracking All items, extensions, and item relationship definitions convey a unique identifier. Change tracking maintains a collection of logical timestamps that record the creation, update, and deletion times of all data items. Use tombstone entries 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 datastore. .. The following examples illustrate this mechanism.
<tables num="48"><img file="JP4394643B2_D0048.tif" /></tables>
All deleted items, item extensions, and relationships are recorded in the corresponding tombstone table. The template is shown below.
<tables num="49"><img file="JP4394643B2_D0049.tif" /></tables>
For efficiency reasons, the storage platform maintains a global set of tables of items, item extensions, relationships, and pathnames. These global look-up tables can be used by applications to efficiently monitor data ranges and retrieve assigned timestamps and type information.
b) Timestamp management The logical timestamp is "local" to the database, that is, the storage platform volume. The time stamp is a monotonically increasing 64-bit value. Preserving a single timestamp is often sufficient to detect if a data change has occurred since the last connection to the storage platform volume. However, in the most realistic scenarios, you need to keep some more timestamps to check for duplicates. The reason will be explained below.
A relational database table is a set of physical data structures, a logical abstraction built on top of B-Trees, heaps, and so on. Assigning a timestamp to a newly created or updated record is not an atomic action. Inserting the record into the underlying data structure can occur at different times, so to the application the records appear to come out of order.
Figure 14 shows that both transactions insert new records into the same B-Tree. Transaction T3 inserts records before transaction T2's insertion is scheduled, so an application scanning a B-Tree may see records inserted by transaction T3 before transactions inserted by T2. is there. Therefore, the reader can mistakenly assume that he has seen all the records created up to time "10". To solve this problem, the database engine 314 provides a function that commits all updates and returns up to the low watermark inserted in each 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 given by the database engine 314 allows applications to efficiently determine which items to ignore when scanning a database or data range for data changes. In general, ACID transactions are expected to last for a very short time, and low watermarks are expected to be very close to the most recently distributed timestamps. If there are long-running transactions, the application may have to keep individual time stamps in order to detect and discard duplicates.
c) Data change detection-event detection The application gets a low watermark when querying the datastore. The application then uses the watermark to scan the datastore for entries larger than the low watermark for which the create, update, or delete timestamp was returned. Figure 15 illustrates this process.
To prevent duplicate notifications, the application remembers 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. Before issuing the select statement, the application inserts all duplicate timestamps that have already been returned and removes those older than the last low watermark returned, as shown below.
<tables num="50"><img file="JP4394643B2_D0050.tif" /></tables>
G. Sync According to another aspect of the invention, the storage platform (i) allows multiple instances of a storage platform (each with its own datastore 302) to synchronize parts of its contents according to a set of flexible rules. (ii) To provide a synchronization service 330 with a third-party infrastructure that synchronizes the data store of the storage platform of the present invention with other data sources that implement a dedicated protocol.
Synchronization between storage platforms is performed within a group of participating replicas. For example, see Figure 3 with datastore 302 on storage platform 300 and other remote datastores 338 under the control of other instances of storage platform, probably running on different computer systems. It may be desirable to synchronize. The overall attribution of this group is not necessarily known to the given replica at a given time.
Different replicas can make changes independently (that is, at the same time). The process of synchronization is defined as making all replicas aware of changes made by other replicas. This synchronous processing function is essentially multi-master.
In the synchronization function of the present invention, the replica can be made as follows. · Determine which changes other replicas recognize. · Request information about changes that this replica does not recognize. · Communicate information about changes that other replicas do not recognize. · Determine when the two changes conflict with each other. · Apply changes locally. · Communicate conflicting resolutions to other replicas to ensure convergence. · Resolve race conditions based on the specified policy for conflicting resolutions.
1. Synchronous 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 having its own data store). The synchronization service runs at the schema level of the storage platform (rather than the underlying table in Database Engine 314). So, for example, "Scopes" are used to define synchronization as described below.
Synchronous processing services operate on the principle of "net change". Synchronous processing services do not record and send individual operations (such as by transactional duplication), but rather send the final results of those operations, thereby making 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's datastore in a single transaction, there is no guarantee that those changes will be applied as the smallest unit to all other replicas-one will appear without the other. There is. The exception to this principle is that if two changes are made to the same Item in the same transaction, those changes are sent and guaranteed to be applied as the smallest unit to other replicas. Therefore, Item is an integrity unit of the synchronization processing service.
a) Sync control application Any application can connect to a synchronization processing service and initiate a synchronization processing operation. Such an application provides all the parameters needed to perform 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 by SCA on one side. The SCA notifies the local synchronization processing service that it will synchronize with the remote partner. On the other side, the synchronization processing service is awakened by a message sent by the synchronization processing service from the calling machine. It responds based on the persistent configuration information (see mapping below) that is present on the destination machine. The synchronization 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 SCA.
Two steps must be taken to enable synchronization. First, the schema designer must annotate the storage platform schema with the appropriate sync meaning (specify Change Units as described below). Second, the synchronization process must be properly configured on all machines that have an instance of the storage platform 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 schema that is tracked individually by the storage platform. For all Change Units, the synchronization service can determine if it has changed or not since the last sync.
Specifying Change Units in the schema is used for multiple purposes. First, it determines how busy the synchronization processing service is on the line. When changes are made within the Change Unit, the synchronization service is unaware of which part of the Change Unit has changed, so the entire Change Unit is sent to other replicas. Second, it determines the accuracy of conflict detection. If two simultaneous changes (these terms are defined in detail in a later section) are made to the same change unit, the synchronization service issues a conflict notification, while the simultaneous changes are different change units. If added to, no conflict notification will be issued and changes will be merged automatically. Third, this has a strong impact on the amount of metadata held by the system. Much of the synchronization service metadata is retained for each Change Unit, so reducing the Change Units will increase the sync overhead.
To define Change Units, you need to find the right trade-offs. For that reason, the synchronization service allows the schema designer to get involved in the process.
In one embodiment, the synchronization processing service does not support Change Units larger than the element. However, the Schema Designer does support specifying change units that are 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:
<tables num="51"><img file="JP4394643B2_D0051.tif" /></tables>
c) Sync settings The group of storage platform partners who want to keep certain parts of their data in sync is called the sync community. If members of the community want to stay in sync, they don't necessarily represent the data in exactly the same way, which means that the sync partner can transform the data that is being synchronized.
In a peer-to-peer scenario, it is impractical for a peer to maintain transformation mappings for all of its partners. Instead, synchronization services take an approach that defines "community folders." A community folder is an abstraction that represents a virtual "shared folder" that all community members synchronize with.
This concept is best understood using an example. If Joe wants to synchronize the 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 Joes Documents folder and the local My Documents folder. From this point on, if Joe's computers are in sync with each other, they will be interacting with documents in Joes Documents instead of their local items. In this way, all Joe's computers understand each other without knowing who they are-that community folder becomes the common language of the sync community.
The configuration of a synchronization service consists of (1) defining the mapping between local and community folders, (2) what is synchronized (eg, who to synchronize, subsets to send, and receive). It consists of three steps: defining a sync profile to determine (kimono), and (3) defining a schedule for different sync profiles to be executed, or manually executing them.
(1) Community folder-mapping Community folder mappings are stored as XML configuration files on individual machines. 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 syntax rules for folders. / mappings / localFolder This element specifies the name of the local folder to which this mapping will be converted. The name follows the syntax rules for folders. The folder must already exist for the mapping to be valid. Items in this folder are considered synced 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 will be performed. In particular, this means that the IDs are not mapped. This configuration is primarily used when creating a Folder cache. / mappings / transformations / mapIDs This element requires that a newly generated local ID be assigned to all mapped items from the community folder, rather than reusing the community ID. Sync Runtime holds ID mapping that converts and reverses items. / 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 when requests for this mapping are processed. If it does not exist, the sender is assumed. / mappings / runAs / sender In the presence of this element, the sender of the message to this mapping must be spoofed and the request must be processed according to its credit certificate.
(2) Profile A Sync Profile is a set of parameters required to kick off synchronization. This is supplied by the SCA to the Sync Runtime to initiate the synchronization process. The synchronization profile for synchronizing the storage platforms includes the following information. · Used as a Local Folder, source and destination for changes. · Remote Folder name to synchronize-This Folder must be published from a remote partner using mappings as defined above. -Direction-The synchronization processing service supports send-only, receive-only, and send / receive 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 a remote partner-Represented as a storage platform query for community folders. · Transformations-Defines how to transform items in local format. · Local Security-Specifies whether changes retrieved from the remote endpoint apply 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 the conflict is rejected, logged, or automatically resolved-In the latter case, specify the conflict resolver to use and the configuration parameters for it.
The synchronization processing service provides a runtime CLR class that allows simple construction of synchronization profiles. Profiles can also be serialized to and from XML files for easy storage (often with a schedule). However, there is no standard location within the storage platform where all profiles are stored, and SCA is hopeless because it allows you to build profiles on the fly without making them persistent. Note that you don't need to have a local mapping to start the sync. All synchronization information can be specified in the profile. However, mapping is required to respond to remote-initiated synchronization requests.
(3) Schedule In one embodiment, the synchronous processing service does not provide its own scheduling infrastructure. Instead, rely on other components to perform this task-use the Windows Scheduler that comes with the Microsoft Windows® operating system. The synchronization processing service acts as an SCA and includes a command line utility that triggers synchronization based on the synchronization profile stored in the XML file. This utility makes it very easy to configure the Windows Scheduler to perform synchronous processing on a schedule or in response to events such as users logging on or off.
d) Conflict Handling Conflict avoidance processing in the synchronous processing service is (1) Conflict detection performed when a change is applied-this step determines whether the change can be safely applied, (2) Automatic conflict resolution and logging-In this step ( Conflicts are executed immediately after they are detected), the automatic conflict resolver is queried to see if the conflicts can be resolved, and optionally the conflicts can be logged, and (3) Conflict checking and resolution-this step is It runs if any conflicts are logged and runs outside the context of the sync session, but at this time the logged conflicts can be resolved and removed from the log- It can be divided into three stages.
(1) Conflict detection In an embodiment of the invention, the synchronous processing service detects two types of conflicts, knowledge-based and constraint-based.
(a) Knowledge base conflict Knowledge base contention occurs when two replicas make independent changes to the same Change Unit. The two changes are called independently if they are made unaware of each other's changes-that is, the first version is not subject to knowledge about the second version, and vice versa. I can say. The synchronization service will automatically detect all such conflicts based on the knowledge of the replica, as described above.
It can be useful to think of conflicts as a turning point in the version history of change units. If there is no conflict during the life of the change unit, its version history is a simple chain-each change occurs after the previous change. In the case of knowledge base contention, the two changes occur in parallel, so the chain is split into a version tree.
(b) Constraint-based contention 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 can occur.
Constraint-based contention involves two independent changes (just like knowledge-based contention), but does not affect the same change unit. Rather, it affects different change units, but there are constraints between them.
The synchronization 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 synchronization services provide a generic mechanism for doing so. Absent.
(2) Conflict Processing When a conflict is detected, the synchronization service will either (1) reject the change and send it back to the sender, (2) log the conflict in the conflict log, or (3) automatically resolve the conflict. You can perform one of three actions (selected by the synchronization initiator in the synchronization profile).
If the change is rejected, the synchronization 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) that do not allow conflict logging. Instead, such replicas force other replicas to handle conflicts by rejecting them.
The synchronization initiator configures conflict resolution in the synchronization profile. The synchronization service supports a combination of multiple conflicting resolvers in a single profile as follows: First, it specifies a list of conflicting resolvers that will be tried one after another until one of them succeeds, and secondly. Associate the conflict resolver with the type of conflict, for example, direct the knowledge base conflict between updates to one resolver and all other conflicts to the log.
(a) Automatic conflict resolution The synchronization processing service has a number of default conflict resolvers. This list includes: · Local-wins: Discard any changes received if there is a conflict with locally stored data. · Remote-wins: Discard local data if there is a conflict with the received changes. · Last-writer-wins: Choose either local-wins or remote-wins according to the change unit based on the change timestamp (note that synchronization services are generally clock value independent. This conflict. The resolver is the only exception to that rule). Deterministic: Choosing a winner in a way that is guaranteed to be the same on all replicas, but not in any other way-in one embodiment of a synchronization service, a partner to implement this feature. Use lexicographic comparison of IDs.
In addition, ISVs can implement and install their own competing resolvers. Custom conflict resolvers can accept configuration parameters, which 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 conflict changes). The synchronization processing service then appropriately adjusts the remote knowledge to include what the conflicting handler has considered, and then applies those operations.
Other conflicts may be detected while applying the resolution. In such cases, the new conflict must be resolved before the original processing resumes.
If you think of a conflict as a branch in the item's version history, conflict resolution can be thought of as a join-combining two branches to form a point. Therefore, conflict resolution turns the version history into a DAG.
(b) Conflict Logging A very specific competing resolver is the Conflict Logger. The synchronization service logs the conflict as an Item of type ConflictRecord. These records are rerelated to the conflicting item (unless the item itself has been deleted). Each conflict record is of 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. Including knowledge. Logged conflicts can be used for inspection and resolution, as described below.
(c) Conflict inspection and resolution The synchronization processing service has an API for examining the conflict log on the application side and proposing the resolution of the conflict in it. This API allows an application to enumerate all conflicts, or conflicts related to a given Item. This also allows such applications to (1) remote wins-accept the logged changes and overwrite the conflicting local changes in order to resolve the logged conflicts (1) remote wins. 2) local wins-ignore conflicting parts of logged changes, and (3) suggest new change-one of three ways if the application optionally suggests a merge to resolve the conflict. Can be used. After the application resolves the conflict, the synchronization service removes them from the log.
(d) Replica convergence and conflict resolution propagation In complex synchronization scenarios, the same conflict may be detected in multiple replicas. When such a situation occurs, the following events occur. Either (1) the conflict can be resolved on 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 the conflict checking API).
The synchronization processing service forwards the conflict resolution to another replica so that it always converges. When a conflict-resolving change arrives at the replica, the synchronization service automatically finds conflict records in the logs that are resolved by this update and deletes them. In this sense, conflict resolution on one replica is binding on all other replicas.
If different winners are selected by different replicas for the same conflict, the synchronization service applies the principle of binding conflict resolutions, picking one of the two resolutions and automatically winning the other. Winners are chosen in a deterministic way that guarantees the same results at all times (in one embodiment, replica ID lexicographic comparison is used).
If different replicas propose different "new changes" for the same conflict, the synchronization service treats this new conflict as a special conflict and uses the Conflict Logger to prevent it from being propagated to other replicas. .. Such situations generally occur in manual conflict resolution.
2. Synchronous processing of non-storage platform datastore According to another aspect of the storage platform of the present invention, the storage platform comprises an architecture for ISVs to implement Sync Adapters that synchronize the storage platform with traditional systems such as Microsoft Exchange, AD, Hotmail. Sync Adapters utilize many Sync Services provided by synchronization processing services, as described below.
Despite its name, Sync Adapters do not need to be implemented as plugins on any storage platform architecture. If you want, the "sync adapter" can simply be an application that utilizes the synchronous processing service runtime interface to get services such as change enumeration and applications.
To make it easier to configure and perform synchronization with a given backend, the Sync Adapter author will perform a standard Sync process given the synchronization profile as described above. You are encouraged to expose the Adapter interface. This profile conveys configuration information to the adapter, which passes some of it to the Sync Runtime, which controls the runtime services (eg, the folder that synchronizes).
a) Synchronous processing service The synchronization processing service provides a large number of synchronization processing services to the adapter creator. For the rest of this section, it is convenient to refer to the machine on which the storage platform is performing the synchronization process as the "client" and the non-storage platform backend to which the adapter communicates as the "server".
(1) Change Enumeration With Change Enumeration, based on the change tracking data held by the synchronization service, the synchronization adapter can easily enumerate the changes that have occurred since the last attempt to synchronize with this partner to the datastore Folder. can do.
The changes are listed based on the concept of "anchors" -hidden structures that represent information about the last synchronization. Anchors take the form of storage platform knowledge, as explained in the previous section. Synchronization 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. Adapters often find it easy to store this information on the client-backends often cannot easily store this information. On the other hand, if multiple clients synchronize with the same backend, storing this information on the client is inefficient and sometimes incorrect-one client has already pushed the other client to the server. I don't notice the changes that are up. If you want to use a server stored anchor on the adapter side, the adapter must send it back to the storage platform when enumerating changes.
In order for the storage platform to hold the anchor (either local storage or remote storage), the storage platform needs to be aware of the changes that have been successfully applied on the server side. Only these changes and these changes can be included in the anchor. When enumerating changes, Sync Adapters use the Acknowledgement interface to report successfully applied changes. At the end of the sync, adapters that use the supply anchor must load the new anchor (which incorporates all successfully applied changes) and send it to the backend.
Adapters often need to store adapter-specific data along with items to insert into the storage platform's datastore. Common examples of such data are remote IDs and remote versions (timestamps). The synchronization processing service has a mechanism for storing this data, and Change Enumeration has a mechanism for receiving this additional data along with the returned changes. This eliminates the need for the adapter to query the database again in most cases.
(2) Change Application The Change Application allows Sync Adapters to apply changes received from the backend to the local storage platform. The adapter is expected to translate the changes into the storage platform schema.
The main function of applying changes is to detect conflicts automatically. As in the case of storage platform-to-storage platform synchronization, contention is defined as two overlapping changes being made without knowledge of each other. The adapter must specify an anchor as to which conflict detection is performed when using the Change Application. The Change Application issues a conflict notification when it detects overlapping local changes that are not covered by the adapter's knowledge. 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 accompanied by applicable changes by the adapter and can also be stored by the concurrency service. The data could be returned at the next change enumeration.
(3) Conflict Resolution The Conflict Resolution mechanism described above (logging and automatic resolution options) is also available for synchronization adapters. The synchronization 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). You can also log conflicts. The adapter may detect conflicts when trying to apply local changes to the backend. In such cases, the adapter can still pass the conflict to the Sync Runtime and resolve it according to policy. In addition, the synchronous processing adapter can request that conflicts detected by the concurrency service be sent back for processing. This is useful if the backend can store or resolve conflicts.
b) Adapter mounting 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 the adapter to perform the synchronization process according to the given synchronization profile, cancels the synchronization process in progress, and reports the synchronization in progress (completed). Rate) can be received.
3. Security Synchronous processing services try to introduce as little as possible into the security model implemented by the storage platform. Instead of defining new rights for synchronization, existing rights are used. Especially, Anyone who can load an Item in the data store can list the 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 an Item in a data store can associate synchronous metadata with that item.
Synchronous processing services do not retain secure copyright information. If user U makes a change on replica A and transfers it to replica B, the fact that the change was originally made on A (or by U) is lost. If B forwards this change to Replica C, it will be done under B's privileges instead of A's. This imposes the limitation 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 the Sync Controlling Application. The synchronization service impersonates the SCA's identity and performs all operations (both local and remote) under that identity. For illustration purposes, User U observes that the Local Sync Processing Service cannot force changes from the remote storage platform for items for which User U does not have read access.
4. Ease of management Monitoring a distributed community of replicas is a complex issue. Synchronous processing services can use a "sweep" algorithm to collect and distribute information about the status of replicas. The properties of the sweep algorithm ensure that information about all configured replicas is finally retrieved and that failed (non-responsive) replicas are detected.
This community-wide monitoring information is available on all replicas. You can run the monitoring tool on any replica of your choice and examine this monitoring information to make administrative decisions. Configuration changes must be made directly on the affected replica.
H. Traditional file system interoperability As mentioned above, the storage platform of the present invention is intended to be embodied as an integral part of the hardware / software interface system of a computer system, at least in some embodiments. For example, the storage platform of the present invention can 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 therefore the storage platform's Item-based data model replaces the traditional file system of such operating systems. For example, Microsoft As embodied in the Windows® family of operating systems, storage platforms can also replace the NTFS file system implemented in that operating system. For now, application programs access NTFS file system services through the Win32 API exposed by the Windows® family of operating systems.
However, with the understanding that to completely replace the NTFS file system with the storage platform of the present invention, it is necessary to recode existing Win32-based application programs, and such recoding is not desirable. It would be beneficial to achieve some interoperability with existing file systems such as NTFS on the storage platform of the present invention. Therefore, in one embodiment of the invention, in a storage platform, an application program that relies on the Win32 programming model can access the contents of both the storage platform's data store and the traditional NTFS file system. To this end, storage platforms use naming conventions that are a superordinate set of Win32 naming conventions that enhance easy interoperability. In addition, the storage platform supports access to files and directories stored within the storage platform volume through the Win32 API.
1. Model for interoperability According to this aspect of the invention, in the exemplary embodiments described above, the storage platform implements one namespace in which non-file items and file items can be organized. Using this model offers the following advantages: 1. Folders in the data store can contain both file and non-file items, which can present a single namespace for files and schematized data. It also provides a uniform security, sharing, and management model for all user data. 2. Both files and non-file items are accessible using the Storage Platform API, and this approach does not apply any special rules to files, presenting a cleaner programming model that involves application developers. .. 3. All namespace operations go through the storage platform and are therefore treated synchronously. Deep property It is important to note that while promotion) (pushed out of file content) still occurs asynchronously, synchronous operations provide a fairly predictable environment for users and applications.
As a result of this model, in embodiments of the present invention, it is not possible to provide a search function for data sources that are not migrated within the data store of the storage platform. This includes files on removable media, remote servers, and local disks. A synchronization adapter is provided that reveals proxy items (shortcuts + upgraded 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 achieved over the namespace and programming model between files and non-file content allows applications to migrate content from the file system to more structured items within the storage platform's datastore over time. You get a better path than you do. By implementing the native file item type in the data store of the storage platform, application programs 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 with respect to Storage Platform Items rather than files.
2. Data store function To achieve the desired level of interoperability, one embodiment implements the following datastore capabilities of the storage platform:
a) Not a volume Storage platform datastores are not exposed as separate file system volumes. The storage platform uses FILESTREAM, which is hosted directly on NTFS. As a result, there is no change in the on-disk format, which eliminates the need to expose the storage platform as a new file system at the volume level.
Instead, the datastore (namespace) is built for the NTFS volume. The database and FILESTREAM that supplement this part of the namespace are located on the NTFS volume to which the storage platform datastore is associated. A data store corresponding to the system volume is also prepared.
b) Store structure The structure of the store is best understood by looking at the examples. For example, consider a directory tree on a system volume for a machine named HomeMachine, as illustrated in Figure 16. With the file system interoperability feature of the present invention, there is a storage platform datastore corresponding to the c: \ drive, for example called "WinFSOnC", which is exposed to the Win32 API via a UNC share. This will allow access to the associated datastore via the UNC name \\ HomeMachine \ WinFSOnC.
In this embodiment, files and / or folders need to be explicitly migrated from NTFS to the storage platform. Therefore, if the user wants to move the My Documents folder into the storage platform's datastore to take advantage of all the additional search / classification features provided by the storage platform, the hierarchy is as shown in Figure 17. Will look like. It is important to note that these folders are actually moved in this example. Another thing to note is that the namespace has been moved into the storage platform, the actual stream has been renamed to FILESTREAM, and the appropriate pointers have been tied within the storage platform.
c) Not all files are migrated Files that correspond to user data or require the search and classification capabilities of the storage platform are candidates for migration to the storage platform's data store. To limit compatibility issues between application programs and storage platforms, the collection of files migrated to the storage platform of the present invention is Documents and in the context of the Microsft Windows® operating system. Preferably limited to files in the My Documents folder in the Settings directory, Internet Explorer (IE) Favorites, IE History, and Desktop.ini files. It is preferable that migrating Windows® system files is not allowed.
d) Accessing storage platform files in the NTFS namespace In the embodiments described herein, it is desirable that files migrated to the storage platform not be accessed through the NTFS namespace, even if the solid file stream is stored in NTFS. This avoids the complex locking and security issues that arise from multifaceted implementations.
e) Expected namespace / drive character Access to files and folders within the storage platform is done via a UNC name in the form \\ <machine name> \ <WinfsShareName>. For classes of applications that require a drive character for their operation, the drive character can be mapped to this UNC name.
I. Storage Platform API As mentioned above, the storage platform comprises APIs that can be used by the application program to access the features and capabilities of the storage platform described above and to access the items stored in the data store. This section describes an 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 an embodiment of the present invention. The Storage Platform API can use SQLCIient1900 to interact with local datastore 302 and SQLClient1900 to interact with remote datastores (eg, datastore 338). The local store 302 can also interact with the remote data store 338 using DQP (Distributed Query Processor) or through the storage platform synchronization service (Sync) described above. The storage platform API 322 also acts as a bridge API for datastore notifications, passing application subscriptions to the notification engine 332 and routing notifications to the application (eg, application 350a, 350b, or 350c), as described above. To do. In one embodiment, the storage platform API 322 also includes Microsoft. You can also define a restricted "provider" architecture to allow access to your data in Exchange and AD.
1. Overview The data access mechanism of this embodiment of the storage platform API of the present invention deals with four areas: query, navigation, action, and event.
Query In one embodiment, the storage platform's datastore is implemented on a relational database engine 314, so that the full expressiveness of the SQL language is inherent in the storage platform. Higher levels of query objects provide a simplified model for querying the store, but cannot encapsulate the full expressiveness of storage.
navigation The 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-like item. The Storage Platform API allows item-to-item navigation via filtering, relationships, folders, and more. This is a higher level of abstraction than basic SQL queries, while at the same time allowing rich filtering and navigation capabilities to 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. In addition, domain-specific actions such as SendMail and CheckFreeBusy are also available as methods. The API framework uses well-defined patterns that can be used by ISVs to add values by defining additional actions.
Event The data in the storage platform is dynamic. The API exposes rich eventing, subscription, and notification capabilities to developers to make their applications react when data in the store changes.
2. Naming and scope It is convenient to distinguish between namespaces and naming. The term namespace, in commonly used usage, refers to the set of all names available within a system. The system can be an XML Schema, a program, the Web, a collection of all ftp sites (and their contents), and so on. Naming is a process or algorithm used to assign a unique name to every entity of interest in a namespace. Therefore, naming is important because it is desirable to have a clear reference to a given unit in the namespace. Therefore, as used herein, the term "namespace" refers to a set of all names available on all instances of a storage platform in a universe. Items are named entities in the storage platform namespace. Use the UNC naming convention to ensure the uniqueness of item names. All items in the datastores of all storage platforms in the universe can be addressed by UNC name.
The highest organizational level in the storage platform namespace is one service, which is just an instance of the storage platform. The next level of organization is volume. Volumes are the largest autonomous container for items. Each storage platform instance contains one or more volumes. There are items in the volume. The item is a data atom within 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 splitting our data universe into multiple named groups. As mentioned above, this concept is modeled within the storage platform by the Folder concept. Folder is a special type of Item, and there are two types of Folder, Containment Folder and Virtual Folder.
Referring to FIG. 18, a Containment Folder is an item that contains retained Relationships with other Items and is an equivalent of the common concept of folders in the file system. Each Item is "contained" in at least one containing folder.
Virtual Folder is a more dynamic way of organizing a collection of Items, which is just a given name for a set of Items-this set is either explicitly enumerated or specified by a query. A Virtual Folder is itself an Item and can be thought of as representing (non-holding) Relationships with a set of Items.
Sometimes it is necessary to model a tighter concept than inclusion, for example, a Word document embedded in an email message is, in a sense, closer to the container than, for example, a file stored in a folder. Is bound to. This concept is represented by the concept of Embedded Item. Embedded Items have a special kind of relationship that references other Items, and the referenced Item can only be bound or manipulated in some other way within the context of the containing Item.
Finally, the storage platform implements the concept of categories as a way of classifying 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 with an Item / Element. This name can be used in the search. The storage platform's data model allows you to define a hierarchy of categories and therefore classify your data in a tree format.
The unambiguous names of items are triplets (<serviceName>, <volumeID>, <ItemID>). Some items (especially Folders and Virtual Folders) are a collection of other items. This provides an alternative way to identify the item (<serviceName>, <volumeID>, <itemPath>).
The storage platform name includes the concept of a service context, which is a name that maps to a pair (<volumeName>, <path>). It identifies an item or collection of items-for example, a folder, a virtual folder, and so on. By using the concept of service context, 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 within 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 survive within the specified path.
3. Storage platform API component FIG. 20 outlines the various components of the storage platform API according to this embodiment of the present invention. The Storage Platform API provides (1) data class 2002, which represents storage platform elements and item types, (2) manages object persistence and provides support class 2006, runtime framework 2004, and (3) storage platform schema. Consists of each component of Tool 2008 used to generate the CLR class from.
According to one aspect of the invention, at design time, the schema author submits the Schema Document 2010 of Domain Method 2012 and the code to a collection of Storage Platform API Design Time Tools 2008. These tools generate client-side data class 2002 and store schema 2014 and store the class definition 2016 corresponding to that schema. "Domain" refers to a particular schema, such as a domain method for a class in the Contacts schema. These data classes 2002 are used at runtime by application developers in response to the Storage Platform API runtime framework class 2006 to work with storage platform data.
An example is presented based on an exemplary Contacts schema for the purpose of exemplifying various aspects of the storage platform API of the present invention. Schematic representations of this exemplary schema are shown in Figures 21A and 21B.
4. Data class According to one aspect of the invention, each Item, Item Extension, and Element type in the storage platform datastore has a corresponding class in the storage platform API, along with their respective Relationships. 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 an object of the corresponding class in the storage platform API. Developers can query, create, modify, or delete those objects.
The storage platform contains an initial set of schemas. Each schema defines a set of Item and Element types, and a set of Relationships. The following is an embodiment of an algorithm that generates a data class from these schema entities. For each schema S For each Item I in S, a class named System.Storage.SI is generated. This class has the following members: An overloaded constructor that contains the constructor used to specify the initial folder and name of the new item. · Properties of each field in I. If the field is multi-valued, the property will be a collection of the corresponding Element types. · An overloaded static method that finds multiple items that match the filter (for example, a method named "FindAll"). An overloaded static method that finds a single item that matches the filter (for example, a method named "FindOne"). A static method that finds the item given the id (for example, a method named "FindByID"). A static method that finds a given item for an ItemContext (for example, a method named "FindByName"). A method that saves changes to an item (for example, a method named "Update"). · An overloaded static Create method that creates a new instance of the item. By using these methods, you can specify the initial folder of the item in various ways.
For each Element E in S, a class named System.Storage.SE is generated. This class has the following members: · Properties of each field in E. If the field is multi-valued, the property will be a collection of the corresponding Element types.
For each Element E in S, a class named System.Storage.S.ECollection is generated. This class follows general .NET Framework guidelines for strongly typed collection classes. 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 (for example, 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 (for example, a method named "FindOneTargetItem"). An overloaded method (for example, 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 (for example, a method named "FindAlIRelationshipsForTarget") 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 single object of nested element type that matches a filter whose collection implicitly contains items that appear in the source role (for example, a method named "FindOneRelationship"). An overloaded method that finds a single object of nested element type that matches a filter whose collection implicitly contains items that appear in the source role (for example, a method named "FindOneRelationshipForTarget").
A class named System.Storage.SR is generated for Relationship R in S. This class has one or two subclasses, depending on whether one or both relationship roles specify one endpoint field. The class is also generated in this way for each Item Extension created in this way.
The data class resides in the System.Storage. <SchemaName> namespace, where <schemaName> is the name of the corresponding schema, such as Contacts, Files, and so on. For example, all classes corresponding to the Contacts schema are in the System.Storage.Contacts namespace.
For example, referring to Figures 21A and 21B, we can see that the Contacts schema gives us the following classes contained in the System.Storage.Contact namespace: -Item: Item, Folder, WellKnownFolder, LocalMachineDataFolder, UserDataFolder, Principal, Service, GroupService, PersonService, PresenceService, ContactService, ADService, Person, User, Group, Organization, HouseHold Elements: NestedElementBase, NestedElement, IdentityKey, SecurityID, EAddress, ContactEAddress, TelephoneNumber, SMTPEAddress, InstantMessagingAddress, Template, Profile, FullName, FamilyEvent, BasicPresence, Windows® Presence, Relationship, TemplateRelationship, LocationRelationship, FamilyEventLocationRelationship, , GroupMemberShip, OrganizationLocationRelationship, HouseHoldMemberData, FamilyData, SpouseData, ChildData
Further, for example, a detailed structure of Person type as defined in the Contacts schema is shown in the following XML.
<tables num="52"><img file="JP4394643B2_D0052.tif" /></tables>
This type gives the following classes (only public members are shown):
<tables num="53"><img file="JP4394643B2_D0053.tif" /></tables>
<tables num="54"><img file="JP4394643B2_D0054.tif" /></tables>
In yet another example, a detailed structure of type TelephoneNumber, as defined in the Contacts schema, is shown in the XML below.
<tables num="55"><img file="JP4394643B2_D0055.tif" /></tables>
This type gives the following classes (only public members are shown):
<tables num="56"><img file="JP4394643B2_D0056.tif" /></tables>
The class hierarchy that results from a given schema directly reflects the type hierarchy within that schema. For example, consider the Item type defined in the Contacts schema (see Figures 21A and 21B). The corresponding class hierarchy in the storage platform API will be as follows.
<tables num="57"><img file="JP4394643B2_D0057.tif" /></tables>
Yet other schemas, that is, schemas that can represent all audio / video media in the system (ripped audio files, audio CDs, DVDs, home videos, etc.) allow users / applications to have different types of audio / video. Can store, organize, search, and manipulate media. This basic medium document schema is versatile enough to represent any medium, and extensions of this basic medium are designed to handle domain-specific properties separately for audio and video media. This schema, and many others, are supposed 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 objects that represent the data in the store. The application modifies the retrieved object or creates a new object and then propagates the changes into the store. This process is managed by the ItemContext object. The search is performed using the ItemSearcher object and the search results are accessible through the FindResult object.
a) Runtime framework class According to another aspect of the invention of the storage platform API, the runtime framework implements a number of classes that support the operation of data classes. These framework classes define a common set of behaviors for the data classes and, together with the data classes, implement the basic programming model of the storage platform API. Classes in the runtime framework belong to the System.Storage namespace. In this embodiment, the framework class includes ItemContext, ItemSearcher, and FindResult as the main classes. Other small classes, enum values, and delegates can also be provided.
(1) ItemContext The ItemContext object (i) represents a set of item domains that you want to search for in the application program, (ii) holds the state information of each object that represents the state of the data retrieved from the storage platform, and (iii) interacts with the storage platform. Manages a file system that is interoperable with the transaction and storage platforms used when doing so.
ItemContext provides the following services as an object persistence engine. 1. Deserialize the data read from the store into multiple objects. 2. Hold the object ID (if an item is given, it uses the same object to represent it no matter how many times it is included in the query results). 3. Track the object state.
ItemContext also runs a number of services that are specific to the storage platform. 1. Generate and perform the storage platform update gram operation required to persist the changes. 2. You can create connections to multiple datastores as needed to allow seamless navigation of reference relationships and modify and save objects retrieved from multiple domain searches. 3. File-backed items ensure that changes to the (s) objects that represent the item are updated properly when saved. 4. Manage the file system in which transactions take place when updating transactions that span multiple storage platform connections and the data and file stream properties contained within file-backed items. 5. Perform item creation, copy, move, and delete operations that take into account the meaning of storage platform relationships, file-backed items, and stream-typed properties.
Appendix A contains a 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 a core feature common to all of these: the target type and the concept of parameterized filters applied to that target type. Also, by using ItemSearcher, the searcher can be precompiled, that is, prepared as an optimization when the same search is executed with multiple types. Appendix B contains source code listings of the ItemSearcher class and multiple closely related classes, according to one embodiment.
(a) Target type The search target type is set when building the ItemSearcher. Target types are mapped to extents that can be queried by the datastore. In particular, this is a CLR type that maps to items, relationships, and item dilateds along with schematized views.
When retrieving a searcher using the ItemContext.GetSearcher method, the searcher's target type is specified as a parameter. When a static GetSearcher method is called for an item, relationship, or item extension (Person.GetSearcher), the target type is that item, relationship, or item extension.
The search expression given by ItemSearcher (eg, "search filter and through find" option or projection definition) is always related to its search target type. These expressions can specify properties of the target type, including properties of nested elements, as well as relationships and bindings to item extensions as described elsewhere.
Search target types are made available through read-only properties (eg ItemSearcher.Type property).
(b) Filter The ItemSearcher contains properties that specify the filters that define the filters used in the search (for example, the property named "Filters" as a collection of SearchExpression objects). All filters in this collection are combined using logic and operators when the search is performed. The filter can include parameter references. Parameter values are specified through the Parameters property.
(c) Search preparation In situations where the same search is performed repeatedly, in some cases with only parameter changes, precompiling, or preparing, the search can improve performance to some extent. This is done with a set of prepare methods on ItemSearcher (for example, a method that prepares a Find that returns one or more Items named "PrepareFind", and maybe a Find that returns a projection named "PrepareProject". Method to prepare). For example:
<tables num="58"><img file="JP4394643B2_D0058.tif" /></tables>
(d) Search options There are many options that can be applied to a simple search. These can be specified, for example, in the FindOptions object and passed to the Find method. For example:
<tables num="59"><img file="JP4394643B2_D0059.tif" /></tables>
Fortunately, sorting options can also be passed directly to the Find method.
<tables num="60"><img file="JP4394643B2_D0060.tif" /></tables>
The DelayLoad option determines whether the value of a large binary property is loaded when the search results are retrieved, or whether the load is delayed until referenced. The MaxResults option determines the maximum number of results returned. This is equivalent to specifying TOP in a SQL query. Most often used with sorting.
You can specify a set of SortOption objects (for example, 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. SortOption specifies a search expression that indicates the properties used for sorting. This expression specifies one of the following: 1. Search target type scalar property, 2. A scalar property within a nested element that can be reached from a search target type by traversing a single-valued property, or 3. The result of an aggregate function with valid arguments (for example, Max applied to multivalued properties or scalar properties within nested elements reachable from the search target type by traversing the relationship).
For example, assuming the search target type is System.Storage.Contact.Person 1. "Birthdate"-Enabled, birthdate is a Person type scalar property. 2. "PersonalNames.Surname"-Invalid, PersonalNames is a multi-valued property and no aggregate function is used. 3. "Count (Personal Names)"-Valid, count of Personal Names. 4. "Case (Contact.MemberOfHousehold) .Household.HouseholdEAddresses.StartDate"-Use relationship and multi-valued properties without invalid, 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, the "FindResult" object). Appendix C contains source code listings of the FindResult class and multiple 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 the IObjectReader (and IAsyncObjectReader) and using the enumerator pattern as defined by IEnumerable and IEnumerator. The enumerator pattern is standard in the CLR and supports language syntax like foreach in C #. For example:
<tables num="61"><img file="JP4394643B2_D0061.tif" /></tables>
Reader patterns are supported because this can increase the efficiency of processing results by eliminating data copies in some cases. For example:
<tables num="62"><img file="JP4394643B2_D0062.tif" /></tables>
In addition, the reader pattern supports asynchronous operations.
<tables num="63"><img file="JP4394643B2_D0063.tif" /></tables>
In this embodiment, FindResult must be closed when it is 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:
<tables num="64"><img file="JP4394643B2_D0064.tif" /></tables>
b) Running runtime framework Figure 22 illustrates a running runtime framework. The runtime framework works as follows. 1. Application 350a, 350b, or 350c binds to an item in the storage platform. 2. 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 get a collection of Items, and the returned collection is conceptually an object graph 2204 (depending on the relationship). 4. The application modifies, deletes, and inserts data. 5. The application calls the Update () method to save the changes.
c) Common programming pattern This section covers various examples of how to use the Storage Platform API framework class to manipulate items in a data store.
(1) Open and close the ItemContext object The application gets an ItemContext object to use to interact with the datastore, for example by calling static ItemContext.Open and providing one or more paths that identify the item domain associated with the ItemContext. .. Item domains scope searches performed using ItemContext so that only domain items and the items contained within them are searched. Examples are as follows.
Open ItemContext using DefaultStore storage platform share on local computer
<tables num="65"><img file="JP4394643B2_D0065.tif" /></tables> Open ItemContext using the given storage platform share
<tables num="66"><img file="JP4394643B2_D0066.tif" /></tables> Open ItemContext using items under Storage Platform Sharing
<tables num="67"><img file="JP4394643B2_D0067.tif" /></tables> Open ItemContext with multiple item domains
<tables num="68"><img file="JP4394643B2_D0068.tif" /></tables>
ItemContext must be closed when it is no longer needed. Explicitly close ItemContext
<tables num="69"><img file="JP4394643B2_D0069.tif" /></tables> Close using statement using ItemContext
<tables num="70"><img file="JP4394643B2_D0070.tif" /></tables>
(2) Object search According to another aspect of the invention, the storage platform API allows application programmers to form queries based on various properties of items in a data store without worrying about the details of the underlying database engine query language. It has a simplified query model that can be used for.
The application can use the ItemSearcher object returned by the ItemContext.GetSearcher method to perform a search between the specified domains when the ItemContext is opened. Use the FindResult object to access the search results. In the following examples, the following declaration is assumed.
<tables num="71"><img file="JP4394643B2_D0071.tif" /></tables>
The basic search pattern involves using the ItemSearcher object retrieved from the ItemContext by calling the GetSearcher method. Search for all items of a given type
<tables num="72"><img file="JP4394643B2_D0072.tif" /></tables> Search for items of a given type that meet the filter criteria
<tables num="73"><img file="JP4394643B2_D0073.tif" /></tables> Use parameters in filter strings
<tables num="74"><img file="JP4394643B2_D0074.tif" /></tables> Search for relationships that have a given type and satisfy the filter criteria
<tables num="75"><img file="JP4394643B2_D0075.tif" /></tables> Search for items that have a given type and have a relationship that meets the filter criteria
<tables num="76"><img file="JP4394643B2_D0076.tif" /></tables> Search for item extensions that have the given type and meet the filter criteria
<tables num="77"><img file="JP4394643B2_D0077.tif" /></tables> Search for items that have the given type and have an item extension that meets the filter criteria
<tables num="78"><img file="JP4394643B2_D0078.tif" /></tables>
(a) Search options When performing a search, you can specify various options, including sorting, lazy loading, and limiting the number of results. Sort search results
<tables num="79"><img file="JP4394643B2_D0079.tif" /></tables> Limit result count
<tables num="80"><img file="JP4394643B2_D0080.tif" /></tables>
(b) FindOne and FindOnly Sometimes it is useful to retrieve only the first result, especially when specifying sorting conditions. In addition, some searches are expected to return only one object, not any objects. Search for one object
<tables num="81"><img file="JP4394643B2_D0081.tif" /></tables> Find a single object that is expected to always exist
<tables num="82"><img file="JP4394643B2_D0082.tif" /></tables>
(c) Search for ItemContext shortcuts There are also many shortcut methods on the ItemContext that make performing a simple search as easy as possible. Search using the ItemContext.FindAll shortcut
<tables num="83"><img file="JP4394643B2_D0083.tif" /></tables> Search using the ItemContext.FindOne shortcut
<tables num="84"><img file="JP4394643B2_D0084.tif" /></tables>
(d) Search by ID or path In addition, items, relationships, and item extensions can be retrieved by giving their (s) ids. Items can also be retrieved by path. Get items, relationships, and item extensions given (s) ids
<tables num="85"><img file="JP4394643B2_D0085.tif" /></tables> Give a pass to get an item
<tables num="86"><img file="JP4394643B2_D0086.tif" /></tables>
(e) GetSearcher pattern There are many places in the Storage Platform API where it is desirable to have a helper method that performs a search 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 preconfigured to perform the given search. For example:
<tables num="87"><img file="JP4394643B2_D0087.tif" /></tables>You can add additional filters before performing the search.
<tables num="88"><img file="JP4394643B2_D0088.tif" /></tables>You can choose how you want the results.
<tables num="89"><img file="JP4394643B2_D0089.tif" /></tables>
(3) Store update The object can be retrieved by the search and then modified by the application as needed. You can also create new objects and associate them with existing ones. After making all the changes that make up the logical group, the application calls ItemContext.Update to make the changes to the store permanent. According to yet another aspect of the storage platform API of the present invention, this API collects changes made to items by an application program and then puts them into a database engine (or some kind of storage) in which the datastore is implemented. Organize to the correct update required by the engine). This allows application programmers to make changes to items in memory while leaving the complex parts of datastore updates to the API. Save changes to a single item
<tables num="90"><img file="JP4394643B2_D0090.tif" /></tables> Save changes to multiple items
<tables num="91"><img file="JP4394643B2_D0091.tif" /></tables> Create a new item
<tables num="92"><img file="JP4394643B2_D0092.tif" /></tables> Delete relationships (and target items if possible)
<tables num="93"><img file="JP4394643B2_D0093.tif" /></tables> Add item extensions
<tables num="94"><img file="JP4394643B2_D0094.tif" /></tables> Remove item extension
<tables num="95"><img file="JP4394643B2_D0095.tif" /></tables>
6. Security Refer to Section II.E (Security) above, in this embodiment of the Storage Platform API, there are methods available on the Item Context to retrieve and modify the security policy associated with the items in the store. There are five. 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 path that exists to the item and works independently of the retention relationship that targets this item. This allows the administrator to infer about item security if he wants to, regardless of the path that exists to the item.
Since GetPathSecurity and SetPathSecurity have a retention relationship from other folders, they have a mechanism to retrieve and modify the ACL existing on the item. This ACL consists of ACLs of various ancestors to the item along the path of consideration, along with an explicit ACL if provided for that path. The difference between this ACL and the previous ACL is that this ACL works as long as the explicit item ACL is independent of the retention relationship for the item but the corresponding retention relationship exists.
ACLs that can be set on items with SetItemSecurity and SetPathSecurity are constrained to inheritable, object-specific ACEs. These cannot contain ACEs marked as inheritance.
GetEffectiveItemSecurity retrieves not only various path-based ACLs, but also explicit ACLs on the item. This reflects the authorization policy that affects a given item.
7. Relationship support As mentioned above, the storage platform's data model defines "relationships" that relate items to each other. When the schema data class is generated, the following classes are generated for each relationship type. 1. A class that represents the relationship itself. This class is derived from the Relationship class and contains members that are specific to that relation type. 2. A strongly typed "virtual" collection class. This class is derived from the VirtualRelationshipCollection, which allows you to create and delete relationship instances.
This section describes relationship support within the Storage Platform API.
a) Basic relation type The storage platform API provides a number of types within the System.Storage namespace that form the basis of the relationship API. These are as follows. 1.Relationship-Basic type of all relationship classes 2.VirtualRelationshipCollection-Basic type of all relationship collections 3.ItemReference, ItemIdReference, ItemPathReference-Represents item reference types, and the relationships between those types are illustrated in Figure 11.
(1) Relationship class The following is the base class of the relation class. 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, and so on. 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 if the ItemContext already has a connection to the target item's domain (call TargetItemReference.IsDomainConnected). public bool IsTargetDomainConnected {get;} // The 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 the base class of item reference type. public abstract class ItemReference: NestedElement { // Create with default values. protected ItemReference (); // Returns the referenced item. public virtual Item GetItem (); // Determine if a connection to the domain of the referenced item has been established. public virtual bool IsDomainConnected (); }
The ItemReference object can identify an item that resides in a store that is different from the store in which the item reference itself is located. Each derived type specifies how to build and use a reference to the remote store. The GetItem and IsDomainConnected implementations in derived classes use ItemContext's multi-domain support to load items from the required domain and determine if a connection with the domain has already been established.
(3) ItemIdReference class Below is the ItemIdRefrence class-an Item reference that uses the item id to identify the target item. public class ItemIdReference: ItemReference { // Build a new ItemIdReference with default values. public ItemIdReference (); // Build a new ItemIdReference for the specified item. The domain associated with the Item is used as the locator. public ItemIdReference (Item item); // Build a new ItemIdReference with the NULL locator and the given target item id. public ItemIdReference (Itemld itemId); // Build a new ItemIdReference with the given locator and item id value. public ItemIdReference (string locator, ItemId itemId); // Target item id. public ItemId ItemId {get; set;} // A path that identifies the WinFS item that contains the target item in the domain. If NULL, the domain containing the item is unknown. public OptionalValue <string> Locator {get; set;} // Determine if a connection to the domain of the referenced item has been established. public override bool IsDomainConnected (); // Extract the referenced item. public override Item Getitem (); }
GetItem and IsDomainConnected use ItemContext's multi-domain support to load items from the required domain and determine if a connection with the domain has already been established. This feature has not yet been implemented.
(4) ItemPathReference class The ItemPathReference class is an item reference that uses a path to identify a target item. The code for this class is as follows: public class ItemPathReference: ItemReference { // Build item path references by default. public ItemPathReference (); // Build an item path reference with the given path, without a locator. public ItemPathReference (string path); // Build an item path reference with the given locator and path. public ItemPathReference (string locator, string path); // A path that identifies the WinFS item that contains the target item in the domain. public OptionalValue <string> Locator {get; set;} // The path of the target item for the item domain specified by the locator. public string Path {get; set;} // Determine if a connection to the domain of the referenced item has been established. public override bool IsDomainConnected (); // Extract the referenced item. public override Item GetItem (); }
GetItem and IsDomainConnected use ItemContext's 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 relationship id GUID. public class RelationshipId { // Generate a new relationship id GUID. public static RelationshipId NewRelationshipId (); // Initialize with the new relationship id GUID. public RelationshipId (); // Initialize with the specified GUID. public RelationshipId (Guid id); // Initialize with GUID string representation. public RelationshipId (string id); // Returns the string representation of the relation id GUID. public override string ToString (); // Convert the System.Guid instance to a RelationshipId instance. public static implicit operator RelationshipId (Guid guid); // Convert the RelationshipId instance to a System.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 relation id is nullable, then OptionalValue <RelationshipId> must be used. Empty values as given by System.Guid.Empty are not exposed. RelationshipId cannot be constructed with an empty value. If you create a RelationshipId using the default constructor, a new GUID is created.
(6) VirtualRelationshipCollection class The VirtualRelationshipCollection class implements a collection of related objects that contains objects from the datastore, plus new objects added to the collection, but not deleted objects from the store. Objects of the specified relation type with the given source item id are included in the collection.
This is the base class of the relation collection class generated for each relation type. The class can be used as a property type in a source item type to access a given item relationship and make it easier to manipulate.
To enumerate the contents of the VirtualRelationshipCollection, you need to load a potentially large number of relationship objects from the store. Your application should use the Count property to determine how many relationships can be loaded before enumerating the contents of the collection. Adding objects to and removing objects from the collection does not require the relationship to be loaded from the store.
For efficiency, it is preferable for the application to search for relationships that meet certain criteria instead of using the VirtualRelationshipCollection object to enumerate all the item relationships. Adding a relationship object to the collection creates the relationship in the store that is represented when ItemContext.Update is called. Removing a relationship object from the collection removes the relationship represented in the store when ItemContext.Update is called. The virtual collection contains the correct set of objects regardless of whether the relationship objects are added / removed through the Item.Relationships collection or other relationship collections on that item.
The following code defines the VirtualRelationshipCollection class. public abstract class VirtualRelationshipCollection: ICollection { // The collection contains the specified type relationships 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 those with the state Inserted as well as those with the state Deleted. public IEnumerator GetEnumerator (); // Returns a count of the number of related objects that the enumerator will return. 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 changed to Retrieved or Modified as appropriate. The source item id for this relationship must be the same as the source item id given when the collection was built. 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 object's state is Added, this is set to Constructed. If the object's state is Retrieved or Modified, this is set to Removed. The source item id for this relationship must be the same as the source item id given when the collection was built. protected void Remove (Relationship relationship); // Objects deleted from the collection. public ICollection RemovedRelationships {get;} // Objects added to the collection. public ICollection AddedRelationships {get;} // Object retrieved from the store. This collection is empty until the 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 relation type When generating a storage platform schema class, one class is generated for each relationship declaration. In addition to the classes that represent the relationships themselves, a relationship collection class is also generated for each relationship. These classes are used as property types within the source or target item class of the relationship.
This section describes the classes that are generated using a number of "prototype" classes. That is, the class that is generated when the 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 their relationships and should not be interpreted literally.
(1) Generated relation type This section describes the classes generated for each relation type. For example:
<tables num="96"><img file="JP4394643B2_D0096.tif" /></tables>
Given this relationship definition, the RelationshipPrototype and RelationshipPrototypeCollection classes are generated. The RelationshipPrototype class represents the relationship itself. The RelationshipPrototypeCollection class allows you to access a RelationshipPrototype instance with the item specified as the source endpoint.
(2) RelationshipPrototype class This is a prototype relationship class for a holding relationship named "HoldingRelationshipPrototype", the source end point has the name "Head", specifies the "Foo" item type, the target end point has the name "Tail", and " Bar "Specify the item type. It is defined as follows.
<tables num="97"><img file="JP4394643B2_D0097.tif" /></tables> (3) RelationshipPrototypeCollection class This is a prototype class generated by the RelationshipPrototype class that holds a collection of RelationshipPrototype related instances owned by the specified item. It is defined as follows.
<tables num="98"><img file="JP4394643B2_D0098.tif" /></tables>
c) Relationship support within the Item class The Item class contains the 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 relational context property of the Item class.
<tables num="99"><img file="JP4394643B2_D0099.tif" /></tables>
(2) RelationshipCollection class This class allows you to access the relationship instance where the given item is the source of the relationship. It is defined as follows.
<tables num="100"><img file="JP4394643B2_D0100.tif" /></tables>
d) Relationship support in search expressions In the search expression, it is possible to specify the traverse of the bond between the relationship and the associated item.
(1) Traverse from item to relationship If the current context of the search expression is a collection of items, the join between the item from which the item is the source and the relationship instance can be performed using the Item.Relationships property. Joins to specific type relationships can be specified using the search expression Cast operator.
Strongly typed relationship collections (eg Folder.MemberRelationships) can also be used in search expressions. Type conversion to relational types is done implicitly.
After a set of relationships has been established, the properties of that relationship can be used in a predicate or as a target for projection. When used to specify a projection target, a set of relationships is returned. For example, the following statement finds all the people involved in an organization whose StartDate property of the relationship had a value greater than or equal to "1/1/2000".
<tables num="101"><img file="JP4394643B2_D0101.tif" /></tables>
If the Person type had a property EmployerContext of type EmployeeSideEmployerEmployeeRelationships (as generated for EmployeeEmployer relations), this could be written as:
<tables num="102"><img file="JP4394643B2_D0102.tif" /></tables>
(2) Traverse from relationship to item If the current context of the search expression is a set of relationships, the connection from the relationship to any end point of the relationship can be traversed by specifying the name of the end point. After a set of related items has been established, the properties of those items can be used in predicates or as targets for projection. 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) whose last name is "Smith".
<tables num="103"><img file="JP4394643B2_D0103.tif" /></tables>
You can use the search expression Cast operator to filter the type of the endpoint item. For example, to find all MemberOfFolder related instances whose members are Person items with the surname "Smith":
<tables num="104"><img file="JP4394643B2_D0104.tif" /></tables>
(3) Combination of related traverses You can get as many complex traverses as you like by combining the two patterns before traversing from item to relationship and from relationship to item. For example, to find all organizations that include employees whose surname is "Smith":
<tables num="105"><img file="JP4394643B2_D0105.tif" /></tables>
The following example finds all Person items that represent members of a household residing in the "New York" area (TODO: this is no longer supported ... alternative).
<tables num="106"><img file="JP4394643B2_D0106.tif" /></tables>
e) Example of using relationship support The following is an example of using relationship support within the Storage Platform API to manipulate relationships. In the following examples, the following declarations are assumed.
<tables num="107"><img file="JP4394643B2_D0107.tif" /></tables>
(1) Search for relationships It is possible to search for source or target relationships. By using a filter, you can select a relationship that has a specified type and is given a property value. You can also use filters to select related item types or property values based on relationships. For example, you can perform the following search: All relationships from which a given item is the source
<tables num="108"><img file="JP4394643B2_D0108.tif" /></tables> All relationships where the given item is a source with a name that matches "A%"
<tables num="109"><img file="JP4394643B2_D0109.tif" /></tables> All FolderMember relationships from which the given item is the source
<tables num="110"><img file="JP4394643B2_D0110.tif" /></tables> All FolderMember relationships where the given item is the source and the name is something like "A%"
<tables num="111"><img file="JP4394643B2_D0111.tif" /></tables> All FolderMember relationships where the target item is Person
<tables num="112"><img file="JP4394643B2_D0112.tif" /></tables> All Folder Member relationships where the target item is a Person with the surname "Smith"
<tables num="113"><img file="JP4394643B2_D0113.tif" /></tables>
In addition to the GetSearcher API shown above, each related class supports the static FindAll, FindOne, and FindOnly APIs. In addition, the relation type can be specified when calling ItemContext.GetSearcher, ItemContext.FindAll, ItemContext.FindOne, or ItemContext.FindOnly.
(2) Navigate from relationships to source and target items After the related object is retrieved through the search, it is possible to "navigate" to the target or source item. The basic relation class has a SourceItem and TargetItem properties that return an Item object. The generated relationship class has equivalent strongly typed named properties (eg FolderMember.FolderItem and FolderMember.MemberItem). For example: Navigate to source and target items for relationships with the name "Foo"
<tables num="114"><img file="JP4394643B2_D0114.tif" /></tables> Navigate to the target item
<tables num="115"><img file="JP4394643B2_D0115.tif" /></tables>
Navigating to the target item works even if the target item is not in the domain in which the relationship was found. In such cases, the Storage Platform API opens a connection to the target domain as needed. The application can determine if a connection is required before retrieving the target item. Check target items in unconnected domains
<tables num="116"><img file="JP4394643B2_D0116.tif" /></tables>
(3) Navigate from source item to 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 done using the Item.Relationships collection property, such as Folder.MemberRelationships, or a strongly typed collection property. From the relationship, it is possible to navigate to the target item. Such navigation works even if the target item is not in the item domain associated with the source item's ItemContext, including if the target item is not in the same store as the target item. For example: Navigate to the relationship from source item to target item
<tables num="117"><img file="JP4394643B2_D0117.tif" /></tables> Navigate to Foldermember relationships from Folder items to target items
<tables num="118"><img file="JP4394643B2_D0118.tif" /></tables>
Items can have many relationships, so applications need to 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, and there are items where many relationships are rare enough, justifying the risk of misuse by developers. The application can check the number of relationships in the collection and use different programming models if needed. For example: Check the size of the relationship collection
<tables num="119"><img file="JP4394643B2_D0119.tif" /></tables>
The relationship collections mentioned above are "virtual" in the sense that the objects that represent each relationship are not actually embedded as initial values unless the application attempts to enumerate the collections. When collections are enumerated, the results reflect those added by the application but not yet saved, in addition to those in the store, but reflect relationships deleted by the application but not saved. do not do.
(4) Creating relationships (and items) 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 retention or embedding relationship. For example: Add a new item to an existing folder
<tables num="120"><img file="JP4394643B2_D0120.tif" /></tables> Add an existing item to an existing folder
<tables num="121"><img file="JP4394643B2_D0121.tif" /></tables> Add an existing item to a new folder
<tables num="122"><img file="JP4394643B2_D0122.tif" /></tables> Add a new item to a new folder
<tables num="123"><img file="JP4394643B2_D0123.tif" /></tables>
(5) Delete relationships (and items) Delete the retention relationship
<tables num="124"><img file="JP4394643B2_D0124.tif" /></tables>
8. "Extension" of Storage Platform API As mentioned above, the result of all storage platform schemas is a set of classes. These classes have standard methods such as Find *, as well as properties to get and set field values. These classes and associated methods form the basis of the Storage Platform API.
a) Domain behavior In addition to these standard methods, every schema has a set of domain-specific methods for it. These are called domain behaviors. For example, the following are examples of domain behaviors in the Contacts schema. Is your email address valid? -If a folder is given, get a collection of all members of that folder. -If an item ID is given, get the object that represents this item. -If a Person is given, get its online status. · Helper feature to create new or temporary contacts. Others.
It distinguishes between "standard" behaviors (such as Find *) and domain behaviors, but it's important to note that they simply appear as methods to the programmer. The distinction between these methods lies in the fact that domain behaviors are hard-coded, but standard behaviors are automatically generated from schema files by storage platform API design-time tools.
By their nature, those domain behaviors must be handmade. This creates the practical problem of having to put the entire class implementation in a single file in early versions of C #. Therefore, this forces the auto-generated class files to be edited in order to add domain behaviors. Naturally, this can be a problem.
A feature called subclasses was introduced in C # because of such problems. Basically, by using subclasses, a class implementation can span multiple files. Subclasses are the same as regular classes, except that the keyword partial precedes the declaration.
<tables num="125"><img file="JP4394643B2_D0125.tif" /></tables>
So domain behaviors for Person can be put in different files like this.
<tables num="126"><img file="JP4394643B2_D0126.tif" /></tables>
b) Value-added behavior Data classes with domain behaviors form the basis for application developers to build on. However, it is neither possible nor desirable for a data class to expose all possible behaviors related to that data. The storage platform allows developers to build on the basic functionality provided by the storage platform API. The basic pattern here is to create a class in which the method takes one or more of the storage platform data classes as parameters. For example, the value-added classes for sending email using Microsoft Outlook or using Microsoft Windows® Messenger can be:
<tables num="127"><img file="JP4394643B2_D0127.tif" /></tables>
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 on which you can query.
Registering a value class is a powerful feature, for example, when you right-click on a Person object in the Shell explorer, you can derive a set of allowed actions from the value class registered for the Person. Is possible.
c) Value-added behavior as a service provider In an embodiment of the invention, the storage platform API comprises a mechanism that allows the value-added class to be registered as a "service" for a given type. As a result, the application can set and acquire the service provider (= value-added class) of the given type. The value-added class that wants to use this mechanism should implement a well-known interface, for example:
<tables num="128"><img file="JP4394643B2_D0128.tif" /></tables>
All storage platform API data classes implement the ICachedServiceProvider interface. This interface extends the System.IServiceProvider interface as follows:
<tables num="129"><img file="JP4394643B2_D0129.tif" /></tables>
This interface allows an application to request a particular type of service provider in addition to setting up a service provider instance.
To support this interface, the storage platform data class maintains a type-keyed service provider hash table. When a service provider is requested, this implementation first looks in the hash table to see if a service provider of the specified type is configured. If not configured, use the registered service provider infrastructure to identify the specified type of service provider. An instance of this provider is then created, added to the hash table, and returned. Also note that it is possible for a shared method on a data class to request a service provider and forward operations to that provider. For example, it can also be used to provide a Send method on a mail message class that uses a user-specified email system.
9. Design time framework This section describes how the Schema of the storage platform is transformed into the Storage Platform API class on the client and the UDT class on the server according to the embodiments of the present invention. The figure in Figure 24 shows the components involved.
See Figure 24, the types in the schema are contained in the XML file (Box 1). This file also contains field-level and item-level constraints associated with the schema. Storage Platform Class Generator (xfs2cs. The exe-box 2) takes this file and generates a subclass for the store UDT (box 5) and a subclass 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), the client (box 6), and both locations (box 4). The codes in boxes 4, 6 and 7 are handwritten (not auto-generated). The subclasses in boxes 3, 4, and 6 together form the 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 obtained from all initial schema domains, boxes 3, 4, and. This 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 subclasses in boxes 4, 5, and 7 together form the complete class implementation of the server UDT class. Boxes 4, 5, and 7 are compiled (box 9) to form server-side UDT assembly-box 12 (actually, the server-side UDT assembly is obtained from all initial schema domains, boxes 4, 5, And 7 is the result of compiler-plus-ing). 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. Assembly-Forms Box 12 (actually, the server-side UDT assembly is the result of compiler-plus-ing of Boxes 4, 5, and 7 from all initial schema domains). 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. Assembly-Forms Box 12 (actually, the server-side UDT assembly is the result of compiler-plus-ing of Boxes 4, 5, and 7 from all initial schema domains). 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 the basics, the application pattern, when using the Storage Platform API, opens ItemContext, uses Find with filter conditions, retrieves the desired object, performs operations on the object, and stores changes. It is to send it back to. This section deals with the syntax of what goes into the filter string.
The filter string provided when finding a storage platform data object describes the conditions that a property of the object must meet in order to be returned. The syntax used in the Storage Platform API supports type conversion and relationship traversal.
a) Filter basics The filter string is an empty formula that indicates that all objects of the specified type will be returned, or that each returned object must satisfy. This expression refers to an object property. The storage platform API runtime knows how these property names are mapped to the storage platform type field names and ultimately to the SQL views held by the storage platform store.
Consider the following embodiment.
<tables num="130"><img file="JP4394643B2_D0130.tif" /></tables>
Nested object properties are also available in the filter. For example:
<tables num="131"><img file="JP4394643B2_D0131.tif" /></tables>
For collections, it is possible to filter members using the conditions in square brackets. For example:
<tables num="132"><img file="JP4394643B2_D0132.tif" /></tables>
The following example creates a list of all people born after 12/31/1999.
<tables num="133"><img file="JP4394643B2_D0133.tif" /></tables>
The first line creates a new ItemContext object that accesses "Work Contacts" on the local computer's storage platform share. On lines 3 and 4, a collection of Person objects whose Birthdate property specifies a date more recent than 12/31/1999, as specified by the expression "Birthdate> '12 / 31/1999'". get. The execution of this FindAll operation is shown in Figure 23.
b) Type Casts The type of the value stored in the property is often derived from the property declarative type. For example, the PersonalEAddresses property in Person contains a collection of types derived from EAddress, such as EmailAddress and TelephoneNumber. To filter based on the telephone area code, you need to convert from EAddress type to TelephoneNumber type.
<tables num="134"><img file="JP4394643B2_D0134.tif" /></tables>
c) Filter syntax The following describes the filter syntax supported by the storage platform API according to one embodiment.
<tables num="135"><img file="JP4394643B2_D0135.tif" /></tables>
11. Remoting a) Local / remote transparency in API Storage platform data access targets local storage platform instances. A local instance is used as a router when a query (or part of it) references remote data. As such, the API layer has local / remote transparency and there are no structural differences in the API between local and remote data access. This is purely a function of the requested scope.
The storage platform datastore also implements distributed queries, so it connects to an instance of the local storage platform and executes queries containing items from different volumes, one on the local store and the other on the remote store. It is possible to do. The store merges the results, which are presented to the application. From the perspective of the storage platform API (and therefore application developers), any remote access is completely seamless and transparent.
By using the Storage Platform API, on the application side, the given ItemContext object (as returned by the ItemContext.Open method) is either local or using the IsRemote property-which is a property on the ItemContext object. You can decide whether to represent a remote connection. In particular, applications may want to provide visual feedback to help set user expectations for performance, reliability, and so on.
b) Remoting storage platform implementation Storage platform datastores interact with each other using a special OLE DB provider that runs over HTTP (the default OLE DB provider uses TDS). In one embodiment, the distributed query is subject to the default OPENROWSET feature of the relational database engine. A special user-defined function (UDF), DoRemoteQuery (server, queryText), is provided to perform the actual remoting.
c) Access to non-storage platform stores In one embodiment of the storage platform of the present invention, there is no general purpose provider architecture that allows the store to participate in the data access of the storage platform. However, it does provide a limited provider architecture for certain cases of Microsoft Exchange and Microsoft Active Directory (AD). This means that developers can use the storage platform API to access data in AD and Exchange just as they are in the storage platform, but the accessible data is schematized in the storage platform. Means limited to type. Therefore, address books (= personal collections of storage platforms) are supported in AD, and email, calendars, and contacts are supported for Exchange.
d) Relationship with DFS The storage platform property promoter does not upgrade past mount points. Even if the namespaces are rich enough to be accessed through the mount points, the query will not go through them. Storage platform volumes can appear as leaf nodes in the DFS tree.
e) Relationship with GXA / Indigo Developers can use the Storage Platform API to publish a "GXA head" on top of a data store. Conceptually, this is no different than creating another web service. The Storage Platform API does not interact with the Storage Platform datastore using GXA. As mentioned above, the API uses TDS to interact with the local store, and any remoting is handled by the local store using the 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 give the developer the flexibility to ensure that the input data meets the constraints without incurring the overhead of round-trip communication to the server. This is essentially useful in interactive applications where the end user enters the data used to fill the object. The storage platform API implements this functionality.
Note that the storage platform Schema, which is used by the storage platform to generate the appropriate database objects that represent the schema, is specified in the XML file. It is also used by the design-time framework of the Storage Platform API to automatically generate classes.
Below is a partial listing of the XML file used to generate the Contacts schema.
<tables num="136"><img file="JP4394643B2_D0136.tif" /></tables>
The Check tag in the XML above specifies a constraint on the Person type. There can be multiple check tags. The above constraints are generally checked in the store. The XML is modified as follows to further specify that the constraints can be explicitly checked by the application.
<tables num="137"><img file="JP4394643B2_D0137.tif" /></tables>
Note the new "InApplication" attribute on the <Check> element that is set to true. As a result, the storage platform API reveals restrictions in the API through an instance method on the Person class called Validate (). The application can call this method on the object to verify that the data is valid and eliminate potentially useless interactions with the server. It returns a Boolean value that indicates the result of validation. Note that the value constraint applies to the server as is, regardless of whether the client calls the <object> .Validate () method. An example of using Validate is shown below.
<tables num="138"><img file="JP4394643B2_D0138.tif" /></tables>
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 ODBC is subject to the same data integrity constraints as data written from the Storage Platform API. Can you guarantee that? All constraints are checked on the store side, so the constraints are reliable. Regardless of what API path you use to reach the store, all writes to the store are filtered through constraint checking on the store.
13. Share Storage platform sharing
<tables num="139"><img file="JP4394643B2_D0139.tif" /></tables><DNS Name> is the DNS name of the machine, and <Context Service> is the contained folder, virtual folder, or item in the volume on the machine. For example, the machine "Johns_Desktop" has a volume called Johns_Information, which contains a folder called Contacts_Categories, which contains a folder called Work, which contains John's work contacts.
<tables num="140"><img file="JP4394643B2_D0140.tif" /></tables>Is included. This can be shared as "Work Contacts". In this share definition, \\ Johns_Desktop \ WorkContacts \ JaneSmith is a valid storage platform name and identifies the Person item JaneSmith.
a) Shared representation A shared item type has properties for a shared name and a shared target, which can be a non-retained link. For example, the name of the share mentioned above is WorkContacts and the target is Contacts_Categories \ Work on the volume Johns_Information. The Share type schema fragment is shown below.
<tables num="141"><img file="JP4394643B2_D0141.tif" /></tables>
b) Managing shares Sharing is an item, so sharing can be managed just like any other item. Shares can be created, deleted, and modified. Sharing is also secured like any other storage platform item.
c) Shared access The application accesses the remote storage platform share by passing the share name (eg \\ Johns_Desktop \ WorkContacts) to the storage platform API in the ItemContext.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 done 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 into Contacts_Categories \ Work and opens it. The query and other operations are then performed just like any other scope.
d) Discoverability In one embodiment, the application program is given <DNS as follows: You can discover the shares available on Name>. By the first method, the storage platform API accepts the DNS name (eg Johns_Desktop) as the scope parameter of the ItemContext.Open () method. The Storage Platform API then uses this DNS name as part of the connection string to connect to the Storage Platform Store. With this connection, the only thing the application can do is call ItemContext.FindAll (typeof (Share)). The storage platform service then merges all shares on all connected volumes and returns a collection of shares. The second method allows the administrator to specify on a local machine, on a specific volume by FindAll (typeof (Share)), or by FindAll (typeof (Share), Target (ShareDestination) .Id = folderId). Shares on folders can be easily found.
14. Meaning of Find The Find * method (whether called on an ItemContext object or on an individual item) generally applies to Items (including embedded items) in a given context. Nested elements do not have Find-cannot be searched independently of containing Items. This is consistent with the desired meaning in the storage platform data model, where nested elements derive their "identity" from contained items. To clarify this concept, examples of valid find operations and invalid find operations are shown below. a) Show all phone numbers in the system with area code 206? Disabled, because find is executed for the phone number-element-without referencing the item. b) Show all phone numbers in all Persons with area code 206? Even if invalid, Person (= item) is referenced, the search condition does not include that item. c) Show all phone numbers for all Murali (= 1 person) with area code 206? Valid, because there is a search condition for the Item (Person named "Murali").
The exception to this rule is for nested element types that are directly or indirectly derived from the Base.Relationship type. These types can be queried individually through related classes. Such queries can be supported because the storage platform implementation uses a "master link table" to store the Relationship element instead of embedding it inside 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 Figures 21A and 21B.
a) Overview of System.Storage.Contact The Storage Platform API contains namespaces for working with items and elements in the Contacts schema. This namespace is called System.Storage.Contact.
This schema has, for example, the following classes. -Item: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location -Elements: Profile, PostalAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupancy
b) Domain behavior Below is a list of domain behaviors in the Contacts schema. From a sufficiently high level, domain behaviors fall into the following well-recognized categories: · Static helpers, for example Person.CreatePersonalContact (), for creating new personal contacts, Instance helper, for example user.AutoLoginToAllProfiles (), which lets a user (an instance of the User class) log in to all profiles marked for autologin, -Category GUIDs, such as Category.Home, Category.Work, etc. Derived properties, such as emailAddress.Address ()-an instance of a derived collection, such as person.PersonalEmailAddresses-Person class, that returns a string that combines the username and domain fields of the given emailAddress (= instance of the EmailAddress class). If given, get that personal email address.
The table below summarizes the methods and categories to which they belong, by class in Contacts that has domain behaviors.
<tables num="142"><img file="JP4394643B2_D0142.tif" /></tables>
16. Storage Platform File API This section outlines the storage platform File API according to one aspect of the present invention.
a) Introduction (1) Reflection of NTFS volumes in the storage platform The storage platform provides a means of indexing 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 within the storage platform.
The storage platform File schema defines two item types-File and Directory-to store upgraded file system entities. The Directory type is a child type of the Folder type and is an containing folder that contains other Directory items or File items.
Directory items can contain Directory and File items, but not any other type of item. As far as the storage platform is concerned, Directory and File items are read-only from any of the data access APIs. The File System Promotion Manager (FSPM) service asynchronously upgrades changed properties within the storage platform. The properties of File and Directory items can be changed via the Win32 API. The Storage Platform API can be used to read the properties of File items, including the streams associated with them.
(2) Creating files and directories in the storage platform namespace When an NTFS volume is upgraded to a storage platform volume, all files and directories within it become a specific part of that volume. This area is read-only from a storage platform perspective, and FSPM can create new directories and files and / or modify the properties of existing items.
The rest of the namespace for this volume can contain a normal range of storage platform item types-Principal, Organization, Document, Folder, and so on. The storage platform can also create multiple files and directories as part of the storage platform namespace. These "native" Files and Directory have no counterparts on the NTFS file system side and are stored entirely within the storage platform. In addition, changes to properties appear immediately.
However, the programming model remains the same, which means that it is read-only as far as the storage platform data access API is concerned. "Native" Files 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, permissions prohibit it). 2. Storage platform item types can be loaded 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 the "upgraded" namespace may not appear immediately in the storage platform, but in the "non-upgraded" namespace, changes are immediate in the storage platform. It will be reflected.
b) File schema Figure 25 illustrates the schema on which the File API is based.
c) Overview of System.Storage.Files The Storage Platform API includes a namespace for working with file objects. This namespace is called System.Storage.Files. The data members of the System.Storage.Files class directly reflect the information stored in the storage platform store, which is either "upgraded" from a file system object or native using the Win32 API. Can be created in form. The System.Storage.Files namespace has two classes, FileItem and DirectoryItem. The members of these classes and their methods can be easily inferred by looking at the schema diagram in Figure 25. FileItem and DirectoryItem are read-only from the Storage Platform API. To fix them, you need to use the Win32 API or use the System.IO classes.
d) Code example This section provides three code examples that illustrate the use of classes within System.Storage.Files.
(1) Open the file and write This embodiment shows a "conventional" way of manipulating files.
<tables num="143"><img file="JP4394643B2_D0143.tif" /></tables>
The third line uses the FindByPath method to open the file. Line 7 indicates that the upgraded property IsReadOnly is used to check if the file is writable. If writable, use OpenWrite () on the FileItem object on line 9 to get the file stream.
(2) Use of queries The storage platform store holds properties that have been upgraded from the file system, making it easy to perform rich queries on files. In this example, a list of all files modified within the last 3 days is displayed.
<tables num="144"><img file="JP4394643B2_D0144.tif" /></tables>
Here's another example of using a query-it finds all writable files of a type (= extension).
<tables num="145"><img file="JP4394643B2_D0145.tif" /></tables>
e) Domain behavior In one embodiment, the file class has domain behaviors (handwriting coding properties and methods) in addition to the standard properties and methods. These behaviors are generally based on methods in the corresponding System.IO class.
J. Summary As illustrated so far, the present invention covers storage platforms 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, including structures such as relational (tabular) data, XML, and new data forms called Items. It is 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 graphical data. It provides a feature-rich, extensible application programming interface that not only makes available features specific to the data model, but also embraces and extends existing file systems and database access methods. It is understood that modifications can be made to the above embodiments without departing from the broader concepts of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed, and is intended to cover all modifications within the spirit and scope of the invention in accordance with the definitions of the appended claims.
As will be apparent from the above, all or part of the various systems, methods, and embodiments of the invention can be embodied in the form of program code (ie, instructions). This program code contains, but is not limited to, floppy (registered trademark) diskettes, CD-ROMs, CD-RWs, DVD-ROMs, DVD-RAMs, magnetic tapes, flash memories, hard disk drives, or other machine-readable storage media. It can be stored on a computer-readable medium such as a magnetic, electrical, or optical storage medium, including, and when the program code is loaded and executed into a machine such as a computer or server, the machine is for practicing the invention. It becomes a device. The present invention is further embodied in the form of program code transmitted on some transmission medium such as electrical or cabling, fiber optic use, 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 a device for carrying out the present invention. When implemented on a general-purpose processor, the program code, in combination with the processor, realizes a unique device that behaves similarly to a particular logic circuit.
Appendix A
<tables num="146"><img file="JP4394643B2_D0146.tif" /></tables> ItemContext creation and management member // The application cannot create ItemContext objects directly, nor can it derive classes from ItemContext. interal ItemContext (); // Create an ItemContext that can be used to search the specified path, or the default store on the local computer if no path is specified. public static ItemContext Open (); public static ItemContext Open (string path); public static ItemContext Open (params string [] paths); // Returns the specified path if the ItemContext was created. public string [] GetOpenPaths (); // Make a copy of this ItemContext. The copy has independent transaction, cache, and update states. The cache is initially empty. Using a cloned ItemContext is expected to be more efficient than opening a new ItemContext using the same (multiple) item domains. public ItemContext Clone (); // Close ItemContext. If you try to use ItemContext after it is closed, you will get an ObjectDisposedException. 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. Returns NULL if the requested service cannot be provided. The IServiceProvider pattern allows you to remove APIs from the ItemContext class that aren't normally used and can confuse developers if used. ItemContext can provide services IItemSerialization and IStoreObjectCache. public object GetService (Type serviceType); Update related members // Save all modified objects and the changes represented by all objects passed to MarkForCreate or MarkForDelete. An UpdateCollisionException may be thrown if an update conflict is detected. 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 Argument-Exception will be thrown. An UpdateCollisionException may be thrown if an update conflict is detected. 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. Throws an ArgumentException if anything other than an item, item extension, or related object is specified. public void Refresh (object objectToRefresh); public void Refresh (IEnumerable objectsToRefresh); // Occurs when an update detects that the data has changed in the store between the time the modified object was retrieved and the time it was attempted to save it. If no event handler is registered, the update throws an exception. If an event handler is registered, an exception can be thrown and the update can be interrupted 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 in 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 ReadCommited. In all cases, a distributed transaction is initiated because it may have to include a change stream typed item property. public Transaction BeginTransaction (); public Transaction Begin Transaction (System.Data.IsolationLevel isolationLevel); Search for related members // Create an ItemSearcher to search within this item context for an object of the specified type. Throws an ArgumentException if a type other than an item, relationship, or item extension is specified. public ItemSearcher GetSearcher (Type type); // Find the item given the id. public Item FindItemById (ItemId itemId); // Find the item given the path. The path may be an absolute path or a relative path. If it is a relative path, NotSupportedException will be thrown if multiple item domains are specified when the ItemContext is opened. Returns NULL if no such item exists. Create a connection to \\ machine \ share as part of the domain to retrieve the item. The item is associated with that 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. The item is associated with that domain. Returns NULL if no such item exists. 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 was opened. If no such item exists, it returns empty. public FindResult FindAllItemsByPath (string path); // Find the relationship given the id. public Relatioinship FindRelationshipById (ItemId itemID, RelationshipId relationshipId); // Find the item extension given the 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 ArgumentException will be 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 meets the given filter criteria. If a type other than these is specified, an ArgumentException will be thrown. If no such object is found, it returns NULL. 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 ArgumentException will be thrown. If no such object is found, throw an ObjectNotFoundException. Throws MultipleObjectsFoundException if multiple objects are not found. public object FindOnly (Type type, string filter); // Returns true if there is 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 ArgumentException will be thrown. public bool Exists (Type type, string filter); // Specifies how the objects returned by the search relate 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; // Include objects from other ItemContexts in this item context. If an object representing the same item, relationship, or item extension does not already exist, an identification map of this ItemContext, the object is cloned and added to the map. If the object exists, it will be updated with the state and contents of the object specified in a way that matches SearchCollisionMode. public Item IncorporateItem (Item item); public Relationship Incorporate Relationship (Relationship relationship); public ItemExtension IncorporateItemExtension (ItemExtension itemExtension); } // Handler for ItemContext.UpdateCollision and ItemSearcher.SearchCollision events. public delegate void ChangeCollisionEventHandler (object source, ChangeCollisionEventArgs args); // ChangeCollisionEventHandler Delegate argument. public class ChangeCollisionEventArgs: EventArgs { // Modified item, item extension, or related object. public object ModifiedObject {get;} // Properties from the store. public IDictionary StoredProperties {get;} } //ItemContext.UpdateProgress handler. public delegate void UpdateProgressEventHandler (ItemContext itemContext, UpdateProgressEventArgs args); // UpdateProgressEventHandler Delegate argument. public class ChangeCollisionEventArgs: EventArgs { // Current update operation. public UpdateOperation CurrentOperation {get;} // The object currently being updated. public object CurrentObject {get;} } // Specifies how the objects returned by the search relate to the object identification map held by the ItemContext. public enum SearchCollisionMode { // Indicates that a new object must be created and returned. Objects that represent the same item, item extension, or relationship in the identification map are ignored. If this option is specified, the SearchCollision event will not be fired. DoNotMapSearchResults, // Indicates that the object from the identification map must be returned. If the contents of the object are modified by the application, the modified contents of the object are saved. If the object has not been modified, its contents will be updated with the data returned by the search. Application can provide a handler for the SearchCollision event and selectively update the object as needed. PreserveModifiedObjects, // Indicates that the object from the identification map must 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. If this option is specified, the SearchCollision event will not be fired. OverwriteModifiedObjects } // Current update operation. public enum UpdateOperation { // Given when Update is first called. CurrentObject will be null. OverallUpdateStarting, // Given after a successful update, just before the Update returns. CurrentObject will be NULL. OverallUpdateCompletedSucessfully, // given just before Update throws an exception. CurrentObject is an exception object. OverallUpdateCompletedUnsuccessfully, // Given when the object update starts. CurrentObject refers to the object used for the update. ObjectUpdateStarting, // Given when a new connection is needed. CurrentObject will be a string containing the path that identifies the item domain as passed to ItemContext.Open. Open or retrieve from the relevant Location field. OpeningConnection } } Appendix B namespace System.Storage { // Perform a search for a particular type in the item context. public class ItemSearcher { constructor
<tables num="147"><img file="JP4394643B2_D0147.tif" /></tables> Property // A filter used to identify matching objects. public SearchExpressionCollection Filters {get;} // 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 works. For a simple search, this is the type of object returned. public Type TargetType {get; set;} Search method // Find an object of TargetType that meets 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 meets the conditions specified by Filters. // Returns NULL if no such object exists. public object FindOne (); public object FindOne (FindOptions findOptions); public object FindOne (params SortOption [] sortOptions); // Find an object of TargetType that meets the conditions specified by Filters. // Throw an ObjectNotFoundException if no such object is found. Throws MultipleObjectsFoundException if multiple objects are not found. public object FindOnly (); public object FindOnly (FindOptions findOptions); // Determine if there is an object of TargetType that meets the conditions specified by Filters. public bool Exists (); // Create an object that can be used to perform the same search repeatedly and efficiently. public PreparedFind PrepareFind ();
<tables num="148"><img file="JP4394643B2_D0148.tif" /></tables>
<tables num="149"><img file="JP4394643B2_D0149.tif" /></tables>
<tables num="150"><img file="JP4394643B2_D0150.tif" /></tables>
<tables num="151"><img file="JP4394643B2_D0151.tif" /></tables>
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;} // Returns whether FindResult contains an object. public bool HasResults {get;} // Returns whether FindResult is closed. public bool IsClosed {get;} // Returns the type of the item 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 enumerators on FindResult, not only all enumerators advance, but FindResult itself also advances. 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 for repeating on objects public interface IObjectReader: IEnumerable, IDisposable
<tables num="152"><img file="JP4394643B2_D0152.tif" /></tables>
<figref num="1">It is a block diagram which shows the computer system which can incorporate the plurality of aspects of this invention.</figref><figref num="2">It is a block diagram which illustrates a computer system divided into three component groups, a hardware component, a hardware / software interface system component, and an application program component.</figref><figref num="2A">FIG. 5 illustrates the traditional tree-based hierarchical structure of files grouped into multiple folders within a directory in a file-based operating system.</figref><figref num="3">It is a block diagram which illustrates the storage platform by this invention.</figref><figref num="4">It is a figure which illustrates the structural relationship between Item, Item Folders, and Categories in various embodiments of this invention.</figref><figref num="5A">It is a block diagram which illustrates the structure of Item.</figref><figref num="5B">FIG. 5 is a block diagram illustrating a composite property type of Item in FIG. 5A.</figref><figref num="5C">It is a block diagram exemplifying the "Location" Item in which the complex type is further described (explicitly listed).</figref><figref num="6A">It is a figure which exemplifies Item as a child type of Item in Base Schema.</figref><figref num="6B">It is a block diagram illustrating the child type Item of Figure 6A (in addition to the immediate property) where the inherited types are explicitly listed.</figref><figref num="7">It is a block diagram illustrating a Base Schema containing two top-level class types, an Item and a PropertyBase, and additional Base Schema types derived from it.</figref><figref num="8A">It is a block diagram which illustrates Item in Core Schema.</figref><figref num="8B">It is a block diagram which illustrates the property type in Core Schema.</figref><figref num="9">FIG. 5 is a block diagram illustrating an Item Folder, its member Item, and Relationships of interconnections between the Item Folder and its member Item.</figref><figref num="10">It is a block diagram exemplifying the Relationships of Category (again, Item itself), its member Item, and the interconnection between Category and its member Item.</figref><figref num="11">It is a figure which illustrates the reference type hierarchy of the data model of the storage platform by this invention.</figref><figref num="12">It is a figure which illustrates the method of classifying a relationship by one Embodiment of this invention.</figref><figref num="13">It is a figure which illustrates the notification mechanism by one Embodiment of this invention.</figref><figref num="14">It is a figure which shows the example which both transactions insert a new record in the same B-Tree.</figref><figref num="15">It is a figure which illustrates the data change detection process by one Embodiment of this invention.</figref><figref num="16">It is a figure which shows an exemplary directory tree.</figref><figref num="17">FIG. 5 illustrates an embodiment in which an existing folder in a directory-based file system is moved to a datastore on a storage platform by one aspect of the invention.</figref><figref num="18">It is a figure which shows the concept of Containment Folders by one aspect of this invention.</figref><figref num="19">It is a figure which illustrates the basic architecture of a storage platform API.</figref><figref num="20">It is a schematic diagram which shows various components of a storage platform API stack.</figref><figref num="21A">It is a relational diagram of an exemplary Contacts schema (Item and Elements).</figref><figref num="21B">It is a relational diagram of an exemplary Contacts schema (Item and Elements).</figref><figref num="22">It is a figure which shows the runtime framework of the storage platform API by one aspect of this invention.</figref><figref num="23">It is a figure which illustrates the execution of the FindAll operation by one Embodiment of this invention.</figref><figref num="24">It is a figure which illustrates the process of generating the storage platform API class from the Schema of the storage platform by one aspect of this invention.</figref><figref num="25">It is a figure which illustrates the schema based on the File API by another aspect of this invention.</figref><figref num="26">It is a figure which illustrates the access mask format used for the purpose of data security by one Embodiment of this invention.</figref><figref num="27">It is a figure which shows the security area which is cut out from the existing security area and is protected in exactly the same manner by one Embodiment of one aspect of this invention.</figref><figref num="28">It is a figure which illustrates the concept of the Item search view by one Embodiment of one aspect of this invention.</figref><figref num="29">It is a figure which illustrates the exemplary Item hierarchy by one Embodiment of this invention.</figref>
Every citation, both waysCites: the store holds 3 of 4
| Document | Relation | Office |
|---|---|---|
| JP07295816A | Cites | Japan |
| JP2002149425A | Cites | Japan |
| JP2002297433A | Cites | Japan |
| 飯塚 富雄,XMLデータストア完全ガイド,XML MAGAZINE,日本,株式会社翔泳社,2001年 4月 1日,第7巻 第6号,p.29-39 | Non-patent | – |
| Sean McCormick,Microsoft.NETプログラミング入門 Part IV .NET Programming Part IV,msdn magazine 2001 日本語版,日本,株式会社アスキー,2001年 6月18日,June No.15,p.69-80 | Non-patent | – |
78 members in 16 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 0326144 | United States of America | W | |
| 0326144 | United States of America | W | |
| 2003026144 | – | – | – |
| WO2003US26144 | – | – | – |
Members78
| Document | Office | Kind | |
|---|---|---|---|
| US2005049993A1 | United States of America | A1 | |
| US2005050053A1 | United States of America | A1 | |
| US2005050073A1 | United States of America | A1 | |
| AU2004271531A1 | Australia | A1 | |
| CA2506337A1 | Canada | A1 | |
| CA2815562A1 | Canada | A1 | |
| CA2815867A1 | Canada | A1 | |
| WO2005024550A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2005024626A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2005024666A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2005063083A1 | United States of America | A1 | |
| CA2533088A1 | Canada | A1 | |
| WO2005029313A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2003259959A1 | Australia | A1 | |
| AU2003259959A2 | Australia | A2 | |
| TW200513874A | Taiwan Province of China | A | |
| NO20052052D0 | Norway | D0 | |
| US2005125621A1 | United States of America | A1 | |
| NO20052052L | Norway | L | |
| WO2005024666A8 | World Intellectual Property Organization (WIPO) | A8 | |
| MXPA05006260A | Mexico | A | |
| EP1573508A1 | European Patent Office (EPO) | A1 | |
| WO2005024666A3 | World Intellectual Property Organization (WIPO) | A3 | |
| BRPI0406512A | Brazil | A | |
| EP1604310A2 | European Patent Office (EPO) | A2 | |
| RU2005119974A | Russian Federation | A | |
| EP1620781A2 | European Patent Office (EPO) | A2 | |
| CN1739093A | China | A | |
| EP1573508A4 | European Patent Office (EPO) | A4 | |
| MXPA06001986A | Mexico | A | |
| EP1658555A1 | European Patent Office (EPO) | A1 | |
| KR20060057524A | Republic of Korea | A | |
| KR20060080921A | Republic of Korea | A | |
| CN1820245A | China | A | |
| BR0318469A | Brazil | A | |
| KR20060113353A | Republic of Korea | A | |
| CN1871598A | China | A | |
| JP2007503049A | Japan | A | |
| JP2007503051A | Japan | A | |
| ZA200504391B | South Africa | B | |
| US2007088724A1 | United States of America | A1 | |
| US2007088725A1 | United States of America | A1 | |
| JP2007517268A | Japan | A | |
| JP2007521532A | Japan | A | |
| KR20070083241A | Republic of Korea | A | |
| WO2005024550A3 | World Intellectual Property Organization (WIPO) | A3 | |
| NZ540221A | New Zealand | A | |
| US7428546B2 | United States of America | B2 | |
| EP1620781A4 | European Patent Office (EPO) | A4 | |
| CN101416153A | China | A | |
| US7529811B2 | United States of America | B2 | |
| EP1658555A4 | European Patent Office (EPO) | A4 | |
| EP1604310A4 | European Patent Office (EPO) | A4 | |
| US7590643B2 | United States of America | B2 | |
| AU2004271531B2 | Australia | B2 | |
| CN100570549C | China | C | |
| JP4394643B2This record | Japan | B2 | |
| AU2003259959B2 | Australia | B2 | |
| US7693858B2 | United States of America | B2 | |
| CN1739093B | China | B | |
| CN101416153B | China | B | |
| JP4580390B2 | Japan | B2 | |
| JP4583375B2 | Japan | B2 | |
| IL168666A | Israel | A | |
| TWI337310B | Taiwan Province of China | B | |
| RU2412475C2 | Russian Federation | C2 | |
| KR101022936B1 | Republic of Korea | B1 | |
| KR101024730B1 | Republic of Korea | B1 | |
| US7917534B2 | United States of America | B2 | |
| KR101109399B1 | Republic of Korea | B1 | |
| JP4901472B2 | Japan | B2 | |
| US8166101B2 | United States of America | B2 | |
| US8238696B2 | United States of America | B2 | |
| CA2533088C | Canada | C | |
| CN1871598B | China | B | |
| CA2506337C | Canada | C | |
| CA2815562C | Canada | C | |
| CA2815867C | Canada | C |
17 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 4394643
- Publication, DOCDB
- 4394643
- Publication, EPODOC
- JP4394643B
- Application
- 2005509096
- Application, DOCDB
- 2005509096
- Application, EPODOC
- JP20050509096
Titles2
- Japanese
- アイテムベースのストレージプラットフォームにおけるデータモデリングのためのシステムおよび方法
- English
- Systems and methods for data modeling in item-based storage platforms
Classification
- CPC, 5
- G06F16/10
- G06F9/06
- G06F16/289
- G06F16/288
- G06F9/00
- IPC, 4
- G06F12 00
- G06F7 00
- G06F17 00
- G06F17 30